Rolling Review Kickoff: Host-Based NAC: Page 3 of 4

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.