Building Trust

Enterprise identity management draws governments' attention, but it's not an easy problem to solve.

by / September 30, 2005
In working to connect formerly isolated IT systems and make governments run smoothly, agencies face a range of issues -- sometimes turf battles put the brakes on creating trust between units of government, while other times, technology itself erects a roadblock to progress.

Identity management -- a key ingredient to widespread IT interoperability -- suffers from both of these maladies.

At its root, ID management software is billed as the simplest way for enterprises to control both how users access information in discrete computer systems, and the mechanism for system-to-system information exchange between agencies or business units.

On the user side, the software is supposed to help enterprises with three key components of personal identity:

  • authenticating that a person is who he or she claims;
  • authorizing that person's access to information in discrete systems; and
  • providing a single sign-on mechanism, whether some version of a password or biometric identifier, for that person to use to access systems internally across the enterprise or to access systems in other enterprises.

    Unfortunately most ID management software isn't interoperable, which creates problems for governments that might want to share information, but are using different systems.

    Another issue is the transparency of the government's identification process. If one agency doesn't trust another agency's methods of authenticating user identities, they are unlikely to share sensitive data.

    Conflicted Identification
    As with other security vulnerabilities, an entire industry has sprung up to address identity management challenges.

    Connecting IT systems blazes a trail for information sharing, but linking discrete systems into a unified chain puts the entire chain at risk, since the chain is only as strong as the weakest link. Since the Internet is the method for information sharing, the potential for outsiders to exploit weaknesses in security policies becomes very real.

    As governments push to integrate information and systems, they up the ante for effective ID management solutions that span organizations, and perhaps jurisdictions.

    But few authentication technologies are interoperable, which is a limiting factor facing those who decide to trust each other's authentication processes, said James Lewis, director of the Technology and Public Policy Program at the Center for Strategic and International Studies.

    "It's not seamless to get a credential from one system and then use it [in] another because you're using different technologies," Lewis said. "As I understand it, GAO [General Accounting Office] had an interoperability lab last year and found out interoperability wasn't as widespread as hoped."

    Lewis also is former chairman of the Electronic Authentication Partnership (EAP), a multi-industry group of approximately 60 members developing interoperability between electronic authentication systems in the private and public sectors.

    The EAP's members include representatives from the Pennsylvania and New Jersey state IT offices, and associations representing other public-sector officials, namely the American Association of Motor Vehicle Administrators (AAMVA), and the National Association of State Auditors, Comptrollers and Treasurers.

    Lewis said the EAP is educating organizations about the value of transparent ID management policies. If one government agency doesn't know how another agency issued an electronic credential -- or token -- that identifies a person, the agency won't trust or accept it.

    "If people don't know the basis for issuance, they limit their trust of the token," Lewis said. "Some of it is the lack of transparency -- you don't know what other people have done."

    States' authentication processes may not be so different, but if Illinois goes through a certain process to authenticate a person's identity, California has no way of knowing how close the process is to its own.

    "They're probably not that far apart," Lewis said. "But until they're the same, the result you get is, 'I don't know what these people
  • did, and it isn't what I do, therefore, I'm going to discount it.' You see that even in the federal government, where what one agency does may not be acceptable to another."

    Perhaps the simplest way to solve this problem is sharing methods of identity management, but the simple things aren't necessarily the easiest to do.

    "There still aren't any rules on how to authenticate people," Lewis said. "There also isn't a lot of transparency. It's not that people are hiding things. It's just not easy to find out. The fact that you don't have rules about how to exchange trust between states is a big impediment."

    Lewis said the EAP's goal is straightforward -- in the public sector, if one government agency authenticates a user, then other agencies needing to authenticate that same user can rely on and trust the first agency's authentication process.

    That exchange of trust between states is critical, Lewis said.

    "A state needs a credible process to link individuals to their digital credentials, but then it doesn't ask other states to match that process when they issue credentials, nor does it share how its process works with other states when they're asked to accept a credential," he added. "You're only sharing the outcome -- 'We did whatever our process calls for, and we decided we trust and authenticate this person, and now we ask you to trust our decision.'"

    Inclusive vs. Exclusive
    While the EAP tackles transparency, another organization known as the Liberty Alliance works to develop open standards for identity management applications.

    Formed in 2001, the Liberty Alliance consists of more than 150 companies and organizations -- both government and nonprofit. Products from eight companies recently completed certification testing by demonstrating interoperability.

    The alliance began its testing program in 2003, and has since tested 40 ID management products for interoperability. Alliance certification is meant to assure organizations that the products will not require extensive configuring.

    Building interoperable identity management products is relatively new to the industry, said Shannon Kellogg, Liberty Alliance board member and RSA Security's director of Government and Industry Affairs.

    In part, vendors active in the identity management arena did what any vendor would -- react to market demands. Little incentive existed to create standards for identity management products.

    Groups such as the Liberty Alliance and the Organization for the Advancement of Structured Information Standards (OASIS) -- a nonprofit consortium focused on driving development and adopting Web services standards -- started the push toward standards when customers began asking for standards-based products.

    "RSA was a founding member of the Liberty Alliance several years ago, and we've also been active in OASIS and on the SAML [Security Assertion Markup Language] spec," Kellogg said. "We thought early on it was critical to drive the standards process while talking to customers. Customers a few years ago didn't necessarily understand and weren't clamoring for federation technologies."

    The impetus then was to hold tight to information, and government agencies wanted products that sealed environments against information coming in or going out. The emergence of Web services as a practical toolset coupled with a change in attitude about the importance of information sharing now has customers asking for a federated identity management environment.

    In this environment, the same user name and password allow individuals to sign onto the networks of more than one enterprise to perform necessary transactions.

    The growth of business-to-business activity, and the need to collaborate on data sharing and information gathering, spurred the change, said Rob Potter, RSA's director of Federal Operations.

    "What people have said is, 'Wait a second. We have these silos of access and authentication. Now that we've built this, how do we go out and do exactly
  • what we said we didn't want to do? How do we open ourselves up?'" Potter said, adding that market demand and the way people wanted to access computing resources helped create the lack of interoperability. "I think that will also be the driving factor in evolving."

    More Than a People Problem
    Though information-sharing projects depend on making sure the people in the agencies involved can be properly identified and authenticated, computer systems must be identified as well.

    In March, the Architecture Working Group of the National Association of State Chief Information Officers (NASCIO) released Government Information Sharing: Calls to Action -- Government Perspectives. The 2005 report re-examined the evolution of public-sector information sharing since 2000, when NASCIO (then NASIRE) published Toward National Sharing of Government Information.

    Bill Roth, Kansas' chief information technology architect, was interviewed for the 2005 report. He told the NASCIO Architecture Working Group that it's necessary to find a secure and reliable way to identify agencies and computer systems, because machine-to-machine data exchange is often the backbone of information-sharing projects.

    "We've gone way beyond people-to-people stuff in most of our system-to-system interactions," Roth said. "If you look at any system model these days, you'll see that one system from one agency feeds another system in another agency. That's evolved to the point where the people are not in the middle anymore."

    Curiously, the enterprise ID issues Roth and his colleagues deal with mirror problems associated with identifying people. One big problem is the proprietary nature of authoritative source and security measures included in different vendors' products, he said, and because there's no common ground, IT staff are forced to improvise.

    "We end up hardwiring, under the covers, a single-user ID that the application itself owns," he said. "Then the application uses that user ID to read, access and push information to some other place where they've got a hardwired user ID to absorb that information inside their environment. We really don't have an industrywide, acceptable way to identify and authenticate the source."

    This causes agencies trouble in verifying that a machine presenting itself to a system is, in fact, the machine being used by a particular department. Roth said guarding the identity of that machine is critical because a person stealing that machine's identity would get free run of any system the machine is connected to.

    Roth said part of why systems architects find themselves in such a pickle is that security policies were built around individual people. Now, as governments look at this multi-tier, multidimensional security issue of access to systems, that access could be application-, machine- or even group-based, he said.

    Addressing these questions requires agencies to have the same talks as EAP members. Establishing trust for other agencies' methods of authenticating users will eliminate the hesitation to launch and participate in information-sharing initiatives.

    "Nobody wants to trust somebody else when we all follow our own objectives and strategies," Roth said. "It's very tough to trust the strategy from another team that you do not have any control over. We're starting to hold some of those discussions in Kansas, but I can't say we've made much progress on a way to agree that if you trust this individual, this application, then that's enough for me to trust that individual and that application."

    Interconnected Issues
    A huge problem facing governments looking to strengthen ID management policies is how far those policies stretch across an enterprise. ID management is just one piece of a large puzzle.

    Government agencies also must accurately classify data and metadata, locate systems of record, and determine authority of source, Roth said, because those systems tie into ID management systems.

  • "All of these things have to work well together," he said. "The problem is getting people to look broad enough and deep enough, and not just at their agency. To look at the full dimensions of identity management and access to information -- not necessarily where we are today, but where we want to be 10 or 20 years in the future -- and then build a model to work toward that."

    If that wasn't enough, agencies don't work in a vacuum, and they don't set their own rules. State legislatures set mandates for access to and movement of information between state agencies. Federal regulations prohibit a state agency from sharing data with agencies not within the same funding stream.

    "Until we raise awareness of the people in the legislative and policy bodies to think about identity and access to information from all these different dimensions, it's going to take a while to overcome these roadblocks," Roth said.

    Even though federal agencies -- such as the departments of education, transportation, and health and human services -- have begun making changes, those efforts create still another problem.

    "We've got to find some way to allow all of these different approaches to look at what is a commonality, what are the ways we can keep from having to reinvent the wheel," he said. "What we're doing is creating new siloed security models at a higher level than we have before so the roadblocks to get across the silos actually get bigger instead of smaller over time."
    Shane Peterson Associate Editor