NAC Attack: Why NAC doesn't work and SN(i)F doesn't, either...alone

I have to admit that when I read Alan Shimel's blog entry whereby he calls out Richard Stiennon on his blog entries titled "Don't Bother with NAC" and "Network Admission Control is a Blind Alley," I started licking my chops as I couldn't wait to jump in and take some time to throw fuel on the fire.  Of course, Mike Rothman already did that, but my goal in life is to be more inflammatory than he is, so let the dousing begin!

I've actually been meaning to ask for clarification on some points from both of these fellas, so no better time than the present. 

Now, given the fact that I know all of the usual suspects in this debate, it's odd that I'm actually not siding with any of them.  In fact, I sit squarely in the middle because I think that in the same breath both Richard and Alan are as wrong as they are right.  Mike is always right (in his own mind) but rather than suggest there was a KO here, let's review the tape and analyze the count before we go to the scorecards for a decision.

This bout is under the jurisdiction of and sanctioned by the Nevada Gaming Commission and brought to you by FUD -- the offical supplier of facts on the Internet. ;)

Tale of the tape:

Richard Stiennon:

1. Richard Stiennon highlighted some of Ofir Arkin's NAC "weaknesses" presented at Black Hat and suggests that NAC is a waste of time based upon not only these technical deficiencies but also that the problems that NAC seeks to solve are already ameliorated by proper patching as machines "...that are patched do not get infected."
2. Somewhat confusingly he follows on with the statement based upon the previous statement that "The fear of the zero-day worm or virus has proved ungrounded. And besides, if it is zero-day, then having the latest DAT file from Symantec does you no good."
3. Richard suggests that integrating host-based and network-based security is a bad idea and that the right thing to do is based upon  "de-coupling network and host-based security. Rather than require them to work together let them work alone."
4. Ultimately he expects that the rest of the problems will be fixed with a paradigm which he has called Secure Network Fabric. 
5. Richard says the right solution is the concept he calls "Secure Network Fabric (SNF)" wherein "...network security solutions will not require switches, routers, laptops, servers, and vendors to work in concert with each other" but rather "...relies most heavily on a switched network architecture [which] usually involve[s] core switches as well as access switches."
6. SNF relies on the VLANs that "...would be used to provide granularity down to the device-level where needed. The switch enforces policy based on layer 2 and 3 information. It is directed by the NetFlow based behavior monitoring system.
7. Richard has talked about the need for integrating intelligent IDP (Intrusion Detection and Prevention) systems coupled with NBA/NBAD (Network Behavioral Analysis/Network Behavioral Anomaly Detection) and switching fabric for quite some time and this integration is key in SNF functionality.
   
   
8. Furthermore, Richard maintains that relying on the endpoint to report its health back to the network and the mechanisms designed to allow admission is a bad idea and unnecessary.
9. Richard maintains that there is a difference between "Admission Control" and "Access Control" and sums it up thusly: "To keep it simple just remember: Access Control, good. Admission Control, bad."

Alan Shimel:

1. Alan freely admits that there are some technical "issues" with NAC such as implementation concerns with DHCP, static IP addresses, spoofed MAC addresses, NAT, etc.
2. Alan points out that Richard did not mention that Ofir Arkin also suggests that utilizing a NAC solution based upon 802.1x is actually a robust solution.
3. Alan alludes to the fact that people deploy NAC for various reasons and (quoting from a prior article) "...an important point is that NAC is not really geared towards stopping the determined hacker, but rather the inadvertant polluter."  Hence I believe he's saying that 802.1x is the right NAC solution to use if you can as it solves both problems, but that if latter is not your reason for deploying NAC, then the other issues are not as important.
4. Alan points to the fact that many of Richard's references are quite dated (such as the comments describing the 2003 acquisition of TippingPoint by 3Com as "recent" and that ultimately SNF is a soapbox upon which Richard can preach his dislike of NAC based upon "...trusting the endpoint to report its health."
5. De-coupling network and host-based endpoint security is a bad idea, according to Alan, because you miss context and introduce/reinforce the information silos that exist today rather than allow for coordinated, consolidated and correlated security decisions to be made.
6. Alan wishes to purchase Pot (unless it's something better) from Richard and go for a long walk on the shore because Mr. Stiennon has "the good stuff" in his opinion since Richard intimates that patching and configuration management have worked well and that zero-day attacks are a non-entity.
7. Alan suggests that the technology "...we used to call behvior based IPS's" which will pass "...to the switch to enfore policy" is ultimately "another failed technology" and that the vendors Richard cites in his BAIPS example (Arbor, Mazu, etc.) are all "...struggling in search of a solution for the technology they have developed."
8. Alan maintains that the SNF "dream" lacks the ability to deliver any time soon because by de-coupling host and network security, you are hamstrung by the lack of "...context, analytics and network performance."
9. Finally, Alan is unclear on the difference between Network Access Control (good) and Network Admission Control (bad.)

So again, I maintain that they are both right and both wrong.  I am the Switzerland of NAC/SNF! 

I'll tell you why -- not in any particular order or with a particular slant...

(the bout has now turned from a boxing context to a three man Mixed-Martial-Arts Octagon cage-match!  I predict a first round submission via tap-out):

1. Firstly, endpoint and network security MUST be deployed together and ultimately communicate with one another to ultimately effect the most visible, transparent, collaborative and robust defense-in-depth security strategy available.  Nobody said it's a 50/50 percentage, but having one without the other is silly.  There are things on endpoints that you can't discover over a network.  Not having some intelligence about the endpoint means the network cannot possibly determine as accurately the "intent" of the packets spewing from it.
2. Network Admission Control solutions don't necessarily blindly trust the endpoint -- whether agent or agentless, the NAC controller takes not only what the host "reports" but also how it "responds" to active probes of its state.  While virtualization and covert rootkits have the capability to potentially hide from these probes, suggesting that an endpoint passes these tests does not mean that the endpoint is no longer subject to any other control on the network...
3. Once Network Admission Control is accomplished, Network Access Control can be applied (continuously) based upon policy and behavioral analysis/behavioral anomaly detection.
4. Patching doesn't work -- not because the verb is dysfunctional -- but because the people who are responsible for implementing it are.  So long as these systems are not completely automated, we're at risk.
5. Zero day exploits are not overblown -- they're getting more surgically targeted and the remediation cycles are too long.  Network-based solutions alone cannot protect against anomalies that are not protocol or exploit/vulnerability signature driven...if the traffic patterns are not abnormal, the flags are OK and the content seemingly benign going to something "normal," it *will* hit the target.
6. You'll be suprised just how immature many of the largest networks on this planet are in terms of segmentation via VLANs and internal security...FLAT, FLAT, FLAT.  Scary stuff.  If you think the network "understands" the data that is transported over it or can magically determine what is more important by asset/risk relevance, I too would like some of that stuff you're smoking.
7. Relying on the SNF concept wherein the "switch enforces policy based on layer 2 and 3 information," and "is directed by the NetFlow based behavior monitoring system" is wholly shortsighted.  Firstly layer 2/3 information is incredibly limited since most of the attacks today are application-level attacks and NOT L2/L3 and Netflow data (even v9) is grossly coarse and doesn't provide the context needed to effectively determine these sorts of incursions.  That's why NetFlow today is mostly used in DDoS activities -- because you see egregiously spiked usage and/or traffic patterns.  It's a colander not a sieve.
8. Most vendors today are indeed combining IDP functionality with NBA/D to give a much deeper and contextual awareness across the network.  More importantly, big players such as ISS and Cisco include endpoint security and NAC (both "versions") to more granularly define, isolate and ameliorate attacks.  It's not perfect, but it's getting better.
9. Advances in BA/NBA/NBAD are coming (they're here, actually) and it will produce profound new ways of managing context and actionable intelligence when combined with optimized compute and forwarding engines which are emerging at the same time.   They will begin, when paired with network-wide correlation tools, to solve the holy trinity of issues: context, analytics and performance.
10. Furthermore, companies such as ISS and StillSecure (Alan's company) have partnered with switch vendors to actually do just what Richard suggests in concept.  Interestingly enough, despite the new moniker, the SNF concept is not new -- Cisco's SDN (albeit without NAC) heavily leverages the concepts described above from an embedded security perspective and overlay security vendors such as ISS and Crossbeam also have solutions (in POC or available) in this area.
11. Let's be honest, just like the BA vendors Alan described, NAC is in just the same position -- "struggling in search of a solution for the technology they have developed."  There are many reasons for deploying NAC: Pre and Post-inspection/Quarantine/Remediation and there are numerous ways of doing it: agent-based/agentless/in-line/out-of-band... The scary thing is with so many vendors jumping in here and the 800 pound Gorilla (Cisco) even having trouble figuring it out, how long before NAC becomes a feature and not a market?  Spending a bunch of money on a solution (even without potential forklifts) to not "... stop the determined hacker, but rather the inadvertant polluter" seems a little odd to me.  Sure it's part of a well defined network strategy, but it ain't all that yet, either.
12. With Cisco's CSO saying things like "The concept of having devices join a network in which they are posture-assessed and given access to the network in a granular way is still in its infancy" and even StillSecure's CTO (Mitchell Ashley) saying "...but I think those interested in NAC today are really trying to avoid infection spread by an unsuspecting network user rather than a knowledgeable intruder" it's difficult to see how NAC can be considered a core element of a network security strategy WITHOUT something like SNF.

So, they're both right and both wrong.  Oh, and by the way, Enterprise and Provider-class UTM solutions are combining ALL of this in a unified security service layer... FW, IDP, Anti-X, NBA(D) and SNF-like foundations.

[Tap before it breaks, boys!]

We need NAC and we need SNF and I've got the answer:

1. Take some of Richard's "good stuff"
2. Puff, puff, pass
3. Combine some of Alan's NAC with Richard's SNF
4. Stir
5. Bake for 30 minutes and you have one F'N (good) SNAC
   (it's an anagram, get it!)

There you have it.

Chris