The competition for NAC

By Joel Snyder
Network World, April 3, 2006

Original Article on Network World Web Site

Mapping Cisco, Juniper, Microsoft and TCG's access-control schemes.

Network access control represents the most significant change in the way that networks are secured since the invention of the firewall. But it’s also contentious, confusing and — when done right — complicated.

With the stampede of vendors laying claim to NAC territory, IT managers are now presented with an overwhelming number of architectures and tools designed to help create a strong link between users, end systems and access to network resources.

In an effort to provide some insight into how each may or may not fit into your network, herein is a breakdown of their similarities and differences.

NAC is a broad new buzzword, and security and network vendors all have ideas about how best to give their products and services a place in the NAC universe. The major NAC schemes we examined were Cisco's Network Admission Control, Juniper's Infranet, Microsoft's Network Access Protection and the Trusted Computing Group’s (TCG) Trusted Network Connect.

Before diving into the who's who of NAC, it's important to understand its basic elements (see NAC primer).

There are three fundamental approaches to NAC based on where the access control is being enforced in the enterprise: edge control, core control and client control.

Edge control takes the principle of the firewall and pushes it to the edge of the network, where systems connect. If you are protecting a LAN, the individual switch port becomes the NAC control point. If you are working with a VPN connection, the IPSec concentrator or the SSL VPN device is in charge of enforcing access controls. In a wireless environment, the access point or wireless switch plays the NAC role.

In the core control schema, controls can be enforced anywhere in the network providing it's in deeper than the edge device. You could insert a NAC device inline, or as a passive tap, between edge switches and the core, where it would collect authentication and endpoint-security information, and then enforce the appropriate access control policy.

These devices (such as Lockdown Network's Enforcer) inspect traffic or control-plane information passing by and reach into the network to change configuration to apply enforcement.

The client-control approach focuses on the end system connecting to the network where greater attention is paid to the management and control of the end system. The Senforce Endpoint Security Suite installs a fairly heavyweight application on each end system that enforces NAC policies and local access controls, such as disabling wireless access if the VPN client isn't in use. An endpoint protected by this kind of tool inherits a strong set of security protections, such as personal firewall, USB device locking and wireless controls that might be difficult (or impossible) to assemble and manage from a slew of other NAC vendors.

While the client control approaches are attractive from a lower budget and simplistic management point of view, they don't strongly overlap with NAC approaches that integrate with the network to help to defend itself, to force user authentication or to provide identity-based access controls.

None of the NAC frameworks touted by the major network players fits neatly into any single deployment category. For example, as a manufacturer of firewalls and SSL VPN devices (but not switches), Juniper's Infranet NAC strategy is very much core-control oriented - except when the controls are being applied to SSL VPN users, in which case the strategy looks more like an edge-control one.

Similarly, Cisco's Network Admission Control is more focused on the edge device and is designed to behave like an edge-control strategy, because Cisco controls the majority of enterprise switches in wiring closets. Cisco includes controls upstream from those switches to handle environments where old switches that can't handle NAC are installed, so its underlying NAC architecture encompasses core-control aspects as well.

There are other distinguishing characteristics among NAC approaches. Some vendors consider the endpoint-security assessment to be a one-time check at system connection, while others take a continual approach, constantly checking and verifying the state of endpoint security. Some tightly focus on endpoint security as the key reason for implementing NAC, while others home in on authentication and policy as the prime pieces. Some work well only in environments where their own agent is installed on the endpoint, while others attempt to embrace environments where no agent is available.

Although these three implementation approaches let you start to winnow your NAC choices, you have to dive deeper into the proposed architectures to further decide what works best in your network.

The first difficulty in evaluating NAC architectures is there is a lot of paperwork but not a lot of products. For example, when Microsoft threw its hat into the NAC ring with Network Access Protection in July 2004, it used the network's DHCP server as one of the primary enforcement mechanisms. If you didn't pass the appropriate endpoint-security checks, you got an IP address regulating you to the land of quarantine so that you could not disturb the rest of the network, but you couldn't fix your problems.

While that approach works great with a cooperative user community, it doesn't protect well against a malicious user looking to gain unauthorized network access. In response, Microsoft changed its architecture by adding a stronger enforcement mechanism based on 802.1X.

That was easy, because all Microsoft had to do was adjust a few white papers on its site to include this stronger enforcement. And while the current set of forecasts are that Network Access Protection will ship with the Vista version of Windows, expected late this year or early 2007, there's no promise that what comes out on those gold master CDs will include all the features in the NAC architecture.