The vast majority of organizations are either deploying network access control or planning to. That was the finding of our survey earlier this year of 325 IT professionals, which is the basis for our NAC Analytics report. The numbers are up sharply this year, with only 15 percent having no plans for implementation versus 46 percent a year ago, indicating that NAC has evolved from an interesting concept to a valid and valued enterprise technology. However, what IT pros who are planning deployments think they’ll get from NAC is turning out to be different from what implementers are actually getting, and while there seems to be general agreement that NAC is a good thing, there’s no agreement on the best architectural approach. Because the differences between planners and implementers were significant throughout our survey, we chose to break down results by those two groups and to compare each to the results we obtained in 2006.
Increasingly, there’s consensus on the drivers for NAC: resource access control and regulatory compliance. It’s compliance, however, that’s coming to the forefront, especially for those who are already implementing the technology. While in 2006 only 52 percent of respondents saw NAC as a response to compliance needs, now 63 percent of implementers see it that way. The numbers are even starker for those concerned with individual regulations like Sarbanes-Oxley. 52 percent of implementers now see specific regulatory requirements as driving NAC adoption, while only 22 percent of those still planning for NAC are so driven.
Both needs are fundamentally the same. No regulation actually calls for anything as specific as implementing NAC. Instead, the law talks of concepts like managing and protecting hosts that access data. That leaves a lot of room for interpretation. NAC—which assesses a host’s condition and, based on that assessment, grants or denies access to the network and its resources—is seen as one way to satisfy regulations and appears to be well on its way to becoming a best practice. Best practices are often emergent in a market rather than dictated; if most companies follow a certain convention, as is becoming the case with NAC, that convention becomes a best practice.

Pain points
NAC isn’t a complete access control system. It functions to grant access to the network, but not generally as part of the access control mechanism for applications. A host may pass a host assessment, for example, and be granted access to the network, but once on the network, NAC may be unable to prevent malicious user behavior such as application-level attacks like SQL injection into a Web application, or even more pedestrian problems such as saving data to removable media like USB drives or other external storage devices. Most of the products discussed in our full NAC report don’t include mechanisms for controlling access to removable media.

It appears that application-level control is on the minds of NAC implementers and planners. Controlling access to data center resources—something that almost always requires application knowledge—is seen as the most important resource for NAC to protect. After the data center comes the more traditional NAC functions, with wired, remote and branch office access cited as the next three most important protection points. Lowest on the list are two concerns originally touted as NAC selling points: guest and contractor access. It appears that many organizations may have sufficiently tackled these problems in other ways, such as limiting access based on the typical network points of entry for guests and contractors. Some organizations have also required that contractors use the company’s systems rather than bringing in their own. While this is a sensible security measure, it also runs afoul of IRS guidelines that define the difference between a contractor and an employee. Contractors use their own equipment, employees use the company’s—at least according to the IRS.

NAC concerns
NAC isn’t without its problems—both real and perceived. A NAC deployment requires much more than introducing some new hardware to the network. A great deal of work is involved in determining access policies and to which groups or individuals they should be applied. A NAC deployment will produce changes in how users are provisioned and new problems the help desk must sort out. A NAC deployment will also introduce other operational concerns, especially surrounding issues such as deploying patches and new applications. In some cases, when remediation is part of the NAC architecture, it simplifies the process of deploying patches and applications, as both can be part of the remediation process.
The top three concerns for implementing NAC are compatibility issues between NAC and other productivity products, the trade-off between security and productivity, and concerns for increased help desk load—all of which are valid and should be vetted during evaluations. Interestingly, those who are planning but haven’t yet begun implementation are more concerned that NAC won’t really increase the organization’s overall security stance than those who’ve already implemented NAC. Two forces are most likely at work here. While it appears that those who’ve implemented the technology are more satisfied, it’s also at least as likely that those who weren’t early adopters stayed away because, as they perceived it, NAC couldn’t solve some critical needs. Nonetheless, greater satisfaction on the part of implementers leads us to believe that for most organizations, the perceived problems are solvable.

While many organizations are implementing NAC, many aren’t doing so pervasively. The twin bugaboos of cost and complexity are by far the most significant barriers to adoption. Cost is rated as a top-three barrier by more than 60 percent in our 2007 survey, and while that’s still the largest concern, it’s down from 85 percent in 2006. The drop in cost concerns probably has something to do with having a good number of actual implementations as guides. It’s likely also because of the greater number of architectural options, some of which are considerably cheaper to deploy than the first NAC architectures described. Complexity concerns remain about the same, being a worry to about 60 percent in both polls. The next-most-cited barrier to adoption is market and product immaturity, with 35 percent of respondents citing it.

Deployment
NAC deployments are indeed complex. While 56 percent of those planning for deployment in 2006 thought it would take less than six months, only 38 percent of those who completed deployment in 2007 did it in six months; the other 62 percent were split evenly among seven to 12 months, 13-24 months, and more than 24 months. Still, as major IT initiatives go, NAC rollouts are comparatively quick. (See pie chart, ‘Deployment Time,’ for estimates vs actual implementation times for a NAC solution.)
Four methods have emerged for deploying NAC. Each comes with benefits and drawbacks, and none has emerged as the architecture of choice (see our NAC tutorial at nwc.com/go/nac-tutorial for more detail). Secure-switch-based systems require support from all switches at the network’s edge, as well as the addition of policy assessment appliances and operation consoles. This system was the basis for Cisco’s original CNAC architecture. It appears to be well understood and accepted, with 48 percent of our poll respondents saying they’d be willing to upgrade their LAN switching infrastructure. While it’s a well-understood architecture, it’s also by far the most expensive to implement pervasively—so much so that Cisco itself now sells an appliance-based, out-of-band solution.
In-band systems were the most preferred, with more than 60 percent saying they’d add in-line appliances to their network. These systems have the benefit of evaluating all network traffic, making them much harder to circumvent than out-of-band systems. They can also watch for anomalous behavior, which could indicate an attack—something other solutions don’t do. In theory, in-line systems can track user activity down to the application level. This may account for their relative popularity as they can facilitate a level of granular access control not possible with other technologies. On the downside, these systems amount to a new single point of failure and potential bottleneck—a concern that vendors are keen to address. Current designs perform well, and are based on highly robust hardware with features such as redundant fans and power supplies.
Out-of-band appliances use a variety of methods to enforce their policies. Because the appliances don’t directly control the flow of traffic, out-of-band solutions are seen as more easily circumvented. While that’s true, these systems are typically cheaper to deploy since many don’t include per-user licensing fees and aren’t affected by high levels of network traffic. About 45 percent in our poll indicated a willingness to use out-of-band products. Microsoft’s Network Access Protection is the best-known example of this architecture.
Finally, a new class of host-based products is emerging. These systems are independent of network design or even the presence of a network. One can think of them as similar to a personal firewall, except that these systems evaluate the state of the host rather than the state of incoming network traffic. Our survey showed 47 percent willing to implement this solution.
While most organizations are likely start with one architecture, it’s quite likely that more than one architecture may preferable. For instance, a university might prefer a more affordable out-of-band system in student dorms, but choose a more robust in-line product for its academic and administrative data processing needs.