Bolting the Back Door with NAC Part 3: Comparing the alternatives
Network Access Control (NAC) promises to improve security, but competing approaches have muddied the waters. In this tutorial, we navigate our way through NAC architectures from Cisco, Microsoft, Trusted Computing Group and the IETF.
by Lisa Phifer
VP Core Competence, Inc.
[June 22, 2007]
In part 1 and part 2, we examined the business needs driving companies to rethink network access control (NAC). Instead of trusting every device on the LAN, NAC combines user identity, endpoint security state, and policies to dynamically decide who should be allowed to use which network resources, under what pre-conditions. Only healthy, compliant endpoints are permitted to reach authorized resources, while everyone else is blocked or quarantined.
This concept may sound promising, but the devil is in the details. Today, NAC is an emerging market filled with divergent implementations and no universally-agreed standard. Here in part 3, we will explore four NAC network architectures:
Cisco Network Admission Control (CNAC)
Microsoft Network Access Protection (NAP)
TCG Trusted Network Connect (TNC)
IETF Network Endpoint Assessment (NEA)
We will also take a brief look at overlay NAC appliances, a near-term alternative for those who like the idea of NAC but don't want to invest in network upgrades.
NAC architectures
Cisco NAC (the original) and Microsoft NAP (Redmond's response) are proprietary architectures, aimed at largely homogeneous networks. Once these sparked market interest, interoperability concerns prompted standards development. The Trusted Computing Group was first out of the gate, publishing TNC specifications in May 2005. A year later, the IETF formed a working group to define NEA. Today, CNAC and TNC-based products are both commercially available. Essential NAP components are still in beta, while NEA is not far enough along to implement.
Although integration points have been proposed, these four architectures all overlap with each other to some degree. Each adds new NAC protocols and/or APIs to network endpoints, servers, and the access devices that connect them. On top of that NAC-enabled network will sit new client/server posture assessment programs.
As described in parts 1 and 2 of this series, NAC can be applied to many scenarios, from controlled guest access to compliance auditing. Before we dive into architectures, let's lay out one common example—keeping infected employee laptops off our LAN:
Without NAC, every employee laptop plugged into a switch or AP has full access to our physical or virtual LAN. Application logins may restrict server/file access, but a hacked laptop can still try to harm everyone else on the LAN.
By adding NAC, we could require every employee to log in before his or her laptop is admitted to the LAN. During admission, an installed client, ActiveX control, or Java applet could scan for missing, inactive, or outdated AV programs. Combining user identity with scan results lets us make more informed decisions, using the switch or AP to isolate compromised laptops.
In theory, CNAC, NAP, TNC, or NEA could be used to implement this scenario. In practice, the kinds of clients, servers, and network devices that can be supported depend on architecture and product. To understand why, let's drill down...
AI
