Many network and security administrators have implemented or are considering network access control (NAC) to support corporate security policies, but doubts remain about the technology.
NAC has grown rapidly as a method for enforcing information security policies, but without a unified standard, there is still uncertainty about how things will shake out. Think Betamax and VHS -- or more recently, Blu-ray and HD DVD -- and the "cold feet" effect becomes understandable.
There are three major approaches to NAC standards, with varying degrees of interoperability and development cooperation.
The Trusted Computing Group's (TCG) Trusted Network Connect (TNC) is a full set of standards for NAC developed by member companies.
Network Access Protection (NAP) is Microsoft Corp.'s entry into computer posture checking and will become fully operational with Windows Server 2008.
The Internet Engineering Task Force (IETF) has been working on a set of NAC standards referred to as the Network Endpoint Assessment (NEA).
NEA is still in the standards process and will likely be there for some time. "The IETF is comprised of [sic] individuals, while TNC was developed by member companies," explains Steve Hanna, co-chairman of both the IETF and TCG NAC working groups. Because contributions to IETF initiatives are often from many individuals around the globe via e-mail, whereas the TNC approach is more streamlined because of limited participation, the IETF process takes longer to produce standards.
Hanna explains that the IETF initiative has been under way for over a year, yet there hasn't been an agreement about what the standard should look like. He says he believes the process could take several more years. But does that imply that those who may be waiting for an IETF standard before deploying a NAC system should continue to wait that long?
Wait or deploy?
Recently, I moderated a NAC panel arranged by a network security consulting company. Potential and current NAC users took this opportunity to grill the panel -- which consisted of representatives from Cisco, Hewlett-Packard's ProCurve unit, Symantec and Juniper Networks -- on NAC product offerings and directions.
Without a doubt, the lack of a single, unified standard was on the minds of many of the attendees. When asked if users should wait to deploy NAC until the standards had settled, however, all representatives were unanimous in stating that if there is an immediate need and a solution exists, then deployment now is preferable.
Still, there is a gamble about whether the standards will converge at all. Hanna has hopes that the IETF will eventually be aligned with the TNC initiative. Cisco Systems Inc. may not yet be on the TNC bandwagon, but the company supports the IETF initiative and has partnered with Microsoft to ensure interoperability with NAP. Adding the fact that Microsoft Corp. donated a standard (download PDF) for the TNC client and a standard to work with the NAP system, it's clear that there is already movement toward that convergence.
So what are some of the vendors' positions on the NAC standards with regard to product development? Eric Stinson, Enterasys Networks Inc.'s director of product management for NAC, explains that while Enterasys has been building NAC type functionality into its network equipment for some time, continuing to follow industry standards as they develop is an important corporate direction. "We remain committed to interoperability and investment protection through [NAC] industry standardization efforts."
As HP ProCurve Chief Security Architect Mauricio Sanchez elaborates, NAC is built on existing standards to an extent. "All of the NAC protocol frameworks have some underpinnings and usage of current standards, such as RADIUS, EAP, 802.1x, etc.," he says. "No one likes to reinvent wheels, so where existing [standards] made sense, there's no reason why they shouldn't be used."
It's through collaboration that a standard emerges -- be it by decree or de facto. Stinson sees movements in collaboration as indicative of the future direction of NAC. "Enterasys expects that TNC and NEA will eventually align with each other, but the fact that Microsoft has endorsed TNC will drive NAC adoption based on Microsoft's market presence in client computing," he says.
Alan Shimel, chief strategy officer at NAC producer StillSecure, agrees. "Microsoft Server 2008 will go a long way towards adoption of NAC" says Shimel, who adds that the proliferation of NAP "is going to really help the TNC standards course."
"Many customers are eagerly waiting to evaluate a complete NAP solution, so if anything, it will serve to solidify customer opinion on what and how they should proceed in addressing their endpoint integrity requirements," according to Sanchez. And that is the real dilemma many network and security administrators as well as CIOs and CISOs are facing: Wait for the standards to solidify, or deploy NAC now?
Customers have real problems now that need real solutions. "If they have a problem they are looking to solve [with NAC], they want to solve this problem," states Shimel. Stinson says, "The centralized visibility and control that NAC can provide to network operations teams today can deliver tangible improvements in efficiency and effectiveness while improving the overall security posture of the organization."
Industry spin ... or not?
It's obvious why manufacturers of NAC products would suggest that such products should be purchased now, despite the standards situation. IT has a long history of offering whiz-bang products that could be considered overkill at a significant cost.
However, consider how NAC has evolved. NAC started out in start-ups and small companies such as Perfigo Inc., which was precursor to the Cisco NAC Appliance, and open-source projects such as NetReg. Usually, such initiatives come about mainly because of need, be it real or perceived. When the need is real, the "big boys" pick up on it and begin to incorporate it into their offerings.
That's exactly what has happened with NAC development. It was the need that drove the initial products, and it was the prediction of a much larger need that led to the marketplace that exists today. It should be no surprise that the standards are trying to catch up, because the need has existed for some time.
NAC vendors naturally suggest that it's appropriate to buy NAC products before the standards mature, but the flip side is that if the market leaders didn't feel there was a need for NAC, they wouldn't have invested as much in development as they have. Watch out for vendor marketing FUD (fear, uncertainty and doubt), but remember that IT exists to serve your business, not the other way around. That, and not the status of standards, should be the primary consideration when considering a NAC deployment. computerworld