Microsoft and the Trusted Computing Group (TCG) have joined forces to create better interoperability between network access control solutions with the announcement of a new specification which ensures that Microsoft's Network Access Protection (NAP) and TCG's Trusted Network Connect (TNC) architecture can work together.
The new IF-TNCCS-SOH specification enables interoperability between NAP clients and servers and TNC clients, servers and infrastructure, and it is a step closer to NAC standardization, the lack of which has prompted many networking and security professionals to delay deploying true network access control (NAC) until some level of standardization is available.
TCG develops open standards for security, and TNC brings together tools from various vendors to create NAC architectures. Microsoft is a TCG member and active participant. To create the new specification, Microsoft contributed its statement of health (SoH) protocol to TNC.
According to Steve Hanna, co-chair of the TNC working group for TCG, the spec ties together a string of tools that in the past were incompatible. He said both Microsoft and TNC are taking a "can't we all just get along?" approach to NAC.
Based on the new specification and SoH protocol, users now have an NAP client that is built into Microsoft Windows Vista to communicate with a TNC server. In addition, they can mix and match which NAP tools they want to use -- for example Longhorn Server, when it's released -- in concert with tools offered by TNC, a consortium of NAC vendors offering a variety of tools.
"It makes it easier for an NAC rollout," Hanna said, noting that many users are on the fence about an NAC deployment because of the uncertainty of future interoperability.
Paul Mayfield, program manager for Microsoft's networking group, agreed.
"This brings market clarification," he said, adding that increased choice can also lead to reduced costs when it comes to NAC and can eliminate the need to throw away tools once NAC is standardized.
Noticeably absent from the new specification is Cisco, which offers its own Network Admission Control framework. Hanna said that "Cisco was welcome to join but declined."
Russell Rice, director of product marketing for Cisco's security team, also noted that the networking giant's lack of participation in the new specification is not a sign that it isn't playing ball. Rice pointed to Cisco's past and current work with Microsoft for compatibility between Cisco's NAC and Microsoft's NAP, which was announced by both tech giants last September.
Rice added that Cisco has been working closely with the IETF's Network Endpoint Assessment (NEA) working group for NAC standards development. Cisco and TNC co-chair the NEA.
"We are very involved [in standards efforts]," Rice said. "Standardization is a very important exercise."
Rice said Cisco users want three things out of a Cisco NAC deployment: They want it to work, they want it to work with Microsoft, and they want a level of standardization to avoid vendor lock-in.
"Generally, people say the most important thing is to relieve pain and then keep that pain away," he said, adding that users also need to be sure the solutions they deploy today will be viable in the future.
One drawback, however, is that if users deploy a mish-mash of solutions from various NAC vendors, there isn't "one throat to choke" when a problem arises. Rice said it's an operational reality for users to want a streamlined approach with one key vendor so that several vendors don't have to get on a phone call when a problem arises to determine where the trouble lies.
Also, if and when NAC standards start to emerge, systems must be created to tie all of the different components together to give users a single view for troubleshooting and diagnostics, to avoid uncertainty about the source of the problem.
"What's my NAC SIMS tool to understand everything?" Rice asked.
Essentially, Whiteley said, today's announcement shows that Microsoft is creating a de facto NAC standard, since it has vowed to work closely with Cisco for NAC and has now teamed up with TNC.
Whiteley called the new SoH protocol a "good first step." He said it will alleviate most users' fears that buying NAC solutions now could paint them into a corner and lock them in with a particular vendor.
"That's been a big inhibitor to mainstream adoption," he said.
But one key piece is missing from the Microsoft/TNC partnership, according to Whiteley. The interoperable solutions still require an agent for guest access, he said. Cisco is working with the NEA for an agentless solution, however.
Overall, he said, the new partnership is a good sign because it shows that standards efforts for NAC are under way. Microsoft and TNC offer the one-punch, but the two-punch is still to come. The new specification is encouraging, he added.
"It's certainly critical to move the market forward," he said.
David O'Berry, director of IT systems and services for the South Carolina Department of Probation, Parole and Pardon Services and holder of several security certifications, said a new level of interoperability "lowers the barrier of entry" for an NAC deployment. He said Microsoft's partnership with TNC adds ease of use and more ubiquity to NAC.
The trouble with most NAC solutions, O'Berry said, is complexity. Interoperability and the move toward standards alleviates some of that.
"It gives you awareness," he said, adding that his chief concern is maintaining control over what he calls "endpoints and flow points." This partnership gives control on both sides.
"It will mean better control and visibility into the network right out of the package," O'Berry said. "You can really begin to get a strong security posture without having to go out and reinvent the wheel."