Silly SNAC's, part Duex

So, Jennifer over at security uncorked believes I went off a bit half-cocked on the silliness of Symantec's "Peer to Peer" NAC referred to in Tim Greene's Network World NAC Newsletter.  I have not had the opportunity to meet Jennifer, so hi, Jennifer.  Nice to meet you; thanks for the feedback.  One of the many things about which I'm uninformed is whether a blog debate such as this should take the form of different entries or simply replies off of the original entry.  I finally decided on the former. By the by, is there no dead-thread rule in the blog-o-sphere?

I digress.  Just so we're clear, my original post was not intended to be a critique of Symantec's overall approach to NAC, nor was it intended to imply that Symantec is somehow moving solely toward peer-to-peer NAC and away from infrastructure based NAC.  It was meant to be a critique of the peer-to-peer approach generally, and to point out that I'm having difficulty seeing the value pitch.  I stand by that original assessment, though in the spirit of digging for facts, I do have a barrage of questions below for Jennifer or anyone else to help answer.  Anyhow, here goes:

From Tim's Article:

With peer-to-peer NAC, groups of endpoints fitted out with Symantec’s NAC software can be restricted to talking only to other endpoints in their group and only of those endpoints meet NAC requirements.

Aside from being editorially challenged (I assume 'of' should be 'if'), this seems to imply that the endpoint must have Symantec's NAC Client (or Symantec's Endpoint Protection Client, or both) in order to carry out the enforcement of the centrally set policy.  No huge surprise, but worth stating for the record.  Now, this also implies that blocking communications while outside the bounds of the enterprise is possible (the primary point of peer-to-peer NAC, according to Jennifer), since the off-premise peers would clearly not be in the same "NAC group" as the governed endpoint.  However, a few paragraphs down, Tim says this:

The big limit of this feature is that it can apply only to machines that are managed and have the Symantec NAC client. So guest machines and those owned by consultants would not support this feature, and they would have to be isolated via other means.

The good news is that the confusion over which client you need is cleared up, which is good.  But if peer-to-peer NAC can't block incoming connections from guests within the enterprise walls who aren't in the governed endpoint's NAC group, how is it to block connections from endpoints outside the enterprise walls?  Tim's a smart guy, so it's hard for me to see his getting something this important this wrong.  It's even harder for me to see Symantec's not responding with a correction if he had gotten it wrong.

So, I'm left with the following questions:

If off-premise protection is the primary benefit to Symantec's peer-to-peer approach, why not pitch it that way to Tim?  Why bother even going into the within-the-walls scenarios in such a short article?

If peer-to-peer NAC can limit inbound connections from off-premise hosts, why not limit on-premise guest machines' access the same way as an additional layer of security?

What is the difference between the off-premise protection outlined in Jennifer's post and the functionality provided by any host-based firewall or intrusion prevention product out there?

Finally, what, exactly, do you really get with this approach?  Is it fine-grained control over the communications between and among enterprise clients operating within the walls of the enterprise and running Symantec's NAC software, as Tim's article implies?  Or is it governance and protection of clients when they are outside the walls of the enterprise, as Jennifer's rebuttal implies?  Or, as if by magic, is it both?

On balance, I still say it's the first one, and it's still a silly place to start.

Comments

[JJ (Jennifer Jabbusch)]

Hi Grant!
I think I can clear up the confusion... if I fail horribly I'm sure Patrick or Rich can straighten us both out.

The peer-based NAC (from what I understand) is a long-term vision with a variety of projected applications. The first step of which is to offer protection of managed endpoints (corporate assets) outside the confines of the brick and mortar or VPN.

With the mobile protection, the peer-based enforcement perhpaps doesn't so much stop those with the client, it *allows* connections from those with the client that meet the policies (set at corporate). So, for a guest/unmanaged endpoint, those connections can be denied (if that's the policy).

Personally I think this is the perfect place to start- at least- to start adding features. Do you offer protection of managed devices off the LAN? Probably not- no one really does.

As for inside the LAN, I think Symantec has a vision for peer-based NAC on the LAN as well. I'm not sure I would buy into that strategy, but I'm interested to see where they go with that...

-jj

[Mathew]

Sigh. This is silly because Symantec's NAC product supports a wide variety of deployment options, only one of which is client-only. So lambasting an entire product set because you don't like just one of the ways it can be deployed seems like wilful ignorance (I could not get to the Tim Greene article myself -- the page took an age to load and then some script running on the page greyed it out... I gave up)

If you want to block unauthorized users using Symantec NAC, then deploy their NAC enforcer and use either DHCP, VLAN, or 802.11x network-based enforcement. Symantec supports all of them. They can also use the Cisco NAC protocol too, though I have not used that.

In the DHCP case, the Symantec SNAC enforcer proxies DHCP requests and allocates addresses based on the endpoint's security status. So you can allocate guests IP addresses from one pool, out-of-policy endpoints IP addresses from a remediation address space, compliant endpoints a regular IP address etc.

The VLAN variant works in similar fashion but communicates with the switch to tell it which VLAN to put the endpoint into based on its security status.

Any of these approaches stops foreign or rogue endpoints from getting unauthorized access.

[Grant Hartline]

Hi Jennifer. Thanks for the clarification, but I think we may just need to agree to disagree.

To me, the functionality that you're describing is more the Endpoint Protection agent than the peer-to-peer piece. BTW, you're right that we don't offer protection outside the walls given our strategic decision not to go down the persistent agent path. However, I'm certain that McAfee, Novell and Sohpos to name a few would be quick to point out that they do indeed offer protection outside enterprise walls. Indeed, I would expect off-LAN protection to be part and parcel of any solution that requires a persistent agent. Not to mention HIPS and host-based firewall packages that have all-the-time endpoint protection as their mission.

Anyhow, I will say that if you're right, Symantec definitely missed the boat by not posting a correction to Tim's assertion that the "big limit" of peer-to-peer NAC is that it won't limit connections from guest machines. That's OK with me, of course; so come to think of it, I hope you're right.

[Grant Hartline]

Hi Matthew

From my original post:

Just so we're clear, my original post was not intended to be a critique of Symantec's overall approach to NAC, nor was it intended to imply that Symantec is somehow moving solely toward peer-to-peer NAC and away from infrastructure based NAC.

I appreciate your insight, and I am generally open to all comments on this blog (no registration, no pre-approval, etc.); but I do prefer that people read the posts before commenting.

[alan shimel]

Grant- first of all on blog etiquette, I think commenting on another's blog post is fine and if you are going to do a full post on yours, you should use a trackback. But a no-no is commenting and tracking back ;-)

On the substance of what you are saying I agree with you. I think the Symantec peer-to-peer stuff is a bit out there from the NAC mainstream. Of course it is not to far removed from the InfoExpress DNAC (dynamic NAC) concept. Much of the functionality JJ is talking about is actually more of a location aware personal firewall. Not NAC per se, but good security nevertheless. I think you need elements of all this to make for a good layered security model.
It will be interesting to see where Symantec goes with this one. On another note, sometimes I find Tim just reports on what a vendor tells him and takes it at face value without digging in or getting another opinion.

[pruti]

You must take care about security of your computer. There is much risk in the internet. Therefore you must install some a spyware program. As for me, I recommend http://file.sh/trojan+guarder+gold+torrent.html