NAC: Here's Where It Gets Hard

Adopting NAC will be the beginning of a new security process ... and adopting it now is a bit premature.

By Sonny Discini | Posted Jun 11, 2007
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Stop me if you've heard this before...

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 you'll hear this new approach called information–centric security, which seeks to secure business critical information and the wide array of people who use it.

Once you've re-architected how security works in your organization on the policy and process side, you're 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).

Network Access Control or "NAC" attempts to control who and what gains access by evaluating devices against a preset policy for specific requirements before allowing them onto the corporate network. If your device passes the NAC policy, it will be issued an IP address and the asset then can access networked resources. If the device fails, it may end up in quarantine, receive automatic updates or an assortment of other remedies for the failed device.

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. Let's 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. Let's say that you are able to deploy out to all of these devices, you still are faced with policy and/or conflicts when you're faced with adding your NAC agent to devices that don't 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. We're peppered with marketing slicks that show what we're told are success stories from blue chip corporations. It's no surprise that vendors hype products and attempt to create needs so let's 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? It's 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 isn't 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 what's 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 we've been told. Until that day, you're going to have to innovate new ways to protect the ever-changing security landscape. Perhaps when it arrives, we'll have all of the other elements in line and bolting on NAC as the final step will be easy.

One can dream.

Article courtesy of Enterprise IT Planet

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter