Let me start this off by setting a baseline. I know a lot about Network Access Control (NAC). A real lot. I work on (as in design, develop and support) what is arguably the industry leading and undeniably the best NAC solution in the industry. I’ll let you guess, since I’m not a shill for my employer. Don’t get paid for it, don’t do it, don’t care. Just say no to marketing. In any case, I know a lot about NAC.
So I sign up for a videocast entitled “NAC: Answering the hard questions” which has this intriguing abstract (emphasis mine):
A recent survey showed that of the companies that already have NAC deployed, 36% said their networks became infected with malware anyway. Clearly, there are still plenty of questions about NAC that need to be addressed. In this video, Joel Snyder, one of the top NAC experts in the industry, will help viewers answer the most pressing questions surrounding this technology, including:
- How do you handle lying endpoints?
- How does NAC extend to branch offices?
- How much does NAC’s effectiveness rely on the security of your network infrastructure?
- And more
I’ve tried to find the source of this study because those afflicted 36% really need to check out my earlier posting “Security Ideas for your mom part 1”. Wherein I enumerate the most important ideas (in my humble opinion) that your mom needs to know about secure computing. Let me quote myself from idea #2:
“don’t use something you don’t understand.”
You see Network Access Control does not directly prevent your network from being infected by malware. What it does, when configured correctly, is verify the security posture of your network endpoints before allowing them access to your network. In other words, a good NAC system will check to see that a PC requesting access to your network has whatever Anti-Virus programs you require installed and that the engine and signatures are up to date, but it will not check to see if the endpoint is already infected with a virus or if the AV package itself is worthwhile. Furthermore, NAC systems have the facility to “white list” certain endpoints since it’s usually a career limiting move (CLM) to quarantine the CEO’s PC. But if your CEO likes to surf for porn on said PC, it might be a CLM, but it’s still not a bad idea for security. So the general statement you can make about NAC is that it will only validate and enforce compliance to your security policy. It will do nothing to make sure your policy doesn’t suck or that you haven’t swiss-cheesed it to allow unlimited access to clueless VIPs. So let me say this once and for all – NAC is not magic. It is not a silver bullet. It will only enforce your network access policies, regardless of how lame they are, and only then if you configure the system correctly.
So I watched the videocast. I’d actually recommend it. Dr. Joel Snyder is a very sharp guy even if he relies a bit heavily on vendor marketing. Since I couldn’t find a place to comment on the site that hosted the videocast (Bitpipe), I decided to comment here. Okay, I was planning on commenting here anyway.
How do you handle lying endpoints? Well, if you are one of the NAC products that Dr. Joel is familiar with, apparently rather badly. He references the Trusted Computing Group (TCG) Trusted Network Connect (TNC) architecture to point out that ultimately system health telemetry originates from sensors on the endpoint itself (Integrity Measurement Collectors (IMC) in TNC lingo). Yep, that’s a problem all right – with the TNC reference architecture. He correctly concludes that some other mechanism (e.g. TCG Trusted Platform Module (TPM)) must be utilized to assure the integrity of the client-based sensors. Okay, how about this idea instead: lets start by assuming that all endpoints are lying (or are capable of lying) and instead of relying on the endpoint to give us a statement of health, have our Policy Decision Point check for itself. There are NAC products (at least one) that do this today. And it works really well. And it can even be done without any kind of agent software installed on the endpoint. Is it magic? No – just really clever design (if I say so myself). Now there are clearly some advantages to the TNC take on this, most obvious is that the vendor of the endpoint security software you want to check for compliance is in the best position to know the health of their stuff and they can build their own IMCs. Problem is, when you have Vendor A’s AV and Vendor B’s firewall and Vendor C’s HIDS running on Vendor M’s platform you are trusting that these vendors will play nicely with each other. Even when they have competing products. You bet.
How much does NAC’s effectiveness rely on the security of your network infrastructure? Dr. Joel answers this one with an emphatic “a lot”. Thereby earning him the Security For All GOTO award for his outstanding Grasp Of The Obvious. Of course NAC’s effectiveness relies on the security of your network infrastructure – in fact, it is predicated on it. If your network infrastructure is not secure, NAC will certainly not make it so. In fact I would go so far as to say that slapping NAC into an insecure environment is no more than security theater – users see it and think they are more secure, while nothing (good) really happens securitywise. To be fair, Dr. Joel is mostly warning NAC implementers to be aware that in all likelihood you will have NAC enforcement at the edge of your network and that it does, in fact, become another attack surface. Of course, it was probably already an attack surface before NAC was added to the picture. The point is that if you are using old leaky routers and switches, or a bad network security architecture you should probably take care of that stuff before you even think about adding NAC into the mix.
Marketeer’s have done an outstanding job of overhyping NAC. The fact that Dr. Joel even has to make himself a candidate for the GOTO award (and my bothering to award it to him), is a testament to how successful NAC vendors have been at getting folks to breathe their exhaust. And it does everyone a disservice. NAC is not magic. There is no silver bullet. Period.
Security For All 