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.
(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.
Comments
The pros and cons of NAC and Analysis: Network Access 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