Whether you're currently using network access control (NAC) in your organization or considering doing so, the fact is NAC is one of the hottest components in an overall IT security infrastructure today. But will we still be talking about NAC a few years from now?
The answer is undoubtedly yes. This is mainly because NAC is more about processes and evolving technologies to achieve the objectives of corporate security policies than about technology itself. While the methods of enforcement will change, the need to do so won't.
But NAC is also about marketing. Think back to when networks were made up of routers and bridges. From an Open Systems Interconnection model perspective, these acted on Layers 3 and 2, respectively. Then switches came along, and they were referred to as Layer 2 and Layer 3 switches.
The desired marketing impression was that Layer 3 switches were new, and routers were old. It's true that there were advancements in the technologies and methodologies, such as moving from software- to hardware-based routing. But "hardware routing" just didn't have the marketing zing of "Layer 3 switching," and thus a new market was born (or reborn).
Not a new idea
Similarly, NAC isn't necessarily a new concept as much as a repackaged and enhanced set of methodologies. Bare-bones network access controls have existed since shared networks emerged. Consider the days of terminal servers, whereby a client logged in to a terminal server, often via a modem or serial connection, and then Telnetted to a device. Access to networked resources was achieved via simple authentication to the terminal server.
The explosion of LANs, online databases and so on created a large demand for access to anything, anywhere and at any time. Controlling network access became secondary as security efforts focused on the endpoints. When vulnerabilities of those endpoints began to be exploited at a rapidly growing rate, the concept of controlling network access came back into vogue.
So the question really isn't so much whether NAC will fade away but rather how it will evolve. There are many products today that use scanning for posture assessment and network standards such as Address Resolution Protocol (ARP) manipulation and Dynamic Host Configuration Protocol (DHCP) network assignment to use existing standards to address NAC needs. However, these methods have their limitations, chiefly due to "bending" protocols beyond their design intentions.
Other NAC products use proprietary methods of client posture assessment. However, there isn't yet a cohesive, well-defined suite of standards dedicated for NAC operation. Such standards are a necessity for interoperability of NAC products between different vendors.
The implications of interoperability are important. Consider a future telecommuter who is required to run a posture-assessment client to access his Internet service provider and to access the corporate LAN. The telecommuter need not load two different assessment clients, even if the security access policies of the service provider and the corporation are different (which of course they would be).
To address the lack of complete NAC component interoperability, standards groups and vendors have been working to create methods and definitions with the goal of becoming the prevalent industrywide NAC standard.
Emerging NAC standards
The Internet Engineering Task Force (IETF) Network Endpoint Assessment (NEA) working group currently is developing requirements for protocols to achieve interoperability between NAC vendor components. The working group describes two basic protocols in this process, the Posture Attribute (PA) protocol and the Posture Broker (PB) protocol.
The PA protocol examines the state of a machine as defined by a security policy. Posture assessment can be performed either from an internal (client) or external (scanning) point of view. PA focuses on the former. The PB protocol defines the transport of the PA protocol information to the assessment server. The end result is that several different clients adhering to the PA standard can communicate with one (or several) different PB enabled servers, regardless of vendor.
The NEA working group recognizes that several proprietary methods of posture assessment and enforcement and may opt to standardize on one, base a new protocol on one or several existing methods, or recommend creation of a new protocol from scratch. The NEA requirements draft is scheduled for submission in August 2007 to the Internet Engineering Steering Group for last call comments.
The Trusted Computing Group (TCG) strives to provide interoperability systems for a variety of applications and has more than 100 members grouped into three categories -- promoters, contributors and adopters. By leveraging industry input and adoption, it intends to develop open standards independent of vendor platform.
The Trusted Network Connect (TNC) work group of the Trusted Computing Group was formed in 2004 to define a standard for ensuring that endpoint posture is met. In 2006, the TNC defined the Platform Trust Services (PTS) in its TNC architecture.
PTS is designed to provide endpoint posture information regardless of platform to also ensure a measure of NAC interoperability among disparate vendors. It utilizes a client broker (the TNC client) to analyze client posture and transmit it to an enforcement server.
NAC was again one of the featured technologies at the Interop exposition in Las Vegas. Staying true to its core goal of testing interoperability, the NAC Interoperability Lab demonstrated a NAC system consisting of equipment and methods from many vendors and groups.
Part of the lab demonstration focused on equipment and software from vendors based on the TNC and IETF initiatives. The other portion showcased two vendor-specific approaches, Microsoft Corp.'s Network Access Protection (NAP) and Cisco Systems Inc.'s NAC, because cooperative efforts between both technology heavyweights could possibly produce the most widely used NAC solution.
Microsoft essentially rules the client/server operating system market space. Partially because of this, the majority of threats are targeted at software running on Microsoft platforms. By working with the networking industry to create a cohesive protection strategy, Microsoft hope to reduce the number of security intrusions related to its operating systems and software worldwide.
NAP is Microsoft's answer to NAC. It's available in Vista and a component of the yet-to-be-released Microsoft Server 2008. A client for Windows XP is currently in development. NAP replaces the Internet Authentication Services and Network Access Quarantine Control in Windows 2003 server. However, a full NAP system relies on Windows Server 2008, which is still in beta.
That isn't stopping Microsoft from attempting to establish a solid NAC base before the release of Server 2008. Many networking and security providers have become Microsoft NAP partners. In addition, TNC announced at Interop 2007 Las Vegas its interoperability with NAP, which can produce benefits for both initiatives.
Cisco has approached NAC from two directions. In 2004, it acquired Perfigo Inc.'s Clean Machines product and repackaged it as Cisco Clean Access (CCA). While CCA offers some extended functionality for Cisco-only infrastructures, essentially CCA is a "black box" product that provides NAC capability without requiring a Cisco infrastructure.
But it's the NAC Framework that Cisco is positioning as its answer to a NAC standard. Developed separately from CCA, it relies on a system involving posture collection (Cisco Trust Agent) and a policy enforcer (Cisco Secure Access Control Server). Like Microsoft, Cisco has also entered into partnerships with security vendors to allow for integration with its product.
The direction is protection and cooperation
Today, not all NAC products can work together. If that were the case, there wouldn't be several NAC standards initiatives out there, each with a goal of interoperability. But the fact that there are groups pursuing interoperability at this point with dozens of hardware and software manufacturers participating at some level is an encouraging sign that a full NAC interoperability solution may not be far off.
The most compelling development in the NAC partnership space may be Cisco's and Microsoft's announcement last year that Cisco's NAC and Microsoft's NAP will be designed to work together. Combined with the TNC interoperability with NAP and the vendor partnerships each has formed, the early version of a future NAC interoperability standard could in fact be in front of us today.
What portions, if any, of the existing offerings are incorporated into the final IETF NEA standard remains to be seen. With a constant feedback cycle enhancing the standards and product development process, the NAC crystal ball should become much clearer within the next year.
Regardless of the final set of standards and implementation methods, it's clear that NAC has emerged as a cohesive technological component of an overall network and system security infrastructure. From the early days, not too long ago, of simple Web authentication and client scanning to emerging standards of complex NAC interoperability, NAC -- or whatever it as a security policy enforcer evolves into -- is here to stay.
Greg Schaffer is a freelance writer in Tennessee. He has over 15 years of experience in networking, primarily in higher education. He can be reached at newtnoise@comcast.net.