7.2. The Technical Components of the Cisco NAC Framework

As discussed in Chapter 2 and Chapter 6, all NAC/NAP solutions consist of the same basic elements. Not all NAC/NAP solutions will contain all of the elements, and some vendors will be better at some elements than others. This section analyzes the following NAC components as they relate directly to the Cisco NAC Framework:

• A technology to analyze the security posture of the device

• A policy-related component to configure and set the policy on what specific security criteria will be analyzed on the device

• A technology to communicate the security state of the device to other facets of the NAC/NAP solution

• A mechanism that receives the security posture of the device and performs an action based upon those results

• A policy-related component to configure and set the policy regarding what action will take place

• A remediation technology whose purpose is to bring the device back into compliance

7.2.1. Analyzing the Security Posture of a Device

There are two methods by which the security posture of a device can be assessed:

• Client — Cisco Trust Agent (CTA) and vendor-specific posture plugins (PPs) are installed on each device accessing the network.

• Clientless — No assessment software is installed on a device accessing the network. Cisco refers to these types of systems as NAC Agentless Hosts (NAH).

As mentioned previously, client-based analysis can reveal much greater detail than clientless analysis. With this solution, it's important to understand how the CTA plays into the analysis. The CTA itself can perform some basic analysis of the device. CTA can also be thought of as the intermediary between the device and the NAC infrastructure. The components that actually perform the analysis of third-party security applications are the PPs. Following is some of the important information that the CTA can natively determine about a device:

• Operating system version

• Operating system release

• Operating system kernel version

• Machine posture state

• Service packs

• Hotfixes

• Host fully qualified domain name (FQDN)

PPs play a very important role in the analysis of devices. These .DLLs provide a means for various security applications to communicate information to the CTA. Just as CTA is the intermediary between the network and the device, the PP is the intermediary between the security application and the CTA. As you would expect, the PP is a key integration point where compatibility with the Cisco NAC Framework is important. Figure 7-1 shows the relationship between these components.

With the Framework solution, the onus has been put on the security application vendors to perform the deep analysis of their security products. This may seem like the responsibility is being dumped on the vendors, but it can actually make sense. Cisco provides CTA to be the intermediary, and each vendor knows their solutions better than anyone else, so they can write the PP to accurately communicate information that is considered important.

Following is some typical information that a PP would communicate:

• Name of the software application

• The version of the software

• The status of the software

• Version of definition files (antivirus, antispyware)

• Date of last scan (antivirus, antispyware)

• Notable settings and configurations

It should be noted that simply because a security application is running, it is not necessarily actively performing its intended function. For example, an antivirus application may be running and this status may be communicated to CTA. However, real-time file scanning may not be enabled within the antivirus application, which means files aren't being analyzed as they are opened. When looking at compatible PPs, it is important to ensure that this type of information can be accurately communicated.

How the PP obtains information about the device's status is purely dependent upon the PP itself. Some PPs may look at the existence or dates of particular files, registry settings, and so on. When looking at the analysis phase, it is important to work with other security vendors to completely understand how their solutions will integrate with this Framework solution.

PPs are the components that provide the analysis on the devices accessing the network. CTA receives and communicates the information from the PP. Technically, the "client" for the client-based implementation can be considered to be a mix of CTA and PPs. From a Framework perspective, CTA is considered the agent. If CTA isn't installed, then a clientless methodology must be taken into consideration. This is important because not all devices are able to run CTA. Printers, VoIP phones, and so on are all devices that can fall into this category.

There are two key ways to address devices not running CTA:

• Statically allowing specific devices

• Utilize a third-party audit server

The static option is relatively straightforward. Based upon a device's IP address or MAC address, or device type, certain rules can be put into place. For example, a list of all printers can be put together and entered into the solution. These devices can be automatically allowed access to the network, even though their security posture isn't technically assessed and CTA is not installed.

Chapter 6 discussed the Network Scanning functionality that was built into Clean Access. For clientless systems, Clean Access scans the devices to try to determine if any security risks are present. The Framework solution offers similar functionality, although it is not inherent to the Cisco solution itself. Cisco has worked with various vendors to allow companies to implement a third-party vulnerability assessment and audit server to perform this type of functionality. The assessments can be performed by such methods as network scanning and browser-based agents. Figure 7-2 shows the relationship between this type of server and the Framework.

7.2.2. Setting Policy for Device Analysis

Whether you are using CTA and PPs or a third-party audit server, there must be a component where the various NAC policies are configured. With the Framework solution, this can actually take place on multiple components. The main configuration point is the Cisco Secure Access Control Server (ACS). Many companies are familiar with the Cisco ACS as their RADIUS server.

Cisco ACS is the starting point where the different NAC policies are con-figured. This configuration is done using vendor-specific Attribute Value Pairs (AVPs). The AVPs are integrated into the ACS by importing a NAC Attribute Definition File (ADF). For each vendor's solution for which NAC functionality is desired, the corresponding ADF must be imported into the ACS.

With the Framework solution, the ACS can also work with different components to perform different (though similar) functions. These different components can also be configured with different policies. For example, as discussed previously, CTA can be used to assess basic operating system information. At the same time, a third-party server could be utilized for antivirus-related functionality, and additional policies may be created there. In this case, the third-party antivirus server would be acting as a Posture Validation Server (PVS). Implementations can be different and, therefore, where policies are actually configured can be different depending upon the technologies in place. Figure 7-3 shows the relationship between ACS and a PVS.

Even though a PVS is used to help assess the device, the ACS is ultimately what decides access. These enforcement rules are configured as part of ACS group policy. Let's take a look at how all of this NAC communication takes place, and the flow for allowing or disallowing access.

7.2.3. Communicating the Security Posture of the Device

There is quite a bit of communication that takes place within the Cisco NAC Framework. While communication does need to occur between the CTA and the ACS, this is by no means the only communication. The Framework consists of many different components, and all of these components must communicate for the solution to work effectively. There are also specific protocols that are used to facilitate this communication between the different components.

The Framework uses the concept of tokens to define the security posture of various security components on the device. There are two key tokens:

• Application Posture Token (APT)

• System Posture Token (SPT)

The APT refers to the security posture of a particular component of the solution (such as antivirus). The posture related to the state of the antivirus application, its virus definition version, and so on are all communicated via the vendor-specific APT. The policies and rules in place on the particular server handling the analysis will govern the analysis. This is an important concept to understand because the ACS does not perform all of the analysis. As previously mentioned, third-party audit servers and PVSs are also used. These servers will analyze the device, create the APT, and communicate the token back to the ACS. Following are common values communicated in the APT:

• Healthy

• Checkup

• Transition

• Quarantine

• Infected

• Unknown

The ACS is in charge of receiving and processing APTs from the various components. Exactly how many components will send APTs depends on what technologies are in place and how the various analytical functions are distributed throughout the Framework. Once all the APTs are received, the ACS will process them and create a SPT, which is the APT that represents the greatest amount of noncompliance. The SPT is then correlated to an appropriate profile that represents the current state of the device. This information is then communicated to the network access device (NAD).

The easiest means of explaining the communication is to illustrate the flow and actions that occur when a device is attempting to access the network. This flow is affected by the assessment methodology used in the Framework. Different assessment methodologies are triggered at different times. The following are the methodologies:

• NAC Layer 3 IP — When a packet enters a router, an intercept ACL determines which traffic initiates the NAC process by sending a message to the CTA on the device. Ultimately, a Protected Extensible Authentication Protocol (PEAP) connection between the CTA and the ACS is established.

• NAC Layer 2 IP — The NAC process is triggered by a Dynamic Host Configuration Protocol (DHCP) or Address Resolution Protocol (ARP) request. These functions are done at Layer 3 on a Layer 2 switchport.

• NAC Layer 2 802.1x — The NAC process is triggered by the 802.1x (data link up) communication between the host and a Layer 2 switchport.

Once the NAC process is triggered by one of these methods, the rest of the process can come into play. The device and Framework communication takes place between the CTA and the Cisco ACS. At the same time, CTA will communicate with various PPs on the device and the ACS will communicate with PVSs, Directory Servers, and so on, on the network end. Figure 7-4 shows a simplified illustration of this communication.

As you would expect, there is considerably more communication that actually takes place within this solution. However, this detailed information isn't necessary for the purposes of understanding the concept of the NAC Framework. Additional information on specific protocols and communications can be found at www.cisco.com/application/pdf/en/us/guest/netsol/ns617/c649/cdccont_0900aecd80417226.pdf.

7.2.4. Taking Action Based on the Security Posture

Once the security posture has become known and can be communicated, it's time to "enforce" an action. This action can be in the form of allowing access or somehow restricting access. By default, access should be restricted when any device first attempts connectivity. If the security posture of the device is sufficient, then restrictions can be lifted. Should the posture be deficient, then quarantining or blocking can be put into place. In any event, the NAC Framework component that performs this restriction is the NAD. The NAD will be a supported Cisco router or Cisco switch.

The use of ACLs is the most common means of restriction known to most people when they think about the Cisco NAC Framework. It is relatively simple and makes sense. Based upon a device's security posture, you can implement different ACLs to control where the device can go. If they are considered to be in a Healthy state, you can allow them to access resources without restriction. If they are in a Quarantined state, you can provide heavy restrictions on what areas of the network can be accessed by the device. The following two examples are from Cisco's NAC Framework Configuration Guide of possible ACLs for a Healthy and a Quarantined device:

• Example of a Healthy device ACL:

  permit ip any any

  
  

• Example of a Quarantined device ACL:

  remark Allow DHCP
  permit udp any eq bootpc any eq bootps
  remark Allow EAPoUDP
  permit udp any any eq 21862
  remark Allow DNS
  permit udp any any eq 53
  remark Allow HTTP to UpdateServer
  permit tcp any host 10.0.200.30 eq www
  remark allow client access to qualys
  permit ip any host 10.0.200.106

  
  

Restricting or allowing access to the network is one action that can take place. Helping to fix the problem is another. Remediation is a key component of any NAC solution. Remediation and quarantining are not interdependent because Cisco's agent itself is not responsible for automatic remediation. Therefore, while processes may run in parallel, there is not an intelligent sequence of events solely within the Cisco NAC Framework.

7.2.5. Remediating the Security Deficiency

With the Cisco NAC Framework, there isn't a component that directly performs the remediation of noncompliant hosts. That is to say, there isn't a Cisco NAC remediation server that would be set up and automatically push patches. Rather, the Cisco solution relies on other methods to fix deficiencies. Remediation with this solution is done by the following:

• The user

• A member of the IT department

• An existing remediation solution

For the user to remediate or contact IT for help, the user must first receive notification that there is a problem. This communication can take place with the CTA by using a pop-up dialog that describes the problem to the end user. Figure 7-5 shows an example of this pop-up. Also, CTA can automatically launch the default browser on the device to a predefined URL with information on the problem and how the user can fix the problem.

The patch on Quarantine functionality provides a more automated approach to remediation. With this method, an existing remediation client is triggered by network authorization or Quarantine, or it is triggered by patch server notification upon network authorization. The first method relies on the existing patch solution being compatible with the Cisco NAC Framework because communication and integration must take place. The latter method is simply facilitated by the fact that the existing patch agent and patch server can communicate with each other, and the NAC solution won't stop this communication from occurring. As a result, the machine has chance of being patched because it could talk to the server component.

7.2.6. The Reporting Mechanism

With many moving parts, reporting information can reside in a number of different locations and come from different components. There isn't one area or console that is accessed for different reporting information. Cisco does offer documentation on how vendors can integrate their reporting solutions into the NAC Framework solution, as well as on what criteria and reporting elements and events should be included. This document can be found at www.cisco.com/en/US/netsol/ns617/networking_solutions_white_paper0900aecd801dee49.shtml.

Since other vendor components can be integrated into the Framework solution, those components can help in viewing reporting information. For example, Qualys offers an audit server to assist with posture assessment. This solution offers detailed reporting information. Figure 7-6 shows a detailed report on a particular device, while Figure 7-7 shows available reports for devices that have been assessed.