• 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.

  • Shane Peterson  |  Associate Editor