Nothing has done more to erode the enterprise security perimeter than the rise of XML Web services. Designed to bypass the existing enterprise Internet Protocol (IP)-based network security infrastructure, Web services create a sea of new security vulnerabilities. Addressing those threats requires both a new approach and a high-performance technology.

By way of a concise introduction, here are the most significant Web services operations. I've made a simple list below, with some notes about the utility of each.

• XML parsing is the first step of converting the XML text into some internal form required to perform any subsequent XML processing.

• XML schema validation determines whether the structure of XML data matches the predefined specification. For example, validation of a Soap request against the Soap v1.1 schema will show whether the structure (but not the contents) of the request is that of a proper Soap message.

• XPath filtering allows arbitrarily complex conditions to be applied to messages; for example, all "Transfer funds" method invocations must be for less than $1,000, and purchase orders for more than $50,000 can be routed to a different server.

• XML encryption provides data privacy at a message or field level by using asymmetric or symmetric encryption. It ensures that sensitive data is protected from snooping even when stored on disk and is the first time that an interoperable means for encryption of an arbitrary portion of a message has been widely available.

• WS-Security can be thought of as a higher-level specification for combining Soap, XML digital signature and XML encryption to provide interoperable message-level security. The specification is broadly supported; it was introduced by IBM, Microsoft and Verisign.

Where message-level security should be carried out is another area of contention, but it is increasingly certain that in many cases it will have to be done on dedicated network appliances that act as Soap proxies. These XML security gateways can be used to secure multiple applications at once and are designed to be managed by the network or the security group. There are no fewer than four vendors currently offering such products, and XML-aware network security is a natural continuation of the application-level security trend. Nonetheless, the technology required is so different that it is disruptive. To apply security policy to an XML message, it is necessary to parse the message and then perform five or six XML processing steps. That means that any message-level Soap security solution must include a complete XML engine, hardened Soap stack and XML security engine.

Compatibility first

Since XML is built for compatibility, not speed, it is not surprising that XML security processing is resource-intensive. Compare the work required with the tasks of a typical HTTP-aware application security device scanning for code-red signatures. The initial setup and handshake processing is the same. Then the application security device has to examine the HTTP header and compare it to a relatively small set of attack signatures and validity rules. Once that check is complete, there is no further interest in the HTTP message content. If persistent HTTP connections are being used, there may be some need to scan the message for the next HTTP header, but that is relatively inexpensive. Since these are generally incoming Web requests, the messages themselves are either empty or quite small (about 1 kbyte), carrying the contents of a Web form.

By comparison, a Web services security gateway has to parse the entire contents of the XML message, which can be anywhere from several kilobytes to a megabyte; perform schema validation; apply complex XPath filters to the content; verify one or more XML digital signatures; transform the content and finally send it to the destination. The filtering alone is much more sophisticated than a simple pattern match, allowing for arbitrary traversals of nodes in the XML tree structure. Digital signatures require XPath, XML canonicalization (a time-consuming process for rewriting XML into a byte-identical form), cryptographic hashing (for example, SHA-1) and, finally, public-key operations (such as RSA). The message content is almost certainly modified several times before it leaves an XML gateway. The contrast in the amount of data processed and the complexity of processing is responsible for the difference in overhead between "HTTP application security" and XML-aware security of an order of magnitude or more.

Every EE knows that any networking function that slow is simply asking for hardware acceleration. But besides RSA and other crypto operations old accelerator technology is not applicable to XML Web services security. Packet filtering and other IP-layer technology is of no use at the Soap layer, above HTTP. The HTTP and virus-scanning technologies were designed to do flat text string searches, which do not help with either parsing XML or evaluating XPath expressions. So while existing technologies can accelerate SSL handshakes, TCP termination, HTTP header parsing and common cryptographic operations, a new, XML-specific acceleration technology is required.

Technical hurdles

One challenge for creating such technology is that the processing is extremely complex compared with existing systems. Another, more difficult problem is that the Web services security standards are still changing; thus, baking the higher-level protocols into silicon could leave a manufacturer stranded. And even in cases where the specifications are approved, occasional mismatches between implementations require interoperability tweaks, and the security policies themselves are customized to every installation. Therefore, any XML security processor has to offer both high performance and tremendous flexibility.

Eugene Kuznetsov is chairman and CTO of DataPower Technology Inc. (Cambridge, Mass.).

See related chart