This story appeared on Network World at
http://www.networkworld.com/reviews/2010/052410-network-access-control-test.html
NAC: What went wrong?
After five years, still no easy way for IT managers to achieve network access control
By Joel Snyder, Network World
May 24, 2010 12:03 AM ET
May 24, 2010 12:03 AM ET
After spending four months in the lab testing the 12 leading network access control products, we've come to this conclusion: Five years of hype, buzzwords, white papers, product launches, standards battles and vendor shakeouts have resulted in very little in the way of clarity. Agreement on what NAC really means and the right approach to NAC remain as elusive today as in 2005, when the first NAC products burst on the scene.
Our head-to-head comparison of specific NAC products from industry heavyweights such as Microsoft, Cisco, HP, Juniper, McAfee and Symantec, will appear in the June 21 issue of Network World. In this report, we analyze the barriers that have impeded the deployment of NAC within enterprise networks.
Network access control, which we're defining as a combination of authentication, end-point security checking and access control, emerged in response to the problem of mobile end users plugging infected laptops back into the enterprise network. NAC was intended to solve real problems and answer real questions: who is connecting to my network? Are they healthy? Can I control where they go? Can I shut them off if they misbehave?
Typically in our industry, products tend to coalesce over time towards common approaches and common feature sets. For example, today's Ethernet switches from different vendors are largely substitutable. Swap out an HP ProCurve switch for Enterasys and the switch is probably going to work in your network. But NAC hasn't worked out that way. The products bear very little similarity to each other. With very close inspection, a network manager might be able to find two or three products that can be compared head-to-head. But finding comparable products is difficult, and doing so pre-supposes that the network manager already knows the feature set and capabilities that they want.
There's no such thing as "best of breed" in NAC, because for the 12 vendors we evaluated, there are nearly 12 different "breeds" of NAC product.
Barrier No. 1: Politics gets in the way
A particularly difficult issue is finding a product that will be compatible both politically and technically with the network. Because NAC combines features of security, network management and desktop management, a NAC deployment faces significant organizational challenges on top of any technical challenges.
To accommodate this, NAC vendors often build their products to minimize the need for cross-team cooperation, usually by making significant compromises. However, every NAC vendor makes these compromises in different places, and to different degrees. For example, Symantec's NAC offering is entirely focused on the desktop team, while HP's NAC product is designed to be installed, configured and managed by the network team.
All this adds up to a significant barrier for network managers who want to deploy NAC. Forget the cost of the products —just figuring out which product will do the job that's needed, and whether the product can be made to work in the organization is significantly more difficult and time consuming with NAC than with switches, firewalls or servers.
Barrier No. 2: Too many vendor variations
NAC's three components are authentication, end-point security and access control, but vendors tend to deliver NAC products based on their particular strong suits. This means NAC products tend to focus on one of those three components, often ignoring the other two. For example, when McAfee approaches NAC, they do so from the context of their own end-point security management product, ePolicy Orchestrator. But Juniper approaches NAC from the context of their network security components: firewalls and, to some extent, switches.
The broad variation in products is also due to legitimate disagreement on the best way to reach the final goal. The problem with this lack of consensus is that it causes confusion in anyone who is interested in adding NAC capabilities to their network. For example, is authentication important or isn't it?
If you ask Forescout, the answer is "no;" their product barely supports end-user authentication. Is access control important? If you ask Bradford, the answer is "no;" their product is focused on identifying devices and putting them on different virtual LANs, not on differentiating users and controlling their access. And if you want to know if end-point security is important, don't ask HP; their NAC product doesn't even support end-point security checking out-of-the-box — you have to go to a third-party partner to pick up this capability.
Of course, each of the NAC vendors has shoe-horned in bits and pieces so that they can check-mark all of the significant features they find in NAC RFPs and tenders. But in our testing, it was very clear that many of these features were fundamentally at odds with the core product architecture.
With so little agreement from major NAC vendors, network managers are in a tough spot trying to figure out whether NAC brings them any real value or is worth the headache of procurement and deployment.
Barrier No. 3: Interoperability woes
When Network World tested NAC products head-to-head in 2007, we had to break our tests up into separate parts. One test looked at two NAC frameworks (Cisco and Trusted Computing Group) and 30 products that worked in those frameworks. The other test looked at 13 standalone NAC solutions. We had predicted that by this time, the frameworks would have unified and all NAC products would support them to one extent or another.
Unfortunately, the products that were resolutely standalone in 2007 are just as resolutely standalone in 2010. This year, we looked at seven of the 13 standalones from 2007, and only one of them (Juniper) has made a significant move towards standards compliance. (Three of the companies have gone out of business, two no longer market their end-point security products as NAC, and one declined to participate.)
Even old standards, such as IEEE 802.1X, have not achieved full support in many NAC products. While we found some products that enthusiastically take an open standards approach to NAC using 802.1X, others have 802.1X support only as a poorly added afterthought.
This adds up to a lack of interoperability between NAC solutions and network infrastructure. Each NAC vendor has a preferred set of other security products they work with, and if you try and bring different products into the mix, you may find your NAC deployment can't or won't support these changes. The result is a strange sort of vendor lock-in: your NAC product may restrict you from making changes in the network switching products you use, your authentication infrastructure, and what end-point security product you install.
With only a few products really taking standards-based approaches to heart, it's clear that NAC has a long way to go before network managers will have a true plug-and-play solution.
Barrier No. 4: Deployment difficulties
One perennial struggle for NAC vendors has been the difficulty of deployment. Although many NAC products we tested are designed to allow gradual installation across enterprise networks, getting even a single port protected by NAC can be a lengthy process. More importantly, the installation of NAC can include many significant decision points — and if those decisions are changed down the line, the entire deployment may have to be restarted. Simple questions, such as "how am I going to do authentication?" or "what mechanism will I use for access control?" are difficult to answer confidently without some in-the-trenches experience — yet must be decided before you can even start rolling out NAC.
Our experience is indicative of the problem facing network managers. Only one of the 12 products could be installed and operational within a single day in our small test network. Most took between two and five days to get fully operational across a handful of switches and subnets. When it takes that long to get NAC installed in the test lab, network-wide rollout will be even more time consuming than expected.
Network managers may also find day-to-day operation and debugging of their NAC products to be challenging. Most NAC products work by interacting with network devices to change VLANs or apply access control lists to individual ports on switches. Network operations teams will have to learn how to discover and manipulate this dynamic information from their existing devices. Although switch manufacturers have made progress in simplifying NAC debugging, not everyone has the latest hardware and software throughout their network.
When NAC products are in-line, this represents another operational challenge, as network teams now have a new device to learn how to manage and debug. And the worst case for debugging is in products that accomplish access control by manipulating protocol elements such as ARP tables (Trustwave NAC) or by injecting protocol management messages into the network (Forescout NAC). Since the behaviors these products are exploiting are never supposed to happen in normal operation, there are no easy ways to debug them when they are misbehaving.
Barrier No. 5: Hidden scalability issues
One of the bright signs for NAC deployments that came out of our testing this year is the relative lack of scalability and availability issues. In previous NAC testing, we uncovered performance problems caused by funneling too much traffic through a single control point. Early NAC products were often entirely "in-line," meaning that you had to buy a new appliance or device of some sort that sat in between devices you were controlling and the rest of the network.
For scalability across a full enterprise network, most network managers agree that enforcement at the edge of the network is required. The products we tested have done away with the requirement for a full in-line deployment and are now able to do their work at the edge, with a couple of caveats. For example, McAfee's NAC appliance will sit in-line during initial authentication and end-point security checking phases of the connection, but reconfigures the network to move itself out of the way as quickly as possible. Juniper's NAC offers both in-line and edge enforcement, giving more sophisticated controls when an in-line device (a Juniper firewall) is used than an existing edge switch can provide. Many NAC offerings continue to include a full in-line option, which may be needed in some environments (such as when applying NAC controls to a WAN, ***, or wireless network).
Although we didn't test high availability, we did examine the architecture each vendor offered to ensure continued operation in the face of different types of failure, and found that everyone has a convincing story in this area.
Network managers should be wary of hidden scalability problems, though. Some products we tested have obvious issues when scaling to large networks. For example, NAC products from Forescout and Trustwave generally require the ability to monitor all traffic from the end systems they are controlling. Because that's such an obvious issue in large networks, it's easy to understand and plan around. Less obvious are constraints such as a dependence on unreliable SNMP traffic or a requirement to poll every user edge switch frequently to detect changes in client status. These designs work great up to a certain point, but can fall apart rapidly as the network scales up or when older switch processors become overloaded with unexpected management traffic.
When we discussed these types of issues with the vendors we were testing, we got the same advice from each: good pre-sales communication is critical to success. To ensure that the NAC solution they choose will scale properly, network managers should make sure they provide as much information as possible during the sales cycle so that prospective vendors can properly size their products.
Barrier No. 6: ROI is not balanced with cost
A good network manager makes a business case for any new technology. Here's what it will cost. And here's what it’s going to save us. If the savings exceed the cost, it's a good deal. With NAC, network managers are having a hard time making a good business case.
It's not that NAC doesn't have any benefits, but those benefits often fall into the nebulous area of security ROI, one of the most difficult returns to calculate. How much is it worth to not have a little break-in? How much to avoid a big break-in? And how likely it is we would have had one? And can this technology promise to avoid it? These are difficult calculations.
The ROI calculations on NAC aren't helped by the costs being charged by many NAC vendors. Some give it to us at a bargain price: Microsoft, for example, includes a full-featured NAC product with Windows Vista, XP, and Windows 7. Assuming you were already going to buy Windows, NAC is almost free of capital cost.
But even if the software is virtually free, deploying NAC is expensive. It takes time, and time is money. You may have to buy more switches or upgrade switches. You certainly have to understand how your network operates very well, and you've got to be prepared to change many of your internal processes for moves, adds, and changes.
What can vendors do?
NAC has certainly not lived up to expectations, but NAC isn't dead either. Frost and Sullivan predicted that NAC vendors will sell 7,500 appliances and rake in at least $250 million, with a nice, steady growth rate of about 25% every year. Vendors aren't seeing the revenue or growth that was predicted. But what can vendors do to accelerate NAC deployments in the enterprise? We have three suggestions:
1. To address the political issues, vendors could design products that naturally break apart into three components: network, desktop and security. If the NAC product lets each team deploy their part of the NAC puzzle in the way that fits best into their network, then the likelihood of success is much greater.
2. When it comes to ROI, some enterprises have seen cost savings with NAC, irrespective of the potential for lowering risk of data loss or intrusion. That's the direction NAC vendors have to go: figuring out how their products can bring value even in the absence of security benefits. We saw this in our testing with some outstanding dashboards and visibility tools. This needs to be a benefit of any NAC deployment to push NAC into the mainstream.
3. The complexity of NAC is the most difficult barrier to overcome. Vendors have pushed features and complexity into their products as they've learned from customer after customer what works and what is needed to make things work. They aren't likely to throw it all out and start over from scratch.
However, if venture capitalists continue to provide funding for start-ups, new products can come out of the woods with a clean architecture based on the lessons learned from everyone else in the industry. If not, NAC just might continue to languish as a great idea that never really takes off.