Without A Standard, Network Access Control Will Frustrate IT Administrators

The explosion of malicious code combined with ever-more mobile users has spurred infrastructure vendors to action, and has spawned an entire market for client validation and access control solutions. Independent vendors including Sygate, Zone Labs, and InfoExpress are striving to create infrastructure-agnostic solutions, while heavyweights like Cisco are trying to develop their own hardware-dependent implementations. Now Microsoft has announced its intention to enter the fray with its Network Access Protection technology. While all these solutions have a common goal, they share little in the way of common standards or protocols. In particular, the actions of Cisco and Microsoft are creating a technological schism that threatens to divide enterprise IT managers between a Microsoft driven solution, a Cisco driven solution, or a third party implementation that may require yet another desktop agent.

Analytical Summary

Cisco NAC, Microsoft NAP, Enterasys TES: A rose by any other name would still smell as sweet to the network administrator. But something stinks to high heaven in this flowerbed. Cisco and Microsoft are delivering competing solutions that have no common basis in standards, simultaneously forcing third party competitors to develop proprietary clients and agents to deliver the functionality necessary to establish trust, validate the end client, and grant access to the network. While competition breeds a healthy market, competition without standards or interoperability creates proprietary solutions that limit end users’ overall technology choices. Network administrators dislike proprietary solutions, and they outright hate solutions that won’t interoperate. Third party approaches may seem safe, but require additional desktop agents and enforcement engines, and often new and obscure product expertise, both of which increase the complexity and expense of deploying and maintaining the solution. The answer to the growing dilemma is standards. The key competitors in the networking, security, and operating system markets need to put aside their differences and come up with a set of standards for exchanging validation, authentication, and enforcement rules and information. The future of client validation technology depends on cooperation from industry heavyweights. Competition is healthy, but differences in philosophy must be put aside for the greater good of network security.

Analyst Perspective

Spending on network security solutions is at an all time high, due to the ever-growing threat of viruses, Trojans, worms, and mal-ware present on the Internet today. It is no small wonder that infrastructure vendors are scrambling to deliver solutions to these problems. Network authentication, access-control, and security solutions not only present a significant source of revenue, but also breed customer loyalty when the solution works as advertised.

While many security efforts have been built on the foundation of standards-based protocols and APIs, the proposed solutions for validating client integrity prior to allowing network access have largely been proprietary in nature. Two of the most visible forces in this market, Microsoft and Cisco, have both chosen to leverage their own proprietary mechanisms for client validation and network access enforcement. The respective approaches may be loosely rooted in 802.1X technology, but they share no common ground in terms of implementation or interoperability.

Microsoft’s entry into the market, dubbed Network Access Protection, is of particular concern to Cisco and third party validation and access control vendors such as Check Point (Zone Labs), Sygate, EndForce, and InfoExpress. While there is little formal information about MS NAP, Microsoft has stated it intends to deliver a solution capable of verifying patch levels and communicating with select third party clients (such as anti-virus). Cisco and Check Point have already forged such alliances, and are shipping products capable of communicating that validation information today.

Why is Microsoft re-inventing the wheel with its NAP technology? From its perspective, client authentication and verification is a function of the network server. In contrast, infrastructure vendors feel that this enforcement needs to happen before the client can connect to the server, to prevent possible infection before the client has passed its security check. In reality, the solution to the problem lies somewhere in-between-and security vendors should not allow their religious differences to prevent the finding of this common ground.

Each vendor has its legitimate needs as well as its partisan baggage, and each needs to contemplate an acceptable and interoperable compromise. For example, Microsoft, with its dominant desktop presence, does need to deliver an agent capable of collecting and verifying client validation information. But rather than provide enforcement itself, Microsoft would be well advised to pass that information on to the network infrastructure vendor where an enforcement decision can be made. In other words, Microsoft needs to re-evaluate its stance towards Network Access Control, and position itself as a services aggregator. It should spearhead the effort by making NAP an open API to which third parties can connect and exchange data in a standards-based way. Cisco, for its part, needs to back away from its proprietary Cisco Trust Agent and work with Microsoft to develop a standard way to exchange trust data.

Without standards, the IT buyer is the ultimate loser in this competition. The lack of cooperation in the industry surrounding NAC, NAP, and similar technologies needlessly complicates the installation and deployment of these solutions, and discouraging customers from adopting the technology. Competition at the expense of the greater good of customer network security is not a recipe for success, and it the responsibility of the entire industry to standardize on a single way to provide this service to the customer.

Recommended Vendor Actions

• Microsoft needs to re-evaluate its Network Access Protection technology roadmap, specifically considering how it can provide a more open architecture for interoperating with third parties on the software and infrastructure side. Microsoft can take this action in conjunction with its existing strategy, but should ensure that a single, common mechanism is presented for both querying the host integrity of the workstation and providing agent-to-agent communication on the workstation.
• Cisco needs to lead the industry towards a single mechanism for NAC/NAP by opening its Cisco Trust Agent API to all parties and working with the industry to refine the trust agent into a universally accepted mechanism. Cisco should also spearhead the industry effort to collaborate with Microsoft to define a single, built-in Windows API for communicating trust information between clients and the network.
• Third party vendors competing in the network access control space should appeal to Microsoft to create a standard, open API which would enable them to leverage Microsoft’s host integrity agent and communicate in a single, standard way with other supporting applications such as anti-virus, host-based IDS, etc.
• Infrastructure vendors should appeal to Microsoft to create a standard back-end mechanism for querying host integrity information from the operating system. Infrastructure vendors need this functionality to achieve universal support for host integrity checking without client-side software.
• Infrastructure, operating system, and software vendors need to gather together under a single industry standards body to provide a standard mechanism for host integrity verification, providing the IT manager with a single, viable solution rather than the scattered, multi-vendor approach that exists today.

Recommended User Actions

• End users can effectively deploy host integrity checking today using a variety of third party platfrorm-independent solutions from vendors including Check Point (Zone Labs), Sygate, and InfoExpress. These solutions offer a less proprietary, though possibly more costly solution than proprietary offerings from Cisco today and Microsoft in the future.
• End users should put pressure on Cisco and Microsoft to use open standards-based mechanisms to provide host integrity verification. End users should approach solutions from Cisco and Microsoft cautiously, as they use proprietary mechanisms that are subject to interoperability issues and require third party support from other vendors to operate properly.
• Infrastructure vendors should rally behind third party vendors (Zone, Sygate, etc) and focus on developing a standardized way of communicating advanced host integrity information between the network and the trust agent.
• Third party software developers should collaborate with Zone Labs and Sygate to create a standard API for communicating trust information between different software platforms, and should submit that API to Microsoft as the framework for a standard windows API for host integrity verification.