In-Depth
Preventing NAC Attacks
Industry standards and trusted hardware keep out unauthorized users and equipment
by Steve Hanna
A Trusted Computing Group investigation has shown that Network Access Control (NAC) technology is vulnerable to a condition called the “lying endpoint problem.” If an endpoint becomes infected by a virus or other malware, the infection may cause the machine to lie about its health status. As a result, infected machines can then gain access to the network and infect other machines. With over 40,000,000 infected machines and more than 35,000 malware varieties, allowing network access to a lying endpoint should be a major concern to everyone involved in network security.
To understand this problem and where we are today regarding its solution, a look at the Trusted Computing Group and its standards development efforts is in order.
Created to develop open industry specifications to establish trust and increase the security of computers, mobile phones, networks, and essentially anything that connects to the network, the Trusted Computing Group (TCG) is addressing every aspect of network security as part of a broad effort to establish a comprehensive security infrastructure.
The fundamental building block for security initially began with a specification for a Trusted Platform Module (TPM) that is now an integral part of more than 50 million business computers. The TPM is a microcontroller that securely stores digital keys, passwords and certificates. As a hardware component, the TPM provides a high degree of security from both virtual and physical attacks.
TCG’s Trusted Network Connect (TNC) Work Group has extended the Trusted Computing Group’s security specifications to networks with the TCG TNC Architecture for Interoperability (see https://www.trustedcomputinggroup.org/specs/TNC/TNC_Architecture_v1_2_r4.pdf) and other specifications. Providing a framework to achieve a multi-vendor network standard, the TNC architecture addresses several network security issues, including platform authentication, endpoint policy compliance (authorization), access policy, assessment, and isolation and remediation. The TNC architecture is supplemented by other TNC specifications that define standard interfaces (protocols and APIs) within the architecture. These standard interfaces allow NAC systems to include products from a variety of vendors while ensuring interoperability.
Essentially, the TNC architecture and specifications allow IT administrators to establish a level of trust in the state of an endpoint by ensuring the presence, status, and software version of mandated applications. In addition, the standard provides tools to determine completeness of virus-signature databases, to interact with intrusion detection and prevention system applications, and to verify the patch level of the endpoint's operating system and applications.
Because endpoint integrity checking is part of the criteria used to authorize network access, it also provides policy compliance. By combining the TNC architecture with the TPM, the security of the endpoint (and therefore of the network) can be raised to a high level, even to the levels needed for high-assurance applications.
Today's NAC
The TCG's TNC architecture for network access control is shown in the figure below. By defining a standard architecture and standard interfaces between the separate entities of Access Requestor, Policy Enforcement Point and Policy Decision Point, the TCG approach accommodates a wide variety of products and technologies from many different vendors, improving interoperability and compatibility while ensuring strong security.
Any component or endpoint attempting to access the network is designated an Access Requestor (AR). To gain access to the network, the AR must be evaluated and approved by the Policy Decision Point (PDP). The PDP's evaluation generally includes user authentication, device authentication, and integrity checking of the AR, comparing the results of this evaluation against the organization's policies for authorized users, acceptable device identity and configuration, etc. Once the PDP decides what access should be granted, it sends its decision to the Policy Enforcement Point (PEP), which can be a switch, firewall, virtual private network (VPN) gateway, or other networking component.
 TCG's Trusted Network Connect architecture for network access control Click to enlarge |
The "Lying Endpoint Problem" -- An Emerging Issue with Network Access Control
The TNC architecture for network access control includes examining the health of each machine when it connects to the network to see whether it has become infected and determining whether the machine is adequately protected against security threats. However, a serious issue that affects all NAC systems is the "lying endpoint problem". An infected or compromised endpoint may provide unreliable information regarding its status during a health check. As a result, an infected machine may gain access to the network and infect other systems. This problem is especially troubling in light of the increasing popularity of rootkits.
A rootkit is a stealthy infection that infects an endpoint and then hides its presence. Once installed, a rootkit can be almost impossible to discover. For example, most rootkits modify the operating system so that the files containing the rootkit are not visible to other software running on the endpoint. This prevents endpoint security software from detecting them. In some cases, rootkits can be detected because of bugs in the rootkit that allow client security software to detect their presence, but this is not reliable.
Unfortunately, rootkits are an increasingly popular tool for attackers. Once a machine is infected with a rootkit, the attacker has complete control over the system and can steal data from it, use it as a launching pad for infecting other machines, cause it to lie about its health, or perform any other nefarious deeds.
Addressing the "Lying Endpoint" Problem
Client security software and network access control can reduce the likelihood of rootkit infection by keeping the endpoint's defenses strong but they cannot reliably detect or eliminate an installed rootkit. There are, however, reliable ways to detect rootkits.
One detection mechanism is to boot the endpoint using a CD-ROM (or other disk) containing a known-good operating system and rootkit detection software, then scan the endpoint's hard disk for rootkits. Since the rootkit installed on the endpoint's hard disk does not get a chance to run, it cannot evade detection.
This approach has several drawbacks. First, it's inconvenient to reboot machines from a known good disk and run a rootkit scan. The cost of doing this for all machines on a regular basis is prohibitive in most environments. Second, a rootkit that infects the endpoint's firmware will not be detected by this mechanism since the rootkit will load before the known good operating system.
Another approach to the lying endpoint problem is to monitor each endpoint after it connects to the network to detect inappropriate activity. One issue with this approach is that the problem endpoint gains access to the network and can spread its problem to other systems before being detected. In addition, keystroke loggers and rootkits cannot be identified by network monitoring unless they perform network attacks, so an infected machine can operate on the network and avoid detection.
The limitations of software-based approaches to lying endpoints can be overcome by using a hardware security component. As we mentioned, such a hardware component, the Trusted Platform Module defined by TCG, is now included in all corporate-grade laptop and desktop computers. In addition to the TPM's use in disk encryption and strong authentication, in the TNC architecture the TPM may be employed for integrity measurement and remote attestation.
The TPM's role in detecting a lying endpoint starts with the boot process. Whenever an endpoint with a TPM initiates a trusted boot sequence, the TPM measures (hashes) all the critical software and firmware components, including the BIOS, boot loader, and operating system kernel before they are loaded. Since these measurements are made and stored on the TPM before the software runs, they are secure from subsequent attempts to modify them.
When the endpoint connects to the network, the stored measurements are securely sent from the TPM on that endpoint to the TNC server and checked at the TNC server against the server's list of acceptable configurations. A non-match is identified as a possibly infected endpoint and can be quarantined for remediation.
Because a TNC system can optionally incorporate trusted hardware such as the TPM, it can reliably detect any sort of infection - even by the most expertly-written rootkit. For high-security environments, TPM-based integrity verification provides the highest possible level of trust in the endpoint and solves the lying endpoint problem. For systems without a TPM, the other rootkit detection techniques described above can provide a lower level of trust (equal to that provided by any other network access control system).
Summary
In today's highly-connected network environment, protecting endpoints from infection by rootkits and other forms of malware is essential. Rootkits are especially dangerous because they are very difficult to detect and can cause the endpoint to lie about its health (the "lying endpoint problem"). Several approaches to detecting rootkit infections have been described. The most practical and reliable way is to combine trusted hardware with a network access control system. The Trusted Network Connect architecture defines widely-implemented standards for achieving exactly this form of protection.
- - -
Steve Hanna is Distinguished Engineer at Juniper Networks and co-chair of the Trusted Network Connect Work Group in the Trusted Computing Group. You can contact Steve about Preventing NAC Attacks at shanna@juniper.net