While I agree with some of what Mike Fratto says in his Dark Reading article, "The Limits Of Access Control In NAC", I don't agree that Network Access Control can't add value to application access control, and that application security has to be entirely taken care of by the application logic. In fact one of the major issues in Enterprise security today is exactly that network and application access control are treated as mutually exclusive with separate islands of policy. The real issue is that you have to have the right kind of NAC solution to provide any real value. At the application layer, policy is easy, but control is hard. The opposite is true at the network layer. Control is easy, but policy is complex and hard. What is needed is a unifying technology that takes application layer policy and enforces it at the network layer.
To do that, you have to have a solution that sits in line (real time processing is critical), is able to recognize applications, do deep packet inspection and IPS, apply network and application policy and control decisions in real time, pull identity based policy from existing application layer policy stores (e.g. identity management systems), and not affect latency or throughput of the LAN. A very tall order, but that technology and solution exists and it's called the Nevis LANenforcer. A network layer policy enforcement device that provides application aware network access control and persistent threat detection. I agree you still need the application logic to do a job (security in depth), but now there is a way to tie the application and network layers together with a single policy model and robust enforcement strategy.
I also agree that the type of solution that StillSecure and others of that ilk provide is woefully inadequate to do anything much more than be a crude gatekeeper at the network layer. They don't have any level of application layer intelligence or real-time logic to make accurate and meaningful application layer security decisions, and Alan Shimel would have you believe that using VLANs to provide granular differentiated access is the way to avoid draconian black and white quarantine decisions. I'm afraid I'll have to call BS on that one. Every user is different and has different needs, but most are not malicious intentionally, so should we limit access whenever someone's endpoint has a vulnerability or it is infected with malware? Wouldn't it be better to just ensure that vulnerability is not exploited or stop the malware affecting any other resource? In other words, drop the bad traffic and let the good stuff through, making the experience completely transparent to the end user. Once you start doing policy control enforcement with VLANs, AAA and switch ACLs, you've either massively increased complexity and cost (and therefore compromised security), or you've had to compromise on the granularity of that control to save costs (and therefore compromised security). Dynamic, identity-based firewall rules for each and every user, with application intelligence is the only way to get simple granular control, and pulling the policy from existing application layers policy stores prevents skyrocketing costs. Remember we're living in a world of increasing virtulization now, if your network policy enforcement device doesn't have application visibility and intelligence in real time, how are you ever going to make meaningful security decisions?
//Dom



Dom: Perfect. Right on. This is great:
"a solution that sits in line (real time processing is critical), is able to recognize applications, do deep packet inspection and IPS, apply network and application policy and control decisions in real time, pull identity based policy from existing application layer policy stores (e.g. identity management systems), and not affect latency or throughput of the LAN."
I have to be on your side on this one!
-Stiennon
Posted by: Stiennon | August 07, 2007 at 02:56 PM