NAC access control: A multi-dimensional puzzle

To understand how access control is done in NAC products, you have to look along three dimensions: where access controls are enforced, how access control is communicated, and the granularity of access control.

But first you need to decide if you want to enforce access control at all. There are two reasons why you might not want to.

One, actual enforcement may not be a goal. For example, if you just want to know your level of compliance with end-point security policies, NAC can help you detect and report on that, even if you don't want to kick someone off the network for being out of compliance.

You may think you have compliance already covered because, in theory, the end-point security products running on your desktops and laptops already do this when hooked back to the central management console.

NAC: What went wrong?

But because NAC actually checks the compliance of everyone who wants to connect to the network, the reality is that you can find systems using NAC that the enterprise consoles don't know about.

The second reason not to enforce NAC is if your plans call for an initial "report-only" phase, prior to moving to enforcement. All the products we tested will let you operate in "report-only" mode.

In the products we tested, enforcement is not a big red switch that you flip. Instead, there's usually the option to not send enforcement instructions into the network, which may take a little digging to find.

Of course, depending on the type of NAC deployment you have, even "non-enforcing" NAC may be intrusive to network operations. For example, if you are planning on using 802.1X for authentication and enforcement, you have to get the basics of 802.1X right, or people won't necessarily be able to get on the network.

If you are very concerned about interfering with network traffic, you may want to look at Bradford Network Sentry, ForeScout CounterACT, and Trustwave NAC, all of which have an exceedingly light touch on the network when used in "observe only" mode.

Enforcement scenarios

Let's say you do decide to enforce access controls. There are four ways to do so: edge enforcement, deep in-line enforcement, protocol-based enforcement and hybrid enforcement.

Edge enforcement, which is a type of in-line enforcement, uses a device at the edge of the network. In the case of switched access, the edge is the switch port. Edge enforcement can also be used in wireless controllers and VPN concentrators, enforcing access at the point of connection to the network. Many NAC vendors call this "out of band" enforcement because their hardware is not enforcing access controls — your edge hardware is. But it's still very much an "in-band" enforcement.

Most products we tested support edge enforcement as an option, with the exceptions being Trustwave and McAfee.

If you move enforcement deeper into the network, that's "deep in-line" enforcement. Sometimes it's done at Layer 2 (the Ethernet layer) by a device that looks like a transparent bridge; other times at Layer 3 (the IP layer) by a device that looks more like a router or a firewall.

Alcatel-Lucent, Avenda, Cisco, Enterasys, Juniper, McAfee, and Symantec offer in-line devices that sit between the user and some part of the network to enforce access controls. For each of these products, deep in-line enforcement is an option, not a requirement.

Hybrid enforcement combines edge-based and deep in-line enforcement. The general idea is that the NAC device starts in-line with user traffic, and then at some point gets "out of the way" by reconfiguring the network to use edge enforcement. The best example of this is in McAfee's N-450 NAC Appliance.

Because hybrid enforcement is, well, a hybrid, not every NAC product works the same way as the McAfee N-450 NAC Appliance when in hybrid mode. Some NAC products reserve hybrid mode for users who are authenticating via Web browsers, a more intrusive way of controlling access, but a common model for guest users.

Many products offer multiple types of hybrid operation as well, depending on whether they are sitting as a Layer 2 or Layer 3 device. If you do choose hybrid or deep in-line operation, make sure you're buying enough boxes. Some products, such as Cisco NAC Appliance and Symantec NAC Enforcer 6100, can operate in one mode or the other, but not both, so if you want to use both in your NAC deployment, you may need to buy additional hardware.

Protocol-based enforcement is an option in Alcatel-Lucent SafeNAC, ForeScout CounterACT, Microsoft NAP and Trustwave NAC. In this model, the actual enforcement depends on devices playing by the rules of the protocol, because there is no real enforcement actually happening.

A good example is DHCP-based enforcement, which is an option with Alcatel-Lucent SafeNAC and Microsoft NAP. With DHCP-based enforcement, end devices are given an IP address that somehow restricts where they can go, such as by manipulating the subnet mask or the default gateway.

As long as the device plays by the rules and listens to what they get told via DHCP, the NAC will "enforce" access controls. If the device starts to cheat, perhaps by not DHCPing in the first place, then the NAC isn't able to enforce access controls.

Protocol-based enforcement is most appropriate in environments where you aren't trying to keep off malicious users. For example, if you have good physical security in your building, your main NAC goal may be end-point security compliance, not authentication.

ForeScout and Trustwave strongly encourage you to use protocol-based enforcement for part of your deployment. Both use more sophisticated mechanisms than simply playing with DHCP. For example, Trustwave NAC poisons ARP caches to redirect traffic to the Trustwave NAC appliance, which then sits in-line during initial authentication and end-point security checks.

Several NAC products also support something we call Host-based Access Control. We didn't test this because it seems to be a different product category, but it is an option in products including Alcatel-Lucent SafeNAC, Juniper UAC, Microsoft NAP and McAfee ePolicy Orchestrator NAC. In host-based access controls, the enforcement is pushed to the end devices.

If you're looking for products with the most flexibility, Alcatel-Lucent Safe NAC, Avenda NAC, Cisco NAC Appliance, Enterasys NAC, Juniper NAC and Symantec NAC are at top of our list because they let you choose what you want: in-line or edge.

When you're only looking at users on switches, that flexibility may not seem all that important, but our experience with real networks and their myriad installations of hidden switches (like that one on your desk that isn't managed or even official), wireless networks, and VPNs to branch offices and remote users has taught us that flexibility counts for a lot.

Communicating access control: Getting the message across

Once you've decided the access control policy for a device, how do you get it into the enforcement point? This point is contentious because it combines all sorts of issues, from the technical, to the political, and even the religious.

There are really three approaches: proprietary, 802.1X and "whatever works."

The proprietary case is easy to understand. When a NAC vendor both sells an enforcement device and a NAC solution, there is often a proprietary API that lets the NAC part of the product talk to the enforcement part of the product. For example, Juniper's UAC can talk to Juniper firewalls to push out access control rules. Alcatel-Lucent switches can query Safe NAC CyberGatekeeper servers for end-point status information.

Sometimes the enforcement device is embedded into the NAC product, such as with McAfee's N-450, and the policy communication is invisible. The downside is that you may not be able to mix-and-match different enforcement devices, but most vendors with proprietary enforcement devices have worked around that by including other ways to communicate enforcement rules.

802.1X factor

When 802.1X is used, the NAC product has the opportunity to push access control information down to the edge device as part of the 802.1X protocol. It's standardized, more-or-less, and it provides a strong and secure linkage between the device trying to connect and the access control policy. This makes using 802.1X a technically elegant solution that security-minded networkers like.

Unfortunately, there are significant problems when using 802.1X, most of which come down to a single point: 802.1X access controls are easy at the moment of authentication, but difficult any other time. For example, if the NAC solution suddenly decides that someone is no longer compliant, or if the NAC manager changes the access control policy in the management system, there is no easy way to get that information out to all 802.1X-authenticated ports.

Standards writers have proposed a solution, called Change of Authorization (usually abbreviated COA), that lets access control changes be sent asynchronously from authentication responses. There are a couple of problems with that: first, most switches don't support COA, and second, most NAC products don't support it either. We found support in some Cisco, Enterasys, HP and Juniper switches, and Enterasys' and Juniper's NAC products, but that was about it.

Linking NAC policy communication to authentication has another problem that vexes NAC vendors, because it requires end-point security to be first evaluated when the user connects. NAC vendors don't always like that, for two reasons. One is that it can take significant time to verify end-point security compliance, which delays logins, which makes end users unhappy. The other reason is that it requires the NAC vendor to tightly link the first end-point security scan to authentication, which makes NAC vendors unhappy.

The solution that pragmatic NAC vendors have come up with is what we call "whatever works:" a combination of SNMP operations and command-line commands sent down either via Telnet or SSH that can be used to push access control information into switches at any time: before, after and during authentication.

Bradford, Cisco, Forescout and McAfee all use this strategy as their path of least resistance: if you take their products out of the box, this is the initial strategy that they encourage, even if 802.1X is an option.

The NAC vendors that strongly encourage 802.1X, including Avenda, Enterasys, HP, Juniper, Microsoft and Symantec, may also support other approaches, but when you select edge enforcement, you're initially pushed towards 802.1X access controls.

As with many technical arguments, this one may come down to preference and experience rather than technical justification. Coming from the security point of view, our preference has been to use 802.1X for access controls, which offers much stronger security than approaches such as SNMP. However, it's not always security which drives NAC projects, so that point of view doesn't always apply. Our testing also uncovered compatibility problems when using SNMP. NAC vendors were quick to fix things after we pointed them out, but there's no guarantee that these problems won't reappear at every switch firmware upgrade.

Many of the vulnerabilities associated with the "whatever works" strategy have been identified and compensating controls are in place. For example, since the SNMP trap that identifies a new system could be lost, many SNMP-focused products periodically scan media access control tables within switches to see if new MAC addresses have shown up that need to be authenticated and checked.

Similarly, the 802.1X issues also have solutions. For example, when the Microsoft NAP client detects that end-point security has changed and the device must be re-assessed, they force a quiet re-authentication that gives their server a chance to change access controls in the background without the user having to re-enter their username and password.

Granularity of controls

The last part of NAC access controls may mean everything to you — or may mean nothing. It all depends on why you're doing NAC and what your access control policies are. NAC projects focused on end-point security may find that only the simplest of access controls are required. If your NAC project is more focused on differentiating users, you may want much greater granularity of access control.

The NAC products we tested fall into every step of the spectrum, from virtually no controls, such as in Trustwave NAC, all the way up to fine-grained stateful firewall access controls, as in Juniper UAC.

For scalability reasons, most NAC vendors try and push the job of controlling access out to existing infrastructure. For example, if you have divided your network into different security areas using virtual LANs, and then used firewalls to provide access controls between the VLANs, the NAC vendors would prefer to simply move users from one VLAN to another, and make use of your existing security plan.

With edge enforcement, you're limited to whatever access controls are available in the edge device. Two NAC vendors, Consentry and Nevis, have both bitten the dust trying to build sophisticated access controls into edge switches, which leaves network managers with only two options: putting users on different VLANs, or using basic stateless access control lists (ACL) in the switch.