Network Access Control (NAC) is one tier of a multitiered approach to protect the security and integrity of your network, applications, and data. The goal of the NAC tier is to discover and vet each device on the network. Once the system discovers a device, it evaluates that device—according to rules that the administrator has set—to determine the likelihood that the device will behave as a proper network citizen. These rules generally require that endpoints run a minimum software configuration (e.g., antivirus software).

The products I cover in this comparative review—Sophos's EndForce Enterprise 2.6, InfoExpress's Dynamic NAC for Windows 5.1, McAfee's Policy Enforcer 2.0, and StillSecure's Safe Access 5.0—all protect against endpoints that plug into the local network. All these products are software that you install on your own hardware. (An alternative in the market is the NAC appliance, a field that deserves its own comparative coverage.) Another class of product—often placed in-line with network gateways—acts in a pre-connect fashion to filter and vet traffic originating outside the local network. Cisco NAC and Microsoft Network Access Protection (NAP) are other proprietary approaches you'll also want to know about. For more information about Microsoft NAP, see the sidebar "Microsoft's NAP Option."

Enforcement Methods
There are several common NAC enforcement methods. Agent-based enforcement relies on software running on each system to assess the system and restrict a failing system's access to network resources. DHCP-based enforcement causes systems that fail a policy assessment to receive a network configuration that restricts their ability to communicate with other systems. SNMP-based enforcement works with network switches capable of SNMP-managed Virtual LANs (VLANs); endpoints that fail assessment are assigned to a limited-access VLAN. Finally, 802.1x-based enforcement works with 802.1x-supporting switches; every time a client activates a switch port, it's placed in a limited-access VLAN until it authenticates to a NAC server and passes assessment.

One of the products tested here—InfoExpress's Dynamic NAC for Windows—uses yet another enforcement method: Address Resolution Protocol (ARP) redirection. Pre-connect and Post-connect testing differentiate the various methods: 802.1x-based enforcement is a pre-connect method because a new endpoint's traffic isn't allowed on the network until it passes muster. In general, the other methods act in a post-connect fashion, which comes with its own associated vulnerabilities.

Each enforcement method has positive and negative aspects. Agent-based enforcement (distinct from agent-based assessment) is vulnerable to systems that aren't running the agent. DHCP-based enforcement is vulnerable to systems with static IP addresses. SNMP and 802.1x enforcement rely on hardware that many organizations don't have.

Sophos EndForce Enterprise 2.6
EndForce Enterprise (EE) 2.6 is a Windows server—based NAC solution that offers both pre- and post-connect enforcement. In January, Sophos acquired EndForce, and in May (after the completion of this review) the company plans to release an enhanced and rebranded version of the product: Sophos NAC 3.0. Although Sophos routinely provides onsite installation assistance to new clients, I installed it with a bit of telephone support.

Architecture. EE implements a client agent/server architecture, with support for enforcement at the EndForce Agent, 802.1x switches, Microsoft or Lucent DHCP servers, and VPN concentrators. It also supports the Cisco NAC framework. In large networks, EE lets you install multiple, identically configured EE application servers in a Network Load Balancing (NLB) configuration.

In all enforcement modes, EE relies on an agent installed on the endpoint to assess the endpoint's policy compliance. EE includes ActiveX and Windows service-based clients, but no clients for Linux or Macintosh systems. Prior to installing an agent, you create a customized installation MSI file to set the IP address of the EE application server it will work with, then select one of three operating modes for the agent: Quarantine, which assesses the client per policy before admission to the network and then periodically thereafter, and quarantines the client whenever the system determines a policy violation; Continuous, which is similar to Quarantine but doesn't quarantine the client on policy failure; and On Demand, which is designed for VPN applications.

Distinct from the other products reviewed here, EE takes an end-user—oriented (rather than computer-oriented) perspective toward NAC policy enforcement. In EE, endpoints have one of three states: a known user on a managed endpoint, a known user on an unmanaged endpoint, and an unknown user on an undetermined endpoint. Within EE's Policy Manager, you assign policies to EE user groups, which you can configure to associate with Active Directory (AD) user groups.

Users often implement both DHCP-based enforcement (to quarantine new DHCP client systems until they can be assessed) and Agent-based enforcement (for ongoing management and periodic re-assessment of company systems). EE implements DHCP enforcement with the use of a DHCP Enforcer module, which you install on the DHCP server. Combined with the use of DHCP user classes, this allows EE to cause the DHCP server to provide endpoints that fail policy tests with network address settings that restrict their access to network resources. For example, an endpoint in violation of policy might receive an IP address, subnet mask, and gateway address that lets it access only a remediation server.

Installation. EE runs on a Windows Server 2003 system configured with Microsoft IIS and Internet Authentication Service (IAS). The product also requires the use of a Microsoft SQL Server 2000 system. The basic installation routine on the EE application server went fairly smoothly, followed by an hour of post-installation configuration involving IIS and IAS, and—through EE's Web console interface—configuring an agent MSI package. The Web console uses popup windows, so I had to turn off my computer's popup blocking. I created a policy requiring only an EE agent; this became the default policy because it was the first. I created an EE user group and associated it with the domain users group, then assigned the policy I had created to the EE user group.

To start testing, I installed the agent to a Windows workstation, then discovered that users are required to provide a user ID and password to the agent for the agent to register with the EE application server. The agent uses IAS to authenticate and register clients with the EE application server. At first, my authentication failed because my user ID lacked remote access privileges, so in IAS I created a remote access policy to ignore a user account's dial-in properties. Registration then succeeded, causing the agent to download default policies. Until then, the workstation had been quarantined from the network because I had configured that option in the agent installation .msi file. Next, I reconfigured the policy to require an antivirus software package that it didn't have. Shortly—within the short policy refresh interval I had set—the workstation was again quarantined. I tried installing the agent to a second workstation, and the system denied network access again. EE's Web console reported the quarantine and the reason, as you see in Figure 1.

Bottom line. EE would be an effective addition to your network security toolkit, with the highest security levels provided using 802.1x or Cisco NAC hardware, which operate in a pre-connect mode. The combination of Agent-based and DHCP enforcement will likely catch the most prevalent threats to network security. I found the structure of EE more complex to implement and manage than that of some of the other systems, and the necessity for users to key their user ID and password into the agent is somewhat annoying. The user-oriented perspective is consistent with the way many networks are managed, although I still would have wanted to see the console able to present a list of all detected endpoints—not just those with agents or DHCP-assigned addresses. The security console's Help system describes all the configuration panels, but I didn't always find the descriptions enlightening. I also looked for—and didn't find—documentation that would describe the architecture in technical detail. Lacking that, I found myself on the phone with my technical contact several times.

InfoExpress Dynamic NAC for Windows 5.1
Dynamic NAC for Windows (DNW), a post-connect NAC solution, is available from InfoExpress as installable Windows-based software and as an appliance. Although InfoExpress markets the product as DNW, the UIs and installation module (i.e., cgsuite.exe) indicate that it's a function set within InfoExpress's CyberGatekeeper (CG) product line. For consistency, I'll use the DNW product name.

Installation. The product has some basic requirements. It requires a Windows 2003 system configured with IIS. It makes use of SQL Server and installs Microsoft SQL Server Desktop Engine (MSDE) 2000 on the database system that you designate if it fails to find an instance of SQL Server. I chose the default installation, which proceeded quickly and painlessly.

Architecture. DNW is a client agent/server-based system with support for Windows, Linux, and Mac network endpoints, although the Linux and Mac agents won't support the NAC function set until later this year. An ActiveX agent is also available. An optional reporting manager consolidates agent logs into the database and generates activity reports. The DNW Server appoints selected endpoint agent systems on each subnet to act as enforcers.

Dynamic NAC uses ARP redirection. To explain, I'll start with a brief networking refresher. At the time of manufacture, a computer's Ethernet card is encoded with a Media Access Control (MAC) address. To send a packet to a specific computer or gateway device on the local subnet, a computer needs to know the target's MAC address. ARP gives the computer the MAC address it needs when it wants to communicate with a particular IP address. ARP redirection works by sending the computer the MAC address of a system other than the one with the specified IP address. Using ARP redirection, one computer can control another computer's access to computers on the network. Note that this technology works on Windows networks because the Windows IP stack seems to always honor the ARP packets that others send to it. A clever programmer could write a stack that behaved otherwise. Agents on each subnet listen for rogue systems—systems that both lack the dynamic NAC agent and aren't defined on a white list for the subnet. When a rogue device attempts to communicate with a system it's not allowed to communicate with, the agent sends it ARP packets, which redirect its communication, usually to a remediation server for installation of an agent and further policy compliance analysis.

Hands on. DNW includes three UIs. You use the CyberGatekeeper Policy Manager GUI to create the policy sets that the system uses to evaluate network endpoints. The CyberGatekeeper Reporting and Management System (CGRMS) is a Web-based interface for configuring and monitoring policy enforcement on network subnets. CyberGatekeeper Server Configuration is another Web-based interface for configuring aspects of DNW server's configuration. During DNW installation, you assign a password to the default "root" account. CGRMS lets you create additional users who are authorized to modify the DNW server's configuration, modify Dynamic NAC configuration, and perform reporting.

DNW requires a fair amount of post-installation configuration. For example, you need to designate subnets to monitor and router-style access lists that let enforced systems (i.e., systems that DNW is restricting from full network access) communicate with remediation servers and other network resources needed for remediation.

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.

I tested host-based enforcement by creating a simple rule requiring McAfee AntiVirus Enterprise to be present on a system, and applied the rule to three systems running the Enforcer agent and lacking the antivirus product. All three reported the lack of compliance, and had restricted network access. Although I could ping other systems on the network, I could access neither network shares nor remote web sites.

McAfee has a lot on its development road map. Windows Vista support is planned for later in 2007. Support for 802.1x and DHCP enforcement are both on the horizon, without a specific timetable. Inline, pre-connect NAC features are also planned, based on McAfee's IntruShield Intrusion Prevention System (IPS) security appliance.

Bottom line. MPE is a well designed, very manageable package. The EPO console is a sweet piece of work that integrates MPE well with other elements of McAfee's system and network security framework. Working with SNMP-manageable switches in particular, it can provide effective NAC. I recommend it to those who can live—for now—without 802.1x and DHCP enforcement methods.

StillSecure Safe Access 5.0
StillSecure's Safe Access, unlike the other products reviewed here, is a Linux-based application that installs to a bare-metal server. StillSecure provides implementation assistance to all clients; an onsite technician performed the installation for this review.

Architecture. SafeAccess supports agentless, ActiveX-based, and client-agent—based endpoint assessment. On the enforcement side, SafeAccess supports 802.1x and inline pre-connect enforcement, and agent-based and DHCP post-connect enforcement. It also participates in a Cisco NAC framework.

Administrators of larger networks can place Safe Access Enforcement servers—either individually or in load-balanced clusters—on network segments at various locations. With this implementation, Enforcement servers all report to, and are managed through, a single management server.

The Web browser-based management interface is well designed and accessible through a secure HTTPS connection. Four classes of user IDs—System Administrator, Cluster Administrator, Help Desk, and View Only—support a distributed administration approach. As Figure 4 shows, the management interface displays the status of all detected systems on the network, along with context-sensitive Help information.

As with the other products reviewed here, assessment and enforcement policies provide a framework for every Safe Access implementation. StillSecure provides a broad scope of assessment tests you can apply to your policies, including testing for the presence of most common security applications, OS and browser updates and settings, and common malware. You can also test for required and prohibited applications. Safe Access ships with a variety of predefined policies, offering high, medium, and low levels of enforcement. Safe Access automatically downloads test updates, making them available for use but not automatically applying any to active policies.

Safe Access offers many features that support a gradual, user-friendly NAC implementation, including an ability to temporarily grant network access to a system that has failed specific policies. When a system fails an assessment test, you can provide the user instructions for manual remediation or make use of Safe Access's support for several popular automated remediation applications.

Hands on. The basic installation, initiated by booting the server with an installation CD, proceeded quickly. As with the other products, the initial configuration took proportionally much longer than software installation. For the testing, I configured Safe Access for 802.1x enforcement. Configuring Safe Access to use 802.1x quarantine networks requires only providing the quarantine subnet addresses and selecting the 802.1x check box. The balance of the configuration included setting initial policies and configuring an 802.1x switch with the required authentication and VLAN information. This post-installation configuration took less than two hours.

Following the assisted initial implementation, I reviewed the available configuration screens and tested additional features. Safe Access lets you specify which of the three testing methods—Safe Access agent, ActiveX agent, or agentless—you want to employ, along with the order in which the system will attempt then. Safe Access supports three sources of credentials for authenticating agentless endpoint testing: Windows IDs, LDAP, and a Java Database Connectivity (JDBC)-accessible database.

Policies work uniquely in Safe Access. Each Safe Access server uses one set of policies. You can customize the provided policies and add additional policies of your own, in either an enabled or disabled state. You assign to each policy a set of Windows domains or endpoint devices by name, MAC address, subnet address, or IP address range, then arrange the policies in a logical order. Endpoints are tested according to the first policy for which they meet membership requirements. Endpoints that match no policies will be tested according to the last—usually most restrictive—listed policy. For each test within a policy, you can set actions that Safe Access will take on failure, including an email message to an administrative email address, immediate or delayed quarantine, and a call to an automated remediation system. When an endpoint fails more than one test in a policy, the software assigns the most restrictive of the resulting failure actions. I configured email notification and found that it provided a detailed description of the reasons an endpoint failed the test—information that occurred to me as potentially quite useful to Help desk staff assisting users with remediation problems. If predefined tests don't meet your needs, the Safe Access user guide documents how to use the Python development language to code custom tests.

When testing quarantine, I found no surprises. Test failure resulted in immediate quarantine when that was configured and in delayed quarantine if that was the test specification. From the device status screen, I was able to immediately grant a quarantined device additional time, and I was able to retest the endpoint for compliance.

Bottom line. Safe Access offers network administrators an excellent combination of ease of use, flexible policy assignment, and network security options. The Web-based UI is responsive, quickly understood, and replete with useful context-sensitive Help. Although the Safe Access management interface lacks the integration of other tiered security products (e.g., McAfee's EPO), you might prefer the lean, efficient simplicity of its design.

Editor's Choice
At the conclusion of my testing, I had two favorites in this group. First, StillSecure's Safe Access gets my Editor's Choice for its clean 802.1x implementation, easy manageability and flexible quarantine features. I didn't test performance features, but I suspect the product's Linux-based, designed-for-NAC core would handle a heavy load. My other favorite is McAfee's Policy Enforcer. I'm a fan of the EPO console for its well designed ability to integrate the management of McAfee's suite of security products.