The NAC labyrinth
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 promising eventual tools
that will 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
bandwagon. The major NAC schemes we examine are 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 own 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 also 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 between NAC approaches. Some
vendors consider the endpoint security assessment to be a one-time check at
system connection, while others take a continuous 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 hone in on
authentication and policy as the prime pieces. Some only work well 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.
Microsoft isn't the only vendor with a paucity of products. The TCG, a
nonprofit industry-based standards organization comprising interested vendors,
has been working on its Trusted Network Connect scheme since mid-2004 and still
doesn't have a completed architecture. The Trusted Network Connect framework
includes six separate protocols to build a complete system, but only two of
these have been fully defined, making it impossible to have a fully deployed
Trusted Network Connect NAC network. TCG has promised the rest of the protocols
any day now.
Start with a little TCG
That said, the best starting point for evaluating NAC architecture is with the
TCG's Trusted Network Connect because its specifications are created in an
open, vendor-neutral environment and can be used as a good model just to get
the terminology straight. Every proposed NAC strategy can be mapped to the
Trusted Network Connect architecture, but that doesn't mean Trusted Network
Connect is a superset of other products. Many NAC vendors add features not
explicitly discussed by TCG, such as control of personal firewall or continuous
rechecking of endpoint security status. Other NAC vendors handle cases that are
not discussed in the TCG architecture, such as how to provide access controls
when the end system is a guest laptop and doesn't have all the necessary
software installed.
The Trusted Network Connect architecture divides the NAC problem into three
entities: the Access Requestor, the Policy Enforcement Point and the Policy
Decision Point.
TCG's Access Requestor is a combination of the entity trying to gain access to
the network, such as a laptop or desktop computer, and the software and drivers
that implement authentication and endpoint security assessment processes. TCG
divides the Access Requestor into three smaller pieces. At the bottom is a
Network Access Requestor, software used by the client to connect to the
network, request access and provide authentication. For example, an 802.1X
supplicant or an IPSec VPN client could serve as a network access requester.
Integrity Measurement Collectors, software components responsible for
evaluating the security posture of the end system, are on top of the Network
Access Requestor, still on the client system and part of the access. If your
policy is defined such that everyone has to be running anti-virus software,
then your anti-virus vendor would provide a plug-in that serves up status
information on its software. TCG divides this task into two pieces: the
Integrity Measurement Collectors, and the Trusted Network Connect client that
collects information from the Integrity Measurement Collectors and helps
package it up for policy evaluation.
The Trusted Network Connect NAC Policy Enforcement Point is exactly as it
sounds: the point at which policy is enforced. TCG's NAC doesn't describe what
kinds of policy-based enforcement mechanisms are available, probably to remain
as vendor neutral as possible, although the architectural documents describe
how quarantine and remediation might be part of policy enforcement.
The Trusted Network Connect NAC Policy Decision Point also is divided into
three parts. The bottom piece, which is in charge of talking to the
authentication server and communicating decisions to the Policy Enforcement
Point, is the Network Access Authority. In a typical network, this would likely
be an AAA (authentication, authorization and accounting) server.
Behind the Network Access Authority are Integrity Measurement Verifiers. These
are the counterparts to the Integrity Measurement Collectors on the client.
They receive the reports the Client Integrity Measurement collectors send and
provide verification information back to the Network Access Authority. The
verifiers and the collectors are a matched set. They can talk to each other
through a tunnel provided by all the other pieces of the NAC architecture,
using whatever proprietary vendor-specific protocol vendors want.
The Trusted Network Connect architecture layers a thin server piece, called the
TNC server, in the Policy Decision Point that is the interface between the
Integrity Measurement Verifiers and the Network Access Authority.
The Trusted Network Connect NAC architecture is designed to work within an
existing 802.1X authentication and authorization system. If you rename the
client-side network Access Requestor to "802.1X supplicant"; the
Policy Enforcement Point to "802.1X-compatible switch or access
point"; and the Network Access Authority Policy Decision Point to
"802.1X RADIUS server", then the Trusted Network Connect NAC plan is
bits of software that sit on top of an existing 802.1X deployment to add
endpoint security assessment to the mix.
This becomes obvious if you look at the protocols the Trusted Network Connect
chose to publish first. There are those that let the vendor-supplied integrity
measurement collectors talk to a vendor-neutral Trusted Network Connect client
on the client system and those that let the vendor-supplied Integrity
Measurement Verifier talk to the vendor-neutral Trusted Network Connect server
on the Policy Decision Point end. As prototype implementations started showing
up, Trusted Network Connect relied heavily on existing 802.1X mechanisms such
as authentication and tunneling to get the other pieces to work, although none
of this is laid out explicitly in the architecture documents.
Focusing on 802.1X does not mean that the Trusted Network Connect architecture
won't support other kinds of Policy Enforcement Points, such as firewalls, VPN
concentrators or core switches. But it does mean that anyone trying to go from
architecture to implementation using the Trusted Network Connect documents will
quickly find even more missing pieces, at least at this stage of the
architecture. Important parts of the big picture, such as how the Trusted
Network Connect client and server talk to the network access requestor and
network access authority, aren't called out for future discussion -- which
means even when the architecture is completed as planned, it won't be fully
complete.
While TCG's Trusted Network Connect architecture is a well-constructed way to
think about NAC, refer to NAC components and compare NAC solutions, it doesn't
yet represent an architecture that's complete enough to be used to begin
implementation.
Back to top
 Click here to submit a story for consideration by Cram Session Editor, stories@cramsessionnac.com
|
