Guard Your Network with Software NAC

Policies are key to the implementation of DNW. As Figure 2 shows, policies consist of When conditions, Requirements, and a response to use if the endpoint fails the policy. The system evaluates an endpoint against a policy when it satisfies all of the When conditions. It fails the policy if it fails any of the Requirements. The response can include a popup message on the client. For managed clients (i.e., clients running the DNW agent), the response can also include code in this window that causes the agent to run a program, which could initiate software installation. Administrators specify both conditions and requirements in terms of predefined or custom Compound Tests or Basic Tests. Basic Tests evaluate a single condition, such as an IP address, a running process, or the presence of a particular OS. Compound Tests consist of several Basic Tests; if an endpoint passes any of the Basic Tests, the Compound Test is deemed true. InfoExpress supplies a large number of predefined policies and periodically provides downloadable updates.

Within policies, Process Tests let you require the presence of any desired running program. To reduce the chances of a malicious user attempting to spoof the test, DNW lets you test attributes of specific DLLs loaded by the application. DNW supports a variety of test types, including OS version and network address.

To create a simple test, I created a policy that required Windows Notepad to be running on every target system. I created a second policy to require that a DLL loaded by the printer spooling service be running. I restricted the policy's When condition to a single IP address, then uploaded the policies to the DNW server. In testing, I discovered that DNW applies to an endpoint only the first policy that passes the When condition. My technical contact told me that this behavior is about to change, and future releases of DNW will cause an endpoint agent to apply all policies associated with When tests that the endpoint passes. Next, I created an agent installation package—a process necessary to preconfigure the DNW server's IP address with the agent. DNW doesn't provide a push-installation facility, so I shared the directory in which DNW placed the agent package, and I installed the agent to two client systems. I discovered that systems failing policy tests didn't have access to other managed systems.

Bottom line. DNW offers a NAC solution that doesn't require any intelligence in network switches. Depending on your ability to meet your endpoint testing requirements with predefined tests, it might take more or less effort to implement, and the structure didn't appear particularly difficult to understand. DNW does rely on the presence of managed agents on each subnet to act as enforcers, but that requirement didn't appear to add much overhead to managed systems.

McAfee Policy Enforcer 2.0
McAfee's Policy Enforcer (MPE) is a software-based post-connect NAC solution that leverages the facilities of McAfee's Common Management Agent/ePolicy Orchestrator (EPO) console server architecture. One of MPE's advantages is its ability to work with other McAfee security products under EPO's common management umbrella.

You can configure MPE to use host agent-based self-enforcement and SNMP-based switch enforcement. MPE uses an MPE agent installed on Windows endpoints (clients and servers) to evaluate systems for policy compliance. Agents designated as Policy Enforcer Sensors on each subnet identify new, unmanaged systems by listening to broadcast traffic and DHCP requests. If the network contains SNMP-managed, VLAN-capable switches, MPE asks the switches to place new, unvetted systems into a limited-access VLAN. Agents designated as Policy Enforcer Scanners assess agentless systems for policy compliance. MPE also supports the Cisco NAC framework.

You can place trusted network appliances and non-Windows based systems on a Trusted Host list, since without an agent, they can't be fully tested for policy compliance and MPE would otherwise restrict their network access. Super Agents also maintain a copy of all current policy sets, relaying them to endpoint systems and reducing network traffic to the EPO/MPE server.

The alternative to a managed agent is to configure the network to redirect unmanaged systems' Web browsers to a Web server, from which it would load and run an ActiveX-based scanning engine. For example, you might use this method to test a visitor's or contractor's system. MPE includes remediation portal Web site code to facilitate the creation of a remediation Web site, as well as the ability to automatically run remediation actions for an endpoint's failed rule.

Installation. You typically install MPE on the same server with EPO, but you can install it elsewhere to distribute the load. EPO makes use of a SQL Server database to store configuration and client-assessment information. After installing EPO, I installed MPE and selected the option to install the remediation portal.

Hands on. Figure 3 shows the EPO console. A console tree on the left includes a system directory, where you can create a multilevel hierarchy to organize endpoint computer systems. When you select an element in the directory tree, EPO displays a related configuration screen. The console is well organized and easy to work with. A right-click menu from the console tree's Directory line lets you import systems from AD containers. Unless you set up the auto-import functionality to assign new systems to folders in the Directory hierarchy by IP address, EPO places new systems in the Lost&Found folder. From there, you simply drag them to the directory folder of your choice. EPO pushes its agent out to selected systems, again from the right-click menu of a directory folder or computer name. With the EPO agent running on selected endpoints, I deployed MPE Scanners to the systems on the Task tab (available when you click a directory folder or computer).

The next step is to install MPE Sensors on network subnets. I completed this step from one of the tabbed screens that appear when you click McAfee Policy Enforcer in the console tree. MPE gave me the choice to designate specific sensor systems or to set a policy and let MPE make the selection. I let MPE choose systems by processor speed. Setting policies for the Policy Enforce Sensor is next (accomplished by creating a named policy through the Policy Catalog in the console tree), then selecting and assigning it to the directory folders holding the MPE Sensor systems.