Applications vs Application Level

In a recent blog, I said that "NAC fails to reach into the application layer and frankly, it shouldn't" and I want to clarify that statement because in response to that blog both Michelle McLean from Consentry and Dominic Wilde from Nevis Networks are describing application level (as in the OSI model) control, not application access control. The difference is application level controls states that a user "may access this web server or that network service" while application access control states that a user "can modify this form/field in this application." The former is well suited for NAC controls, the latter is not. Each type of control has its place in the world and my saying this or that technology has limits doesn't mean I think the technology is bad or ineffective. It just means that limits are a reality that needs to be understood and that NAC isn't always the most effective solution to an access control problem

Web applications are particularly complex and common, so I am going to use one as an example, but my comments apply to any complex network application regardless of transport, such as Oracle's SQL*Net, Let's say you have an ERP application. There will be many users with different access rights to the application governing what a particular user or group can access and how they can modify data. Those access controls should be defined and enforced within the application logic itself, not in some external system, because within the application lies the context for the access control decision. In any sufficiently complex system, there are many paths to the same information and a user who doesn't have access to, say, an employee's records, should be denied access no matter how they attempt arrive at it. If an outside system, say a NAC appliance had the context to make application access control decisions, then you have just recreated the very business logic in the NAC appliance that should be in the application. Yuck.

Context is the very problem that web access control products have when working with web applications. The first step is for the web access control product to understand the structure of the web application. That means knowing the queries and expected responses for the entire web application. Then you have to define which users and groups have what kind of access to the web application. That makes up your policy. Then the web access control policy can be applied. However, any changes to the web application may require changing your web access control policy because the application logic may have changed. That puts web access control in lockstep with application development. Even web application firewalls that claim to enforce strict policies have to learn a web application such what are the acceptable characters in a form field, before it can enforce a policy, and then re-learn the web application when the application changes. Web application access control outside of the web application is incredibly complex and difficult to get right. For that much effort, shouldn't it just be done in the web application in the first place?

Granted, some functions like SSL offload, protocol conformance, application proxies, and XML schema validation are easily handled in the network because in many cases the protocols and formats are standardized and well understood. HTTP, for example, is a well known protocol that defines required fields, acceptable characters, and other attributes of the protocol which can all be validated by network devices. An XML file can be compared to it's Data Type Definition to see if the file is well formed. I will even grant that some application level intrusion detection like cross site scripting, SQL injection, and the like may be detected via network devices, but I wouldn't bet the farm on it.

Tying in knowledge about a user, a host's condition, a host's behavior on the network, and any anomalous or malicious events from that host, maybe a powerful tool to accurately detect and react to malicious hosts. But it's not the end-all and be-all of access control.