As enterprise networks have grown in size, complexity and ubiquity, controlling access inside those networks has become increasingly difficult. Network access control (NAC) technologies provide a mechanism to authenticate, assess and control endpoint systems that are connected to an enterprise network.
Although there are many benefits to NAC -- improved access control, reduced rogue endpoints, better logging and detailed auditing, to name a few -- implementation of the technology can be very difficult. Because NAC projects encompass many aspects of a business and infrastructure, they are one of the more troublesome -- and often abandoned -- deployments for organizations.
Service providers are in a unique position to help their clients with NAC tools. With a careful and measured approach, you can help your clients successfully implement network access control products and realize the benefits that the technology promises. In this tip, we'll review a NAC checklist that will help your customers determine their specific access control needs before they begin a deployment.
A NAC deployment project plan: Questions you need to ask
Before clients charge off and buy a NAC product, it is vitally important that they have a clear understanding of what NAC is and why they need it. The marketing surrounding network access control can often seem like a one-size-fits-all answer to every security challenge an organization faces. In reality, NAC is well suited for a handful of very specific business needs and poorly suited for many other needs.
NAC is ideal for limiting access to network jacks and enforcing basic security policies, such as ensuring the latest AV signatures are installed on end-user systems. NAC, conversely, is not good at intrusion monitoring, Web filtering or securing data. These features are not generally included with a NAC tool. Some network access control products integrate with IPS or DLP tools, but those integrations can be tricky.
A NAC deployment should begin with a project plan that addresses these primary concerns:
- Business risks: What risks does the business wish to reduce with a NAC product? For example, the most common threat customers cite when considering NAC is the "rogue" host that infects the environment. This can be a legitimate problem at some organizations, but for many, it's more of a generic fear than a real or occurring one. NAC should focus on solving legitimate business risks and not generic fears. Has there been a recurring threat with unwanted hosts infecting systems? Does the organization have a lot of exposed systems that are easily infected or hacked? Analyze these business risks. It may be better to focus on shoring up fragile systems or improving intrusion prevention than implementing network access control.
- Why NAC? What does the business hope to gain by implementing a NAC technology? This must be specific, not some generalized hope. Ideally, the business is looking for increased control and compliance with security policies. NAC is very useful at helping enforce a base set of requirements on a diverse or dynamic pool of systems.
- Where? What networks and locations does the client wish to secure?
- What features are important to the business? And likewise, what features are not important? The ability to enforce policies, such as the existence of applications or security controls, is typically a must-have. Some NAC technologies can also perform inventory and user auditing functions as well. This feature may be vitally important to an internal audit team, but something the IT department never really considered.
- Who will run it? NAC tools can demand a lot of care and feeding, especially in the early months of adoption. If a company does not have the resources to manage the product, then it should not be deploying it. A large enterprise implementation (covering more than 2000 hosts) can often require a full-time operator, especially in the first 2-3 months after deployment.
- Compliance objectives: NAC is a great way to enforce organizational standards and policies (such as antivirus updates). Who will define these polices and ensure they are enforced? Typically an internal auditor or compliance analyst will define the policies, and a member of the security operations team will enforce them. Service providers can certainly assist in the policy definition process, but they would need to know the business well.
- Exception handling: Almost every failed NAC project is littered with poor exception handling. No matter how well the policies are planned, there will be exceptions. For example, 802.1x authentication may work fine on all of your workstations, but that one Mac the marketing department uses just will not integrate. While it may be premature to design an entire exception handling process before implementation, make sure the team has a plan and understands that agility and flexibility are important to success.
- What's the test plan? How will solutions be tested? If 802.1x authentication will be used, make sure all host types are examined. If policy enforcement is being implemented, review how out-of-compliance systems are treated. In short, test all the features and make sure they function as expected.
- Success metrics. What will be considered a successful test?
NAC technical details
There is a broad range of available network access control products. Some offer rudimentary policy enforcement and access control, while others can deliver extensive network controls and authentication. In order to test out the various tools, your client must have a good idea of NAC features, and more specifically, its own business requirements. Key technical considerations include:
- Authentication integration: How does the solution authenticate users? Can it integrate with existing repositories, such as Active Directory (which is often the best method)?
- Enforcement throughput: How is enforcement handled? Are there special appliances?
- Infrastructure interoperability: How well does the NAC device work with the existing network infrastructure? How homogeneous is that infrastructure? A network that uses Cisco gear entirely will be much easier to integrate than one that uses multiple platforms or vendors.
- Enforcement options: How does enforcement work and what options are available? Some NAC tools work as DHCP servers, while others can control which VLAN the user is in. Others work in-line, similar to a firewall or IPS. Also, the client needs to define where that enforcement will be placed. At the edge, at the distribution layer, at the endpoint? The relevant issue here is to know how and where the client plans to implement enforcement.
- Agent deployment: Does the tool require an agent? How is that deployed? Some NAC products have "dissolvable" agents that are deployed via a captive portal. Others require an agent on all endpoints.
- Quarantine: How does the quarantine process work, and how can users get out of quarantine when they need to?
- End-user communication: How does the NAC tool communicate with end users when they are out of compliance or blocked? Does the device use captive portals? Such portals can be useful in helping a user know his or her status, but it also helps unwanted users know what you are looking for.
- Device differentiation: How does the device differentiate between users, wireless devices, printers, etc.?
NAC and human nature
Once you have a network access control product lined up and ready for deployment, the first big hurdle to overcome isn't technical, but rather, human. Networks may be made up of servers, switches and wires, but they exist to serve people and their job functions.
NAC can be a very disruptive technology. It holds great promise to control access and prevent abuse. It also holds great potential to block access and infuriate users. IT must establish a clear set of expectations with employees. They must understand not only when these products are going to be implemented, but why and how these tools can disrupt access.
Don't assume you can anticipate all the exceptions. There will be some you simply didn't anticipate. Sometimes the most problematic issue isn't disrupted service, but new behaviors. NAC solutions may require the deployment of agents or "dissolvable" applets that may frighten users. Inform users of what to expect, when to expect it, and what to do if there are problems.
NAC is a powerful technology that holds great promise. It also can be an opportunity for solution providers to build a lasting relationship with a customer. Focus on the details and the logistics of making a NAC product work. In the end, your customer will thank you for the insight and hard work.
About the author
Andrew Plato, CISSP, CISM and QSA, is president and principal consultant at Anitian Enterprise Security. Andrew has more than 20 years of experience in information systems, networking and information security; 15 years of that experience has been spent building Anitian into a national information security consultancy that currently advises more than 2,000 businesses and public entities.
Join us on LinkedIn.
Send your comments on this tip to [email protected].