NAC: The Hard Part
A harbinger of impenetrable networks? Perhaps, but presently the technology may cause more problems for your organization than it solves.
Data has become fluid. There is no such thing as a network perimeter anymore. Security has to be baked into the business process and system design lifecycle. People have to be just as secured as data. Security has to travel with the data.
Indeed, we have all heard this, and much more, in recent years. Security experts, industry regulations and new threats have forced organizations to forge new ways to handle a new dawn in infosec. Many of our projects today reflect this new way in which information is protected and exchanged. Sometimes youll hear this new approach called informationcentric security, which seeks to secure business critical information and the wide array of people who use it.
Once youve re-architected how security works in your organization on the policy and process side, youre going to have to augment with some technologies that support the remodel. One such technology that you may find on the table is Network Access Control (NAC).
NAC implementations also seek to stop threats and exposures from seeping onto the network. The idea being that if we can control what is on the network and establish a security baseline, the risk of loss is reduced.
The irony of adding NAC is that it can potentially add to the threats and exposures on your network. Lets have a look at two problem areas in NAC.
The first is the deployment of software agents to all devices that connect to your environment. In addition to the already large job of deploying out to desktops, you still have to hit the entire mobile force. Lets say that you are able to deploy out to all of these devices, you still are faced with policy and/or conflicts when youre faced with adding your NAC agent to devices that dont belong to you.
A classic example is when business partners arrive at your location with their own gear. Sometimes they cannot install software or perhaps have a policy where applications outside of the ones supported by their organization cannot be added. Even if you navigate past all of these land mines, you still have to deal with client software issues in large deployments. Adding administrative overhead may not be something that management is willing to accept or fund if you now require extra bodies to manage NAC.
Another problem is the quarantine server used to hold devices that fail policy. The server makes a wonderful target as it contains a list of hosts that failed the NAC policy and many times the reason for failure is close at hand. This is a treasure chest of goodies for those looking to attack or penetrate your network.
Many vendors today claim that NAC is ready for prime time. Were peppered with marketing slicks that show what were told are success stories from blue chip corporations. Its no surprise that vendors hype products and attempt to create needs so lets see what a one security engineer on the front line had to say about NAC.
NAC has been pitched to us for years now and we took the bait from a well known vendor. Even though we thought that NAC was ready for mainstream use we had problems almost immediately.
The engineer, commenting upon condition of anonymity, went on to say that the combination of software issues, unexpected behavior in the solution and inexperienced vendor and enterprise staff quickly derailed the NAC implementation and the project was terminated after the pilot.
He is not alone. Many engineers share similar stories of NAC horrors which revolve around most of the points made above.
So what does one do? Give up on NAC? Wait for something better? Its hard to say what to do but there are some things that can be done as we toil with this thorny offering. The first thing to do is get polices hardened up. Once you do this, you can move along and get security baked into business processes and design.
This will take most of us years to achieve anyhow, so worrying about NAC at the moment isnt a good use of your time. Adding technology to the architecture is the easy part and in many cases is mistakenly done first. The old adage of putting the cart before the horse is certainly appropriate here.
Getting past political hurdles and other road blocks of organizational change is whats going to be difficult. Concentrate on these things first since prematurely imposing a finicky technology will certainly undermine any support you may have as you embark on rebuilding your security stance.
Down the road we may see a NAC implementation that actually does what weve been told. Until that day, youre going to have to innovate new ways to protect the ever-changing security landscape. Perhaps when it arrives, well have all of the other elements in line and bolting on NAC as the final step will be easy.
One can dream.This article was first published on EnterpriseITPlanet.com.