Spreading thin

Recently, the Web services buzz has been getting louder. Once in place, this group of data exchange and application standards promises to enable government agencies to swap information more easily — within their own systems, with other agencies and with citizens.

Extensible Markup Language is the foundation for those new capabilities, which can play a vital role in many homeland security efforts, from tightening borders to spotting bioterror attacks. XML breaks traditional barriers in application design by replacing proprietary software interfaces with standard components. As a result, information from different sources can move dynamically, allowing agencies to respond more quickly to new operational requirements.

But as agencies have begun tinkering with the alluring technology, they have found some glaring holes. "Most security products were designed to operate with simple point-to-point connections and cannot handle the one-to-many links possible with Web services," said Susan Eustis, president of WinterGreen Research Inc., a Lexington, Mass., market research firm.

Suppliers are aware of the problem and are moving to boost the security capabilities of their products. They are also crafting an array of standards so agencies can be sure XML transactions move securely from place to place. The work is complex and has resulted in a hodgepodge of standards and initiatives (see "Web security standards no easy task"). Ideally, the developments will meld into a security architecture that federal agencies can easily deploy using off-the-shelf products, but that outcome is far from certain.

"With XML, an agency can create a document one time and then move it from a browser to a printer and then to a file system," said Marion Royal, the General Services Administration's XML expert and co-chairman of the CIO Council's XML Working Group.

However, the new markup language evolved in a manner similar to other dramatic changes, such as the explosive popularity of personal computers and the Web: The foundation for efficient processing was put in place first and security issues were addressed later.

"XML by itself is not secure," said Barry Leffew, vice president of VeriSign Inc.'s public sector group. "Vendors need to add new distributed security components to make sure XML transactions are not open to interference from outsiders."

Because of the security limitation, federal agencies are adopting XML on a selective, rather than widespread, basis. "Many organizations are implementing XML only behind the firewall and using it to help different internal applications communicate," said Owen Ambur, a systems analyst at the Fish and Wildlife Service and co-chairman of the CIO Council's XML Working Group. For instance, information technology executives can use XML to add Web-based services to human resources management systems on their agencies' intranets.

Only in rare cases are agencies going outside their firewalls with XML (see "XML allows Census to change directions"). However, when they do, many rely on Secure Sockets Layer to improve security. Although SSL ensures that no outsider taps into a line and reads a communication, the protocol cannot help an agency determine if certain information is safe enough to be downloaded or if it is being delivered to an authorized user.

Federal agencies have three options for meeting those needs. First, agencies can build their own XML security systems. Because the work is complex, government departments may prefer to hand it over to a third-party security specialist. "There are a number of firms that are making a pretty good living developing security systems for government agencies," Eustis said.

A second option is to use proprietary products to fill the void. A growing number of vendors offer middleware software and services that boost XML security. They include BEA Systems Inc. in San Jose, Calif.; Tibco Software Inc. in Palo Alto, Calif.; and VeriSign in Mountain View, Calif.

Both options can ensure that XML transactions are protected, but they can be costly and time-consuming to deploy. Furthermore, they lock agencies into a single vendor's solution, which may make it difficult to keep IT costs down over time.

The third and perhaps ideal option is to build a distributed security system using a variety of commercially available products that can be easily integrated. However, creating such an infrastructure requires standards. Developing such standards will be tricky because people have different visions about how XML security systems should work and how much security is enough.

Underscoring the complexity of the task, vendors are creating a slew of standards — more than a dozen from three organizations — to secure XML links. The standards are evolving in a building-block manner, starting with the transport layer (basically the network) and working up the protocol stack to the top (the application layer).

However, there are a couple of potential stumbling blocks. The World Wide Web Consortium (W3C), the Organization for the Advancement of Structured Information Standards (OASIS) and the Internet Engineering Task Force are all contributing to the mix.

"With different groups working on various security standards, there is a distinct possibility that they will deliver items that don't quite fit with one another," Eustis said.

Proponents are aware of potential problems and are trying to help ensure that the various standards will interoperate. For instance, they are basing higher-level standards, such as Web Services Security (WS-Security), on lower-level standards, such as those for XML-based digital signatures and encryption.

Also, OASIS and W3C have been comparing their efforts with the aim of crafting consistent security standards. The cooperation was evident with WS-Security, a specification IBM Corp., Microsoft Corp. and VeriSign developed and turned over to OASIS in 2002. A short time later, OASIS and W3C sponsored a forum to evaluate work being done by both groups.

Vendors are also trying to help ensure consistency. "A number of the engineers, such as myself, who are part of OASIS working groups also work on [W3C] committees," said Krishna Sankar, a distinguished engineer at Cisco Systems Inc.

"Most vendors are ready to move into beta testing now with their WS-Security-compliant products, expect to have them in production in the summer and anticipate users ramping up deployments as the year ends," said Bob Blakley, chief scientist for security at IBM's Tivoli software group in Austin, Texas.

Such projections are based on the belief that vendors will deliver products that can be easily connected, but that may not be the case. "These XML security specification are quite broad, and compliance is open to interpretation," said Pete Lindstrom, research director at Spire Security LLC, a Malvern, Pa., consulting firm. "A vendor can leave out one full set of functions but still claim to comply with the standard. Obviously, such a product would not work with another system using all of the functions."

Ideally, a customer would be able to tell how well different products would interoperate by turning to a third party responsible for compliance testing, a step typically taken with networking products, such as Ethernet switches. To date, no group has stepped forward to fill that void and it seems unlikely that anyone will.

"There was a lot of discussion initially among vendors about setting up a conformance-testing entity, but there were hurdles, such as how much money would be required to fund it and its legal liability, so the talk died down," said Eve Maler, XML standards architect at Sun Microsystems Inc.

So how smooth will the migration to XML security functions be? "Already, a few interoperability demonstrations have been held, and there have been only minor problems getting different products connected," Sankar said.

Others are pessimistic. "Distributed security is a complex issue, one that will require significant investments by users and vendors," Eustis said. "Progress is being made, but it will take a few years — maybe more — before we see easy-to-install solutions based on industry standards."

Korzeniowski is a freelance writer in Sudbury, Mass., who specializes in networking issues. He can be reached at paulkorzen@aol.com.