As I read the raging debate this week between Amrit (Williams at BigFix) and Alan (Shimel at StillSecure) about the value of NAC, it struck me how much we can get caught up on semantics. It also seemed that the old adage "the truth is somewhere in the middle" most certainly applies.
If you define NAC as primarily about seeing whether an endpoint is "safe" and deciding to allow someone onto the LAN, concluding that NAC doesn't provide nearly enough value for the work involved makes total sense. When I read the knocks on NAC (would those be "NAC knocks"?) by Rothman, Stiennon, and Williams, the issues seem rooted in that view - geez, overhaul all your gear or deploy a bunch of new hardware, and all you have is "this is joe, and his machine appears to be clean"? Yeah - I wouldn't do it either.
When NAC is done right, it's about much more than admission and endpoint posture. So rather than spelling it out as Network Admission Control, if NAC instead means Network ACCESS Control it's much more compelling. (Of course, now we're back arguing semantics.) The key is, after you know it's Joe, you've got to control what Joe can do.
Amrit rightly points out that knowing what Joe can do on the LAN is really, really hard. And it's not IT that decides this info - it's the line of business. And getting that info from them - and getting the right info - is also really hard. One of our customers just went through this lengthy and difficult business process step to do just this. They sent excel files to all managers, listing the company's 6000 employees, and asked the managers to check off which resources each user should get to access. Painful for sure. And they didn't even get it right. Not only did they have to send the excel file multiple times to managers to get a complete response, but the data didn't come back right.
How did they know? This customer took all the excel info, turned it into policies on our system, and then turned on logging to monitor the users for a while. And guess what - there were a lot of access violations. So IT had to go back to the managers with the violation logs and ask whether the resources in question were ones that the users should be allowed to reach. Whoops - indeed, the managers had forgotten several resources the users had legitimate grounds to access. It puts visibility in a whole new light. Instead of a "nice to have" extra, it was fundamental to the process - this company couldn't have successfully rolled out identity-based control without it.
So does NAC have value? Absolutely, provided you define it right. The key is to broaden what NAC means, and implementing it right is hard, definitely requires the business people, and is about WAY more than just making sure the endpoint's clean. For this customer, NAC was all about restricting access to sensitive resources, and it also got them compliant with PCI (Payment Card Industry - specs for how to handle credit card data) along the way.
As I've commented before, it really doesn't matter what we as vendors say NAC is - all that matters is how the enterprise defines its LAN security requirements. At the end of the day, enterprises must define their needs, map those needs to the solutions that can meet them, and then look at how easily those solutions can integrate into their existing infrastructure.
I think with this debate, semantics got in the way and kept these guys - both clearly smart - from seeing the elements of truth to both sides of the issue.
Michelle McLean
mmclean-at-consentry-dot-com
Comments