To test NAC products, we built a small network that we hoped would represent a snapshot of a typical, slightly chaotic, enterprise network. We created a user network using typical edge switches from Cisco, Enterasys, and Juniper. Each switch represented a different building, so users on each switch were normally in different VLANs, with each VLAN being a different subnet. We also set up an Aruba wireless controller as part of the user side of the network, and a SonicWall SSL VPN device for remote access. On one of the ports attached to the HP switch we also connected an unmanaged hub.
To test NAC products, we built a small network that we hoped would represent a snapshot of a typical, slightly chaotic, enterprise network. We created a user network using typical edge switches from Cisco, Enterasys and Juniper. Each switch represented a different building, so users on each switch were normally in different VLANs, with each VLAN being a different subnet. We also set up an Aruba wireless controller as part of the user side of the network, and a SonicWall SSL VPN device for remote access. On one of the ports attached to the HP switch we also connected to an unmanaged hub.
We connected a variety of devices to the user side of the network, including Windows 7 and Macintosh OS X 10.6 clients, Polycom VoIP phones, HP printers, and mobile wireless devices from Apple and Nokia.
On the other side of our test network was a “data center” based on HP switches. Between the user and server side of the network was a Check Point Firewall-1 running on Check Point (formerly Nokia) hardware (which also connected us to the Internet). We set up Sourcefire IPS appliances to inspect traffic. We also created a separate out-of-band network for management purposes.
In the data center, we installed Windows 2008 R2 servers running Active Directory, a Windows 2003 server running Steel Belted RADIUS, and a Linux server running RSA’s SecurID authentication server. We installed SYSLOG, DHCP, DNS and NTP servers as well. Most of the data center servers were running on VMware vSphere 4 ESX servers.
For end-point security, we selected Sophos and installed the current version of their enterprise console and client software.
In picking products for our network, we tried to select vendors who were not participating in our test, such as Sourcefire, Sophos and Check Point. We hoped that this would give a more level playing field. Although these are all top-tier vendors, we found very different levels of support for each. Sophos was a particular problem for many of the products we tested, as many of the NAC vendors had not updated their products to handle the 6-month-old version of Sophos that we were using.
In some cases, vendors brought in their own security and networking products. For example, Juniper wouldn’t work with the Check Point firewall or Sourcefire IPS devices, but provided its own firewall and intrusion-prevention system products. Alcatel-Lucent, HP and Enterasys also provided switches beyond our initial configuration.
Once our network was set up, we also designed a basic security policy. We divided the staff world into three categories of users with three access levels to different parts of the data center. We also had policies for VoIP and printer devices, as well as one for guest users. We defined a very simple end-point security compliance policy (a pass/fail policy), along with an access policy for staff users who failed the end-point compliance check.
With our network in place, we looked at each NAC product and asked: “How can this product be used to add security to this network and implement our security policy?” In some cases, vendors visited our lab to help install their products, and we put the question to them and let them take the lead in deployment (Alcatel-Lucent, Avenda, Forescout, Juniper and McAfee sent people to our lab). In other cases, we used the documentation provided by the product vendor, as well as their technical support staff, to install and configure their product.
One of the things we discovered in testing NAC products is that many of them have capabilities but discourage you from using them, either because the capability is not well implemented or because the vendor doesn’t really agree with the need. A common example is 802.1X authentication. Some products insist on it; some don’t use it at all. But a few products support it, yet don’t make good use of the information provided or don’t really fit into the 802.1X model.
As part of our testing, we attempted to discover the natural “best path” for each product, and we tried to test the product in the scenario that showed its greatest strengths and following the NAC philosophy that the product designers had envisioned.
An obvious example was McAfee and Symantec products. While they could have been used with our Sophos end-point security tools, we knew that this would have been a very un-natural deployment, and so we elected to test them with their own end-point security products. (This actually didn’t stop McAfee, who took on the challenge of working with Sophos and even fixed a bug they found in its Sophos support.)
Sometimes finding the most natural way to use a product was a challenge. When Alcatel-Lucent showed up in our lab they brought with them a 5-foot tall rack filled with gear and a 30-page document showing 10 “high demand” deployment scenarios. Just figuring out what was going on took most of a three-day visit. Alcatel-Lucent was an extreme example, but far from the only one. We tried, where possible, to determine what the underlying product philosophy was, and separated that out from the PowerPoint and marketing materials that described every product we touched as the Swiss army knife of NAC tools.
Although we tested each of the NAC products in our example network for a full week, there were many aspects of the more complicated products that we didn’t explore completely.
One of our guiding principles was to focus on making the most realistic and secure deployment possible, rather than the simplest one. Many NAC test beds we’ve seen use VLANs as an access control technique, assuming some sort of uber-firewall connecting the VLANs.
In our own experience and after talking to many network managers, we’ve discovered that what looks good in a booth at a trade show doesn’t work very well in existing deployed networks with real-world complexity and old baggage. Thus, we tried to focus on NAC deployments that used access control lists on switches or which could leverage our firewall to provide access controls, rather than the more simplistic model that VLANs requires.
All the edge switches we used in our testing supported both standards-based VLAN management as well as access control lists. We didn’t shun VLAN deployments entirely, since they can work in some environments and under some security policies, but we gave greater credit to products that went beyond VLANs in providing access control.
To evaluate the NAC products, we looked in six specific areas:
1) Management – including visibility into NAC status, high availability and scalability, as well as the problem of “separation of roles” in NAC management.Authentication – how products authenticated users and devices in different roles, including staff users, contractors, guest users, devices which are connected but not logged in (important for off-line updates, patching, and remote management), and devices which had neither browsers nor users, such as VoIP phones and printers.Access Control Enforcement – how products controlled access in a variety of topologies, including edge control using VLANs or ACLs, embedded controls in the network itself, and access control in environments such as VPN remote access or wireless.Endpoint Security – how products handled endpoint security checking, such as the mechanism used, the flexibility of the checking, when checking was done (at the moment of authentication, before, and after), as well as system misbehavior detection.Client support – what clients are supported and how; is a ‘dissolvable’ agent available.Topology support – what types of network topologies are supported, and what restrictions are in place.
2)
3)
4)
5)
6)
We elected not to test performance, because of the very different types of products provided and the lack of any sort of coherent benchmark for NAC.
THANKS TO: Thanks to Aruba Networks, Avocent, Check Point, RSA, Sophos, Sourcefire, and VMware for providing infrastructure products for our testing. Microsoft provided Windows 7 and Windows 2008 Server R2 kits, and was also a participant in the test.
