Network access control technologies are complicated enough to plan and implement on a technological level, but dealing with the politics of policies can be an entirely new headache your IT department never saw coming.
Conversations about NAC frequently start with basic information gathering: What features are you looking for? What operating systems and switches are in the environment? How do you want to handle non-compliant devices? And, of course, the sales guy will slip in the ol' "What's your budget?" line.
Take this set of Q&A with a grain of salt. When making decisions about NAC, there's another set of primary questions that should be addressed first: What are the primary drivers for implementing NAC? What organizational policies need to be enforced? Where is your organization's trade off between security and productivity?
The Technology of Policy
For the network administrators, IT directors and technologists these questions are the equivalent of that mandatory legal jargon in size 6 font on a page footer; superfluous at best and an impediment at worst. And so here comes the catch-22 we face in every NAC implementation -- the struggle of finding the equilibrium between the policies of management and the technology of security.
When we talk about network access control systems, we start talking about segmenting, VLAN-ing, quarantining and isolating devices and/or users from the various network resources. We're stopping users from accessing the Internet, we're stopping laptops from accessing the primary database servers and maybe we're even preventing a critical billing or HR system from accessing the resource it needs to cut the weekly paychecks. We are, as technologists, implementing a control that will, in effect, be playing God on the network.
And yes, I know the prospect of total supreme network domination is exceptionally appealing to you all. Aside from sounding cool, it does give us complete purview over the network and control over any objects that may become security risks for the organization. For those of you who have spent your entire career protecting the network from dumb users and protecting those same dumb users from themselves, NAC can be a key tool for you; however, implemented without controls and proper planning, it can also be the bane of your (and everyone else's) existence. Why? It's pretty simple, the first time a critical system or critical employee gets zapped from the network, either you or your NAC solution will disappear -- and quickly.
I get dirty looks every time I say this, but it's true - network access control is a BUSINESS DECISION, not a technology decision. We put the technology in place ONLY for the purpose of supporting and enforcing an organizational policy that is already in place. When organizations do it the other way around and start making policies around the technology, they've doomed the project before it began.
There are a host of reasons to not set access policies Willie-nilly on the network. Aside from the obvious ones, there's an assortment of legal and business reasons to hold off on total network domination. In this age, the IT department is forced to take into account such off-the-wall issues as human resources policies, compliance and regulation mandates, corporate initiatives and even partner contracts. What if one of your newly imposed NAC policies conflicted with a primary policy or standard for operation and violated your organizations HIPAA or SOX compliance? What if you cut off a partner resource that was contractually provisioned with an uptime guarantee? Or what if the policy you set is simply not enforceable by the HR department?
Five Steps for a Successful Start
If NAC is something your organization's management recognizes as a necessity and has signed off on, then you're heading down the right path and there are some key things to consider in a successful NAC rollout.
- REVIEW your organization's current policies on network resource usage, access and enforcement. If they need to be updated or rewritten, do that first and then continue with your project.
- IDENTIFY, ORGANIZE AND CATEGORIZE key resources, devices and users. You don't want to cut off your arm if your finger is bleeding, and for some users, you don't want to ever cut off anything. Understanding the key pieces in the network is the first step to matching your NAC policies to the real policies.
- MAP the NAC policies to your organization's usage policies. That's why we do step 1 first. If users in Group A aren't allowed to Resource X, in Circumstances C, D or E, then make it happen that way. If a device is critical, exempt it from enforcement policies and only monitor and audit it.
- START slowly and monitor first. Most NAC solutions offer a monitor-only function that allows you to create policies and then determine which systems would pass or fail based on the current posture of the devices -- without actually enforcing any restrictions. Monitoring lets you ease in to the solution, identify non-compliant devices and fix them before your help desk (or your cell phone) is inundated with calls from end users.
- RINSE AND REPEAT. NAC policies need adjusting as endpoints, programs and the Internet changes and evolve. New threats and new organizational goals are always on the horizon, and the only way to prevent stale and useless policies is to stay on top of them.
Jennifer Jabbusch is an infrastructure security consultant with Carolina Advanced Digital, Inc., a security integrator based in North Carolina. Jennifer specializes in areas of network security, NAC/NAP, 802.1X and wireless security and consults for a variety of government agencies, educational institutions and Fortune 100 and 500 corporations. She serves as a contributing SME on access control, business continuity and telecommunications, and lead SME in the cryptography domains of the official (ISC)2 CISSP courseware and maintains the SecurityUncorked.com blog.
 |
|
Rate this Tip
|
To rate tips, you must be a member of SearchMidmarketSecurity.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
