XML Web Services rely on IP and most typically HTTP as a transport layer to connect applications and associated resources to one another. Because XML is a text-based data encoding standard, it is human-readable and easily deciphered when intercepted. For example, each field of an XML document is identified with an element tag, making location and retrieval of sensitive information such as a Social Security Number simple. Consequently, robust XML Web Services security is built on a strong foundation of transport layer security so that this information cannot be intercepted and read in transit.

Although IPSec-based VPNs are the technology traditionally associated with securing extranets, SSL has proven easier to deploy and provides a more flexible security model. It is easily deployed between both servers that are inches and thousands of miles apart. While transport layer security such as SSL cannot provide the more granular security functions described in later sections of this paper, it is a minimum requirement for ensuring confidentiality of information during transport.

It is also recommended that server certificates are used during authentication and if possible, the use of client certificates is recommended as well. This helps protect against the known weaknesses associated with using source IP or DNS information for access control or authentication.

Creating and maintaining SSL connections is computationally intensive and in high-volume environments, can quickly overwhelm ordinary software processors. As such, hardware-based accelerators are the preferred way to secure the transport layer while maintaining high performance for transactions.

Companies that have built secure perimeters using firewalls are familiar with the concept of filtering traffic to create a secure perimeter. Typically traffic is blocked based on network information such as IP address or port number. In the case of XML Web Services, traffic is designed to flow through port 80 or 443 undetected just as ordinary Web site traffic de. But unlike Web traffic, XML and SOAP in effect act as executable code destined for valuable resources. As such, these new traffic types expose critical operations and in turn, require sophisticated processing to ensure that transactions are known to be good before they penetrate deep into the enterprise.

With XML, protective filtering policies can be set at the content-level but requires that XML documents are fully parsed and processed before such filtering decisions can occur. If the enterprise can read and process an XML document at wirespeed, it is able to establish business rules such as what size a purchase order must be to be serviced or what account numbers are bona fide versus not. This enables enterprises to secure transactions based on business information all without interacting with application software where possible performance degradation and security vulnerabilities are introduced.

XML filtering provides managers with a full spectrum of functionality as complex rulesets can be built around network level information, message size, message content and a host of other variables.

Because these filters are XML-based, they are easily updated as new threats are detected. Setting up simple filters based on message size or XML Digital Signatures is an easy place to start. As application usage increases, filtering based on content and other parameters enables the security staff to implement sophisticated and granular business rules.

One sound security practice deployed by many today is the use Network Address Translation (NAT) to obscure internal IP addresses. Utilizing NAT is an important first step and requirement for sound XML Web Service security but XML can still expose more information about a company than ever desired. Even a simple URL can indicate what internal and external resources are being utilized by a given application.

In addition to using NAT, one effective way to mask and protect internal resources from external parties is to disallow direct TCP connections between application servers and outside parties. By using a proxy to rewrite URLs and other information, enterprises can quickly and simply hide a significant amount of their internal configuration.

XML Denial of Service attacks may not be as popularized as the syn-flood attacks of the dotcom era but they are more easily launched and capable of much more damage. Whereas IP-based DoS attacks require coordination of thousands of clients to simultaneously swamp a server with requests, an XML DoS attack can be launched with a single low-bandwidth message that is undetected by an IP firewall. In some instances even unintentionally malformed content can create a service outage. Recently issued security advisory bulletins have detailed how vulnerabilities in several vendors' XML parsers can enable maliciously malformed XML documents to create a Denial of Service by consuming CPU cycles and memory.

Because these traditional security devices lack the ability to differentiate bad XML from good XML, it is simple to forward a malformed or corrupted XML document directly to backend resources for processing. Once the message passes beyond traditional network-level security systems it can compromise backend server resources by erasing data, exporting sensitive information or consuming resources with an infinite processing loop. Rather than a temporary bandwidth outage, this can result in serious and sometimes permanent disruption of service.

There are several steps enterprises can take to protect against XDoS. The first is to implement reasonableness constraints for all incoming messages. Using an XML Security Gateway as a proxy, network managers can configure simple settings on message size, frequency and connection duration to name a few. The goal is to allow access to resources while simultaneously using XML filtering rules to reduce the aperture of entry into the corporate network.

Processing cycles on backend servers are valuable yet frequently and unknowingly misspent on processing bad data. Because XML is text-based and in many instances generated by humans, there is significant room for error in message creation. Whether data is malformed intentionally or unintentionally it can consume valuable server processing cycles without warning, resulting in service degradation or complete outages. One simple step to prevent this problem from occurring is to use XML Schema Validation to ensure that both incoming and outgoing messages are known to be valid.

This best practice reduces the risk of security holes of unknown/undocumented fields or protocol features that might otherwise compromise resources. In addition to performing Schema Validation on all messages, managers should also check messages for XML well-formedness (during parsing), improper identity or lack of resource references, protocol (e.g. SOAP) validity and other message validity checks.

As with all other XML Security functions, performing Schema Validation is processing intensive and challenging during times of peak usage. For widely available XML engines, a simple rule of thumb is that schema validation and parsing is three to four times more time-consuming than parsing alone. As a result, hardware accelerators will be used within XML Security Gateways so that application performance is not compromised.

Masking internal resources with a proxy and URL rewriting provides some basic protection but XML's ability to be easily transformed provides the ability to hide internal resources from external parties at the XML application layer as well. By transforming all the XML messages (or requests and responses) network managers enable XML Address Translation: mapping between the private internal data layout and the external one. This kind of application-layer protection is easily implemented today using XSLT, one of the most mature XML technologies. Using XSLT, businesses can obscure internal schemas and object layouts from outside parties. This technique can also be used to extract or present only the needed data for a given transaction. In this fashion the message is optimized for processing before it is delivered to recipients.

While not strictly a security implementation, Message transformation is frequently required for translation purposes as well. As the number of XML dialects and vocabularies increases, message translation will become a key first step in processing any application request.

XML Web Services rely on massive server to server interconnections both inside and outside the enterprise. In such an environment, ensuring integrity of data is paramount. Validating the identity of a service requestor is a form of authentication and also prevents documents from being tampered with during transmission. Together the IETF and W3C have specified an XML Digital Signature standard that when properly implemented provides this protection across an entire XML document or even at the element level within a document.

There is a misconception that to use XML Digital Signatures both the sender and recipient must be enabled with appropriate technology. As a best practice, a sender can apply signatures to all outgoing documents and recipients have the option of performing signature verification for authentication. In this example, even if the recipient does not perform verification, the sender gains a form of non-repudiation. By signing each outgoing message, the sender can create a secure audit trail by logging each message with a signature that can be verified post-transaction. Because each log entry is signed, their contents cannot be modified or altered and the sender gains non-repudiation protection. While signing and verifying every incoming and outgoing message may seem processing-intensive, use of a hardware appliance avoids the performance bottlenecks that accompany software-based solutions.

Enterprises can augment non-repudiation capabilities by using the Network Time Protocol (NTP) to synchronize all XML network nodes to a single authoritative reference time source. This simple step adds timestamps to all incoming and outgoing messages. When used with XML Digital Signatures, network managers now have a cryptographically secure timestamp that enhances non-repudiation capabilities by being able to definitively prove at what time a given transaction took place.

Application managers that have been deploying SSL and IPSec connections in networks for several years may wonder why XML would require a separate approach to encryption. The answer is that transport layer security is designed to provide bulk encryption of content being sent from one point to another. Once the content is delivered to the recipient, bulk decryption occurs and the entire message's content is visible. Because of XML's plaintext format, this is a significant issue.

The XML Web Services model is different as it is frequently multipoint in nature and requires that different portions of a message be selectively shared with recipients depending on their identity. Take a purchase order as an example. The accounting department needs to see payment information such as credit card number while the shipping partner only needs basic address information, creating the need for separate but simultaneous encryption policies within a single XML document or application request (see Figure 2).

Figure 2. XML Field-level Encryption

As such, the XML Encryption standard allows application developers and network administrators to encrypt individual XML documents and data fields within documents with different encryption keys. This is far more valuable for business applications than the bulk encryption of a network connection. With this capability a single HTTP connection may carry plaintext (unencrypted) headers and three different XML documents encrypted with different keys. Although sharing a TCP connection, the documents may be meant for different destinations or individuals, their contents obscured from anything or anyone who does not have the decryption key. To support the many possible variations and enable interoperability between far-flung servers, part of the specification defines standard ways of describing cryptographic algorithms, settings and keys within the document. But the flexibility of the specification goes even further: parts of a given document can be encrypted, down to individual fields being encrypted.

Unlike bulk encryption of entire TCP sessions, XML Encryption requires one to parse the XML transaction, then select the section(s) to encrypt/decrypt and finally perform a set of processing-intensive XML and crypto operations. The algorithms responsible for the actual encryption of XML data are the familiar DES, 3DES, RSA, and others used in SSL and IPSEC, but they are now applied at a document or field level instead of at a packet level. This means that 80% of the work and, therefore, the processing time, of XML Encryption is not cryptography, but XML parsing, XPath selection, serialization and other XML operations necessary to search and process the encrypted data fields. Because both crypto and XML processing are very resource-intensive, deploying both XML Encryption and its companion, XML Digital Signature, can have a significant performance impact on high-transaction applications. For mission-critical production applications, it is becoming increasingly common to offload these functions onto specialized XML-aware network hardware such as an XML security gateway that provides high-performance application security in an easy to deploy solution.

Because the underlying ciphers are the same, the keys and certificates used can also be the same as those used with other applications and protocols, potentially loaded from an existing PKI repository or key management system. As with SSL or VPN rollouts, keeping software toolkits and key material both up-to-date and secure across multiple servers can be as big of a challenge in practice as learning and configuring the technology in the first place. Centralized policy or centralized enforcement of it, can help mitigate these costs and reduce administrative burden.

The importance of auditing cannot be underestimated and while many network managers rely on syslog for creating audit trails, alone it is not reliable or totally secure. XML Web Services provide several new features for enabling secure auditing.

By using a combination of XML Digital Signatures and time stamping, a manager can quickly and easily create secure e-business transaction logs that can be used for non-repudiation. These audit trails are key to prosecuting computer criminals or holding partners accountable for business transactions. In many instances legal requirements demand that the logging technology used is secure and verifiable.