I Want to Know Who You Are!

Blogger: Eric Maiwald

We are in the final stages of analyzing the results of our research into network security architecture and one of the things that jumped out of the research was a huge desire and need to know who and what is connecting to the enterprise networks. The need to identify users and machines is a major driver for network admission and access control. For the most part, the decision was binary – I know you or I don’t; I recognize the machine as one of ours or I don’t. This decision applied equally across wired, wireless, and remote access networks.

User and machine identity is used to determine access to resources but more importantly, it also determines how you are allowed to access the resources. For example, if the user is recognized but the machine is not, the user might be redirected to a terminal server environment (if access is granted at all).

But there is more to it than simply knowing who is connecting to the network. There is a desire to hold users accountable for their actions. One of the interviewees put it very clearly, “I don’t just want to know which IP address or machine performed this bad thing, I want to know which user did this.” Based on the research results, we can take things a step further and say that holding the users accountable for their actions once on the network is becoming as important as preventative controls. It seems that this change comes from cultural issues that show security (and more generally IT as a whole) cannot be an impediment to business.

Along the same lines we found most organizations are thinking of NAC as using user and machine identity to control access. While there was some discussion about health checking the end point, this appears to be more of a future wish list item. We found problems with health checking at the time of admission to the network, but the real issue was what to do if you found a non-compliant end point. If security and IT cannot be an impediment to business, then a non-compliant end point may not be sufficient reason to deny the user access to the network (assuming that the end point belongs to the enterprise of course). This is especially true if the remediation of the non-compliant issue is not quick, easy, or invisible to the user.

We have more analysis to perform on our data. The results of the research will be presented in June at Catalyst North America in San Diego. Look for more blog entries and content based on this research in the future.

Comments

[An IT-Manager]

I wonder if there are any who are going the reverse approach... i.e. "I am going to consider my company's network to be untrusted and harden access control at the resource level" - secure the backend resources rather than every edge/end-points. What if everthing in our networks was available in the DMZ - this is a possible appraoch we have been thinking about as more and more thing move into DMZ - then it doesn't matter if you are connected to a guest network or anywhere on the Internet - this becomes interesting combined with the statement "should IT be managing laptops or letting user procure/manage their own laptops"

[Eric Maiwald]

The comment from "An IT-Manager" asks a good question. During the network security architecture research we did find a number of organizations that were putting more focus on resource level controls. The focus generally was to add granularity to access control decisions at the application level.

We did not find a general trend of moving to an untrusted network. We did find a small number of organizations that were thinking along those lines for the future, however. One problem that comes up with this idea is that sensitive information may still move to the end point. If the end point is compromised or not under the organization's control, protecting the information becomes much more difficult. The road tends to lead toward some type of digital rights management or enterprise rights management system. Another alternative is to prevent sensitive information from moving to the end point. We did find many cases where terminal servers were used for remote access - especially in cases where remote access was allowed from non-organization end points.