Network Access Control Technologies and Symantec Compliance on Contact
NAC solutions require multiple enforcement methods and policy flexibility to cover the entire enterprise network. As an innovator in NAC solutions, Symantec provides the most comprehensive and flexible set of options for deploying NAC to best fit your enterprise needs. Read this paper to learn more about the theory behind Symantec’s technology.
Click here to download PDF

The Essential Elements of Comprehensive Endpoint Security
Description: For today’s computing environments, there is little question that endpoint security is a required component of an overall enterprise security strategy. Read this paper is to clarify the various aspects of the endpoint security problem and to identify the functional requirements of a comprehensive endpoint security solution.
Click here to download PDF

Internet Security Threat Report
The Highlights of this volume reveals the security threat environment continues to be populated by lower-profile, targeted attacks as cyber criminals identify new ways to steal information or provide remote access to user systems. This report offers analysis and discussion of threat activity, including: Internet attacks, vulnerabilities, malicious code, phishing, spam, security risks, and future trends.
Click here to download PDF

NAC - Combining the health-check with resource access control 

Richard Stiennon is slamming NAC again in his article over at NetworkWorld. In it, he again talks negatively about NAC as he sees it now (health-checking and quarantining). Here is where I started turning red. I have heard Richard's arguments time and time again, and it has almost always been "we need to do this and stay away from this", saying that if we combine this technology with this other one, we would have it.  So I have often graded his blogs and articles on NAC as no more than what he calls them in his post: "...rants on that topic." There's nothing wrong with a well-placed rant, but I think it should be backed up with a clear cut strategy as well.

But as I went further into the post, I noticed his mention of Enterasys and how they were pushing the "user-defined network" five years ago. When he mentioned that, I remembered taking three weeks worth of Enterasys classes about 4 years ago when the VAR I was working for signed a partnership deal with Enterasys. And I remembered being TOTALLY amazed at this new way of thinking about access control. With a RADIUS server and a switch (and some pretty difficult administration tasks), we were logging into the lab network and only getting access to the resources we were supposed to see, all at the same time being on the same IP segment. This was a completely different way of thinking, and I was simply amazed. This was going to be a boon for security access control.

So what happened to this path? Why did the original idea move to another path? Well, it sort of did and didn't at the same time. What the vendors did was simply start controlling access via health checks instead of credentials (Richard blames this on Cisco, with some good reason). So you get access to resources depending on whether or not you meet certain standards (no viruses, current patches, current signatures, etc.) rather than your login. This was not a total diversion from the path as much as it was a different way of walking down the same path.

Now hopping on one leg down a path holds more dangers than simply walking down a path. You could fall and hurt yourself by hopping. But walking also holds dangers. What in the world does that mean? It means that both ways have their benefits, and both ways have their pitfalls. I would prefer to see a combination of both means of access control (just as Alan Shimel points out here).  Richard's ideas are good, but he proposes only blocking the bad behavior, not cleaning the host that is infected. If he has amended this point in a subsequent post, I apologize, but I simply do not get NOT cleaning the endpoint. If you can do so without blocking access to the network, well and good. That would be extremely difficult to do in my opinion, and I think most would agree with that. But if it can be done, I am all for it. But I still think the endpoint needs to be cleaned.

Also, how do you know if you are blocking all bad traffic? Richard suggests using NetFlow data to baseline your network behavior and block traffic that deviates from that baseline. But is that completely reliable? And how can you baseline in a small (and sometimes large) organization with psycho-execs running around asking for new apps installed and access to every website in the world? It sounds like a pipe-dream to me, Richard. No offense, but that is one of the reasons I got out of security ops and management. Those people were driving me nuts, and I could not control them at all to protect the network. I just don't see this working without combining the other side of the equation, namely cleaning the endpoint.

So, you can try to block the bad stuff without cleaning the endpoint, but it doesn't make sense. That laptop is still going to contribute to the total insecurity of the Internet if it remains unpatched and infected because that it is still going to be lugged into hotels, homes, etc. that don't have much security (if any). But just as well, you should be able to clean the endpoint without having 8000 helpdesk calls from users (and the one call from the CEO that trumps the 8000 calls) saying they can't get into the network and have some screen that says they need to download some patch, or sig-something (another reason for integrating remediation into NAC).  It needs to be clean, and it needs to be effective, and it needs to be efficient.

Another pipe dream?  Maybe so.

Back to top

Click here to submit a story for consideration by Cram Session Editor, stories@cramsessionnac.com