2.4. Taking Action Based on the Security Posture
At this point, the device has been assessed and its security posture communicated to other necessary components of the NAC/NAP solution. So, now what?
This question is as much political and philosophical as it is technical. The real question is "What does your company want to do, and does it have the strength to stand behind that decision?"
There are a number of logical action items that can be taken against devices. These actions depend upon whether or not Mobile NAC or LAN-based NAC is being used.
2.4.1. Mobile NAC Action
Mobile devices are in a unique situation. It doesn't do any good to be able to quarantine a noncompliant laptop to only certain areas of the corporate LAN if the laptop is sitting at a Starbucks and isn't connected to the LAN. The restriction that will protect that device must relate to its current environment. This point will be made very clear in Chapter 3, "What Are You Trying to Protect?"
As such, here are some action options to consider for noncompliant devices with Mobile NAC:
Prohibit the device from connecting to the corporate LAN via VPN
Prohibit the device from connecting via Wi-Fi
Quarantine the mobile device so that it can only access certain areas of the Internet, such as remediation servers that can fix any security issues
Restrict the use of certain applications, such as Internet Explorer and e-mail, when in a noncompliant state
Automatically fix the problem!
Based upon the fact that the mobile device is mobile at the time these actions would need to take place, these actions would need to be performed when the device was not connected to the corporate LAN. The logic to perform those actions would need to be software-based, not hardware-based. That is an important difference between Mobile NAC and LAN-based NAC.
Prohibiting the device from accessing the LAN while mobile is an important action item. If Microsoft patches are missing, and antivirus software isn't running or up to date, the device can be a significant risk to the enterprise. Consequently, it simply shouldn't be allowed to VPN into the corporate network. This could be accomplished by having Mobile NAC kill the VPN application, or by having the VPN or other device enforce the restriction as the remote access to the LAN is attempted.
Sitting at a public Wi-Fi hotspot is the most vulnerable a laptop will ever be. Not only is it connected to the Internet (which has its own challenges), but it is also connected to the hotspot's LAN with direct connections to a number of unknown systems. Also, the data from the laptop is literally flying through air, and is often unencrypted. Because of these risks, it is a very good idea to prohibit public Wi-Fi Internet access when a device is in a noncompliant state. For example, if a mobile device is missing a Critical Microsoft patch that would allow a person with ill intent to connect directly to the device and exploit it at will, it would make sense to ensure that the device isn't able to connect to risky networks (such as public Wi-Fi hotspots) until the patch is received and the vulnerability remediated.
Quarantining to specific Internet subnets is pretty similar to restricting Wi-Fi. If the mobile device is in a bad state, stop it from accessing the wild Internet where it can get into even more trouble. The key point here isn't to restrict it from accessing the Internet entirely. The key is to have the user of the mobile device be productive and be secure while doing so. Locking users down completely isn't necessarily the best answer. If the device is still allowed to connect to servers that can push down any missing patches or update programs that may be out of date, this would allow the system to become compliant and the user to become productive.
A great number of vulnerabilities are browser-based. Just look at any Microsoft Patch Tuesday (the first Tuesday of every month), and you'll be pretty much guaranteed to see a number of patches being released to fix holes in Internet Explorer. These holes could allow a hacker complete access to a mobile system, just by the user's accessing a malicious web page for 2 seconds. That is quite a risk. If the device is missing a Critical Internet Explorer patch, it's a logical step to prohibit the user from using Internet Explorer until the patch is received. In essence, the applications that the user can use would be restricted.
The same is true for e-mail and other data-sharing applications. If a machine is in a noncompliant state, it has the potential to introduce bad things to the corporate LAN. Applications such as e-mail can expose the LAN to noncompliant systems. Therefore, restricting their use to only compliant systems will help protect the corporate LAN.
Here's my favorite action: Automatically fix the Problem! If the system is noncompliant, fix it so that the user can be productive. Remediation will be covered in just a bit here, but realize that the ultimate goal isn't to lock people out and stop productivity.
2.4.2. LAN-Based NAC Actions
As with Mobile NAC, the action items to take depend upon the environment. In basic terms, LAN-based NAC will do the following:
Allow compliant systems onto the LAN
Segment unhealthy systems to specific subnets of the LAN
Determine if the device is unknown and provide "guest" access to the device
In a Cisco NAC environment, the following are states in which a device can considered to be:
It would make sense that a healthy device be allowed normal access to the LAN. The difference between Healthy and Checkup is that the latter implies a state that could be better, though restriction is still not enforced. For example, antivirus definitions may need to be updated, though they aren't so far out of date that the device needs to be restricted.
Quarantine basically means that the device is in a noncompliant state. Therefore, it is restricted in what network resources can be accessed. As with Mobile NAC, it may not make sense to completely restrict the device. Allowing access to remediation servers can put the device into a compliant state and make the user productive.
Infected is considered to be about as bad as you can get. Something bad is actively happening on the device, and this has been detected. In this state, it may be desirable to completely restrict the device from any portion of the LAN. Keep in mind that a machine can actually be infected and in bad shape, though the state "Infected" may not be communicated — think rootkits that are hidden.
Unknown means just that. The LAN cannot tell anything about the device. Perhaps, this is a guest machine and it doesn't contain the Cisco Trust Agent. Enterprises may still allow unknown guest access, but that access may only be to a particular portion of the LAN. I've seen where companies only allow guests to have access to a segment that only allows connectivity to the Internet. This allows contractors, vendors, and so on, to get the access they need while not allowing them to get on the corporate LAN.