Rolling Review Kickoff: Host-Based NAC

In Hollywood, the killer mutant virus always kicks mankind's butt. For security pros, this is one area where life too often imitates art--a single infected laptop can make for a very long night. While the Storm worm made headlines, its main propagation method is through user action. That's defensible. It's automated worms such as SQL Slammer and Code Red that are likely to do far more damage when they get into your network, because they can infect any vulnerable computer without end user intervention.

Welcome to the final chapter in our ongoing series of NAC Rolling Reviews. We've covered in-band and out-of-band network access control systems, and now we turn to host-based NAC, which aims to solve problems such as malware propagation and unauthorized access by adding agents to hosts and controlling access from the source of the problem, rather than in the network or at a perimeter.

We've invited 11 vendors to show us their stuff. Most tout simple-to-install agents that augment or replace existing security tools. What's more, there are no network changes involved. No recabling. Fewer choke points and single points of failure. No creating virtual LANs, subnets, DHCP scopes, or 802.1X. That benefit alone will make host-based NAC palatable to companies that just don't want to mess with their network topologies.

Our most recent NAC trend survey showed host-based NAC on par with out-of-band, both at 48%, when we asked what changes readers would be willing to make to their networks. In-band is still the NAC architecture of choice, at 56%. We also asked about types of activity that require access control. The top three answers: access to the data center (49%), remote access (39%), and branch office access to company resources (37%). This shows that our readers want internal access control and that they have operational power over endpoints--a critical requirement for host-based NAC. Companies for which controlling guest access is crucial should look to another strategy, because installing a permanent agent on an unmanaged node is an iffy proposition at best.WATCH OUT FOR THAT WORMNAC vendors across the board say worm containment is a top driver. The idea is that assessment during and after network connection will pinpoint infected nodes. The NAC system can then take action, moving the host to a quarantine network or forcing upgrades and cleaning before it's allowed back on the network. The big "if" here is properly detecting infections in the first place--not an easy task because more-invasive malware disables antivirus and other security software.

Still, if your goal with network access control is to restrict user activity, what better place to apply policy than on the host itself? Many host-based NAC software suites combine anti-malware, desktop firewall, and application access control, at a minimum, to protect hosts from malicious software ... and from the person at the keyboard. We know that antivirus software can identify only that malware for which it has signatures, meaning new viruses are often undetected. In contrast, desktop firewall software not only blocks network traffic attempting to access the host, it can also limit how host applications can access the network. Application access control is not new--it's been in desktop firewall software for years--but the relevance to NAC is evident: If an application is unable to send e-mail or connect to IRC, or make any network connection, for that matter, its adverse impact is mitigated. The malware must still be removed, but you've bought yourself time.

Considering that many network access control products allow access to the network to do assessments anyway, a host-based NAC product squelches problems at the source.

One sticking point: IT often shies away from agent technology. Yet nearly all NAC products use some form of agent for host assessment and login tracking. So-called "dissolvable agents" are ActiveX or Java components that must be downloaded and executed on the user's computer, often with Power User or local Administrator rights. Moreover, unlike network-based NAC products that sit in line or out of band, the protective measures inherent in host-based systems travel with the computer, so a laptop is equally protected from attack at the coffee shop down the street as it is on the corporate LAN.

(click image for larger view)THE REQUIREMENTS
The critical factor for successful host-based network access control is centralized management. That includes agent deployment, configuration, reporting, and troubleshooting. The last thing you want is users making decisions about what should or shouldn't be allowed to run.Equally important is that IT be able to centrally manage hundreds or thousands of agents from a single point. That means visibility into the health of all agents, plus organizational features that allow you to group similar host agents and delegate administrative functions to distributed staff. For example, you might want to give departmental IT admins the ability to set some access policies while retaining central control of host configuration requirements.

Client interface features are also a vital part of host-based NAC, and the ability to control the agent user interface is important to streamlining management. A client that's popping dialog alert bubbles results in help desk calls. All logging and alerting should be sent back to a central log server, where experienced administrators can view activity and take corrective actions. In some organizations, tailoring the client experience can reduce this burden: Tech-savvy users may be granted more access to UI functions, while details are hidden from those inclined to panic at warning messages. In either case, ensure that the product you choose provides a way to remotely troubleshoot agent issues without having users jump through hoops or read cryptic messages over the phone.

Because host-based NAC agents protect computers no matter where they are, pay particular attention to how policies may be defined based on a network location. In some cases, location could be as simple as a defined IP range--if a host has an IP address from the corporate network, it's considered to be on the local LAN. Ideally, IP-based location will be fairly granular, down to specific IP ranges denoting a department or building location. If your IP addressing is tightly tied to networks or locations, this is a decent option for location services.

If you use RFC 1918 reserved addresses, however, bear in mind that IP location alone may fail because many external networks, such as those in hotels, hotspots, and home routers, use the same IP address ranges as those used in RFC 1918. A better way to determine location is to combine IP address with a host's ability to access servers that are available only when connected to the company network. For example, if a host is on a subnet that is defined as within the network, but it can't reach the Active Directory or NAC policy server, the system should know it is not, in fact, on home turf.

The benefit of basing policy on location is partly for usability, partly for strengthening security. Host-based NAC--or any NAC system for that matter--can easily cut users off from legitimate resources. Windows networking components, for example, are dynamic and difficult to nail down tightly, and users are used to working in ad hoc fashion. While ad hoc networking may be dangerous, the reality is that many organizations rely on it. Disabling that feature across the board may cause more trouble than the added security is worth. However, you don't want company assets exposed when a user is out in the wild, either. Support both situations, and don't rely on users to make access-control decisions. We recommend setting a less restrictive access policy that enables file sharing and may be used when the host is internal; a more restrictive policy for use when the host is external should disable file sharing or block all incoming connections.Another consideration is per-interface policies. Employees who use a VPN to connect to the internal network might need a specialized policy, for example. That's because many VPN concentrators pass out IP addresses from the internal network, so using simple IP addressing as a location determinant won't work. The ability to specify accounts for multiple active interfaces is critical as well.HOST CASE

NAC isn't the only choice for network defense. Technologies and organizational processes--including 802.1X for computer and user authentication, VPN encryption, strongly enforced desktop management policies, and proper role definition and application access controls--can help achieve this goal. But even if you implement all these, you still have the roaming computer problem, and that's perhaps the strongest argument in favor of host-based NAC. Protect the computer while it's out of your control, then ensure that it's not infected when it returns home.

Host-based NAC features such as application access control and host firewalls for outbound as well as inbound traffic may keep malware like the Storm worm off your network, even if an individual system becomes infected. Today, host-based NAC makes most sense in cases where most of the computers are company-owned; the guest access issue is generally not well addressed, and in this Rolling Review we'll ask vendors about their plans in this area.

Photo illustration by Getty Images

Host-Based NAC Rolling Review

The Invitation

This Rolling Review will focus on network access control products that are installed on hosts and both assess system health and enforce NAC policies. Companies are looking at NAC as a way to protect internal resources and limit the activities that users and hosts can perform on the network. Binary policies that choose "on" or "off" based on host condition are often not robust enough to be effective. Policies need to match acceptable access rules that allow users and devices to interact on the network while maintaining security. Our written policies and goals will reflect that reality.
Similarly, enforcement decisions are not always "grant" or "deny." Rather, a variety of enforcement choices, such as warning a user, starting an update in the background, or limiting access to certain resources, should be available.
We will test common scenarios, such as a conference room that is open to the public and an internal network segment that contains managed computers. All testing is conducted under real-world conditions. We'll assess products based on these criteria:

The Test Bed

We will test using Windows XP, Vista, and Mac OS X workstations. All workstations, except those attached to the conference room access switch or in use remotely, will be managed and part of our Active Directory domain. Workstations attached to the conference room access switch will be guest computers. We also will throw a Linux server and other "unmanageable" devices into the mix. We'll use 802.1Q virtual LANs throughout the network, and traffic between VLANs will be routed. In this scenario, access switches will use 802.1Q uplink trunks to the distribution switch.
Our Active Directory server will provide AD, Radius/IAS, DNS, and DHCP services. We'll also maintain an update server for systems and apps. While the test bed will be largely self-contained, we'll have our network fully functional and will integrate products into the existing network. We won't replace access switches.
We're willing to put client software on computers in the AD domain, but we won't put persistent agents on guest computers. Dissolvable agents are acceptable for guest access. We want to test multiple enforcement types. Our expectation is that the conference room won't use 802.1X because we can't assume clients will have properly configured supplicants, but 802.1X will be acceptable on the managed wired and wireless networks. We'll design a set of common policies spelling out configuration guidelines and goals for groups of workstations. Some hosts will be in conformance, some not. In addition, some hosts will be infected with known malicious software, and some will exhibit signs of malicious activity. We'll examine both initial and ongoing assessments and the resulting actions for hosts that violate our policies.

The Vendors

Check Point Software Technologies, Great Bay Software, Identity Engines, InfoExpress, LANDesk Software, McAfee, Nortel Networks, Senforce Technologies, Sophos, StillSecure, Trend Micro.

THE PREMISE

Rolling Reviews present a comprehensive look at a hot technology category, beginning with market analysis and wrapping up with a synopsis of our findings. Our extended testing span lets us accommodate today's accelerated revision cycles and focus our attention on individual products, while maintaining a consistent test bed. For consideration, contact the author.

Find more Rolling Reviews, past and present: networkcomputing.com/rollingreviews