Rolling Review: 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 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.

NETWORK ACCESS CONTROL
Immersion Center

NEWS | REVIEWS | BLOGS | FORUMS TUTORIALS | STRATEGY | MORE

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.

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.

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.

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.

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.

0