Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Standards = Survival

This week, Steve Hanna sent the TCG/TNC specifications to the NEA working group for consideration as working group documents. These are basically submissions of existing TCG/TNC specifications along with an explanation of how the specifications meet requirements already agreed to by the NEA working group. Apparently, these are the only specifications submitted to the working group.
Great news? Not if you listen to Mike Rothman, who thinks companies don't care about standards. He thinks companies raise the standards barrier when they want to spare a salesperson's feelings. Having sat on both sides of the sales table, I don't think that's really the answer, but I also don't think Rothman's basic assessment that companies don't care about standards is off the mark.

For the last couple of years that I have polled IT professionals about NAC, I have asked how critical standards are. The responses are lukewarm for any particular standard or framework, but it's clear that IT professionals want a standard. There's good reason for that desire. If a standard emerges, that opens the door to competition among not only all the products that a NAC can leverage, but opens competition to the NAC system itself. You aren't locked into a product purchase because your NAC system depends on some other applications.

The question to ask isn't really how important standards are. The question to ask is whether organizations wait for standards. It's not as though NAC is a critical feature like IP or DNS. Organizations can live without NAC; they can still control access to applications using other technology; they can still manage guest access through process and technology; and they can still stop malicious activity like worm outbreaks. NAC just makes some of that control simpler and, depending on the product, more surgical. Would you rather stop a problem close to the source, like at the host or network port, or would you rather stop a problem that gets deeper into your network? NAC standards foster integration with everything else you've purchased.

The desire for standards hasn't reached a critical stage and probably won't for a long, long time. Today, nothing critical will be broken if NAC standards aren't adopted because few or no business processes depend on NAC. I recall troubleshooting interoperability problems between PPP stacks and remote access servers back in the '90s. Microsoft used CHAP as the remote access authentication scheme in PPP, but rather than using MD5 hashing specified in RFC 1994, Microsoft used MD4, which is what NT LANManager used. That wreaked havoc with companies using Microsoft's RAS dialer and their existing RAS equipment because users couldn't login using their domain credentials. Standards mattered in that case because of the existing RAS equipment that already had been deployed. I bet there were organizations that used Windows NT as their RAS server and had no problems at all.

Rothman's right in thinking that companies that really want NAC will move forward whether or not standards exist. They already are moving forward. Someone is buying this gear. But standards aren't just for customers. Standards are about easing integration among multiple vendors so that the salespeople don't have to jump over barriers in the field. I will even go so far as to say that no matter what form NAC takes in the future, if it's going to thrive, standards that cover every aspect from host assessment to transmitting enforcement will have to be in place and adopted by everyone.