The NAC Attack

This Musing continues the Long Conversation About Security started in October of last year and continued in November and December.  The last Musing was about the 2^nd Phase of Cisco’s Self Defending Network (SDN) initiative called Network Access Control (NAC).  In this Musing, we bring the description of SDN up-to-date, including Cisco’s recently announced Adaptive Threat Defense (ATD) and discuss the limitations of SDN overall.

One of the downsides of writing serial Musings is that something is bound to change as one develops a story across multiple months.  In this case, Cisco announced Phase 3 of SDN – Adaptive Threat Defense – at the 2005 RSA show in February.  I wasn’t expecting for Phase 3 to be announced yet and was going to use this Musing to describe what I believe to be the limitations of NAC.  Now I have to change my plan and talk about what the limitations of NAC and ATD are!

Let’s start with the original and easier target – NAC.   The problem with NAC starts with the number of moving parts required to deploy it.  This implies a lot of both CAPEX and OPEX, and then more of both down the road as one attempts to keep all of the components in release lock-step to ensure on-going interoperability and functionality. 

The diagram above shows the items you will probably need to add, upgrade, or replace to deploy NAC.  Basically, everything, including all clients and servers, needs to be touched.  And not once, but possibly over and over again and all components of the system incrementally evolve.  That probably explains that “Cheshire cat” smile on your Cisco sales rep’s face as he glanced at his Rolex while heading towards his BMW.  You inevitably get a chill down your spine when he or she suggests a meeting to go over the latest news related to their Send Dollars Now (SDN) initiative. 

But let’s remember, the pain we are trying to alleviate here is enormous.  So sending Cisco a few million dollars and undertaking all the effort of installing software from multiple vendors on every client and server, upgrading or replacing every wiring closet switch, displacing your existing RADIUS server with one from Cisco, layering in and integrating with a bunch of new back end authentication servers, deploying multiple disjoint management applications, developing new operational methods and procedures around all of this new technology, and training your IT staff across all disciplines, would all be worth it if it really alleviated the pain. But does it? 

“Santa Clara, we have a problem.”

Even with all the effort associated with NAC, it doesn’t seem like it will really significantly alleviate security issues.  Let’s assume that NAC ensures that every device connected to the network is running the proper software – the latest antivirus software with the latest signatures, the latest adware/spyware software, the latest OS updates and patches, etc.  You’ll probably still get infections.  Cisco and other vendors readily admit this.  One of the popular presentation diagrams these days  shows how the time between an OS or application being introduced, vulnerabilities being recognized by “bad guys”, and an exploitation being created, has reduced over time from years to months to weeks to days.  What that means is that even if you have the latest and greatest software on every network-attached device, you are still only hours away from potentially being successfully attacked.  Every day is “zero-day.” 

So you still need an effective way of detecting and protecting against such infections. NAC doesn’t do that. NAC only says “his software looks up-to-date to me, let this guy connect”.  NAC doesn’t follow up by monitoring traffic and detecting whether there truly are infections, or possibly even worse - anomalous behavior by the user that might indicate a directed attack.  NAC just assumes that the admittance decision it made based on information provided by the potentially corrupted endpoint itself  is good enough to ensure system integrity.  It’s kind of like meeting a seedy character in a back alley, asking them if they intend harm, and if they say no, turning your back on them.    

NAC, ala Cisco, is at best a desktop software configuration management tool, not a security tool.

Plus – even if you believe that NAC does give you some security protection - you can’t have NAC everywhere.  There are plenty of devices for which the NAC-required host software doesn’t exist or is irrelevant (FAX machines, IP Phones, clients running old versions of Windows, MAC clients, some Linux clients, HP-UX servers, AIX servers, some PDAS and cell phones, etc.). And as client and server operating systems evolve, there will always be a lag between new versions and NAC support.  So the lack of coverage will get worse with time, not better.  Plus some IT people aren’t at all comfortable with introducing new OS patches, for instance, into their production environments as soon as they are available.  Some of these people like to test and “soak” fresh technology first to make sure it doesn’t adversely affect application operation.  Crazy, huh? 

Cisco says the lack of coverage is not a problem because they have some kind of device that can test such devices for vulnerabilities and infections across the network, without requiring endpoint software, before allowing them to connect to the network.  Two questions immediately come to mind when I hear that from Cisco:

1. If that technique really works, why do I need all this other NAC crap?
2. If that technique doesn’t work, and therefore my network is vulnerable to such devices, what’s the value of all this other NAC crap?  This is a situation where a partial solution is no solution.

Cisco has essentially admitted to these issues related to NAC in the process of introducing Adaptive Threat Management to the market.  I believe that Adaptive Threat Management is their updated term for what they initially called Phase 3 of SDN when they first announced the roadmap – Network Infection Containment (NIC). 

It’s interesting that they announced Phase 3 of SDN before they’ve even delivered on Phase 2 of NAC (LAN security).  As a Cisco Product Manager said at RSA in the beginning of a presentation about ATD, “Things are starting to get interesting.  We’re moving from a phase of pure Marketecture  to one where we’re getting close to starting to deliver on some components of a real security solution”.  I doubt he knew just how honest he was being.  It makes me feel kind of silly for criticizing the previous Phases of SDN.  If I had known it was just Marketecture, I wouldn’t have bothered.

Once again, in ATD, there are a lot of moving parts.  There are upgrades to firewalls, VPN devices, routers, switches, and desktop software, as well as the introduction of new Catalyst modules (for DDOS), and management applications (not just one, but two). 

As opposed to NAC, which seemed fairly well thought out architecturally, albeit unwieldy, ATD seems a little thrown together.  There is a lot of overlap in functionality and how the component parts add up to a complete solution is difficult to divine.  It seems more like an attempt at a unifying story for a bunch of individual product team enhancement and acquisition decisions. 

In spite of that, for the WAN perimeter, ATD offers what looks to be some reasonable options. But I don’t think the WAN perimeter is where the major security issues are any more.  I care more about the internal perimeter, i.e. the LAN.   

In the LAN, ATD doesn’t offer so much. The main ATD component relevant for the LAN is IPS 5.0 (although there may be some useful IOS features in release 12.3(14)T if you are willing to upgrade all of your routers).  Let’s assume IPS 5.0 truly has the features required to detect, quarantine and remediate infections within the LAN (there is not enough information presently available yet to do anything more than assume).  One thing I haven’t been able to get an answer on from Cisco is how ATD and NAC work together. I believe that essentially they don’t. If the Cisco IPS detects an issue with a host, it will use its own methods of blocking or quarantining that host, even though such mechanisms are also built into NAC.  My worry here is “split brain” behavior that could come from two systems independently regulating access.  

But the good news is that you’ll never actually experience a potential problem such as this because you simply won’t be able to afford it.  NAC is already hugely expensive, but may look modest compared to ATD.   The top-of-the-line IPS from Cisco is spec’d to run at 1 Gbps and is priced at more than $60,000.  Where are you going to deploy such devices so that you can detect infections coming from wired desktops before they infect a large number of other users?  Do you desire to keep infections within the set of users served by a wiring closet?  If so, are you willing to spend $120,000 (assuming 2 Gigabit downlinks per wiring closet) per wiring closet to achieve that goal?  If not, are you willing to let more devices get infected every time “briefcase firewall bypass” occurs in order to save money?  The present price/performance of Cisco IPS technology simply does not allow it to be used effectively in the LAN.

In Summary

The motivation and goals of SDN are right on.  More control over who accesses the network when and for what purpose is desperately needed. And attacks, from both outside the network and within, need to be squelched. 

Cisco is a great company that does a lot of things well, and will probably dominate some new markets they are attacking ferociously such as VoIP and storage networking.  But SDN is about adding value in the core market segment they traditionally dominate – large enterprise.  It’s not totally clear whether they are trying to defend their customers networks or are trying to defend the revenue stream that comes from them. They’ve tried to go for a systems approach that involves a lot of components.  Technically, this approach may be required to cover every corner case.  I’m sure Cisco truly believes that.  Surely they aren’t motivated by trying to get every enterprise to completely churn their stable and paid-for infrastructure once again, are they?

But the Cisco solution, if ever fully delivered, is unwieldy because it involves the addition, upgrade, or replacement of so many components in the network, and the infection containment part of the solution won’t scale economically.   Therefore I believe it will collapse from its own weight and thus provide opportunities for other vendors, such as Juniper and a whole slew of smaller companies, to attack Cisco in a market segment they haven’t had much competition in for years. 

Starting with next month’s Musing, we’ll start to characterize some of the alternative solutions being promoted and try to separate the wheat from the chaff.