Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Rolling Review: Host-Based NAC: Page 3 of 5

 

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