Wave Systems Corp. (fka WAVXQ)

[wavxmaster]

Dude Danny

"Source: Burton Group"


Microsoft,Trusted Computing Group Find NAC Interoperability
Source: Burton Group | Priority: Fortifying Network Security | Topic: Access Control
Date Published: 5/24/2007 | Date Reviewed: 7/20/2007

TAKEAWAY: After years of struggling for interoperability, the network access control fog is clearing with the announcement from Microsoft and the Trusted Computing Group that Microsoft's Network Access Protection initiative and Trusted Network Connect will be interoperable. Bloggers Phil Schacter and Dan Blum say the announcement brings the industry one step closer to a true NAC standard.



http://srmsblog.burtongroup.com/2007/05/the_nac_fog_beg.html


May 24, 2007
The NAC Fog Begins to Clear
Bloggers: Phil Schacter and Dan Blum

Several years ago Cisco announced an initiative to deliver a framework for network admission control using the Cisco Trust Agent client software, 802.1x-enabled Ethernet switches and a Cisco policy server. On the surface Cisco’s NAC offered the promise of network enforcement of endpoint security policies to reduce the risk of vulnerable desktop and laptop systems introducing malware to the enterprise network.

But gradually the industry discovered Cisco’s NAC framework had too many moving parts and adoption lagged. Customers were also reluctant to replace existing routers and switches with Cisco NAC-capable ones.

At the same time as Cisco promoted its framework, Microsoft promoted its own Network Access Protection (NAP) initiative. NAP comprised APIs and endpoint functionality with Windows Vista, and various policy decision points that would run on the Longhorn server. However, the proprietary NAP protocols between the endpoint client and the policy server were firmly closed.

The problems with the Cisco and Microsoft frameworks left NAC in a fog. The Trusted Computing Group (TCG) did promote an open Trusted Network Computing (TNC) initiative, but had few takers on the market, save for Juniper. A number of other proprietary NAC products came available from vendors such as Symantec and McAfee. Hedging its bets and trying to accelerate customer investments in network security, even Cisco began selling a different NAC solution based on its Perfigo acquisition.

But the industry still lacked a standard. In late 2006, Microsoft and Cisco announced an agreement by which NAC and NAP could interoperate, but this solution would require customers to operate duplicate policy systems – Cisco’s Secure ACS and Microsoft’s Network Policy Server (NPS). Hardly an ideal interoperability scenario, and still more moving parts to maintain and operate.

Finally, this week at Interop the fog cleared. Microsoft and the Trusted Computing Group announced interoperability between NAP and Trusted Network Connect (TNC). While Microsoft, as one of the founding members of the TCG, had previously committed to “harmonize” NAP with the work on TNC, the nature of this week’s announcement went much further than anticipated. Microsoft contributed its protocol for communicating system health information to TNC, which dubbed it IF-TNCCS-SOH.

Unpronounceable or not, IF-TNCCS-SOH looks like a win for the industry. Let’s call it the Statement of Health (SOH) protocol for short. SOH makes it possible for a true plug-and-play market to develop with any agent able to communicate with any policy server. Microsoft effectively allows established vendors with NAC appliances to displace NPS as the policy server for NAP, and it is possible for protection software on Windows and non-Windows endpoints to speak SOH as well. But at the same time, the long lineup of vendors already writing to Microsoft’s APIs virtually assures the dominance of NAP as the client architecture for NAC on Windows systems. At Interop, Microsoft and Juniper will demonstrate an early implementation involving Juniper’s Unified Access Control (UAC) product, which is also a TNC server.

Microsoft’s NAP is already shipping in every copy of Windows Vista and will be included in a Service Pack for Windows XP. As soon as Juniper and other third party NAC appliance vendors are able to provide customers with upgrades to support the SOH protocol, customers can begin their NAP deployments without having to be dependent on Microsoft’s Longhorn ship timetable. There will certainly be solutions in the market before the end of 2007, with most vendors in the NAC market having products to support NAP endpoints by mid-2008.

This week’s announcements go a long way to providing a de facto standard for factoring system health information into access control decisions. Rather than every NAC vendor having to create their own agent software, it is expected that endpoint security vendors will produce the System Health Assessment (SHA) modules that NAP requires, and that these modules will work with any NAC appliance and its policy infrastructure. At some point it is likely that the TNC effort and early stage work underway by IETF’s Network Endpoint Assessment group will converge, resulting in a de jure standard. The establishment of such standards reduces customer risk in deploying products, and enables co-existence between products from established network infrastructure and security vendors, and new entrants with innovative offerings.

Cisco is not a member of TCG and has distanced itself from the work on TNC, preferring to work through the IETF while advancing its own initiatives and product offerings. However, the new TNC-Microsoft protocol provides Cisco with an opportunity to shed the residual client aspects of its largely unsuccessful framework. It is also a competitive opportunity for Cisco to succeed in providing the policy infrastructure for customer networks dominated by Windows endpoints. One fallout of the new protocol is that it largely makes the Cisco NAC interoperability solution with Microsoft NAP irrelevant. All Cisco has to do is implement support for SOH in their NAC (CleanAccess) appliance. The only problem that Cisco and other NAC vendors face in the market is what to do with their client agent software. Their choices are to re-instrument and provide a SHA to plug into NAP on Windows clients, and then accept messages generated by NAP in their backend appliances; or to withdraw from the agent market once sufficient endpoint security vendors deliver their native support for SHA and the NAP Windows architecture.

The bottom line here is that we’re closer to a true NAC standard than anytime in the past six years, and this is good news for anyone interested in investing in NAC as part of an anti-malware strategy.