The limits of access control in NAC

Alan Shimel, in his July 30th blog Is quantine black and white or is there access control in NAC?, takes Kurt Roemer from Citrix to task for Roemer???s portrayal of NAC as black and white access control. I agree with Shimel that access control doesn't have to be black and white, but I do have to agree with Roemer that NAC is about network access control and shouldn???t be confused with application access control. Your security policy should be concerned ultimately with controlling access to data regardless of where it resides. If you could wave a magic wand, your policy would allow users access to only the data and resources they need to do their jobs and nothing more. Part of that policy is expressed in the network access control and part of the policy is expressed in application access control. Black and white policy decisions, like Roemer expresses, may work, but you absolutely need to have a rock solid process for quickly dealing with exceptions. When security butts heads with revenue generation, security often losses.

NAC determines if you have access to a server or resource on the network and that is one layer of protection. If you don???t have the permission to reach a web server because, for example, you didn???t authenticate or your computer is out of policy compliance, then you can???t attack that web server. If you are authorized to reach a web server, then NAC will let you go, but now are free to exploit application logic. Some application attacks may be detected by an IDS/IPS, but I wouldn???t count on it.

Application access control determines if you can access some part of an application and what you can do when you are there. Application access control should be built into the application logic, but third party web application security products like CA???s SiteMinder or Entrust???s GetAccess, can add strong user access control to existing web applications.

Most NAC products don???t even touch application level attacks that exploit application logic like SQL injection, forceful browsing, cross site scripting, and protocol attacks. If we think about network attack vectors for a moment, there is a clear distinction between the types of attacks NAC can, and can not, defend against. Attacks against server software and operating systems, denial of service attacks, spoofing network traffic, man-in-the-middle attacks, unauthorized servers, covert channels, and encrypted tunnels, when launched by a malicious host that has attached to your network, can be stopped by NAC systems from even starting if, and only if, the NAC policy doesn't allow that actvity and your NAC product can regulate activity. If your NAC product only supports a grant/deny access enforcement, and let's face it many NAC products only control access that far, then access to the network means open access.

NAC fails to reach into the application layer and frankly, it shouldn???t. I have never been a proponent of strong application security in the network because network devices like NAC, IDS/IPS, firewalls, network anomaly detection systems, generally don???t have the context to recognize and enforce application access control. You need policies and solutions (meaning products or development for existing products) that target security functions. NAC is good for the network, but that's only part of the solution.