In-Depth

Case Study: Furthering Role-Based Access

Securing access in the post-mainframe world

• By Mathew Schwartz
• 10/18/2005

Goodbye mainframe, hello access-control questions.

When the University of North Carolina at Charlotte began moving from mainframe-based financial and human resources systems to Oracle databases, application servers, and multiple Web interfaces, IT security officer Carter Heath knew he’d have to adapt. “We always had RACF sitting in front of the mainframe for access control purposes. That provided us assurances of who’s getting what off of the mainframe.”

In the emerging post-mainframe environment, however, the university still needed access controls, but the question was, what would they be? Furthermore, would they fit the existing security paradigm? “We’re here to guard things,” notes Heath. “We don’t own your data, we don’t own those systems. We’re here to provide security protections to those systems, and enable you to get access into those systems in the most secure manner possible.”

So Heath began exploring new access control technologies. First he looked at building a firewall to filter users’ access based on subnet and individual IP address. “That was just an unmanageable scenario,” he says. He also ruled out fobs or RSA tokens. “That just gets unwieldy from a cost perspective, especially in a university environment; it’s $60-$100 per fob,” he notes.

Later at a conference, however, he came across the Identity appliance from Trusted Network Technologies (TNT), “a device with minimal modifications that was able to provide access control to multiple resources by an identity,” he says. “That was intriguing.” In January 2005, he received an evaluation unit, and by May the university had purchased an Identity appliance and added it to the production environment. Currently it’s using Identity version 2.0.

Schooled in Identity

From an identity management standpoint, Heath is lucky: the university, a Novell shop, already had extensive institutional experience with access controls, and using ZENworks from Novell for application delivery. It also had Active Directory, as well as group-level permissions and processes for adding or removing users.

Hence the TNT appliance was able to work with an existing infrastructure. For example, the appliance performs a daily LDAP query against designated groups in Active Directory, then “sucks down any new additions,” says Heath—an approach which requires minimal oversight. “We’re not actively doing anything except reviewing what our operations people tell us about who should have access.”

Implementation Experiences

Overall, rolling out the Identity appliance went smoothly, says Heath. When he initially looked at the appliance, then in its 1.0 release, however, “we did have some problems—some issues with the driver, the way it sets bits and modifies the IP stack, and we’ve had a couple of issues with the gateway itself.” Even so, “whenever there was an issue, TNT was on top of it almost immediately; the CIO or head development guys were there almost immediately to fix the problem,” he says, “They’ve sold us on their customer service, and they’re faster than I’ve seen in the 10-plus years I’ve been in the industry.”

To gain access to the TNT appliance, users must have a TNT access control driver running on their PC. The university automates driver distribution by using ZENworks. Once a person is part of a group that needs access to Identity, the drive gets pushed automatically.

Currently over 500 university users have access to applications which the appliance protects, and since they move around, over 1,000 machines have permission to download the driver. “Universities are transient, people may move in one area for a week, and another for another week, or use this at home from a VPN.”

The appliance logs the ID and host workstation of every access attempt, and which resources were accessed. Its built-in software also includes some reporting capabilities, though Heath wishes there were more. “The reporting mechanism is very rudimentary. It gives you very good information, but all managers love to see charts and graphs, and being able to provide better management features for reporting would be nice to have.”

Complying with Security Policies

While evaluating the appliance, senior managers came to Heath with a concern: what if a user with insufficient privileges to use the access driver nevertheless was using a PC that has the driver on it?

Not a problem, says Heath, since there’s a two-fold check in front of sensitive applications and resources. First the box checks access attempts against its list of allowable IDs and IP addresses. “We screen out a lot of the VPN traffic, and most of all the campus traffic, by doing that—by putting the box in place.” After clearing the appliance, users still need appropriate credentials for each application or resource they want to access.

Such access controls also help the university comply with such regulations as “FERPA, GLBA, HIPAA, and no one has ever confirmed SOX or not—it’s still kind of a nebulous environment—then Visa PCI,” notes Heath. Overall, “we’re subject to a myriad of regulatory issues,” and using the appliance “makes our auditors a little more comfortable, and from an overall compliance perspective it gives us a bit of a leg up in these areas.”

Going forward, the university plans to use the Identity appliance to protect more Web interfaces. “Now we have in excess of 60 interfaces being protected by the box, and we’re going to continue to add application servers and databases and grow the policy and access controls and see where it takes us,” he says.

In other words, the TNT appliance is University of North Carolina at Charlotte’sanswer to post-mainframe access control, says Heath. Without it, “honestly, I don’t know what we’d be doing, except possibly doing some very broad firewall permissions or restrictive access control lists to give us some coarse-grained control. That’s the beauty of what the box provides: some very fine-grained access control.”

Related Articles:

Q&A: Harnessing Trusted Computing Modules
http://esj.com/Security/article.aspx?EditorialsID=1517

Enterprises Struggle with Identity Management Roles
http://www.esj.com/Security/article.aspx?EditorialsID=1433