2.3. Communicating the Security Posture of the Device

Once the NAC/NAP solution has the appropriate policy so that it knows what security components to analyze and actually performs that analysis, the security state of the device must be communicated. This communication can go to:

• Another NAC/NAP-specific software component

• A third-party software component

• A component external from the device itself (such as a server or piece of hardware)

Keep in mind that the first two points have to do with NAC/NAP-related software running on an individual machine. The third component has to do with the NAC/NAP software on the machine communicating outside of the device itself.

Whatever the component, the intention is the same. The state of the security posture has been determined, and another component (or components) must know about it. The type of NAC/NAP that you are utilizing, as well as how you are using it, will determine which of these methods will be used.

This communication must take place so that the other NAC/NAP components know what action to take based upon the compliance state of the device. If a network device is going to restrict where on the network a device can go because it's noncompliant, that network device first must know if the device is compliant or not. This is simply done via communication.

2.3.1. Communicating with NAC/NAP-Specific Software Components

It is common for NAC/NAP solutions to have multiple components in the solution as a whole. Going back to the car example, there's more to a car than just the engine: there are tires, a steering wheel, and so on. All the components need to work together to make the car (or NAC/NAP solution) go.

Once the analysis takes place, the state of the security posture can be communicated to the other components of the solution. Here's a quick vendor-neutral example of this type of analysis.

Let's say that a company is using a NAC solution where the state of each laptop is constantly being assessed. The state of the laptop, either compliant or noncompliant, determines whether or not the laptop can use different applications. Specifically, if the laptop is noncompliant, then the end user cannot utilize Internet Explorer. The enforcement of restricting this application is also done by the same NAC/NAP solution that analyzed the security posture of the system, but it is done by a different component. How does the restricting component learn the state from the analyzing component? The answer is communication.

Ideally, this communication is "hidden" within the NAC/NAP application on the system and is never really seen in clear text. One example of how this could be done is by having the current state reside within an encrypted database within the application. That way, the only other entities that could determine the state of the device are other components of the solution that had access to the encrypted database. Why does this even matter?

Well, if the security state of the device was in clear text and it was known from where other components would read this information, then the security posture of the device could potentially be modified. An end user, or even malware, could potentially want to falsely communicate that the device was compliant when, in fact, it is not. That way, a noncompliant device would be considered compliant and, therefore, would not be restricted.

Following are two examples of where the security state could potentially be modified:

• Registry settings — If there is simply a registry setting that is modified to communicate to the restriction component the current state of the device

• .ini, .inf, and other files — The security state is simply being written to an .ini, .inf, or other file.

Keep in mind that registry settings and .ini files are not the most secure means for NAC/NAP solutions to communicate their state to other internal components of the same NAC/NAP solution. Conversely, these methods may be the only choice when a NAC/NAP solution needs to communicate the security state to a third-party application.

2.3.2. Communicating the Security Posture to Third-Party Applications

Ideally, if separate NAC software components from different vendors needed to communicate to each other, they would use a secure API to do so. That way, the communication regarding the security posture of the device could not be modified, and it would protect the integrity of the NAC/NAP solution as a whole. Because there can be so many moving parts, and because NAC/NAP is truly not extremely mature at this point, this isn't routinely the case.

Let's look at an example of why it could be important for a third-party application on a laptop to know the security posture of the laptop as part of a NAC/NAP solution. The following will be the two main components of this example:

• A NAC/NAP component that analyzes the security posture of the laptop and communicates that state to ...

• ... an enterprise-grade personal firewall that can implement different firewall rule-sets based upon the communicated security posture.

This type of solution actually can have tremendous value for enterprises. If a mobile laptop's security posture becomes deficient, it would have tremendous value if that laptop could be restricted at Layer 3. This is particularly true if all inbound traffic could be blocked and outbound rules could be put into place whereby the laptop could only communicate with particular servers to be remediated.

So, there are certainly NAC/NAP components out there that can analyze devices to see if they are compliant, as compared to a defined list of criteria. There are also enterprise-grade firewalls that are capable of having multiple firewall rule-sets and can switch between these rule-sets based upon some kind of input. The key is getting these two components to talk to each other.

Again, it would be great if there were a magical API with which all major vendor software components could talk to each other securely to communicate this type of information. Until this is the norm, there is actually a pretty good solution to this.

This may seem completely contrary to what was stated in the previous section, but using registry keys can actually be a pretty good way to communicate different states to different applications. The key, again, is that this communication is to different vendor applications. This is not internal software application communication. Using the registry to communicate application state is not a new method, and many applications do this whether intentionally or not.

In fact, a quick example is the Cisco VPN client. By looking at a specific registry key, some very useful security information can be determined from this client. The registry key HKEY_LOCAL_MACHINESOFTWARECisco SystemsVPN ClientAllAccess determines whether or not a VPN tunnel is established with the Cisco VPN client. Figure 2-11 shows the key when a VPN tunnel is not established, while Figure 2-12 shows the key when a tunnel is established.

I know of many different applications that key off this registry setting and it is very helpful. Is it 100 percent foolproof? No, it really isn't. If you look at Figure 2-13, you will see that while the Cisco VPN client is actually connected (note the "lock" icon in the System Tray), the registry setting has been modified to communicate that the tunnel isn't connected. This was simply done by changing the registry key entry, as shown in Figure 2-14. Again, this doesn't mean that the use of the registry key isn't useful. There's a point with anything security-related where how foolproof a solution is needs to be weighed against how useful it is and how much security is added as a result of using the solution.

2.3.3. Communicating with Network Devices

In the case of Cisco NAC, Microsoft NAP, and other LAN-based NAC technologies, 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.

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 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 communication is to the NAC solution. If the communication is somehow tampered with, devices that should not have access to the network may gain unauthorized 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 intentionally 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.

2.3.4. 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 incorrectly. 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.

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.

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."

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 authentication 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.

2.3.5. Understanding TCG IF-TNCCS and Microsoft IF-TNCCS-SOH

Just as Cisco utilizes the Cisco Trust Agent for device-to-server NAC communication, the Trusted Computing Group utilizes its own standard. That standard is IF-TNCCS, which stands for "Trusted Network Connect Client Server."

As mentioned, TCG and Microsoft announced interoperability earlier in 2007. Basically, they have added the SOH (Statement of Health) binding to the IF-TNCCS protocol to create IF-TNCCS-SOH. This allows for Microsoft and other TCG-supported NAC solutions to interoperate.

The IF-TNCCS-SOH protocol utilizes a handshake methodology for its NAC/NAP functionality. Essentially, a client sends its SOH, which contains information on its current security posture. The NAC/NAP infrastructure then receives the SOH information and responds with its Statement of Health Response (SOHR). This communication handshake is illustrated in Figure 2-17.

Just as previously described, this communication is subject to the same vulnerabilities as with the Cisco Trust Agent. In the IF-TNCCS-SOH standard, there is a section that outlines details on how risks should be handled. Specifically, it states:

Security for health messages SHOULD be provided by IF-T. IF-T SHOULD guard against replay tampering and provide confidentiality and authentication of Health Messages. Health messages SHOULD NOT be transmitted in the clear if the transport protocol itself does not encrypt the communication.

So, if you consider the communication security questions, you see that TNC tries to directly address the first two within its protocol standard:

• 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 intentionally communicate an incorrect security posture?

While I am not aware of any current exploits against Microsoft or other TNC-compliant NAC/NAP systems that falsely communicate the security state to the agent, security professionals do need to be on the lookout. This is an important item that each enterprise must remain educated on in relation to its NAC/NAP solution.