Business Innovation
Home IT Optimization Human Factors Information Management Governance/Risk Management Business Agility Resources
Information Management
eBook
Brought to you by IBM
Business Intelligence: Integrating the DataBusiness Intelligence: Integrating the Data
Today's corporate performance initiatives require greater visibility into all corners of the enterprise. Business intelligence has become a central element to every part of the business. Click here.
 
 
INNOVATION:
White Papers & Resources
Brought to you by IBM
 
 
 
MORE INSIGHTS FROM:
IBM Database Magazine

TIP of the WIKI
Join the community in building the best collection of tips and tricks for IBM information management software.

Poll

What's the greatest innovation in DB2's 25 year history?
Referential integrity
    20%
Triggers and stored procedures
    11%
Data Sharing (DB2 for z/OS)
    24%
DB2 9's pureXML capability
    18%
Cost-based optimization
    28%

Sign Up for IBM Database Magazine's E-mail Newsletter

IBM Database Magazine authors share tips and insight on DB2 and Informix performance, certification, security, and more. Join the conversation by adding a comment or asking a question.

 
 
 
IBM BUSINESS INNOVATION NEWSLETTER SIGN-UP:
Subscribe to the newsletter!
 
 
To receive the latest articles as they are posted SUBSCRIBE here.
     

Business Innovation Homepage > Information Management

Rolling Review Kickoff: Out-Of-Band NAC
 
Out-of-band NAC lets you lock down your network from a central command center. So why is it on the outs?


By Mike Fratto
Network Computing
October 22, 2007

When it comes to network access control, you have freedom of choice: IT can select from a number of different methods for assessing hosts, enforcing policies and integrating into the network. In this Rolling Review, we're focusing on out-of-band NAC. These products attach to the network from a switch port and, unlike their in-band brethren, don't require re-cabling. Like all NAC products, an out-of-band system makes use of a policy server, which contains access policies and makes decisions on which nodes should be allowed into the network. The policy server can be the enforcement point, or it may drive other network infrastructure devices, such as switches, routers or firewalls, to grant or deny access.

Thing is, out-of-band NAC seems to have an image problem: Our own reader research indicates that 65% of organizations deploying NAC prefer in-line appliances versus 50% using out-of-band products. And the outlook doesn't look likely to improve. Nearly 70% of companies in the planning stages are leaning toward in-line systems, versus just 43% favoring out-of-band NAC. A recent survey by Infonetics Research shows that 55% of companies plan on buying in-line NAC products; this syncs with the firm's market forecast, which shows more than half the NAC units shipped are in-line appliances. Is the problem just bad PR, or does the out-of-band approach really carry technical disadvantages compared with going in-band?

Three Way Try
We decided to get to the bottom of the plusses and minuses of in- and out-of-band NAC, as well as host-based systems. We launched a Rolling Review of in-band NAC products in our Aug. 13 issue, and the first installment of that testing can be found refer to Consentry. Watch for our host-based Rolling Review to kick off early next year.

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

Out-of-band NAC products do offer a number of benefits, including a broad array of enforcement and integration options, fewer physical plant changes, and the ability to manage multiple networks from a central location. However, out-of-band NAC is not always simple to install. You'll often need to make configuration changes to switches and routers, and many host discovery and enforcement methods, such as DHCP and MAC address control, can be bypassed unless you do some switch integration. Moreover, out-of-band systems can't perform post-connection network monitoring unless you integrate with third-party tools like IDSes and network monitoring platforms.

InformationWeek Reports

The key factor in establishing whether out-of-band NAC is a good fit? Determine whether you need to control access to specific network resources after the host has connected to the network. If so, you will want an in-line NAC appliance that can act as a host- or user-based firewall. Realize that most out-of-band NAC products are limited to granting or denying access to the network, then steering a computer onto a specific IP subnet or VLAN. Say users with a human resources role should able to access HR assets from any location, but should never have access to engineering resources. It's pretty rare that a company will have all its HR and engineering servers and applications in their own, separate VLANs. More often, resources are spread throughout the network, and a user may be connecting to a segment that doesn't have access to his respective IP subnets or VLANs.

The extent of enforcement for nearly all out-of-band NAC systems is steering a host onto an IP subnet or VLAN. Fine-grained access control—think port-based firewall—is generally not available. Some products may be able to integrate with specific firewalls from vendors like Cisco or Check Point, but these systems are rare and useful only if your organization uses those firewalls.

Out-of-band NAC products do tend to offer a variety enforcement methods, including 802.1X, VLAN steering or IP subnet configuration, enabling IT to deploy the best enforcement technique for a given task.

The general out-of-band NAC process (see diagram above at right) starts with a host in a quarantine IP network or VLAN. The host may be able to access the policy server or remediation servers. Once a host is assessed and passed, it's moved into its destination network or VLAN. Out-of-band NAC uses the same host-assessment methods as any other NAC system, including persistent, dissolvable agent scans; network scans; and remote commands. Where products vary widely is in how they enforce policies.

Show of Force
In 2006, companies spent on average two-thirds of their NAC budgets on 802.1X switches, according to Infonetics. Ratified in 2001, the 802.1X protocol is a Layer 2 access control mechanism that authenticates users and computers, and turns a port on or off, granting a host access to the network. Originally, 802.1X was conceived as a physical access control mechanism for wired networks. At the time, however, there was little compelling reason to deploy 802.1X, and few supporting resources, like supplicants, 802.1X clients and switches, that could leverage it. Thus 802.1X didn't really take hold until 802.11 wireless LANs took off, and vendors like Funk, later acquired by Juniper, marketed supplicants for wireless networks.

Now, 802.1X is used to authenticate hosts and turn network ports on or off, thus granting access to the network or not, as the case may be. When a host connects to an 802.1X switch port, the host can communicate only with the switch, limiting the opportunity for mischief. In contrast, other out-of-band enforcement methods, like DHCP and VLAN steering or MAC address management, must let the host connect to the network before enforcing a policy.

The power of 802.1X is that it is extensible, and it's one of the methods used by the Trusted Computing Group Trusted Network Connect APIs to forward host information to policy servers. Moreover, in modern switches, 802.1X is simple to configure, requiring IT to do little more than enable the feature and define an authentication server, like RADIUS, to communicate with.

The difficulty lies in ensuring that all your hosts have properly configured 802.1X supplicants, and in supporting non-802.1X-capable hosts. Some switches do have configurable port defaults for hosts that can't authenticate using 802.1X; for example, they may automatically place all such users into a specific VLAN. You will need to plan for that eventuality.

Beyond the Gates
The 802.1X standard is good for allowing or denying access to the network, just like a security guard is good for letting employees into a building. Problem is, once inside, there are no access controls.

To get around this limitation, 802.1X enforcement is often paired with VLAN steering, which puts hosts into specific virtual LANs based on a NAC policy. The VLAN assignment is returned to the switch from the authentication server, and the port is assigned to that VLAN. Because 802.1X allows for reauthentication, NAC products that use 802.1X may take action against a host whose condition has changed. Perhaps the user is no longer in compliance with company policy—a failed reauthentication can trigger moving a host into a quarantine VLAN.

Reauthentication is particularly useful to address insider threats. Say an employee logs in as normal, then attempts to install software that is considered threatening, or tries to access data that she has no reason to be looking at. By detecting the change in the host condition or the malicious activity, forcing a re-authentication ensures that a new host assessment is run and that the current user is still connected.

VLAN steering, mentioned above, is as simple as taking a host from one network to another and is usually paired with other enforcement methods. Don't confuse VLANs, which are a network design, with a security technology. Configuring VLANs alone doesn't afford you any security functionality beyond logical separation of traffic. To successfully use VLANs in a security context, you must configure your switches properly.

Some switches in the past have been vulnerable to MAC flooding attacks, in which a large number of MAC addresses are sent to the switch. Generally called content-addressable memory attacks, these assaults succeed when available memory is exhausted and the switch, in essence, turns into a hub and begins forwarding all frames to all ports. Modern switch software should not be vulnerable to these attacks. Thanks to configuration options that limit the number of MAC addresses that can be on a single port, you can preempt MAC flooding attacks by setting reasonable limits. At minimum, switch ports should be configured as either access ports or trunk ports, and never allowed to negotiate. Otherwise, an attacker could connect a host and mimic a switch port. These are good configuration options for switches in any case, but critical for NAC products that use VLAN steering.

DHCP management is used by itself or with VLAN steering and is in fact similar to VLAN steering in that it manipulates a host's IP address to restrict its access at Layer 3. While touted as an easy and simple method to enforce NAC, the most significant drawback when DHCP management is used by itself is that it can be easily bypassed by setting a static IP address in the host. DHCP snooping, a security feature found in today's switches, may significantly strengthen DHCP management because the switch monitors DHCP requests and responses, and maps a DHCP lease to a host on a port. Optionally, all hosts that are not in the DHCP table can be denied network access, removing the threat represented by static IP addresses.

The level of network integration required for an out-of-band NAC appliance varies, depending on the product and enforcement method used. But you will certainly face a more difficult haul than plugging in an in-line appliance. On the other hand, you don't need to place out-of-band appliances everywhere, just near the core, where all switches and routers can reach it. Most configuration will take place on your switches—defining quarantine VLANs, setting up authentication servers and pointing DHCP relay agents to your NAC appliance.

Policy, Policy, Policy
Defining an access policy for an out-of-band NAC implementation is usually simpler than with an in-band system in that it revolves around acceptable host conditions and what to do with hosts, rather than defining access controls.

However, as the product space matures, expect to see more integration work between vendors. In-line NAC vendors are positioned in the network to view and act on every packet, so intrusion detection and traffic monitoring are possible. Out-of-band NAC products, on the other hand, require external systems to feed host-state information and IDS events. The level of integration is not yet standardized, and often, integration is limited to a few select products, like the open-source Snort IDS.

Host assessment is another matter. While a number of vendors license endpoint detection from OPSWAT, a few build their own. This provides customization capabilities but also requires them to maintain lists of application signatures. Overall, the value of host assessment is debatable because the definition of acceptable versus unacceptable configurations varies, and while you can control your company's computers (maybe) you can't control guests and contractors. You may find yourself developing assessment policies based on whether a computer is company property or not.

Like any critical network infrastructure component, out-of-band NAC requires redundancy. In fact, you'll need the same level of redundancy and resiliency as an in-line product because failure of critical services, like authentication, VLAN assignment and IP address management, will stop traffic cold just as quickly as the hardware failure of a network switch. Plan on having redundant NAC products running in the event of failure. If that's not feasible, ensure you have a strategy to restore connectivity quickly in the event of failure.

Scenario: Out-of-band NAC Rolling Review
The Invitation:
This Rolling Review will focus on NAC products that are installed out of band from the network and both assess and enforce NAC policies. We will test based on a few 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.

Companies are looking at NAC as a way to protect their internal resources from malicious nodes and to limit the activities that users and hosts can perform on the network. Binary policies that choose "on" or "off" based on a host's 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 an acceptable host condition. Our written policies and goals will reflect that reality. We will choose acceptable conditions that products must fall into, for example. 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 to match a company's policy.

We will evaluate how much flexibility each entry provides as well as the following criteria:
• Policy Development, which will cover the ability to create flexible assessment and enforcement policies. The breadth of information used for host assessment (pre- and post-assessment) will be evaluated, along with the available types of actions or enforcement options;
• Integration with existing infrastructure and services, including network devices, such as routers, switches and VPN hardware; features, like ACLs, VLANs and 802.1X; and services, such as RADIUS, DHCP, DNS and Active Directory;
• Management/configuration of the devices that as well as agents, if required;
• Price as configured for testing; and
• Reporting and troubleshooting tools available to visualize what is occurring on the network. Ability to view the status of the current network, monitor hosts and user activity, and generate historical reports will also be evaluated.

The Vendors:
We asked 19 vendors to participate: AEP Networks, Array Networks, Bradford Networks, Cisco Systems, Enterasys Networks, FireEye, Forescout Technologies, Identity Engines, Impulse Point, InfoExpress, Insightix, Juniper Networks, Lockdown Networks, Nortel Networks, Senforce Technologies, Sophos, StillSecure, Symantec Corp., TippingPoint, and Trend Micro.

The Testbed:
We will test using Windows XP, Vista, and Mac OS X workstations. All workstations except those attached to the Conference Room Access Switch and remote users 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 have a Linux server and other "unmanageable" devices on the network. We will use 802.1Q VLANS through out 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 have an update server for system and application updates. The test bed will be largely self-contained. We will have the network fully functional and integrate products into the existing network. We will not be replacing 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 the configuration guidelines and goals that we will want to implement 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.

NWC's Rolling Reviews present a comprehensive look at a hot technology category, beginning with market analysis and wrapping up with a synopsis of our findings. See our kickoff to this Out-Of-Band NAC series at nwc.com/rollingreviews.

Click here for more Information Management articles

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  Copyright © 2008 United Business Media LLC | Privacy Statement | Your California Privacy Rights | Feedback | RSS

We encourage your feedback: businessinnovation@cmp.com

Visit these other IBM and TechWeb Partner Sites:
Maximizing ROI Through Business Process Management (BPM) and Service-Oriented Architecture (SOA)
Internet Evolution – The Macrosite for News, Analysis, & Opinion About the Future of the Internet
IBM Database Magazine – Strategies and Solutions for DB2, Informix, and IBM Data Servers

 
 
 
CMP Media Business Innovation