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 innovator. He is currently consulting, speaking and writing on all manner of security topics and has just announced the launch of Seccom Global, a Managed Security Service Provider focused on UTM. He was most recently chief marketing officer for Fortinet. He has served stints at PricewaterhouseCoopers, Gartner, and Netrex, the world's first managed security service provider.
|
|
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.
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.
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.