NAC Facts, Opinions and Misunderstandings
When researching and evaluating NAC for your network you will inevitably encounter a variety of concerns, opinions, and misunderstandings about its value, "costs", security and ownership risks, best practices, etc. raised by industry analysts, vendors and other potential users. You will also run into a lot of ambiguous terminology. While this makes your job difficult we encourage you to embrace the learning experience as the ultimate reward is better decision-making.
In this area of Secure Access Central we maintain an inventory of the ones we hear most often along with a brief analysis. The ultimate goals are clarity and acuity which admittedly are often elusive targets.
We encourage you to use our online forums either to comment on content in this area or to submit new entries along with your perspectives.
Is NAC security important enough to warrant serious consideration?
We believe the answer is yes. But how you approach this subject will determine whether you make excellent decisions, or not. Ultimately NAC should reduce important security risks at an acceptable cost. However, with security that's almost always easier said than done. To start, you will need to identify your reasons for wanting NAC and appreciate how much risk reduction is achievable with different approaches.
Why is understanding NAC and it's potential value so difficult?
There are many reasons for this situation.
- First, there is no consensus on what types of protection are included in a NAC SOLUTION. While most, but not all, include pre-admission posture assessment and network level enforcement a review of our definitions of basic and advanced NAC reveals that different combinations of security functions exist under the NAC umbrella.
- NAC gateway/appliance vendors have adopted different approaches to the basic NAC functionality (e.g., admission compliance checking) of their NAC gateways and product capabilities vary a great deal.
- There is also the fundamental issue of what amount of additional risk reduction is actually provided by endpoint security compliance enforcement (e.g., basic NAC). Views differ widely from very meaningful to meaningless.
- Several different NAC "initiatives" from Cisco, Microsoft and the TNC are vying for attention and market traction; this raises the bar for what information must be appreciated before making a NAC decision.
- Deployable NAC is relatively new and dozens of vendors are marketing products that are rapidly evolving. Confusion is a natural byproduct of new and dynamic competitive markets.
- And few companies have had significant experiences with complex NAC solutions so little hands-on knowledge has been widely shared within the security community.
Is NAC worth the effort and investment?
The answer is maybe. One well-known analyst Richard Stiennon of IT-Harvest argues that NAC is NOT a good idea. You can read his column Network Admission Control is a Blind Alley to understand his reasoning. We also strongly encourage you to visit Mike Rothman's Security Incite blog to read a lively discussion of Richard's column by Mike.(President of Security Incite), Mark Bouchard (industry analyst and founder of Missing Link Security Services), and Chris Hoff (security analyst and author of Rational Security blog). You can also listen to a 30-minute podcast at The Security Roundtable where all of them enthusiastically debate this issue.
NAC is clearly not a security panacea but it can add another significant layer of security to your networks. Before one can honestly answer the "is it worth it?" question for their particular environment one must carefully think through what they are trying to accomplish, understand what is and is not possible with current NAC and complementary technologies, assess the risk and costs, and then make a well-reasoned decision. Does it get any easier than that?
Why are there such wide ranging perceptions about the value of basic NAC?
Here are a few some perspectives on this issue.
- While basic NAC functionality is intended to provide an additional layer of security its effectiveness for network infection risk reduction depends largely on other layers of security. For example, if endpoints are equipped with the best available personal security software - like that for malicious code prevention, then NAC can ensure that a current version of the security suite is operating. If, however, endpoint security is not well-designed than NAC will clearly add less value.(Note: some NAC vendors are including malicious code prevention features in their products.) A key conclusion is that one needs to examine the total security picture not just NAC. Does this message sound familiar?
- Some security professionals believe that the idea of NAC is fundamentally
flawed. Their reasoning goes: all NAC implementations that require
the interrogation of endpoints unwittingly accept the responses
they receive as trustworthy. And since everyone agrees that nothing
is 100% trustworthy especially a personal computer, laptop, etc., NAC
adds no real value. The counter argument is that no security measure
is 100% trustworthy so why single out NAC as having this "fatal flaw"?
Even if some infections spread some of the time is that not (much) better
than allowing more of these events?
Another companion argument against basic NAC is that hackers can fool this security layer by sending responses that do not correctly represent the true security posture of the endpoint. The counter arguments are (1) the personal security software on endpoints should defend against this type of malicious code when the user is unaware of this attack and (2) if the device is being used by a deliberate hacker on his/her own computer either the NAC can be designed to reduce this risk, the risk is accepted, or other measures can be taken to detect and block this activity.
Why is the enforcement of device-level security policies important?
- Harmful malicious code can spread rapidly across networked computers.
- Organizations can significantly reduce the risk of widespread infections by controlling what "versions" of system, applications and security software are running on computers allowed access to their networks and by enforcing required software settings.
- The amount of ACTUAL risk reduction will depend on many factors including the malicious code defenses on the endpoints and the NAC defenses that are employed.
- There are many reasons why personal computers are out-of-compliance with prevailing policies. IT administration may not roll-out patches and service packs immediately and end users may not update virus signatures nor run anti-spyware software frequently enough.
- Organizations naturally have much less control over unmanaged devices owned by employees, contractors, guests, and business partners. However, they should still require these endpoints meet suitable security policies.
What is meant by the security posture of an endpoint?
In the context of NAC security posture usually refers to how well an endpoint is defended against infections. The security compliance criteria can vary a great deal from what versions of system, application and security software is running on the endpoint to how these items are configured.
Is a compliant endpoint infection-free?
Unfortunately, the answer is no. No one can ever guarantee an endpoint is infection-free all the time even if rigorous security measures have been continuously maintained. However, the risk of a device infecting others on a network can be reduced substantially by combining strong security measures at the endpoint, e.g., host intrusion protection (HIP) AND admission security checks to ensure they are performing the way you want them to. For even greater risk reduction a layer of network-based intrusion protection (NIP) can be employed as HIP and NIP are complementary security technologies that potentially overlap but not 100%.
Will NAC prevent unauthorized users and rogue endpoints from gaining access to networks?
Again, the answer is no. However, a NAC system can include specific security measures that substantially reduce the risk of these attacks.
Why is it important to carefully decide where NAC will be enforced in a network?
NAC can be enforced at the endpoint, edge and distribution layer (usually switches), at the perimeter (for remote access) and within the core network (usually routers).
The location and number of of NAC enforcement points can impact security, costs, performance and administrative workload.
If one is primarily concerned about protecting server applications then network-based NAC enforcement can be installed only at data center boundaries. If an inline appliance is employed it must be designed to handle all data center traffic.
If instead one is also concerned about the spread of malicious code between user devices then multiple enforcement points should be installed within the edge or distribution layer of the switched network and the number of enforcement points will rise as protection is pushed outward to edge switches. This decision increases administrative complexity and, if many switches must be upgraded or NAC controllers installed, can greatly increase equipment costs.
Enforcement at the endpoint can be used if one simply wishes to make go/no go network admission decisions but not control where admitted users can connect within a production network.
Which is better - an agentless or an agent-based NAC solution?
Be warned. This question often stirs emotions and answers ripe with partial truths. In terms of scanning for device compliance both local (agent) and network-based (agentless) methods can be very effective. However, if a client is downloaded additional functions can be provided. Only you can determine their value in your particular environment.
Examples of additional agent-based functions
- Can scan a device when its off-network so this activity will not add delays to user connection times. Instead the scan results are submitted immediately to the policy checker.
- Can transparently run post-connection checks in the background to ensure that device protection remains in-place
- Can provide various types of device-level threat management such as host IPS and malicious code protection.
One caution is warranted here. Most vendors offer installed agents only for Windows. So the richest device scanning capabilities are not available for non-Windows endpoints.
Which is better - an inline or out-of-band network solution?
This is another source of heated debate. The primary issues are performance, availability and cost. If the device is installed inline it can monitor, analyze and control traffic without any need to communicate with LAN switches or routers but it must have the horsepower to perform these functions without impeding traffic. If the NAC controller is installed at the network edge performance traffic volume can be relatively low; if installed at the perimeter (e.g., for remote access) or within the core network the traffic levels can be much higher And if inline network IPS is not highly valued, the overall workload on an inline controller is greatly reduced. With regards to cost both approaches can require redundant NAC controllers if high availability is prized. This may be viewed as necessary only for mission-critical LANs.
How can NAC work well with unmanaged devices when they may not permit a NAC client?
Organizations have a number of choices. They can either require a user to download a NAC client as a condition for receiving any access privileges, deploy a NAC solution that uses a a clientless agent or network-based scanner, or simply severely restrict user access privileges- e.g., can only connect to the Internet.
What does identity-based admission/access control mean?
These terms are often used to refer to very different things so it is very important to understanding what is intended. The following are just three examples.
Every time a user attempts to connect to a network, a basic NAC solution will log the event, collect the results of compliance tests and link this information to an authenticated user identity (the compliance test could also include the identity of the device). So the network admission event log is identity-based.
Basic NAC solutions also enable organizations to vary security compliance policies by user and group. So the compliance policies are identity-based.
Some advanced NAC solutions offer two additional capabilities. First, they enable organizations to implement identity-based and policy-based control over access to specific network resources, a capability similar to SSL VPN gateways. And some can maintain an identity-based resource log that includes detailed information about all the resources individuals have either accessed or attempted to access.