Solving the XML enigma
- By Brian Robinson
- Jan 12, 2003
The introduction of Web applications based on Extensible Markup Language creates a new security problem for federal agencies. Solutions, however, are emerging before many people even become aware of problems.
XML, a key component in emerging Web services that link systems via the Internet, eases information exchange by tagging data so disparate applications and systems can easily recognize it. But the link that Web services provide opens another backdoor to otherwise secure systems. As federal XML projects progress from pilot stages to full-scale systems in the next two years, security will be a major requirement.
Agencies need "end-to-end" security that permeates every part of a Web services infrastructure, according to Brand Niemann, a computer scientist at the Environmental Protection Agency and head of the CIO Council's XML Web Services Working Group.
"With XML Web services, you are dealing with potentially highly distributed applications, and that's the antithesis of strong security, which is generally seen as centralized [and defined by] lots of firewalls," he said. "Web services require security at every location [in the enterprise] and with every application, every user and every bit of data," Niemann said.
That requires that different vendors' XML security products work together seamlessly throughout the enterprise, he said.
The good news is that industry standards are well on the way to completion.
Security Assertion Markup Language, which defines a way to exchange security and related data across distributed systems, was ratified in November as an open standard by the Organization for the Advancement of Structured Information Standards (OASIS).
And sometime this year, the first version of the Web Services Security (WS-Security) specification, which will describe the basis for a broad, platform- independent Web services security framework, may be published. It was first proposed by IBM Corp., Microsoft Corp. and VeriSign Inc. and then moved to OASIS in the middle of 2002.
In the meantime, XML security is the domain of a small number of niche vendors who want to carve a market presence ahead of the expected entry of bigger and more established players such as Cisco Systems Inc., 3Com Corp. and Check Point Software Technologies Ltd.
Vordel Ltd., for example, recently published the latest version of its XML security product, VordelSecure 2.0, which provides an enterprisewide XML firewall and access control. It gets around the need for application-level security by intercepting XML traffic in the network.
"Our product provides the ability for a network administrator to set a security policy to run a Web service and only allow certain kinds of data into that service," said Mark O'Neill, Vordel's chief technology officer. "No extra coding is required."
Reactivity Inc. offers the Reactivity Service Firewall as a proxy through which XML traffic is channeled for use by Web services applications.
Sanctum Inc.'s AppScan takes a somewhat different approach by running continuous, dynamic scans of the Web services environment in order to identify where security holes may pop up.
"There are common vulnerabilities that applications have that may not have posed much of a problem in the past because only a few people had access to the applications themselves," said Steve Orrin, Sanctum's chief technology officer. "XML services will now expose those applications to the Web, so AppScan tests for potential security problems and provides detailed vulnerability assessments, and then recommends ways to fix them."
The drawback to deploying security for XML and Web services is that it's a new area and people don't know the nuances right now, said Jeremy Epstein, director of product security for webMethods Inc. However, with standards developing rapidly, he doesn't expect that to hold true for long. n
Robinson is a freelance journalist based in Portland, Ore. He can be reached at [email protected]
Network security tools that are not based on Extensible Markup Language protect communications by checking the headers on IP packets against constraints set in policies by network administrators and any aberrations that might signal potential vulnerabilities. XML messages, however, contain much of this header information in the body of the message and, because they are text-based, can be easily manipulated. Security that only reads the IP headers would miss any attack embedded in the XML data itself.
At a minimum, any XML security must:
* Authenticate both the identity of the message sender and the integrity of the message.
* Validate that the message content conforms to rules set by network administrators.
* Authorize both single user and group access to XML traffic.
Additionally, because XML Web services are formed by chaining together services, security must be end-to-end and incorporate safeguards at the application level and for each node in the extended Web services infrastructure.
Brian Robinson is a freelance writer based in Portland, Ore.