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.
- 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.
- 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.
- 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.
- 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.
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 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.
|
|
