Security and Risk Management Strategies Blog

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.

Trust, NAC, and the Art of Ceasing Operations

Blogger: Eric Maiwald

In the security world, we talk a lot about trust – the assured reliance on character, ability, or strength of someone or something (according to Webster). We place confidence in products, mechanisms, processes, companies, and people to act in a particular way. The trust that we have in something or someone directly affects how we view the risks associated with various activities.

Our trust may be based on any number of things – who the person is, their reputation, testing done on a product or mechanism, etc. In the network world, knowing who is coming on to the network seems to be an important consideration. The Security and Risk Management Strategies Service (SRMS) at Burton is working on a project to learn how the network fits into an overall enterprise security architecture. This project seeks to learn whether enterprises are currently using or planning to deploy an overlay style of architecture, and whether defenses are being shifted to the endpoints, application systems, information systems, and data centers. It will also challenge the messaging that vendors use to justify their NAC products and their strategy for building security intelligence into networks by tracking recent customer experience with NAC projects and gain an understanding of how network security architecture is evolving in enterprise customer networks. So far in our research, the idea of placing a control to limit the access of unknown people or clients to the network is appearing regularly. It appears that enterprises have a desire (and sometimes a need) to at least find out who is connecting to the network. Maybe that is the basis for identifying how far the enterprise will trust the individual or the client system and maybe that trust forms the basis for a perceived risk.

If there is a need to know who is coming on to my network, does that imply that NAC (network admission or access control) is important? (In a previous blog entry, I talked about the confusion in the NAC market and what NAC actually is) Well, at least identity seems to be important. Enterprises are using the identity of individuals and client systems to make decisions on entry to the network and access to resources once on the network. Other preliminary indications in our research show that the configuration and status of the client system are less important than whether the client system belongs to the enterprise or not and whether the individual is an employee or not. So maybe it is that some type of control over the network is important.

The failure of Lockdown Networks this past week is seen by some as an indication that NAC has failed. I think that goes too far. Our research indicates that some type of control over who enters or connects to the network is important to enterprises. However, trust has another part to play in the success of vendors who offer this type of control. Customers have to have confidence that the vendor can provide the product as advertised and that the vendor will do well enough to provide the necessary support for the product over the long haul. It seems that Lockdown did not inspire the necessary confidence in the market. Perhaps Lockdown offered a product that didn’t fit into what the enterprise customers were looking for or perhaps Lockdown’s financial future was sufficient secure for enterprise customers to take a change on a small vendor.

We will be finalizing our research and presenting the findings from our network architecture research at Catalyst North America in San Diego. Come join us there in June!

What is NAC?

Blogger: Eric Maiwald

Admission or access? Products, product category, or what? Why is there so much buzz about NAC? Should I be looking for a NAC under the Christmas tree this year? Is it something that should be part of my New Year’s resolutions – “I will NAC this year!” Or maybe “I will buy a NAC!” Or perhaps “I will install a NAC!” You get the idea…

The acronym has three components:

• Network – There is a debate as to how much of this type of mechanism belongs in the network. It might be that these mechanisms belong on the end points.

• Access or Admission – You can take your choice here. Admission implies a mechanism to limit end points as they come on to the network while Access implies a mechanism to limit how the end points can use the network and connect to resources.
• Control – Control is the word most overlooked. Webster defines control as “verb: to check, test, or verify by evidence or experiment, to exercise restraining or directing influence over.” As a noun it is defined as “power or authority to guide or manage."

So we are talking about exercising influence or management over who can access to resources either by limiting connections to the network or by limiting the traffic as it is directed to the resources. So NAC is really another control that an enterprise can use to enforce a policy and better manage their resources.

Don’t we do that already? Just look at the IT environment. We have authentication mechanisms, vulnerability scanners, patch management systems, firewalls, intrusion detection and prevention devices, content filters, VPNs, and the list goes on. Aren’t these mechanisms implementing a policy regarding access to resources? It sure seems like they are.

Maybe I just don’t understand the secret sauce that is found in the “NAC products.” Alright, let’s take a look at them:

Some NAC products sit on the network (either in-line or out of band) and watch the traffic. They make decisions on what traffic should pass and what traffic should be blocked. The NAC product might block traffic or it might communicate with a switch that kicks the offending end point off the network. Doesn’t this sound like a firewall, IDS, or IPS? I have a policy about what traffic is allowed on my network and I am going to control it by placing some device within the network.

Some NAC products watch for an end point to come on to the network. They check the policy on the end point (patch level, virus signature level, configuration, etc.) before making a decision to allow the end point to connect or not. This sounds like a great way to perform vulnerability management (assuming that you have a good remediation mechanism! I would hate to have to explain to my CEO why he couldn’t check his email for a few days.). I have a policy that says that an end point can’t connect to my network unless it conforms to some configuration standard and I am going to control it by verifying the configuration of the end point before I activate the switch port or provide the network address or allow it through my VPN.

I think enforcing policies like these makes a lot of sense. We already know that better management of the end points helps to limit compromises of sensitive information and outbreaks of malicious software. When it comes down to it, better management helps us control lots of bad things. Maybe NAC is really all about better management.

What do you think? Have you seen similar views in other places? Post your comments, views, or links in the comment section.

Burton Group will be examining the whole NAC issue in greater depth in 2008.

The NAC Fog Begins to Clear

Bloggers: Phil Schacter and Dan Blum

Several years ago Cisco announced an initiative to deliver a framework for network admission control using the Cisco Trust Agent client software, 802.1x-enabled Ethernet switches and a Cisco policy server. On the surface Cisco’s NAC offered the promise of network enforcement of endpoint security policies to reduce the risk of vulnerable desktop and laptop systems introducing malware to the enterprise network.

But gradually the industry discovered Cisco’s NAC framework had too many moving parts and adoption lagged. Customers were also reluctant to replace existing routers and switches with Cisco NAC-capable ones.

At the same time as Cisco promoted its framework, Microsoft promoted its own Network Access Protection (NAP) initiative. NAP comprised APIs and endpoint functionality with Windows Vista, and various policy decision points that would run on the Longhorn server. However, the proprietary NAP protocols between the endpoint client and the policy server were firmly closed.

The problems with the Cisco and Microsoft frameworks left NAC in a fog. The Trusted Computing Group (TCG) did promote an open Trusted Network Computing (TNC) initiative, but had few takers on the market, save for Juniper. A number of other proprietary NAC products came available from vendors such as Symantec and McAfee. Hedging its bets and trying to accelerate customer investments in network security, even Cisco began selling a different NAC solution based on its Perfigo acquisition.

But the industry still lacked a standard. In late 2006, Microsoft and Cisco announced an agreement by which NAC and NAP could interoperate, but this solution would require customers to operate duplicate policy systems – Cisco’s Secure ACS and Microsoft’s Network Policy Server (NPS). Hardly an ideal interoperability scenario, and still more moving parts to maintain and operate.

Finally, this week at Interop the fog cleared. Microsoft and the Trusted Computing Group announced interoperability between NAP and Trusted Network Connect (TNC). While Microsoft, as one of the founding members of the TCG, had previously committed to “harmonize” NAP with the work on TNC, the nature of this week’s announcement went much further than anticipated. Microsoft contributed its protocol for communicating system health information to TNC, which dubbed it IF-TNCCS-SOH.

Unpronounceable or not, IF-TNCCS-SOH looks like a win for the industry. Let’s call it the Statement of Health (SOH) protocol for short. SOH makes it possible for a true plug-and-play market to develop with any agent able to communicate with any policy server. Microsoft effectively allows established vendors with NAC appliances to displace NPS as the policy server for NAP, and it is possible for protection software on Windows and non-Windows endpoints to speak SOH as well. But at the same time, the long lineup of vendors already writing to Microsoft’s APIs virtually assures the dominance of NAP as the client architecture for NAC on Windows systems. At Interop, Microsoft and Juniper will demonstrate an early implementation involving Juniper’s Unified Access Control (UAC) product, which is also a TNC server.

Microsoft’s NAP is already shipping in every copy of Windows Vista and will be included in a Service Pack for Windows XP. As soon as Juniper and other third party NAC appliance vendors are able to provide customers with upgrades to support the SOH protocol, customers can begin their NAP deployments without having to be dependent on Microsoft’s Longhorn ship timetable. There will certainly be solutions in the market before the end of 2007, with most vendors in the NAC market having products to support NAP endpoints by mid-2008.

This week’s announcements go a long way to providing a de facto standard for factoring system health information into access control decisions. Rather than every NAC vendor having to create their own agent software, it is expected that endpoint security vendors will produce the System Health Assessment (SHA) modules that NAP requires, and that these modules will work with any NAC appliance and its policy infrastructure. At some point it is likely that the TNC effort and early stage work underway by IETF’s Network Endpoint Assessment group will converge, resulting in a de jure standard. The establishment of such standards reduces customer risk in deploying products, and enables co-existence between products from established network infrastructure and security vendors, and new entrants with innovative offerings.

Cisco is not a member of TCG and has distanced itself from the work on TNC, preferring to work through the IETF while advancing its own initiatives and product offerings. However, the new TNC-Microsoft protocol provides Cisco with an opportunity to shed the residual client aspects of its largely unsuccessful framework. It is also a competitive opportunity for Cisco to succeed in providing the policy infrastructure for customer networks dominated by Windows endpoints. One fallout of the new protocol is that it largely makes the Cisco NAC interoperability solution with Microsoft NAP irrelevant. All Cisco has to do is implement support for SOH in their NAC (CleanAccess) appliance. The only problem that Cisco and other NAC vendors face in the market is what to do with their client agent software. Their choices are to re-instrument and provide a SHA to plug into NAP on Windows clients, and then accept messages generated by NAP in their backend appliances; or to withdraw from the agent market once sufficient endpoint security vendors deliver their native support for SHA and the NAP Windows architecture.

The bottom line here is that we’re closer to a true NAC standard than anytime in the past six years, and this is good news for anyone interested in investing in NAC as part of an anti-malware strategy.