I haven’t argued with Shimel in ages, and seeing as there are several host-based NAC reviews and analysts reports forthcoming I thought I would resurrect an article from last year – enjoy 🙂
Few security initiatives have enjoyed as much hyperbole as network access control (NAC) – DLP being the exception of course. Aggressively promoted by industry titans Cisco and Microsoft, NAC had been adopted as a rallying cry by the majority of security vendors. In the real world, however, NAC technologies have experienced more than their share of delays, failed deployments, and over-promised and under-delivered solutions. Despite these difficulties the NAC concept is neither dead nor useless. With an initial phased approach, realistic expectations, proper planning, optimized (re)use of existing infrastructure, and integration into a comprehensive, proactive approach to IT security policy management, NAC can be a valuable addition to an overall information security program.
What is NAC?
NAC is a process and not a product. NAC is the process by which a device is assessed to determine its state prior to that device gaining access to a network or other resources. The state of the device is compared to the admitting organization’s policies and configuration standards, and an action is taken to disallow access, limit access, or allow full access to network resources. This admission process is called pre-connect NAC. There is also referred to as post-connect NAC; that is, the device is assessed after a network connection is made and then an action is taken if the device is determined to be or becomes non-compliant due to changing policies or configuration drift, or if the device is compromised and/or becomes hostile to the network.
Adding to the confusion is the swarm of vendors that claim to provide NAC solutions. Some assess the devices remotely, others rely on permanently resident or dynamic client-based agents; some perform network access control via networking gear such as switches, others constrain the end-point in the network but require additional appliances placed throughout the network. A group of patch and configuration management vendors integrate with NAC solutions or offer stand-alone solutions that provide the remediation and mitigation services aimed at returning quarantined devices to a policy-compliant state. Whatever the solution, even the most technically advanced organizations will need to overcome significant challenges to make NAC work and deliver value to the enterprise.
Prior to the worm attacks at the beginning of the decade, most organizations focused their security efforts on building a strong perimeter against external threats. Firewalls and anti-virus technologies became the most widely adopted technologies and, when used correctly, did a good job of rebuffing and containing attacks on networked resources. Soon the black hats accelerated the pace of “innovation” and the gravity of their attacks. At the same time, an increasingly mobile work force, and more outside stakeholders—contractors, suppliers, partners, service providers, etc.—required enterprise network access. As a result, it became very difficult for most organizations to defend the integrity of their infrastructure. As threat-specific defense techniques became less effective, systems became more difficult to manage, and worms laid waste to network availability – the traditional security approach was about to be turned on its head.
The vectors for worm attacks shifted to managed assets that left the network perimeter (and the immediate control of IT managers), became infected, and returned to the enterprise. Bypassing traditional security mechanisms, the compromised device (and its uninvited guests) wreaked havoc as the infections sought other vulnerable hosts to exploit. Although the infected end-points acted as the carriers of infection, it was the network that bore the brunt of the attacks as the worms degraded network availability and transaction integrity. Under these circumstances it became clear that protecting the whole was more important than protecting individual devices, and that blocking suspect devices from network access would isolate threats before they could spread.
NAC’s Achilles Heel
NAC technologies pose a number of implementation-level issues, including large resource requirements, lack of product maturity, management complexity, logistical challenges, little visibility into the identity of the users, the ability for attackers to bypass controls, and process and technology integration. However, NAC’s biggest flaw is that it focuses on quarantining hostile devices rather than implementing mechanisms to prevent managed devices from becoming non-compliant or compromised in the first place.
The process of quarantining first and fixing a compromised device later can create many technical and organizational issues. Quarantining the CEO’s laptop could be a career-limiting move, as would locking out a device a salesperson relies on to post an order, or quarantining a device that delivers critical services. Quarantining is clearly a very blunt but effective mechanism whose use requires subtlety and skill to avoid unintended consequences.
Needed: A New Approach to NAC
Continuous policy enforcement, the ability to update security defenses, patch systems, and reconfigure devices, on or off the network is critical to moving an organization from reactive, fire-fighting mode to a mature security posture that puts the organization back in control of their systems. This is particularly true with NAC solutions where continuous policy enforcement can be used to assess and “pre-mediate” devices to conform to NAC dress codes before they log onto the network.
The mobility of the workforce is increasing while the ability of the IT organization to manage these assets is decreasing. Managed assets that leave the control of the IT group essentially become unmanaged assets. Currently, the vast majority of system management solutions do not enable effective continuous policy management. Conventional system management technologies (with their weaknesses) fall into three areas.
First, they lack real-time information on managed device configuration state. This is particularly the case for scanning-based solutions where configuration information is only valid at the time of a scan. There are long intervals between scans due to the workloads they impose on networks and managed devices. Even if an organization could scan its infrastructure daily for policy compliance, this gives managed devices 24 hours to drift out of compliance, get infected by malware, and set themselves up as candidates for quarantine.
Second, most conventional solutions have blind spots that exclude significant classes of assets from effective assessment and remediation. It’s common for many solutions to focus on only a single technology platform—usually Microsoft Windows. While Windows remains the biggest game in town, it’s not the only game. Most organizations will also need to manage Unix and Linux devices and may also need to enable access for technology platforms not officially supported by the organization but used by qualified outsiders or employees checking in from home or on the road (e.g., Mac OS).
Third, administrators must use multiple tools to remediate the wide variety of configuration settings and software (both operating systems and applications) that may be subject to a NAC dress code. This not only slows the process of assessing and remediating managed devices, but any additional complexity in technologies and processes creates opportunities for errors and inconsistencies.
NAC is a result of IT’s inability to manage systems that leave their control (remote or mobile workforce) and an inability to properly segment the network for access by contractors. NAC can only be effective when coupled with a program of continuous policy enforcement of managed systems. Quarantining devices should be a last and final line of defense and not the main method to secure an environment; it is a small part of an organization’s overall security program, not the cornerstone.