It wasn't that long ago that everyone and their dog wanted in to the NAC market like it was a peep show on pay day. Some NAC companies sprung up from the dirt fully formed through VC funding, while others made (often fatal) changes in product or company direction in order to get a piece of the action. Companies that had nothing to do with NAC - and sometimes nothing to do with security at all - planted their flag on the barren NAC lunarscape to avoid missing out on the inevitable cash cow (that never came).
In the rush to add "Network Access Control" to their datasheets, some companies allowed Bad Ideas to turn into Bad Products. Self Enforcement is one of these Bad Ideas.
Self enforcement was used as a "foot in the door" to the NAC market by a number of vendors. Maybe if you heard they were a NAC company, you'd want to buy their vacuum too...
Often, these companies had an existing software client that included some combo platter of AV, firewall, IDS, and web filtering capabilities. Since they were "already on the desktop" it made sense to beef up the agent with even more functionality. I get that. Customers get that. If you tell them they can get NAC without deploying yet another piece of software to an already overloaded desktop, you have their ear. Now if you can develop that NAC piece by re-using work you've already done, you can provide it cheaply - maybe even for free.
It's a compelling story on the surface, but like all good yarns, it's better in the telling than in reality. What came out of all this is that some companies simply cobbled together the pieces they already had, and called it NAC. (I can almost see Gilligan and Skipper building a NAC solution out of bamboo and coconuts as I type.) A common outcome was a desktop tool that combined maybe AV, IDS and a personal firewall. If the IDS or AV portions sensed a problem, it told the firewall to take the endpoint off the network.
Can you spot the flaw?
Think of the panic buttons on most domestic security systems. It's a good concept... if the neighbour staggers in by mistake one night, hit the button and help is on the way. But nobody - and I mean nobody - expects that if a burglar starts a fire while robbing your place, he's going to use that panic button.
So why on earth would we expect a system that has just been fingered as a security problem to do the right thing?
And yet, that's self enforcement. You've found an "endpoint gone wild" on your network, and now you've politely asked it to refrain from doing anything nasty. What are the odds it's going to buck up and pay attention? Maybe pretty good, but "Maybe" and "Pretty Good" aren't in the CISO's handbook.
And that's just if things are working the way they should be. What if your firewall component crashes? Or worse, the whole combined agent calves? (Stay tuned for a rant on the dangers of a using an overloaded client...)
You could be left with no protection at all, while staring at a deceptively peaceful "green light" on your central console.
I may be jaded, but this sounds like the basis of a good network security policy about as much as trusting someone when they tell you that the red light on their webcam is always on.
I've long believed that it's a mistake to buy into self enforcement just so you can check off the "NAC" box on your requirements sheet. Frankly you'd be no worse off if you skipped it entirely. At least in that scenario you don't labour under the illusion of security.
NAC is not an endpoint graciously bowing out when it shits the bed. Real NAC uses off-box technology to ensure the party crashers are kept offline or hosed down before they're let back on.
My advice? Ask yourself if you want to trust your network's security to a concept like self enforcement. But more importantly, ask your NAC vendor the tough questions up front.
- Log in to post comments