Alright I will take the bait. I am a sucker for a good troll. :-) Alan Shimel, chief blogger for NAC provider StillSecure, came away from RSA pretty upbeat about the prospects for NAC. His likening me to the Grinch refers to my frequent cries of protest that NAC is worthless. I guess he is afraid that I will ruin the Christmas morning pay off that the NAC vendors hope for.
First the background: NAC of course was a concept invented by Cisco's marketing department in 2003 to counter a problem caused by RPC Decom based worms such as MSBlaster. Even organizations with great firewalls and desktop security were getting damaged by infected laptops brought into work. The concept was simple: have the network inspect those laptops to see if they were properly configured with software updates and virus signature updates before letting them on the network. That is Network Admission Control, and as Shimel points out it is rather hard to accomplish. Most of the NAC players changed their approach and marketing so that "Admission Control" morphed to "Access Control". Don't get me wrong, I have been a huge proponent of user access control ever since being exposed to Enterasys Networks' concept of identity based networking. You have to restrict an end user's access to applications, data, and portions of the network to protect yourself against the insider threat.
Like Shimel at RSA I met with a bunch of so-called NAC vendors. There was at least one there that was downright depressed. You could tell they where the next LockDown. I won't mention which vendor because I would hate to be accused of hurrying their demise. I then met with the firm that my buddies at Gartner use as an example of NAC getting traction. (Sorry Alan, it was not StillSecure.) After spending a year in the UTM space which is already pushing $500 million/year by one measurement, it was like putting on magnifying spectacles to evaluate their business: 40 employees, a few tens of $millions in revenue and a whole lot of excitement about the education market.
NAC was created to solve the problem of users bringing infected laptops on to the network. And that is why there is no large market for NAC. For every type of organization, other than higher-ed, technologies are already being deployed that solve the problem. To wit: patch control, desktop protection, and internal network segmentation.
I am sorry Alan, NAC is not a viable business model for a vendor and for the enterprise it is added complexity and cost that reduces network access while doing nothing for enhanced security. Not a security solution? How can I say that? Easy:
1. NAC does nothing to stop the malicious user with a clean computer from having their way with your network.
2. A zero-day infection will infect properly configured machines with up-todate signatures.
3. NAC violates Stiennon's first and only rule of network security "Thou shall not trust an end point to report its own state." Just as IP address and MAC addresses are spoofed regularly by hackers, machine state can be spoofed.
NAC is a great enforcement tool when you have a body of users that descend on your network every semester with out of date machines from multiple vendors, with multiple OS's and you can deny them access until they are up to snuff. That is the only place that model works. And even at Universities I believe they will eventually figure out that it would be a lot simpler to manage network security effectively than to worry about desktop configuration all the time.
Put it this way: Can you secure your network without NAC? Yes. Does NAC in anyway reduce your overall costs? No. Does NAC tie you down to one vendor's eco-system? Yes, if you go down the Cisco, Juniper, or Microsoft route. Does NAC make you more secure? No.
Then why would you invest in NAC?
Richard Stiennon is a security industry analyst. He is currently consulting, speaking and writing on all manner of security topics for IT-Harvest, the IT research firm he founded to cover the security space. He was most recently chief marketing officer for Fortinet. He has served stints at PricewaterhouseCoopers, Gartner, and Webroot Software.
The Leader in Network Knowledge
Grinch
Just a thought...
Maybe you wouldn't be perceived to be so grinch-esque if you offered positive alternatives instead of saying everything is junk.
OK
Poistive alternatives:
1. patch management
2. Secure Network Fabric. Google it
3. Configuration management
Figure it out. Do your own
Figure it out. Do your own research.
This blog is such troll
This blog is such troll material! So here I go... A properly designed NAC does NOT trust an endpoint to report on its status - it TESTS the endpoint to make sure that nothing malicious is originating from it in addition to checking that the OS is up to date. It CONTINUES to monitor and test endpoints even after they have been admitted to the network via direct and indirect methods and uses remote sensors and switch information/logs to make sure nothing is happening on the network that shouldn't be. It is almost as if the blogger doesn't understand how properly designed NAC systems work...
How?
All the NAC solutions I have seen query the end point with either an onboard
client like Cisco Secure Agent or an ActiveX or Javalike download that checks
config state and checksums of DAT files. That type of "test" relies on the endpoint to report its state. The client software is saying "Hey let me in, I just checked myself over and I am OK". That is stupid as has been demonstrated by at least one lab in Germany.
If you are monitoring transmissions from the clients why not block malicious traffic and let the device continue to be productive? Consentry and Nevvis can do that. Why bother with the quarentine stuff?
Impedance mismatch
As Stennion correctly points out, the NAC approach is nearly valueless for improving internal network security (defined as keeping the bad guys out, letting the good guys in, and exposing all the access decisions to the corporate governance structure).
Under the best of circumstances, traditional NAC has some value at the network edge, where identity-based access decisions can be made.
Even here, there is a serious impedance mismatch. First, it's far too coarse-grained an approach to meet the needs of larger organizations that often need to control access to resources down to the level of individual database columns. Second, and more importantly, the wrong people are doing the work.
Traditional NAC has to be managed by the same people who deal with the switching and routing infrastructure. But in reality, access-control decisions are reflections of business policy, not network policy. You end up with long chains of cumbersome workflow and, of course, widespread circumvention of the controls.
What's really needed is a full-stack, network-resident solution that combines access to authenticators and, crucially, authorizers with end-to-end encrypted channels between end-points. This must be deployed pervasively in an enterprise network and not just at the network edge. There is some value in a hybrid approach that exposes resource (server) endpoints to such a combined solution as well.
But trying to do it all in the layer-2 infrastructure just won't meet the larger business needs.
Brilliant
Another great argument that even as currently hypothosized by NAC
proponents NAC sucks.
Impedance mismatch
As Stennion correctly points out, the NAC approach is nearly valueless for improving internal network security (defined as keeping the bad guys out, letting the good guys in, and exposing all the access decisions to the corporate governance structure).
Under the best of circumstances, traditional NAC has some value at the network edge, where identity-based access decisions can be made.
Even here, there is a serious impedance mismatch. First, it's far too coarse-grained an approach to meet the needs of larger organizations that often need to control access to resources down to the level of individual database columns. Second, and more importantly, the wrong people are doing the work.
Traditional NAC has to be managed by the same people who deal with the switching and routing infrastructure. But in reality, access-control decisions are reflections of business policy, not network policy. You end up with long chains of cumbersome workflow and, of course, widespread circumvention of the controls.
What's really needed is a full-stack, network-resident solution that combines access to authenticators and, crucially, authorizers with end-to-end encrypted channels between end-points. This must be deployed pervasively in an enterprise network and not just at the network edge. There is some value in a hybrid approach that exposes resource (server) endpoints to such a combined solution as well.
But trying to do it all in the layer-2 infrastructure just won't meet the larger business needs.
First, it's far too
First, it's far too coarse-grained an approach to meet the needs of larger organizations that often need to control access to resources down to the level of individual database columns.
Name 'em. I've worked at a lot of Fortune 1000 companies and I've never even heard a hint of a suggestion of a company that wanted such fine-grained access control. Do you have the faintest idea what kind of logistical nightmare managing permissions on every individual file in an enterprise would be? Does the solution you describe even exist? I can't think of anything even close to a cross-platform, cross-application ACL system for the enterprise. And even if their were, NOBODY would use it.
"Traditional NAC has to be managed by the same people who deal with the switching and routing infrastructure."
This is a good point. NAC requires the network people and the system people to cooperate in ways they did not previously. Breaking down the artificial separation of these two groups is a good thing and one of the primary BENEFITS of NAC.
"What's really needed is a full-stack, network-resident solution that combines access to authenticators and, crucially, authorizers with end-to-end encrypted channels between end-points. "
This is unnecessary. Encrypting all your traffic really doesn't get you anything on your internal network unless you're getting lots of internal MitM attacks, which would be weird. Encryption costs CPU time which costs money. Just blindly encrypting everything wastes money, and would probably HURT security because it would limit your ability to so deep inspection on your network traffic.
I'm not sure what you mean by "authenticators" vs "authorizers". I think you mean "identification" vs "access control", sort of LDAP vs. ACLs. And yeah, and ACL directory would be a good idea. Microsoft is working on something like this. I believe there are also nascent solutions on Linux as well. However, this strikes me as a manageability nightmare.
Impedance mismatch
As Stennion correctly points out, the NAC approach is nearly valueless for improving internal network security (defined as keeping the bad guys out, letting the good guys in, and exposing all the access decisions to the corporate governance structure).
Under the best of circumstances, traditional NAC has some value at the network edge, where identity-based access decisions can be made.
Even here, there is a serious impedance mismatch. First, it's far too coarse-grained an approach to meet the needs of larger organizations that often need to control access to resources down to the level of individual database columns. Second, and more importantly, the wrong people are doing the work.
Traditional NAC has to be managed by the same people who deal with the switching and routing infrastructure. But in reality, access-control decisions are reflections of business policy, not network policy. You end up with long chains of cumbersome workflow and, of course, widespread circumvention of the controls.
What's really needed is a full-stack, network-resident solution that combines access to authenticators and, crucially, authorizers with end-to-end encrypted channels between end-points. This must be deployed pervasively in an enterprise network and not just at the network edge. There is some value in a hybrid approach that exposes resource (server) endpoints to such a combined solution as well.
But trying to do it all in the layer-2 infrastructure just won't meet the larger business needs.