NAC Is Fighting the Last War

My post on the IETF Network Endpoint Assessment Working Group elicited a comment that suggested I expand on my thoughts, namely that Cisco Network Admission Control (NAC) / Microsoft Network Access Protection (NAP) / Trusted Network Connect (TNC) "are all fighting the last war." Let's see what the comment poster's own company has to say about NAC.

(Please note that although I use NAC in the text that follows [as used by my sources], I could just as easily say NAP or TNC or NEA. I only single out Cisco because they are investing so much effort into NAC.)

Network Admission Control (NAC), a set of technologies and solutions built on an industry initiative led by Cisco, uses the network infrastructure to enforce security policy compliance on all devices seeking to access network computing resources, thereby limiting damage from emerging security threats. Customers using NAC can allow network access only to compliant and trusted endpoint devices (PCs, servers, and PDAs, for example) and can restrict the access of noncompliant devices.

On the surface, that sounds reasonable. But lets think about the problem we are really trying to solve. Why does one seek to "enforce security policy compliance on all devices seeking to access network computing resources"? The answer here is "limiting damage from emerging security threats." What threat might that be? If you spend any time reading NAC and related marketing, you see a common theme:

[NAC] Ensures endpoints (laptops, PCs, PDAs, servers, etc.) conform to security policy... [NAC] Proactively protects against worms, viruses, spyware, and malware; focuses operations on prevention, not reaction...

Again, from this Q&A document:

NAC helps ensure that all hosts comply with the latest corporate security policies, such as antivirus, security software, and operating system patch, prior to obtaining normal network access...

Cisco NAC is able to control and reduce large-scale security events such as virus outbreaks...

Proactive protection against worms and viruses: Cisco NAC reduces and prevents large-scale infrastructure disruptions caused by vulnerability-based exploits...

It enables customers to use their existing network investments, including antivirus and other security and management software.

Basically, NAC and friends is an anti-virus/worm technology. It's a reaction to the biggest problem the industry faced five years ago: viruses and worms like Code Red and Nimda. That malware exploited vulnerabilities for which patches had been available for weeks or months. "If only hosts connecting to our network were patched!" was the complaint. NAC was developed as a "solution," specifically for the Blaster worm of 2003.

Let's assume NAC was instantly available and deployed in 2001. NAC still doesn't solve what any serious security person should consider the real problem: disclosure/theft, corruption, or denied access to a business' data. Malware can be a means to any of those ends, or it can be an end unto itself, simply spreading for the joy of it.

What does NAC have to say about the half-dozen or more publicly exposed zero-days discovered in 2006? Zippo. So what if you're fully patched and NAC lets you in? You could still be owned and then spread that ownage to the rest of the company.

Malware isn't the only way to break the CIA triad, however. NAC has nothing to say about exploiting poorly configured targets that may be fully patched. It does not address transitive trust. It fails when a system is compromised using stolen credentials. Worst of all, NAC is completely worthless when facing rogue or malicious users operating completely compliant endpoints.

I'm sure some NAC advocates will say my focus on malware misses the boat, perhaps citing the following:

Q. Can Cisco NAC provide additional enforcement beyond antivirus, firewall, and security patches?

A. Yes. Cisco NAC is designed to deliver broad policy compliance enforcement capabilities. Even though antivirus, firewall, and security patches are popular examples of security policy requirements, Cisco NAC can enforce other requirements as well. For example, if organizations want to protect the confidential data residing on their mobile users' laptops from physical loss or theft, they can use Cisco NAC to enforce encryption requirements.

That's great, but it doesn't address any of the issues I previously covered.

I've got a cheaper and easier way to ensure I'm not plugging an unpatched Windows host into someone's network. I run FreeBSD on my laptop.

Now, not all NAC is bad, as Richard Stiennon says. First he criticizes NAC as I have done:

I have written often enough about the absurdity of deploying the infrastructure to check the state of a device... My advice is to do NAC and run as fast as you can from system-health monitoring and quarantine...

Here is the twist:

[A]pplying network-level controls to user access... is an idea whose time has come...

I first heard about the concept of the user-defined network from John Roese, CTO of Enterasys Networks, about five years ago. The idea was that there would be a detailed policy for every user that would define a custom network enforced with virtual LANs (VLAN), that gave access only to resources needed to do the user's job.

Not only would an engineer, say, not be able to log into the payroll server but she could not even see it on the network. This subdividing of the network would limit the exposure to risk from the devices connected to it. Infected laptops could not spread their malware to others. Malicious employees would be hampered in their ability to scan the network for targets. Visitors would be limited to Internet access only.

That's a form of segmentation enforced on a per-user level. That's a neat idea, but I wonder just how willing administrators are to go through the trouble. I think 802.1X might be enough for most people, although the rise of virtual systems all sharing a single switch port makes that difficult.

RS has written and podcasted a LOT about NAC -- read/listen here.

So, in brief -- if you want a way to make sure your NAC-compatible devices are patched to some level you want, in order to reduce their vulnerability to malware, in the hope that running a certain version of Windows makes a difference, then use NAC to enforce compliance. Otherwise, don't waste your time or money.


Anonymous said…
Two NAC-related pieces which you may also find interesting are:
The pros and cons of NAC and Analysis: Network Access Control
Anonymous said…
I think endpoint security policy enforcement is less about AV deployment and more about control.

In far-flung enterprises it can be difficult, almost impossible, to control what devices are accessing the LAN, causing perimeter erosion (and a strong perimeter is still important, no matter what the Jericho Forum thinks). Rogue wireless, unmanaged Internet connections, and unauthorized systems make this a challenge.

802.1x goes part of the way to controlling LAN access, but it really authenticates people, not systems.

IPSec domain isolation is fantastic for control, but has other drawbacks (difficult to support outside of Windows environments, encapsulation breaks QoS, network monitoring).

I see endpoint security policy enforcement as a means to improve control, until something better comes along.

- Chris
Unknown said…
So, I think RS is somewhat correct and I also agree with you (Richard) and Chris to an extent - the chief value proposition now is control (access or application) and viruses/worms are no longer the primary driver. Part of the confusion comes from some of the mixed marketing messages from Cisco in the past. I will comment specifically on Cisco since I am more familiar with their approach. There has been a struggle between the NAC framework and the NAC appliances, and it looks like the NAC appliances (formerly Perfigo) are the new direction - and it is because of the control aspect. The CCA (Cisco Clean Access) appliances can enforce security policies such as where you can and cannot go and what network resources you can and cannot access - both in-band or out-of-band (requires 802.1x). As with most solutions, there are caveats depending on the mode, but it is a workable (not perfect) solution today for wired or wireless control of vendors,contractors, internal staff, etc. I agree that there are still some things that are very difficult to prevent (namely malicious internal users with the proper credentials that decide they want to do something bad), but that's where I think defense in depth has to be present. Also, I always recommend customers go a step further and implement HIPS in the form of CSA (yes, I am biased because that is what I have used with good results. I am sure that someone can propose several alternate solutions that do similar things - I am open to learning new tricks if you want to share examples). Having that last step of host protection often makes all the difference in the world and stops the attacks at the last point of defense - the host. Cisco pitches CSA in the overall NAC story but does not require it - so it really depends on who is telling the story (doesn't it always?) The bottom line in my opinion is that there needs to be more consistency in the story and host defense above and beyond the access control offered by NAC. Once you get onto the endpoint, then you can start with the host-based application control - as long as you account for vulnerabilities in the host agent deployment scheme. Richard, you had another interesting post where you mentioned the differences between trusted and trustworthy systems - and I think that is why you need host-level defense and something to validate that host-level defense and be there if it fails (or violates policy ).
Dustin said…
This comment has been removed by a blog administrator.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics