General

Bolting the Back Door with NAC
Part 2: Examining your needs

Before you deploy NAC, identify one specific task you want it to accomplish. Start with a local deployment; it can grow larger, later, if you want to do more.

by Lisa Phifer VP Core Competence, Inc. [June 21, 2007]

Before you worry about product selection or solution design, start by answering some basic questions about your network environment and access control needs.

Why: What are your objectives for deploying NAC? Do you want to control network access at a more granular level? Do you want to log access for regulatory compliance? Do you want to automate local or remote endpoint audits? Do you want to automate pre-admission virus detection and remediation? Do you want to enable limited network access by unmanaged endpoints? Don't try to tackle everything at once. It helps to establish long-term goals, but choose a top-priority objective to shape initial deployment.

Who: Which user groups and devices do you hope to address? If your goal to control or log employee access, which users are top priority and what devices, operating systems, and network access/authentication methods do they use? If you want to permit visitor access, what can you assume about those endpoint capabilities, administrative rights, and ability to run NAC client software? If your goal is to enable limited access by customers, contractors, or others with whom you have an on-going relationship, who are they and how much control do you have over their devices? These answers will have a huge impact on how you deploy NAC and what you can accomplish.

When: For each user group/device type, decide what conditional checks (if any) should be performed before authentication, after authentication, or periodically after network admission. Create a prioritized checklist, based on your security policy and NAC goals. Consider what should happen if each check passes, fails, or cannot be evaluated. Bear in mind that this assessment will ultimately be limited by your chosen NAC platform, endpoint capabilities, your control over them, and the login delay your users can tolerate.

Where: Map each defined identity and assessment result onto a resource access policy that dictates where traffic can and cannot be sent. This task can be simplified by mapping reusable roles to resource authorizations. For example, you might map all endpoints that fail virus checks onto a quarantine role. During implementation, that quarantine role might be mapped onto an isolated VLAN, subnet, and/or remediation URL. At the end of the day, your NAC solution must be able to enforce the access policies that you require.

Sample use cases
In part 4, we'll share our lab experience with one NAC product. But before we unpacked a single box, we considered what we wanted to accomplish. Ultimately, we hoped to illustrate NAC deployment considerations and admin/user impacts. But to do that, we had to create a scenario: a network without NAC and business reasons to add NAC.

NAC adopters run the gamut from SMBs to enterprises; hospitals and schools have taken an early lead. But why should ISPs care about NAC? For starters, most face the same internal threats as any company, including staff with access to sensitive systems they don't need and shouldn't have. ISPs also process payments and store subscriber account records that may contain information subject to regulation. But ISPs may also have unique interests. For example:

• Providers that host colocated or managed servers may need to permit customer access to systems inside their data center. Clearly, that access must be tightly controlled and secure—NAC can help ISPs accomplish this.
  
  
• Providers who run wireless hotspots need to permit what amounts to guest access, but may want to stop threats from spreading to other guests and network elements. NAC has long-term potential here as well.
  
  
• Providers that deliver managed network or security services may wish to someday incorporate NAC as part of those offerings. In fact, as NAC finds its way into business network infrastructure, managed LAN customers will expect this.

For our test drive, we focused on a very common case: controlling staff access to network resources, based on identity and compliance. We also included very restricted customer access to colo servers and guest internet access.

For staff, we authenticated local LAN and WLAN endpoints against our Windows Active Directory, using group membership to let administrators reach subnets that were off-limits to other users. We required all Windows endpoints to run firewall and anti-virus programs, with exceptions for known non-Windows devices.

For customers, we authenticated local endpoints against an authorized user list, assuming nothing about OS and varying checks by customer. Endpoints that passed received access to individual customer servers. (In real life, those endpoints could be remote as well.)

For guests, we provided anonymous public web access. We had planned to deny non-compliant guests, but this proved impractical (see Part 4), so we settled for segregating guests and giving better access to devices that could demonstrate compliance.

We isolated non-compliant staff and customer endpoints on a quarantine VLAN and supplied remediation advice. But, to keep our pilot simple, we did not attempt advanced NAC services like auto-remediation or custom/third-party plug-in security assessment.

Conclusion
Now that we have examined NAC capabilities, benefits, and use cases, it's time to move from requirements to solution design. In part 2, we will compare several NAC approaches and choose one for our test drive.

—End