The Long Road for NAC

By Larry Seltzer  |  Posted 2008-04-02 Print this article Print

The honeymoon's over, and Network Access Control has a long, tough road ahead of it.

Like eWEEK Channel Insider Technology Editor Frank Ohlhorst, I'm basically enthusiastic for and optimistic about NAC. NAC is a generic use of the name for Cisco's Network Access Control. It has come to be used for the entire approach to qualifying endpoints before they gain access to a network.

As Ohlhorst says, the two big players in this market are Cisco and Microsoft with its NAP (Network Access Protection). There are a number of smaller vendors in the market too, but it's not all good times for them. Lockdown Networks, Vernier, and Caymas Systems have all gone out of business, or at least out of the NAC business, in the last few months. But there are larger, deeper companies also in the business, like Juniper and Symantec. It's not going away.

There's no shortage of new and useful technologies that enterprises should be adopting, and I'm not surprised that they're not climbing all over each other to adopt NAC. First, once they come to realize what NAC actually does, some buyers must be disappointed. It doesn't keep compromised or malicious systems off of your network-at least not directly. What it does is to set certain configuration qualifications for access to your network and to enforce them.

That means you can make sure that a system has a personal firewall, anti-virus updated no more than n days ago, all the latest patches, and so on. You can define your own requirements, too. Those with problems are put into a sandboxed subnet from which they can remediate their problems and seek help but not access sensitive network resources.

But nothing specifically stops the "good" clients from being compromised through vulnerabilities undetected by their software. And NAC systems are not invulnerable themselves. Every now and then they get their own vulnerability disclosures, and you can rest assured that this is an area that has not yet been rigorously tested. The more popular NAC becomes, the more attacks on it will be unearthed.

Perhaps the biggest problem with NAC is political. NAC is surely seen by end users as one more pain they must endure just to get their work done. Think of the trouble IT departments have just keeping iPhones off of the network. The only way some departments will begin NAC deployments is with the understanding that they will be compromised from the beginning.

For all these reasons, NAC as a product set isn't going to make it. In the longer term, NAC will become part of the landscape of services offered by networking systems. Better support for devices will help a lot, and for that the only real hope is a standard for them to follow.

The standards action in this space is at the Trusted Computing Group and the IETF's NEA (Network Endpoint Assessment) Working Group. At the recent IETF meeting in Philadelphia, attendees voted on three draft standards the group had been working on; the IETF seems to be developing standards compatible with the TNC standards.

It's going to be a long process. More than just the efficacy of the standard has to be worked out. To be deployed and accepted widely, there needs to be widespread support for NAC and ways to make it easy to deal with.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

For insights on security coverage around the Web, take a look at Security Center Editor Larry Seltzer's blog Cheap Hack.

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel