No Comments
Written by jj on July 3, 2009 – 11:15 am
Management is on board with your decision to roll out NAC, and your team is working diligently on a migration strategy. You have your organization’s policies clearly defined. You’re ready to create a set of recommendations for handling non-compliant devices and take them to management. Where do you start?
While each organization’s handling of non-compliant devices can vary widely, there are a few good guidelines and best practices to get you started. First of all, we have to consider the allowed tradeoffs between security, ease of management and productivity. There are some organizations, primarily government and high-risk corporate groups, which have zero allowance for tradeoffs that compromise security at any level. Others, such as many commerce-driven companies, have a minimal tolerance for any down time that directly affects revenue.
We could revisit the ubiquitous C.I.A. triad of confidentiality, integrity and availability. Our security systems are a delicate balance of the beloved security triangle. I’m obligated to read and write enough CISSP materials as it is, so I’ll just leave you with the triad to keep in the back of your mind.
Options for Unruly Users
What can we do to our unruly users and malware-ridden demonic devices? You’ll usually see one of these four solutions, or some slight modification thereof.
- 1. Monitor only. Most NAC solutions offer a monitor-only function, which allows you to create policies and then see which systems would pass or fail based on the current posture of the devices — without actually enforcing any restrictions. It’s like a dry run. This is a great place to start, and may be the best place to stay, if you can afford a bit of security tradeoff in favor of productivity.
- 2. Probation. This lets you specify an amount of time a non-compliant device is allowed to remain on the network and function uninterrupted. This option imposes no restrictions but usually notifies the user that the endpoint doesn’t meet the policy requirements and tells them how long of a probation period they’re permitted. On most users, this is a wasted effort and you’ll need the IT department to proactively remedy the issue. Again, this can be a nice transition option when going from zero to full enforcement.
- 3. Quarantine. Quarantining can be one of the most restrictive actions, but it can also be as flexible and permissive as you allow. If you’ve set up quarantine policies using VLANs and/or ACLs, you can permit or deny access to internal and external resources and — for example — only inhibit connections to critical segments of the network, or - as another example - confine the device to accessing a very small set of remediation servers. NAC solutions that offer some level of auto-remediation are ideal if this is important since the built-in quarantine functions of most are meager at best.
- 4. Block. There are some organizations that entirely block access to all network resources for non-compliant devices of a particular nature. Complete blocking of access is really a more restrictive function of a quarantine action. In most NAC systems you can configure different levels of access policies so that a user might have unrestricted or probationary access if the operating system patches aren’t quite up to date. But, if the device scans positive for a virus, it’s immediately blocked from all access so as not to spread malicious code.
Again, the key is to understand the pain thresholds and tradeoff allowances. The four actions above are arranged from most lenient/least secure to least flexible/most secure. Of course, the actual security provided will depend on the quality of policies and proper execution of enforcement.
At first blush, most network admins are predisposed to blocking anyone for any reason. You’ll soon learn during your exploratory and monitor-only period that this isn’t a feasible option. Try not to jump in head first with NAC policies — you’re sure to bust your head wide open. Be judicious about it and refrain from the overzealousness that accompanies all the new blinking lights.
It’s difficult to quantify threats and vulnerabilities without a team dedicated to security and audit functions, but you can make some educated decisions when planning your NAC strategy. Just make sure your policies and restrictions make sense and the action warrants the punishment you’re imposing.
# # #
This content and similar articles appear in Search Midmarket Security by TechTarget.
No Comments
Written by jj on July 2, 2009 – 12:30 pm
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.
- 1. 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.
- 2. 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.
- 3. 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.
- 4. 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.
- 5. 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.
# # #
This content and similar articles appear in Search Midmarket Security by TechTarget.
