In the case of Cisco NAC, Microsoft NAP, and other LAN-based NAC tech- nologies, the security posture of the device must ultimately be communicated to an external network device, where restriction and other actions can take place. This communication takes place via specific components and protocols. The components and protocols are another area of NAC where it would be ideal if different systems were able to play nicely together.
Communicating the Security Posture of the Device 41
Figure 2-13 Registry setting modified to show the tunnel isn’t connected
Figure 2-14 Changing the registry key entry
As mentioned in Chapter 1, there are initiatives by TCG and Cisco to make their various NAC/NAP solutions all work together nicely. In a perfect world, this would be the case, but it’s not the case today.
There are three NAC-related communication technologies with which you should be familiar:
Cisco Trust Agent TCG IF-TNCCS
Microsoft IF-TNCCS-SOH
These three technologies are used to communicate a device’s security posture state. CTA is clearly for Cisco NAC networks, TCG IF-TNCCS is for NAC networks that adhere to TCG’s standards, and Microsoft IF-TNCCS-SOH
42 Chapter 2 ■ The Technical Components of NAC Solutions NAC/NAP Communication Agent:
“Here is detailed information I have gathered on the security posture of
this device.”
NAC Infrastructure: “I will use this information to determine the level of access, if any, that you will receive to
this network.” Device Requesting
Access
NAC Infrastructure Corporate Network
Figure 2-15 NAC/NAP communication
is Microsoft’s method to communicate a device’s Statement of Health (SOH) to a TCG-supported device.
Figure 2-15 shows how these agents and protocols communicate their security posture.
Let’s take a quick moment to contemplate just how important this commu- nication is to the NAC solution. If the communication is somehow tampered with, devices that should not have access to the network may gain unau- thorized access. Likewise, devices that should be able to gain access can be wrongly locked out from the network. Neither scenario is good; there’s either a bypass in security or a loss in productivity. Both can have significant negative impacts on the enterprise.
With this is in mind, it’s important to ensure the integrity of the data being communicated from the device to the NAC hardware residing within the infrastructure. The following are safety measures that should be kept in mind: Is the security posture information being communicated being sent in an encrypted state?
Is there a mechanism to ensure that the security posture information hasn’t been altered in transit?
Can the communication agent be tricked (or otherwise hacked) to inten- tionally communicate an incorrect security posture?
The simple use of encryption and hashing algorithms has helped protect the integrity and confidentiality of information in transit for quite some time. Don’t assume, however, that the NAC solution you want to utilize takes advantage of these practices. Also, it is important to take note of the last point and keep up to date on any exploits that can use this communication to exploit or gain access to the network.
Communicating the Security Posture of the Device 43
Cisco Trust Agent
Those utilizing Cisco NAC will need to be familiar with the Cisco Trust Agent (CTA). This agent is the NAC component responsible for communicating the security posture of the device. We’ll get into more detailed information on how the Cisco Trust Agent works within the Cisco NAC Framework solution in Chapter 7. The important point to understand is that this component interacts with different security applications on the device and communicates their state. This function sounds relatively simple, and conceptually it is. Consider, though, what if the security posture of the device were communicated incor- rectly. Think it can’t be done? Well, it has!
At BlackHat Europe 2007, Dror-John Roecher and Michael Thumann showed how they found a way to hack Cisco NAC with their NACATTACK exploit. The two researchers were able to take advantage of the last point mentioned, ‘‘Can the communication agent be tricked or otherwise hacked to intentionally communicate an incorrect security posture?’’ For them, the answer was ‘‘Yes!’’ Using reverse-engineering techniques, their ingenuity, and, as they stated, ‘‘RTFM: Reading The &*#(@)@) Manual,’’ the two researchers developed a means to give the Cisco Trust Agent incorrect information. In doing so, they could essentially communicate that their device was in a different security state than it actually was. They did this by utilizing what they described as ‘‘Posture Spoofing Plugins.’’ These plugins are what communicated the incorrect state directly to the Cisco Trust Agent.
N O T E Plugins are commonly used as a means for third-party applications to be able to communicate with different NAC solutions. For example, when technologies say they work with a particular form of NAC, it is common to have that refer to how their application can ”talk” to the NAC agent, which in this case is CTA.
These guys have a good sense of humor and were able to communicate incorrect device information, such as the following:
The device was running Windows XP Service Pack 3 or 4 (which is funny, if you realize that XP is currently only up to Service Pack 2). The device was running Trend Antivirus, when, in fact, Trend Antivirus wasn’t even installed.
A visual representation of how this is done is illustrated in Figure 2-16. The researchers point out two critical concepts that they were able to take advantage of:
Cisco NAC relies upon receiving information from an unknown and untrusted device to determine if the device itself is compliant. There are no methods of authentication.
44 Chapter 2 ■ The Technical Components of NAC Solutions
Posture Spoofing Plugins: “Even though I don’t have antivirus installed, I’m going to tell you that I
do.”
NAC/NAP Communication Agent: “I will communicate that you have
antivirus installed.”
NAC Infrastructure: “I see that you have antivirus installed and will give
you access to the network.” Device
Requesting Access
NAC Infrastructure Corporate
Network
Figure 2-16 NACATTACK NAC/NAP communication
The first point is pretty interesting. Think about it from the perspective of someone wanting to gain access to a place where access is controlled, say, like in the movie Beer Fest when the Americans were trying to gain access to the Beer Fest competition. (There are, of course, many different skits out there where a person is attempting to communicate with a person behind the locked door in an attempt to gain access.) With Cisco NAC, and other NAC solutions, the conversation would essentially go like this:
Unknown Person: ‘‘Hi, I would like to gain access. Please open the door.’’ Person behind the Door: ‘‘How do I know you aren’t carrying any weapons and that you don’t pose a security threat?’’
Unknown Person: ‘‘That’s easy, just ask me and I’ll tell you!’’
Person behind the Door: ‘‘OK, are you carrying any weapons and do you pose a security threat?’’
Unknown Person: ‘‘No, of course not. I am fine and meet your minimum security standards. For example, my gun is unloaded and the blade of my knife is less than 4 inches in length.’’ (He’s lying, and is giving the incorrect state of this security posture. In reality, his gun is fully loaded and he is carrying a knife that has a 10-inch blade.)
Person behind the Door: ‘‘Our policy specifically states that all guns must be unloaded and that all knives must have blades less than 4 inches in length. Based upon those policies, you meet the minimum requirements. Thanks for telling me that information. You are permitted access.’’
Communicating the Security Posture of the Device 45 That would be a pretty strange and insecure conversation. I hope you get the point. The information would ideally come from a trusted source that wouldn’t, or couldn’t, lie.
Let’s not forget about the second point — authentication. Rather than using the security posture alone, it would be more secure to couple that security posture with an authentication method.
Adding authentication would change the previous conversation to the following:
Person behind the Door: ‘‘Our policy specifically states that all guns must be unloaded and that all knives must have blades less than 4 inches in length. Based upon those policies, you meet the minimum requirements. Thanks for telling me that information. Now that I know you meet our compliance standards, what is the secret password to gain access?’’
Unknown Person: ‘‘I do not know the password. Can I have access anyway?’’ Person behind the Door: ‘‘Our policy specifically states that you must be compliant and provide the secret password. Since you do not know the password, I cannot authenticate who you are. Consequently, your access is denied.’’ (The password was Bosco.)
To be fair to Cisco, they do offer a NAC option that would require authenti- cation and it uses 802.1x. If this option were used, the specific spoofing attack described earlier would not have worked. Authentication, however, is not mandatory and is one of three different configuration options that can be used. If you really want to implement a secure NAC solution, these examples should show you how important it is to provide an authentication mechanism.
N O T E Utilizing NAC with Remote Access VPN can provide an authentication mechanism. The authentication would be the credentials that are entered into the VPN client when the mobile person attempts to gain access.