2.2. Setting Policy for Device Analysis

As with a lot of security software (and quite a bit of software in general, for that matter), it's necessary to set up the configurations for how the technology will work. How this is done with NAC/NAP solutions depends on whether or not you are using agentless or agent-based solutions:

• Policy for an agentless solution can manually be configured on the server or piece of hardware performing the scan and subsequent analysis.

• Agent-based solutions can either be manually configured on each device or centrally configured via a policy server.

The first method is rather self-explanatory. You go to the device and tell it what to look for on devices that are attempting to gain access to the network.

The second method can require a bit more setup to help ease administration. For some NAC/NAP solutions, you can simply go to each device and manually configure the different security criteria that will be analyzed. This is obviously a very tedious and error-prone task, and is why having a centralized server on which to centrally administer policy is so important.

2.2.1. The Need for Different Analysis Policies

There is a distinct possibility that when a NAC/NAP solution is implemented, it will require the need for multiple analysis policies. As with many things, one way of doing something doesn't necessarily fit everybody.

The following are two major reasons why there would be more than one analysis policy for a NAC/NAP solution:

• Users utilizing different security technologies

• Users performing different roles within an organization

In a perfect world for enterprises, every single user would be standardized on the same software products and services. They'd all have the same software installed with the same version on the same OS and with the same configuration. Unfortunately, this isn't usually possible. Most organizations have a mix of versions and of technologies. So, if you're going to implement a NAC/NAP solution and analyze for different security criteria, you require a degree of flexibility.

A good example of security software not being standardized occurs with versioning. Many times I will speak with security departments and ask the simple question, "What version of antivirus software are you running?" Commonly, the answer is something such as, "We are running Symantec 10, though we still have some users on version 8 and 9." Then someone else will add, "... and we just bought a new company that is actually running McAfee ... and our research and development team kind of does whatever they want, so they are running Trend...."

Clearly, if a company responded in that manner, it would run into serious problems if it were basing network access on the requirement of Symantec 10 running and up to date. All the non-Symantec 10 users may have their antivirus software running and up to date, but they wouldn't meet that criterion, and would be restricted when accessing the network. Following are two good ways of addressing this problem:

• Having multiple policies — Users running Symantec would have one analysis policy, those running Trend would have another, and so on.

• Having "optionality" — In this scenario, there would be one policy looking for any major antivirus program to be running and up to date.

The invention of optionality has some very clear advantages over having multiple policies. Mainly, it's just less work, easier, and, consequently, less prone to error. You just have to ensure that the optionality component is able to look for all the software that you are looking to use. For example, optionality for one NAC/NAP component may only look for either Symantec, Trend, or McAfee to be running and up to date. That may work fine for one organization, but a separate company may actually have Computer Associates, Sophos, and so on, and that optionality component may not work for the software that they have in place.

In addition to different software, different users have different roles within an organization. Therefore, they may require different analysis policies. Consider the roles of a system administrator versus that of a sales guy. A sales guy really has no reason to mess around with his security setting and applications. A sales guy should not be disabling his personal firewall or antivirus; they are there to protect the system.

On the other hand, a system administrator may have very valid reasons for temporarily disabling certain security settings and applications. In fact, doing so may be necessary to perform the job function. Whether it's performing network analysis, testing applications, or testing various settings, the system administrator often needs the ability to modify settings.

If both users were treated exactly the same, then the system administrator could be quarantined or prohibited access from the very network he or she is attempting to administer. The sales guy, however, should not be able to access the network if his security posture is deficient. The ability to have various policies is clearly a key for scenarios such as these.