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
