NAC is about more than security at UNC
- 19 May, 2008 11:14
When the University of North Carolina in the US implemented network access control campus-wide last year, it was as much a natural progression of the school's network management strategy as it was a security project.
"We view good management as equal to security and security as equal to good management," said Mike Hawkins, associate director of networking for UNC, during his talk at the recent Network World IT Roadmap Conference & Expo in Dallas.
To many, NAC implies solutions that interrogate end devices to ensure they have proper security controls in place before they are allowed on the network. At UNC, it's more about automating the implementation of acceptable-use policies that the school has had in place for years. And while tales abound of NAC rollouts that require wholesale network infrastructure upgrades, UNC has NAC working on switches that are as many as 7 years old and come from multiple vendors. Of course it helped that UNC was in on the ground floor with its NAC vendor, enabling it to help shape what the product looked like. (Because of university policy against endorsing vendors, UNC declined to name vendors for this story.)
UNC Chapel Hill, the second-oldest public university in the United States, has some 28,000 students, 3,100 faculty and 7,500 staff. Altogether, some 35,000 users of traditional computing devices connect to its network each day along with about 50,000 other types of devices, ranging from soda machines to parking gates and water meters.
For years the university has been applying acceptable-use policies to its switch ports to dictate what each type of device can and cannot do when it connects to the network. While that worked well enough, it was a manual, static process to assign an acceptable-use policy each time a new device wanted to connect.
The university's NAC implementation brings a new level of automation to the table, said Jim Gogan, director of networking at UNC Chapel Hill. "The issue is how to provide the appropriate policies for whatever class of device wants to connect," he says. If a utility group connects a steam meter, the network should immediately recognize the device is a steam meter and apply the appropriate policy. That saves the network group from having to get involved every time some specialized device needs to connect.
"This is precise, granular edge control over what goes on in the network," Hawkins said. "I see very few NAC solutions that are actually doing this."
The term NAC typically conjures images of solutions that interrogate end devices to ensure they have proper security controls in place before they are allowed on the network. But UNC Chapel Hill is sensitive to being quite that intrusive given its network lives to serve an environment meant to foster research and teaching. So it takes a slightly different tack, using other security measures to catch dangerous traffic and then using NAC to shut down the offending port or IP address.
For example, the school uses intrusion-prevention appliances to block virus infections from spreading. When it detects an infected machine, the appliance will kick off a trouble ticket detailing which IP address the virus is coming from. "I got three of those this morning between 10 and 11 a.m.," Hawkins said. "Within minutes, I applied a policy to each of those hardware addresses and forced them off the network. No matter where they plug in, they will not be allowed on."
Users of infected machines are then allowed access only to a Web page explaining why they've been denied access and pointing them to remediation resources. That redirect happens automatically, driven by the NAC implementation.
UNC chose to go with its NAC vendor for a number of reasons, not least of which is the fact that about 90 per cent of switches on campus come from the vendor. But UNC also liked the idea of policy enforcement taking place on the switch, near the network edge. Likewise, all the work the school had put into developing its acceptable-use policies would be immediately applicable. The team was also impressed with how easy it was to deliver policies to its switches, with the ability to update any number of switches with the press of a button - an important capability given that the university has more than 3,700 switches on campus.
"This was one of the few [NAC products] we looked at that scaled to tens of thousands of switches and routers," Gogan said. The product enabled the school to automate the rollout of NAC software to all of its switches, which greatly diminished implementation time as compared with other solutions that require software on all client computers. "Because we don't own the desktops out there, that would've been a nightmare," he says. Two to three staffers working roughly four hours each per day rolled out the NAC software in about two months - all the while dealing with their day-to-day trouble tickets and other issues.
The NAC idea first came up three or four years ago, before any vendor had NAC products available, Hawkins said. "We were on the same wavelength [as our NAC vendor] in terms of blocking things at the edge of the network. So some of the original thinking was ours as well as theirs."
Being involved at the alpha stage also enabled UNC Chapel Hill to have a hand in shaping product features. One example is the scripting feature that complements the graphical user interface of the NAC management software. Essentially, the capability enables users to trigger scripts based on SNMP alerts. The scripting capability is what enables UNC to take automated actions, such as the one that redirects users with infected machines to remediation resources or to apply the appropriate policy when a steam meter connects, all without involving network personnel. Another script can detect copyright violations, such as when students download and distribute illegal recordings. The script then proceeds to remove offending machines from the network and directs users to a page that explains the copyright offense and provides instructions for how to get back on the network.
Another bonus is that UNC's NAC software works with multiple vendors' switches. While 90 per cent of UNC Chapel Hill's switches are from the same vendor, it has about a dozen dorms outfitted with switches from two other vendors. In each case, the university has a switch from its primary vendor at the entry point to the dorm acting as an uplink for the other switches inside.
"The point of NAC in that building is the entrance switch," Hawkins said. "We can authenticate each user on that switch and take action on them on the uplink port. We can either block them or extend to them the capabilities they need based on that one device." The only down side is that if a machine inside the dorm becomes infected with a virus, it may infect other users connected to the same local switch, "but it won't infect all 3,000 users in the resident domain."
UNC Chapel Hill is far from finished with its NAC deployment. Rather, it continues to investigate ways to get more out of the system, such as by extending the automated blocking of offending devices and users to more constituencies and scanning for offending devices, especially repeat offenders. The school is also looking to streamline the process of connecting various types of devices to the network by creating policies for different device classes - everything from card readers to HVAC monitoring tools - then letting appropriate managers on campus decide whether a specific device belongs in that class. If it does, the manager can register the device's hardware address in the policy database and, no matter where the device connects on the network, it will be outfitted with the appropriate policy.
The school is also continually evaluating additional anomaly detection products that it may tie in to its NAC system and examining whether it can be extended to the school's wireless network.
Asked for advice for others who may be headed down the NAC road, Hawkins said adhering to standards greatly improves your flexibility, giving you the ability to add in new products. Such standards include 802.1X, RADIUS and RFC 3580, which deals with RADIUS-based virtual LAN assignment. UNC's NAC management software, for example, relies on RADIUS for much of its media access control address authentication. "There are solutions out there that use proprietary sorts of things. You need to be very careful about that," he said.
Gogan said to think about your goal. "If the ultimate goal is to keep infected machines off your network, that's pretty short-sighted for the capability of a tool like this."
The goal at UNC Chapel Hill was far broader, Hawkins added. "Our goal was to improve how we manage the devices on our network. We feel like we've taken a big step forward in that."
Desmond is president of PDEdit, an IT publishing company. Reach him at email@example.com.