2.1. Analyzing the Security Posture
It would be pointless to have a NAC/NAP solution that treated every device exactly the same way. For example, if the goal was to restrict every device from a network, there are certainly ways to globally lock everybody out, though what would be the point of having a network where no one connected? The same is true for letting all devices onto a network. You would simply let them all on and not really need any type of NAC/NAP solution. The element needed is knowledge to make a decision on whether or not the security posture of a particular device that is attempting to gain access is sufficient enough to allow that access. An important step in that process is analyzing the security posture of the device.
There are two basic means to analyze the security posture of a device:
Using an agent or client that resides on the device
Using a network-based scanning mechanism to assess the device
Both of these options have advantages and disadvantages. These will be covered in detail later in this chapter, but it's important to understand now that these basic two options are the choices.
2.1.1. What to Analyze?
The analysis of the device is certainly one of the most important elements of any NAC/NAP solution. This is the "meat" of any NAC/NAP solution, and it requires very careful consideration. A fine balance is necessary between being stringent enough on the criteria to allow access to an appropriate level of security, and being realistic enough as to not adversely affect productivity. For every company, this balance will be unique to its goals, users, infrastructure, corporate policy, and corporate political environment.
Commonly, the following criteria are considered for analysis on devices attempting to gain access:
Are antivirus software definitions up to date, or within an acceptable margin of time? (For example, the software may not necessarily have the latest version of the definition files, but the definitions are only one or two versions behind, or have been updated within the last 14 days.)
Are antispyware software definitions up to date or have they been updated within an acceptable period of time? (For example, the software may not necessarily have the latest version of the definition files, but the definitions may be only one or two versions behind, or have been updated within the last 14 days.)
Does the device have the required patches for other software components? (Microsoft programs aren't the only enterprise applications that require security patches/updates.)
Are any prohibited applications installed or running on the system? (These can included LimeWire, Kazaa, and so on.)
Is the device an asset owned by the enterprise? (This is often established by checking a registry setting, the existence of specific files or other flags that only exist on corporate-owned assets.)
Are Sys Admin, Audit, Networking, and Security (SANS) Institute Top Security Vulnerabilities present? (These are not fixed by patches; they are configurations that can exist on a device that make it particularly vulnerable to exploitation. More info can be found at www.sans.org/top20.)
Are other specific enterprise security applications installed and running?
Custom checks as deemed appropriate by the enterprise.
This list pretty much sums up what most enterprises are seeking to analyze on devices attempting to gain access to their networks. That's certainly not to say that additional elements couldn't be added, or even modified. I know of a company that didn't care if its antivirus was necessarily running; it cared if it was installed and set to automatically start upon system boot. Why did it want to have this unique policy? The answer is because its specific antivirus would shut itself down when it would get updates. These updates sometimes took a while, so it didn't want to lock out its users when these updates were taking place.
2.1.2. Does Your Company Have the "Strength"?
There's really no right or wrong answer when it comes to deciding the criteria that will be analyzed. It's what is right for each enterprise that matters. That being said, there certainly are best practices that should be considered, regardless of the type of NAC/NAP solution that is being used. Without a meaningful analysis, NAC/NAP can be pointless. This poses a very big philosophical question to all enterprises wanting to implement a NAC/NAP solution:
"Does your company, and its leadership, have the strength and steadfastness to actually enforce a meaningful analysis of devices coming onto the network, and are they willing to take the stance that noncompliant devices will be temporarily restricted if they do not meet the minimum security requirements?"
This sounds like a simple question, but you would be amazed at the companies that simply don't have the internal "strength" to take this stance. I've spoken with companies in healthcare, law, and so on, who simply state that their doctors, lawyers, and so on, simply wouldn't put up with this type of restriction, so it's not an option for them. That is a very weak stance, or excuse, and let me just say that I'm glad I don't work for one of those companies. That notwithstanding, IT professionals truly need to get buy-off on this question before they pull the trigger and start implementing a NAC/NAP solution. Otherwise, all the efforts put into the solution will be for nothing, because the company doesn't possess the strength to implement a meaningful solution.
2.1.3. Patch Analysis Best Practices
There are some best practices around patch analysis that need to be discussed. Checking each device for patches is one of the most important security checks that can be done. The reason for this is that patches remove vulnerabilities. By patching a machine, you are protecting it against all of the exploits that attempt to take advantage of that vulnerability. In contrast, antivirus and other reactive software will try to catch individual exploits. They may find some exploits and miss others. Consequently, it is much better to simply remove the vulnerability (and subsequently all the related exploits) entirely by patching the machine.
A challenge to enterprises is deciding upon which patches really matter to them, which ones would be nice to have, and which ones actually end up breaking their systems. If a moderate Microsoft patch breaks a core enterprise application, it wouldn't make a whole lot of sense to ensure devices had that patch before they were granted access to the LAN. Patch analysis best practices can be broken down into two basic types:
For noncritical patches that do not pose an immediate and significant threat to enterprise, allow a sufficient period of time for devices to receive these patches before analyzing for them and implementing restrictive measures.
For critical patches that pose an immediate and significant threat to the enterprise, immediately begin analyzing for the patch and restricting access if the patch is not present.
The first point makes sense, but I have seen companies not give it much thought. Depending on the severity of the problem the patch addresses, you may want to give users a fair opportunity to get the patch before you decide to add it to the list of items to check that would make it noncompliant.
The second point is really important. If you're going to take the time to implement a NAC/NAP solution, you need to have the commitment to actually look for critical shortfalls and take action upon them. The important point to realize is this:
"Restriction is not forever!"
Just because a user is temporarily restricted until that user gets a patch doesn't mean the world is going to end. It simply means the user must be brought up to snuff and that's a fact of life for users attempting to gain access to a network that uses NAC/NAP. So, enterprises do need to protect themselves against systems that are missing these patches, and the first step is to actually look for the patches.
Determining which patches to check for can be a challenge for companies. Microsoft Tuesday comes around all too often, and the list of Critical patches alone is quite long. Following is a list of Critical Microsoft patches just for 2006:
MS06-001
MS06-002
MS06-003
MS06-004
MS06-005
MS06-012
MS06-013
MS06-014
MS06-015
MS06-019
MS06-021
MS06-022
MS06-023
MS06-024
MS06-025
MS06-026
MS06-027
MS06-028
MS06-035
MS06-036
MS06-037
MS06-038
MS06-039
MS06-040
MS06-041
MS06-042
MS06-043
MS06-044
MS06-046
MS06-047
MS06-048
MS06-051
MS06-054
MS06-055
MS06-057
MS06-058
MS06-059
MS06-060
MS06-061
MS06-062
MS06-067
MS06-068
MS06-069
MS06-070
MS06-071
MS06-072
MS06-073
MS06-078
That's 48 Critical patches just for 2006. There are also many Important Microsoft patches whose absence, in actuality, may be just as lethal to an organization. It is still important for enterprises to go through their own analysis of Microsoft patches to determine which ones matter to them, because not all of them may be important. Regardless, it is imperative that companies use their NAC/NAP solution to check for the ones that are.
2.1.4. How the Analysis Takes Place
How exactly the state of the security application or configuration is determined depends on a number of different factors. Among these factors are the security application or configuration being monitored and the type of NAC/NAP solution being used. The following are some methods by which the security state can be analyzed:
Utilizing application program interfaces (APIs) from the operating system or security application that are specifically designed to communicate their state to NAC/NAP solutions
Monitoring processes
Monitoring services
Monitoring registry settings
Monitoring for the presence of (or properties of) specific files
In realizing how the analysis takes place, it's important to note what criteria should be analyzed. Following are common examples:
The current state of the security application (that is, running, stopped, disabled, updating, and so on)
The current version of the security application
The current version of any components of the solution that are frequently updated (such as antivirus definition files and antispyware definitions)
Understanding how and at what level security applications integrate with a NAC/NAP solution is very critical. Some of the methods require very little work by the enterprise, while others require a level of research and trial and error. Let's talk about the different methods and their impact on the enterprise.
2.1.5. Utilizing APIs for Analysis
The quickest and easiest way for analysis to take place is via APIs. You'll find that many of the leading security vendors will find it in their best interests to provide APIs that can be used by different systems performing NAC/NAP functionality.
A good example of a company that uses this method is Symantec. It has created an API that various SSL and IPSec VPN devices can utilize to understand the security state of their security application. This makes the integration that much easier for the enterprise, which then does not need to get creative, as you'll see in some of the other methods.
Figure 2-1. Task Manager listing processes currently running on a system
2.1.6. Monitoring Processes
Sometimes, an API is either not available, or there is another need to look at a process to determine a security application's state. Looking to see what processes are running on a system can easily be done by utilizing the built-in Windows utility Task Manager. Figure 2-1 shows Task Manager and a listing of the processes currently running on a system.
Let's say that you want to determine if a particular security application is running. We'll use the ISS/IBM enterprise-grade firewall Proventia, formerly BlackICE and Real Secure Desktop Protector (RSDP), as an example.
When the firewall is running, there are a number of processes that can be seen running. Figure 2-2 shows two of the key processes, blackd.exe and blackice.exe. As an administrator, it's pretty easy to determine that these processes are linked to the firewall, particularly if you know that it was called BlackICE in the past. Blackd.exe is the actual service engine and blackice.exe is the graphical user interface (GUI) component.
So, if a NAC/NAP solution was being utilized, it would be possible to look at these processes and the state of the firewall could be determined — mostly.
Figure 2-2. Two key processes seen running when a firewall is running
Here's the part where the research and trial and error must be put into place. While it is true that you can monitor these processes and get an idea of what's happening with the firewall, it won't necessarily give you the big picture. For example, there are other processes that may need to be monitored. For instance, the process RapApp.exe is a key process that provides advanced functionality. Without knowing all the processes, it could be easy to miss this process and, therefore, not get a full picture of the state of the application. Figure 2-3 shows the process RapApp.exe.
The key point to understand is that detail must be known as far as what the processes are and what they do. This information is best obtained from the vendor.
It's also extremely important to note that sometimes processes can disappear under certain circumstances. For example, a process may run under normal conditions, but when the application is being updated, that process may disappear and be temporarily replaced by another. The best advice, again, is to communicate with the application vendor.
Figure 2-3. The RapApp.exe process
Monitoring for wanted processes is an important method for understanding the state of security applications. A related task is monitoring for unwanted processes and applications.
2.1.7. Monitoring for Unwanted Processes and Applications
Just as it is important to monitor for wanted security applications, it can be equally important to analyze the device for unwanted security applications. With many users having the ability to install any applications they desire, it's necessary for enterprises to know what unwanted applications are running. There are a number of applications that fall into this category, such as the following:
Instant messaging (IM) applications
File-sharing applications
Shareware and unlicensed software
Figure 2-4. Task Manager and the associated process running for Yahoo! IM
The security risks with these types of applications are significant. Chapter 3 examines specific threats to these applications. For the purpose of this section, let's look at Yahoo! Instant Messenger. While I personally like and utilize Yahoo! IM, there are enterprises that do not want it or other IM applications to run on their systems.
As with monitoring for wanted applications, unwanted application can also be analyzed by looking to see if their associated processes and services are running. Figure 2-4 shows Task Manager and the associated process running for Yahoo! IM.
NOTE
Take a look at Figure 2-4 and note the amount of memory being utilized by the Yahoo! Instant Messaging application. You will see that it is over 37MB of RAM! Commonly, I will hear enterprises complain about having to put additional agents and software onto their systems to help secure them. They state that their systems can only afford to give up so much RAM and hard drive space in the name of security. Whenever I hear this, I literally mention to them how much memory Yahoo! Instant Messenger actually utilizes and compare that to the RAM from the security application in question. Drawing that comparison will almost always put that issue to rest.
While looking at the process is an easy way to see if an unwanted application is running, there's a better way of doing it. Looking at the hash of the application, not just its name, will provide better results.
Let's say that a company has a policy that states the computer game Solitaire can't be played. In addition to having a written policy, the company also has a technical means to see if Solitaire is running and, if it is, then the application will automatically be killed. The technical means consist of the security application looking for the appropriate process; in this case, the process is called sol.exe, as shown in Figure 2-5.
As an end user, you may be rather upset about your company controlling which applications can run on your machine. Perhaps, you really like Solitaire and use it to kill time in airports or during boring conference calls. You don't see a security risk, so you decide to see if you can circumvent this policy. Can it be done? Yes, it can, and it can be done rather easily.
The particular method this company was using was simply looking to see if sol.exe was running as a process. If it was running, the application would be killed. Now, what if Solitaire were running, but it wasn't running as the process sol.exe. Would it be caught? How could that be done?
Figure 2-6 shows the actual file executable for Solitaire, which is sol.exe. This is the file/application that is executed when a user tries to run Solitaire.
If the end user wants to run Solitaire and sol.exe is being monitored, the user can simply rename the executable. When this is done, Solitaire will be running under a different process name and can, therefore, circumvent the system. Figure 2-7 shows sol.exe being renamed, while Figure 2-8 shows Solitaire running under the new process name.
Figure 2-5. The sol.exe process
Figure 2-6. File executable for Solitaire
Clearly, this is not a very complex hack, but, at the same time, it really does work a lot of the time. In fact, the very computer that was utilized to take those screenshots actually had a security policy in place to kill sol.exe when it was running. Consequently, those screenshots needed to be taken very quickly before the application was killed. Once the process name was changed to FooledYa.exe, however, the Solitaire game could run as long as I desired.
Now, let's say that a security application didn't use the simple technology of looking at the process name. Let's say that, instead, the security application looked at the hash of the application. Figure 2-9 shows Pinpoint Laboratories' hashing application "Pinpoint Hash" displaying various hashes for sol.exe.
As shown in Figure 2-9, the SHA-1 hash for sol.exe is 849ABAA9C524 FF6DA8891C3DA01350C18EA1A1D4. This can be treated as a unique identifier for the particular file. In all the world, there should not be another file that has that same hash.
Conversely, let's look at the hashfor FooledYa.exe. Remember, FooledYa.exe is actually just sol.exe renamed. Figure 2-10 shows a screenshot of Pinpoint Hash creating the hash for FooledYa.exe.
Figure 2-7. sol.exe being renamed
Figure 2-8. Solitaire running under the new process name
Figure 2-9. Pinpoint Laboratories' hashing application displaying hashes for sol.exe
Figure 2-10. Hashes for FooledYa.exe
You can see by looking at Figure 2-10, that the SHA-1 hash for FooledYa.exe is 849ABAA9C524FF6DA8891C3DA01350C18EA1A1D4. Regardless of the filename, the SHA-1 hash for the application executable is exactly the same for sol.exe as it is for FooledYa.exe. That is because the contents of these two application files are also exactly the same.
It should be very clear that using hashes is a much better way of identifying application executables and files. Consequently, if a company really wants to ensure certain applications do not run, using hashes is the better method to achieve this policy. Any NAC/NAP solution that such a company would want to use, then, would ideally have the functionality to use hashes instead of process names.
As a good starting point, following is a list of applications each company should consider how it would like to handle. In no way is this book attempting to say that these applications are bad and shouldn't be used, but it is the experience of the author that these are applications that various customer security departments have previously communicated as being of concern.
Planet.MP3Find
ScourExhange