NAC vs. NAP

It all started with the Blaster worm in August 2003. That disastrous epidemic proved once and for all that boundary gateway protection alone is a failed security strategy. Since then, beginning with broader adoption of host-based personal firewalls, vendors have been cooking up host-based schemes to harden the “soft, chewy” center of the network. The most interesting battle over how end-point defense should proceed is between Cisco’s NAC (Network Admission Control) and Microsoft’s NAP (Network Access Protection).

Both NAC and NAP fall under the rubric of Network Access Management, aka end-node quarantining, which  assures that computer nodes are securely configured -- with a firewall, anti-virus software, up-to-date patches, and so on -- before they are given normal or continuing access to the network. Otherwise, they’re quarantined.

Cisco currently leads the field with its NAC platform. To work, NAC requires Cisco products. All NAC-compliant end point and application server solutions,    such as anti-virus, firewall, and so on, must communicate with the freely available, often embedded Cisco Trust Agent client software to determine compliance. NAC also requires NAC-aware Cisco network access point equipment and the proprietary Cisco Secure Access Control Server.

Microsoft’s NAP is at an earlier phase. The NAP server will be a core component of future Windows server versions, but cost and licensing has not been decided. NAP requires a NAP server (to be released only on the next server product release), a NAP client (XP Service Pack 2, Vista, or Server 2003), a quarantine server (Microsoft Internet Authentication Services), and one or more policy servers. NAP works by controlling access via DHCP leases, VPN quarantine, 802.1x, or IPSec with x.509 certificates. Although NAP is not yet available outside of beta testing, many vendors have already pledged support.

The risks of choosing one platform over another could be significant. NAC is potentially a more secure solution because end points can be secured at network layer 1 through layer 3, but it requires a Cisco network device (Cisco may eventually allow other network device vendors to join the NAC family). In theory, Cisco can easily extend NAC beyond Microsoft products, but only Windows clients are supported currently.

NAP could debut at minimal cost. Windows XP Service Pack 2, with an update, can be a NAP client. As with Microsoft’s current Network Quarantine Access Control offering, NAP could be offered as a free server component. NAP could come along at no additional cost as customers regularly update their Windows servers. NAP doesn’t require proprietary hardware, but at the same time, that lack of reliance means a slight increase in the possibility of malicious code being transported around a NAP-enabled network than around a network employing Cisco’s solution.

NAC and NAP are in their infancy. Many vendors support both platforms, but most network administrators will be forced to align themselves into one camp or the other to ease central management. Cisco and Microsoft have pledged interoperability and have even licensed each other APIs, but the details are not forthcoming.

During the NAC vs. NAP wars, a third option has emerged: The Trusted Computing Group TNC (Trusted Network Connect) initiative. TNC’s architecture theoretically functions in the same way the other two solutions do but without the proprietary requirements. Microsoft and Cisco have pledged support, but unless customers demand TNC compatibility, why would the two titans expend effort on an initiative that threatens their interests?

Even if you’re not considering a network access management solution now, investments now may well lock you into one scheme or the other in the future.