NAC & NAP: Two Horses of the Same Color?
Network Security: Cisco and Microsoft are behind two of the most prominent network access initiatives. Both raise troubling questions about vendor lock-in and client support.
What's the largest risk in an enterprise network?
It's the transient computers, not the ones you control and patch on a daily basis. It's the CEO's laptop that caught a virus at Starbucks, or a student's laptop that introduces a new worm behind your perimeter.
Both Microsoft and Cisco have offerings to deal with this risk, though. NAP, or Network Access Protection, comes from Microsoft. NAC, or Network Admittance Control, is Cisco's solution. Both are basically the same: they require that client software be installed on each and every computer. The NAP or NAC server will query the host wishing to gain network access, and ask it to kindly provide some information about how clean it is. Both solutions check to make sure all available patches are installed, as well as the latest virus definitions.
If you're thinking this is a bad design, you're probably right. Last year I wrote about a homegrown solution that works without client software, but relies on network-based anomaly detection or administrator intervention. NAC and NAP are the second best options in some aspects, but advantageous in others. The ability to actually check if a computer has been updated is a huge advantage, and only works if the computer has installed the client software, but hopefully not a hacked version.
Both Cisco and Microsoft's solutions have an API for 3rd party software. Antivirus vendors are updating their software to allow the NAC or NAP client software to query for status reports. Don't be surprised to see malicious versions of the client software whose goal it is to always report an "OK" status. Of course, the most likely place this will turn up is in the next nasty virus.
NAP: Intrusive, with a Touch of Lock-In
First, the NAP solution from Microsoft: it's a bit intrusive to say the least. Your entire network will be changed to support this new infrastructure. The NAP solution relies on a Windows DHCP server running on the still unreleased Windows "longhorn" server. A client installed on every PC, called the Quarantine Agent (QA), is queried by the DHCP server for information about the computer's health. This information is submitted to a server running IAS, the Internet Authentication Service, via RADIUS. If the PC is granted access, it is given an IP address that's allowed full access. If the computer is deemed to be in poor health, it's given a "quarantine IP" which will place it within a quarantine subnet. Readers who have been following our Networking 101 series know that this is easily circumvented, since both the good and bad PCs will be in the same broadcast domain. The bad ones can simply assign themselves a good IP and be off and running, or infecting. It is also clear that with Microsoft's NAP solution administrators will have to delegate DHCP services to a Windows server. This is a scary prospect for many organizations, not to mention a management nightmare if it's still necessary to run non-Windows DHCP server as well.
NAC: Same Color, Different Horse
Cisco's NAC is basically the same, except that it uses 802.1X at the port-level. The client software for NAC is called CTA, or Cisco Trust Agent. After the switch it's speaking with queries the client, the information is then passed to an Access Control Server (ACS). The ACS makes the decision, and the switch will either allow or deny access. If access is denied, the computer simply isn't allowed to send any data, or its switch port is flipped into a quarantine VLAN. If a machine is allowed to talk to its normal network, it can then attempt to obtain DHCP by the normal means. If it's in the quarantine VLAN, it's given DHCP as well, but the default router will be more strict. Presumably, for the quarantine subnet, the router will still allow a host to update itself, but deny all other access. This is clearly the most secure and user-friendly option.
Both NAC and NAP also work with VPN connections, so remote users aren't as much of a concern as they once were. That is, assuming you're not allowing IPSEC connections to anything but a Cisco router or Windows Server that's capable of running NAC or NAP. Both NAC and NAP also assume you're a corporation that has control over the software that's installed on the client computer.
Being locked into a vendor's solution is certainly a valid concern. If you adopt the Windows solution, chances are you're only supporting Windows clients. The Cisco network-based solution is just as capable of querying Windows clients to inquire about health, but it offers a more secure quarantine. Both companies have promised their technologies will be compatible, but it's hard to say what that really means. Cisco plans on creating a CTA client for Unix and Linux, so for people who aren't already hopelessly locked into one vendor's product, there's a solution. Currently, only the Windows client exists though.
The inherent insecurities aren't a concern if you're simply trying to block honest people, but they're valid if you're searching for a truly secure environment. The big issues, for those looking for a secure solution, are: client software being replaced with malicious versions, and NAP clients guessing a non-quarantined IP address. If Cisco implements an anomaly detection appliance with NAC, they will be able to deny access to infected clients automatically, regardless of whether or not they have the client software running.
Neither solution prevents authenticated and authorized computers from becoming infected and spreading the infection to others. Both solutions are a step in the right direction, though. Both will be intrusive and possibly lock you into a vendor's product. Be sure to think carefully about the level of security you require for client authentication before adopting the non-network-oriented solution.