The Evolution of NAC: a response, rave and rant

After catching a quick glimpse of Alan’s post on the Evolution of NAC, I popped over to the Infonetics site to download the whitepaper his post was referring to.

It’s a short 5-pager that will only take a few moments to read, so I encourage you to check it out. For those of you that read my articles and blog, I want to provide a response, noting several things I liked in the report, a few things I think are misleading, and a couple of items that are complete crap (sorry Jeff).

What I liked.
Overall, I really enjoyed the tone and the positive outlook on NAC in the whitepaper. I completely agree with the overall message it sends and the evaluation of organizations’ needs and capabilities of NAC. Certainly, I’ll side with the assertion that NAC solutions have been difficult to implement and unruly (at best) to manage.

The idea (as Alan mentioned) of using other (non-NAC) solutions to provide NAC-like functions and features is something I’ve been discussing for a long time. As it stands for most organizations, there are less expensive and easier means to an end for specific functions they’re seeking without implementing bulky NAC systems.

Having said that, Jeff succinctly notes the ability of NAC to provide a multi-tier level of security for networks and endpoints alike and reminds us of unique features NAC can provide, such as the combination of port security, user use reporting and audit features, change tracking and the availability of real-time data about the network; a contrast to several scan-based inventory solutions that may be used in place of NAC.

In the summary, Jeff notes the inability of many solutions to address the unmanaged devices found on almost all networks and reiterates the growing need for organizations to have a full grasp of everything on the network for real posture analysis and protection. 

All good. I’m on board here.

A bit misleading.
I get the sense that this whitepaper is written based on one or two specific vendor products. I say that because many of the features mentioned are specific to particular products on the market today. Several successful NAC products don’t operate in the methods described and the features mentioned repeatedly are quite specific to other solutions. I’ll leave it at that.

The notion that this is the new, evolved NAC is misleading. You could easily take this whitepaper, remove the dates and, scratch a couple of references and put a publish date of 2007 or even 2004 on it; it wouldn’t be ahead of its time in content.

Along the same lines, the statement in the opening paragraphs that “the latest generation of NAC solutions is far more easily deployed than the first generation” is also misleading. I don’t think we’ve hit the second generation of NAC. The next gen will come as vendors begin implementing the standards and frameworks in progress by organizations like IEEE, IETF and TNC. You can read more about my feelings on Gen 2 NAC in my recent whitepaper Catching the Unicorn: a technical exploration of why NAC is failing. I could argue on further comments by Jeff on “first gen vs second gen” but to spare you long boring explanations, I think the underlying assertion of having a second gen NAC now is wrong.

The whitepaper also says “knowing what’s connected to your network is difficult”. I’m putting this in the misleading section instead of the crap list below, since I agree that maintaining real-time visibility into the network is difficult. I disagree with the notion that basic network discovery is difficult; there are a variety of solutions, both free and fee-based, hardware and software, that provide this function. Everything from switch management tools to NMAP, inventory applications and products such as Great Bay have proven more than effective for network visibility of managed and unmanaged endpoints.

On the third page, we see that “in the absence of a state-of-the-art NAC solution, it would be very difficult for any organization to understand what their employees are installing themselves, or what hackers have managed to install through malware“. Misleading. NAC doesn’t inherently monitor what users are installing. Monitoring or controlling that behavior can be a function of endpoint integrity offered through NAC, but it can most certainly also be offered by OS lockdowns and group directory settings. Using NAC, we would  only be ensuring the presence and status of any endpoint protection already in place. Then, to imply that NAC can find hacker-installed malware goes well beyond misleading.

Wrapping up our misleading section is my personal confusion over Jeff’s multiple statements of new NAC solutions all offering visibility into, and control of, endpoint peripherals and removable media. I opened this section by saying I felt the whitepaper was directed toward a specific product (or products) and the recurrence of this feature solidifies that feeling for me. It is a great feature, but I think it’s touted too heavily here.

The crap.
Here are the few things I take specific exception to. In his opening lines, Jeff alludes to the fact that first generation NAC required complex integration with 802.1X. Well, he doesn’t so much allude to it, as come right out and say it. That’s crap. From the beginning of NAC’s time, no vendor has required 802.1X integration. In fact, I would say most advertise and evangelize that you do not need 802.1X and recommend a layer 3 enforcement model (based on IP filtering instead of 802.1X assigned VLANs).

I get the feeling the author is trying to say second generation NACs are out-of-band, versus previous in-band solutions and that those inline solutions required 802.1X. Again, I say crap. While it’s true Cisco (in the genesis of NAC) offered an inline solution using their products as enforcement points, there have been few other vendors (even fewer successful) that relied on an inline enforcement solution. The rest of the world has offered out-of-band solutions for a long time. In addition, the inline solution does not require 802.1X; that’s one of the perks of an inline solution. The communications can be proprietary and the enforcement can happen without a standard port security (802.1X). I see 802.1X often comingled with or mistakenly confused for NAC. They’re not the same, and neither requires the other. For more, read What is 802.1X? A Technology Primer.

Last, but not least, the idea that “traditional network security solutions – such as firewalls and IPS – provide no protection from insider attacks” is somewhere between misleading and complete crap. It fell on this side of the fence for one reason; I want to reiterate the importance of intelligent network design. If an organization has implemented an intelligent segmented design, conducive to internal security, then the IT teams are probably using LAN-based firewalls and/or IPS systems to control and monitor behavior inside the network. Conversely, a NAC solution is only as good as its underlying network structure. If NAC is implemented to allow or disallow (the guest/employee model mentioned by Jeff) then you are no better protected from insider attacks. NAC systems leverage other security implementations (including firewalls, segmentation, filters, ACLs and IPS) to provide the level of security we expect from them. So, the thought that these traditional systems cannot provide that type of security is quite simply incorrect.

Wrap up.
All in all, I do agree with the overall thought behind the whitepaper. NAC offers things organizations need and we’ll continue to grow this market. Although I disagree with the first and second generation statements and some specific technical assertions, it’s a good whitepaper.

What do you think?

More resources.

• Alan’s post: http://www.ashimmy.com/2009/11/the-evolution-of-nac.html
• Infonetics whitepaper, The Evolution of NAC: http://www.infonetics.com/whitepapers/2009-Infonetics-Research-The-Evolution-of-Network-Access-Control-FINAL-112309.pdf
• My whitepaper, Catching the Unicorn: a technical exploration of why NAC is failing: http://securityuncorked.com/2009/09/catching-the-unicorn-why-nac-is-failing/

# # #