You are who you are

Identity management systems can help agencies meet security mandates

When Utah rolled out an identity management system five years ago, the state did it for a simple reason: The governor (now Health and Human Services secretary) wanted a new e-mail address.

'He was tired of spelling out 'Michael dot Leavitt at state dot UT dot US,' ' said Phillip J. Windley, then CIO for the state. 'We owned the domain Utah.gov, so we decided to give him and every other state employee a Utah.gov address.'

But this simple-sounding change turned out to be not so simple. The state had to upgrade network directories at nearly every agency, then create a metadirectory to synchronize the data for all of them. It also had to get everyone to agree on how to handle naming (i.e., first name, last name). 'Getting everyone in a decentralized organization to agree on anything can be a challenge,' Windley said.

Homeland Security Presidential Directive-12, issued in August 2004, requires federal agencies to adopt standard ways of securing physical access to buildings as well as logical access to information systems. And although not covered by HSPD-12, many state and local governments are moving toward IDMS as well, for the security and efficiencies it brings.

'Our first reason for adopting identity management was to tighten up security,' said Norman Jacknis, CIO for Westchester County in New York, which is currently rolling out IBM Tivoli's identity management suite to more than 6,000 county employees. 'We also realized we're wasting enormous resources having every software developer build their own ID structure.'

But security is only part of what an IDMS delivers. Identity management solutions can slash the number of passwords each employee must remember, reducing the temptation to use insecure passwords or write them on Post-Its stuck to their monitors. And they can automate the password recovery system when employees do forget their sign-ons. More important, an IDMS can simplify provisioning for new hires or terminations, allowing IT or human resources departments to control access to network resources with a few keystrokes.

But identity management technology is still relatively new and continues to evolve. Whether driven toward an IDMS by federal directive or internal initiative, experts say government IT shops have a lot to consider when choosing a system. Getting familiar with the technology is the first step.

Before any organization can roll out an IDMS, it must define roles and set policies for every employee and contractor, allowing individuals to access some systems but not others, depending on the role they've been assigned.

'You can go crazy trying to assign rights on an individual basis,' said Jacknis. 'You have to think in terms of roles. But ... it's not as easy as slapping some software on top of your directories and thinking that will take care of it.'

Some identity management systems are more flexible and granular than others, said Ellen Libenson, vice president of product management for Symark, an enterprise IDMS vendor in Agoura Hills, Calif. She said agencies planning an identity management RFP should ask whether the software lets you define roles based on such factors as an employee's title, work status, department, region and security clearance. Ideally, an IDMS would be granular enough to, for example, deny access to certain databases after normal working hours.

More roles than employees

The ability to manage large numbers of roles also is key for certain types of public-sector agencies. For example, the United Kingdom's Ministry of Defense has around 400,000 employees but more than 600,000 roles, said Torgeir Pedersen, senior architect for Trondheim, Norway-based MaXware, which also counts the Marine Corps, NATO and others among its long-time customers.

At its most basic level, an IDMS authenticates users, manages access to certain resources and allows agencies to get a better handle on password security. A well-designed IDMS should provide a 'three strikes' capability, where users are locked out after a specified number of failed log-in attempts, said Libenson. It should also capture users' keystrokes during the log-in process to spot potential break-ins.

And while passwords may be fine for net log-ons, access to more sensitive data requires tighter security. 'If you need strong authentication,' Libenson said, 'you'll need a system that integrates easily with tokens, smart cards and/or biometrics.'

At the federal level, the IDMS should integrate with smart cards based on Federal Information Processing Standard-201 for personal identity verification. FIPS-201 requires smart cards to store digital fingerprint data and support public-key infrastructure credentials for user authentication.

Security doesn't stop after a user has logged in. A key driver for IDMS is the Sarbanes-Oxley Act, which requires companies, and some agencies, to maintain audit trails of which employees accessed what information systems. If someone attempts to gain unauthorized access to a secure database, the attempt can be logged and the person identified. The trouble is that most identity management solutions stop logging the moment you gain access, said Toby Weir-Jones, director of product management for Counterpane Internet Security in Chantilly, Va. 'The system will know when and where you logged in and that you logged out seven minutes later, but it won't know what you did in between.'

Weir-Jones said most IDM systems aren't designed to track user activity inside applications, so they should let you integrate with third-party tools that do so.

Making connections

IDMS solutions touch every major system in an organization'including aging legacy apps not on speaking terms with one another'which makes them challenging to implement. A small organization standardized on a single platform may be able to install an 'identity appliance' in hours or days, said Philip Kwan, director of product marketing for ID appliance maker A10 Networks in San Jose, Calif. But large agencies with diverse platforms can expect to spend months if not years fully rolling out an IDMS.

Nearly all core enterprise applications, from e-mail to HR to accounting, have their own user directories. An enterprisewide IDMS must be able to communicate with the directories in each application and synchronize the data'even if the account is listed as 'George W. Bush' in the accounting application, 'Bush, George W' in HR, and 'potus@whitehouse.gov' in e-mail.

With most government agencies using a mix of mainframe, Unix, Linux and Windows platforms, as well as a plethora of databases and network directories, it's not a trivial undertaking.

'Big organizations have identity data stored in all sorts of different repositories and systems,' said Chris Zannetos, CEO of Framingham, Mass.-based Courion Corp. 'A key requirement of any identity management system is how effectively it can connect to and use data held by multiple systems.'

Counterpane's Weir-Jones suggests agencies start by doing a thorough inventory of all systems that hold identity data, and then asking IDMS vendors if they provide interfaces into each of these systems. 'If they don't, you'll have to build them yourself, which can be expensive'and when the tool changes, you have to upgrade the interface,' he said.

An alternative, said MaXware's Pederson, is to look for an IDMS that offers tools that let you build your own connectors between applications. Even if the software has the right connectors, they may need to be tweaked to work properly with your apps'without having to hire a customer programmer for each app. As agencies add new software to the mix, connectors will need to be written for those too.

Another key consideration is whether an IDMS works with other agencies' identity management platforms.
Just as FIPS-201 requires a single smart card to work in any reader at any federal agency, a so-called 'federated' identity management scheme would allow employees to use the same log-in and password no matter what federal network they're logging into.

'I think the federal government is very keen about expanding is use of federation,' said Javier Vasquez, a senior technology specialist for Microsoft's Federal division in Washington. 'The next step would be enabling private citizens to use a range of public services simply by logging in once.'

Unfortunately, federation standards are still in flux, so any IDMS must support multiple standards from the Liberty Alliance, IBM and Microsoft's Web Services architecture, and the open-source Security Assertion Markup Language 2.0.

'One of the biggest stumbling blocks is interoperability with other agencies,' Weir-Jones said. 'Can you build a large trusted network, or will you end up with a system you can use internally but whose external hooks may or may not work correctly?'

Can we see some ID?

The biggest challenges to implementing an identity management system may not be technological as much as practical. It's important to take a step back and look at the problem from a business or organizational point of view, said Jon R. Wall, principal technology specialist for Microsoft Federal.

'Before you write an RFP, figure out what triggers what,' Wall said. 'Walk through two scenarios from beginning to end'hiring a new employee and terminating a current one. Chart out every system that process will touch and in what order, and do it from an internal agency perspective, not a technology perspective. We can bend software to do a whole lot of stuff for you, but identity management is really driven by business practices.'

The University of Utah's Philip Windley said moving to an IDMS can be a sea change for most agencies, one that must begin at the very top.

'This isn't a solution you're going to buy from someone as much as it is a cultural change in your organization,' he said. 'How do you assess risk for the various components of your information infrastructure? What authentication guarantees can you pass on to the underlying system? These are things you need to decide before you put out an RFP, and the risk assessment has to be driven by business leaders, not IT security professionals.'

Westchester County's Jacknis recommends bringing in a consultant to help develop the RFP, especially at the state or federal level where the RFP will likely be complex, and a systems integrator to implement whatever solution an agency ultimately chooses. He also advises doing a slow and steady rollout'and having lots of patience.

'This is not the kind of thing you want to do in a big bang approach,' he said. 'We've had so many surprises with identity management products that I can only say that I hope to be done [with our rollout] by the end of 2006.'

Technology journalist Dan Tynan is author of Computer Privacy Annoyances (O'Reilly Media, 2005).

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above