NAC appliances reveal who's rapping at your network door

As the NAC (network access control) market matures, the solutions are becoming more sophisticated at identifying users and assessing the security compliance of host devices. Answering questions such as how snugly they fit into the existing infrastructure (is it a forklift upgrade?) and how well they qualify a device’s security compliance posture before admitting it to the network helps to separate the wheat from the chaff.

NAC is all about identifying end-users, checking their host devices to ensure they’re within defined security requirements (anti-virus installed and running, for instance), and then assigning a security policy to them.

The security policy is key. It has to be created dynamically to fit a user’s current security status. The policy must determine whether the user is logged in on a wireless connection or in a conference room. Is it a line-of-business manager or the CEO? Are the user’s anti-virus signatures current? Are there any open ports on the hosts that violate acceptable policy? As a user’s posture changes, so should the security policy they receive.

When selecting a NAC system, administrators will also need to consider whether they want to deploy a solution that enforces at the host level or at the network layer. Doing it at the host level entails installing software agents on end-user systems across the enterprise and requires local access to each host. This approach can provide an extremely effective means of enforcement (see Elemental Compliance System).

Controlling user access at the network level may require wholesale equipment upgrades, but it can prevent an unknown user from gaining even the tiniest access to the LAN.

In this review, I tested four NAC appliances that enforce at the network layer and inspect all end-user traffic as it passes through. I had the opportunity to check out the Caymas 525 Identity-Driven Access Gateway, Lockdown Networks Enforcer 4.2, Nevis Networks LANenforcer 1048, and the Vernier EdgeWall 7000.

The good news is that each solution actually works insofar as authenticating users and applying access policies to them. All support a captive portal log-in for user authentication, which is fine for guest or unmanaged devices, but a captive portal is Caymas’ only means of logging in users. All vendors but Caymas support 802.1x for a more seamless log-in for managed devices. Two of the appliances reflect some of their past uses: Caymas has a strong SSL VPN history and Vernier includes many features borne of wireless security. Neither of these features detracts in any way from their respective products; they just add flavoring.

End point vulnerability assessment is where the products vary the most. Of the four, only Nevis currently lacks a host-checking engine. Caymas pushes either an ActiveX or Java agent down to the client on connect (which requires the logged-on user to have local administrative or power user rights), and destroys the agent at log-off. Vernier’s host check is agentless but does need Windows credentials to scan the device. Lockdown covers all bases with an agentless mode, Windows and Mac agents, and SMB (Service Message Block) scanning like that in Vernier. The one common theme is that for any of these solutions to truly determine the security posture of a host, access to the local device is required.

At the end of my evaluation, I found that none of the products cover every base. Each one is missing the last piece of the NAC puzzle: scalability, end point assessment, or reporting. The one that came closest to meeting all aspects of an ideal NAC solution is the Caymas 525 Identity-Driven Access Gateway. My biggest complaint is the cost of the unit -- $70,000 -- but this is for all features enabled, even the SSL VPN services for 5,000 concurrent users. Vernier’s EdgeWall 7000 was the low-price leader and was just narrowly edged out by the Caymas appliance. If it had a better on-device reporting system, it would have scored a little better and claimed top honors.

Caymas 525 Identity-Driven Access Gateway

The Caymas 525 Identity-Driven Access Gateway is an SSL VPN appliance for secure remote access to applications and data, as well as a flexible NAC solution for managing user access to the network. The 525 authenticates users then dynamically builds an access control policy based on their security postures. Its host-assessment capabilities aren’t as comprehensive as Vernier’s but they do provide a good measure of confidence.

Capable of handling as many as 5,000 concurrent users, the 525 is a 2U appliance with four Gigabit Ethernet interfaces and redundant power supplies. Each interface can provide connectivity to different network segments, allowing for flexible deployment. All user traffic must pass through the 525, but physical location in the infrastructure isn’t as important as how traffic flows through the device. Typically, like the other NAC solutions, admins will place the 525 near the network core.

Setting up, installing, and getting a basic default configuration online took me approximately an hour, with the better part of a morning getting device, application, and user groups defined. Microsoft SBS (Small Business Server) 2003 with AD (Active Directory) handled the authorization services. The 525 can also use LDAP, RADIUS, Secure ID, and a local database as a source of user names and passwords. I was able to map user groups in AD back to the Caymas appliance to take advantage of existing security groups. Caymas’ Java-based user interface was easier to navigate than most others in the group, second only to Vernier’s UI.

Integrated Windows log-in is one feature missing from the system. This means Caymas cannot make use of users’ Windows credentials to authenticate them and place them into a security zone. To access the network, all users must authenticate using the captive portal feature. The solution can, however, look up users in a number of different directories to obtain their group affiliations. Caymas says integrated Windows authentication will be available in a future release.

Caymas’ policy engine, like the others, requires some planning to get the most out of it, but after it’s in place, it requires little ongoing maintenance. Admins can define networks, resources, and applications either singularly or in groups. Admins can also create various security zones that bind networks, authentication methods, and host-checker results to specific Web and file resources and applications.

For example, I created a Financial security zone that required my users to authenticate against Active Directory, to be on an internal network segment, and to successfully pass the host checker. To this security zone, I then assigned a group of applications and resources users would then be able to access. If a user fails any of the required security items, he or she would be placed into a limited-access quarantine policy.

As I was creating and changing my security policies and zones, I was happy to note that I could easily see what my users’ effective ACLs (access control lists) would be. No matter if I had selected a specific application or a group of users, I could see in the same window what the security policy was for that object. This glimpse made double-checking the effective rights much quicker.

The Caymas host-checking system does not require an agent to be installed on the host PC. During the authentication process, the appliance will scan the host by pushing either an ActiveX or Java agent (depending on the environment) to the client. On disconnect, the agent is removed with no traces left behind. For the agent to install and run on the host PC, the logged-on user must have power-user or administrative rights to his or her PC. This could be a problem in enterprises where users have limited local rights.

As of this release, Caymas doesn’t come with a predefined list of anti-virus, anti-spyware, or personal firewall vendors. Admins have to create their host checking policy by entering the process name or some other identifying information, such as rtvscan.exe, to look for Norton AntiVirus, for instance. With minimal effort, however, it will scan for open ports, Windows service pack level, Registry entries, and files. Admins can nest host-checker policies using Boolean logic to create complex rules. Later releases will feature built-in anti-virus, anti-spyware, and personal firewall lists, as well as the capability of scheduling recurring host checks.

The 525 inspects all user traffic from Layer 3 to Layer 7, taking advantage of the application security engine normally applied to SSL VPN deployments. In fact, the underlying SSL VPN and security features are very much a part of the system. Basically, Caymas provides a stateful inspection firewall for every user and builds ACLs based on the overall security profile of each user. Each packet is inspected as it passes through the appliance, no matter where it comes from. Unlike with Nevis and Lockdown, a “one user to one port” association is not necessary.

Reporting is very well represented in the 525. Admins can view reports on user and resource activity, the number of successful and failed log-ins, and other system information. Admins can export the reports to CSV (comma-separated value) files for analysis in other reporting tools.

Lockdown Networks Enforcer

The Enforcer from Lockdown Networks takes an entirely different tack than the other NAC solutions in this review: It performs enforcement at the managed-switch level through SNMP by placing users into policy-defined VLANs. The policy engine is robust, though not the most intuitive one of the bunch. It does include various sample policies on which to build. Reporting features are the best of the lot with a wide variety of rich reports and graphs.

The Enforcer is available in 1U and 2U configurations (I tested the 1U device), with the 2U doubling the CPU and power supplies. Both versions come with a single Gigabit Ethernet interface for connecting to your managed switches. A single Enforcer can manage up to 256 switches and 4,096 VLANs.

Lockdown also offers the Sentry, a low-cost appliance that brings policy-based access control to remote offices, and the Commander, an appliance that will allow admins to manage multiple Enforcers and Sentries from a single console. Neither the Sentry nor the Commander were part of my testbed.

Among all the NAC appliances reviewed here, Enforcer is the only one that does not sit inline with the flow of traffic. Instead, it talks to managed switches via SNMP and places each port on the switch, based on user authentication, in various VLANs. Each security policy corresponds to a VLAN, either an existing one or one defined for the purpose of managing access to specific resources.

Enforcer’s approach to policy enforcement differs greatly from that of its competitors; it’s also quite limiting. Part of the initial setup of my Enforcer included creating a connection, called a Control Point by Lockdown, via SNMP to my Cisco Catalyst 2950 switch. Each port in the Catalyst is enumerated in the Enforcer UI and assigned a specific type of policy enforcement. For example, ports 1 through 6 might be defined for use in a conference room where host assessment is required but authentication is not (guest access). Admins can assign other ports different access policies as needed.

Unlike Caymas and Vernier, Enforcer requires you to explicitly define which authentication methods apply to each switch port, a process that will require some forethought. Each port can support multiple authentication methods, or not require authentication at all. When assigning authentication methods, admins will have to tend on the side of security and place stricter policy settings across all ports in order to make sure all possible scenarios are covered. For many enterprises, however, physical switch and port connections are static and well known to IT. So in this case, administrators can make some assumptions about what type of device will connect and what access policy should be in place. To prevent any SNMP spoofing or poisoning, SNMP Version 3 will be supported in a later release.

Because user traffic doesn’t pass through the Enforcer, it relies on the physical port in the switch for enforcement, much like the Nevis LANenforcer. Therefore, if a group of users is connected in a remote workgroup switch and their traffic is aggregated back to a switch under Enforcer’s control, only a default policy can be applied to them. Because there is no one-to-one relationship between user and physical port, Enforcer cannot apply a specific policy or manage user authentication. Access control is accomplished using traditional methods, such as switch-based ACLs. The same goes for branch-offices: They either need their own Enforcer or their switch remotely managed by the enterprise Enforcer. Lockdown addresses these scenarios with the $1,495 Sentry box.

Enforcer’s user interface is one of the best looking of the quartet, providing easy access to the various management tasks. Creating a policy, on the other hand, isn’t quite as intuitive as with Caymas or Vernier. The policy editor is extremely powerful and allows for a very granular rule set.This is where the complexity creeps in: The wide range of choices and settings make policy definition seem difficult. With some help from technical support, I was able to create a handful of policies and assign them to different ports in the Catalyst.