Rolling Review: Host-Based NAC

Malware spreads fast, and the best risk management strategy is to not get bitten in the first place. Time to kick off our host-based NAC Rolling Review

January 12, 2008

11 Min Read
Network Computing logo

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 like 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.


Immersion Center


Welcome to the final entry in our NAC Rolling Review trilogy. 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 like 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. Vendors tout simple-to-install agents that augment or replace existing security tools. What's more, there are no network changes involved. No re-cabling. Fewer chokepoints and single points of failure. No creating VLANs, 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, 51% to 50%, when we asked what changes readers would be willing to make to their networks. In-band is still the NAC architecture of choice, at 65%. In that same survey, we asked about types of activity that require access control. The Top 3 answers: access to the data center (50%), remote access (39%) and branch office access to corporate resources (37%). That sends a strong message that 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 an alternate strategy, because installing a permanent agent on an unmanaged node is an iffy proposition at best.


Impact Assessment Click to enlarge in another window

Creepy Stallies

NAC vendors tout worm containment as 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 actually 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.


This article is the first of a series and is part of NWC's Rolling Review of host-based NAC. Click on that link to go to the Rolling Reviews home page to read all the features and reviews now.

Considering that many NAC 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 log-in 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. The Requirements

The critical factor for successful host-based NAC 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 UI is important to streamlining management. A client that's popping dialog alert bubbles results in helpdesk 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.


Control Points Click to enlarge in another window

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 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, like those in hotels, hot spots 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 corporate network. For example, if a host is on a subnet that is defined as within the corporate network, but it cannot reach the Active Directory or NAC policy server, the system should know it is not, in fact, on home turf.

Name Your Price

Click to enlarge in another window

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 that use a VPN to connect to the internal network might need a specialized policy, for example, 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 show in town for network defense. Technologies and organizational processes including 802.1X for computer and user authentication, VPN encryption, strongly enforced desktop management policies to ensure that your hosts are properly configured, 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 it's not infected when it returns home.

Host-based NAC features like application access control and host firewalling of 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 the majority of 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.



Host-based NAC Rolling Review

THE INVITATIONThis Rolling Review will focus on NAC 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. Rather, policies need to match acceptable access rules that allow users and devices to interact on the network while maintaining security. For this Rolling Review, our written policies and goals will reflect that reality.

Similarly, enforcement decisions are not always "grant" or "deny." Rather, a variety of enforcement choices, like warning a user, starting an update in the background, limiting access to certain resources or quarantining hosts, should be available.

We will test common scenarios, such as a conference room that is open to the public, an internal network segment that contains managed computers, and a remote worker. All testing is conducted under real-world conditions. We will assess products based on the following criteria:


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 will also throw a Linux server and other "unmanageable" devices into the mix. We'll use 802.1Q VLANS 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 will also maintain an update server for systems and applications. While the testbed will be largely self-contained, we will have our network fully functional and will integrate products into the existing network. We will not replace access switches.

We are 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 will not use 802.1X because we can't assume clients will have properly configured supplicants; 802.1X will be acceptable on the managed wired and wireless networks, however. We will 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 will examine both initial and ongoing assessments and the resulting actions for hosts that violate our policies.

THE VENDORSCheck Point Software TechnologiesGreat Bay SoftwareIdentity EnginesInfoExpressLANDesk Software

McAfeeNortel NetworksSenforce TechnologiesSophosStillSecureTrend Micro

THE PREMISERolling 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. This installment focuses on host-based NAC. For consideration contact the author.


Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like

More Insights