Wherefore art thou TCG IF-MAP?

This all started, as many things do, with an article by Hoff wherein this idea was posed.

I’m really interested in how many vendors outside of the NAC space are including IF-MAP in their roadmaps. While IF-MAP has potential in convential non-virtualized infrastructure, I see a tremendous need for it in our move to Infrastructure 2.0 with virtualization and Cloud Computing.

Integrating, for example, IF-MAP with VM-Introspection capabilities (in VMsafe, XenAccess, etc.) would be fantastic as you could tie the control planes of the hypervisors, management infrastructure, and provisioning/governance engines with that of security and compliance in near-time.

So, of course, a response was crafted by NACMeister Alan Shimel who thoughtfully sets Hoff straight on the state of TCG/TNC adoption by NAC vendors, explaining it this way.

I think very few vendors are actually supporting and have implemented it. In fact it is not just non-NAC vendors, it is NAC vendors as well. Other than Juniper, I am not aware of another NAC vendor who actually supports MAP yet. Not because we don’t want to, it is just not important enough. Customers have not demanded it. So no one has the cycles to spend on it.

And predictably Steve Hanna fired back with this explanation of the TNC adoption curve.

I have found that standards adoption follows the classic innovation adoption lifecycle. Innovators are the vendors and customers that have the vision and foresight to see where things must go. They are the first to create and adopt new technology. Next come Early Adopters, Early Majority, Late Majority, and Laggards. It takes at least a year for each stage: six months to turn prototypes into products and six months for the next generation of adopters to catch on. That’s the timescale we’ve seen for the other TNC standards. So I expect to see Innovator vendors shipping products that implement IF-MAP in the next few months and Innovator customers deploying those products in the months after that.  Then will come Early Adopters and so on.

So clearly I couldn’t let this topic slide by untarnished by my view from the NAC trenches.

In principle I don’t disagree with anybody here. I mean as a card-carrying member of the group who would enjoy the most benefit from adoption of TCG/TNC – NAC software developers – what’s not to like? A standard. Everybody being able to interoperate. Not having to design one-off protocols to allow your own products to interoperate. Reverend Hanna, you are preaching to the choir – say Amen!

But Alan’s point about customers not demanding it is the nasty thing floating in the TCG/TNC NAC adoption koolaid punch bowl. However I think the reason for this lack of demand is more problematic than “it simply hasn’t hit the customer’s radar”. Given that TNC’s raison d’être is to allow different vendors’ products to interoperate such that a customer could integrate new stuff into an existing environment or do a “best of breed” grab bag for a complete NAC solution; and given that implementing a real, working NAC solution is, shall we say, non-trivial; I don’t see customers clamoring for this feature any time soon. I mean, it is challenging enough to get a single vendor’s NAC solution working in your environment even with copious amounts of support from that vendor. It makes me queasy to even think about trying to make multiple competing NAC vendors’ stuff play nice. Much less actually work. Cage match maybe, NAC solution not so much.

So I’m thinking that Hoff’s ideas may actually help TCG/TNC adoption get traction quicker than the NAC purveyors it was intended to corral into a single herd. Because at the end of the day, I don’t really think customers give a rodent’s patoot whether or not your NAC product implements an industry standard. They just want NAC with the least amount of pain and suffering. If and when we can make TCG/TNC the agent of that blessed relief, then it will be.

So say we all.

NAC: answering the right questions

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.