Closing the XML security gap

If you use a firewall as part of your network security strategy, you might be feeling smug, thinking that you’ve closed access to thousands of ports and vulnerabilities. What you may not realize is that your firewall is most likely blithely passing XML through port 80, the Web’s default port.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Because Web services rely on the transfer of XML information, they threaten to disrupt standard security procedures by making every packet a potential Trojan horse. Some of the XML sent to your network might be SOAP and thus contain executable messages. But hackers can place SQL and Windows executables inside an XML packet, and poorly written applications may provide pathways for these to be executed. Even if you have not deployed production Web services, XML can pose a security risk if enterprising employees are experimenting with Web services and leaving security holes in their wake.

But there is hope for application security in the form of XML firewalls. These devices sit behind a traditional firewall and monitor traffic on port 80 and any other ports you select. They pick through the contents of the XML packets, looking for potential trouble and taking action when trouble is found.

These three XML firewall appliances from DataPower, Forum Systems, and Reactivity are designed to maintain your existing investments by plugging the XML security hole. I was struck by how similar these devices are to the Web service intermediary products I’ve recently reviewed (infoworld.com/457). In fact, the job these appliances are built for positions them nicely to compete in that space.

Many organizations that buy Web service intermediaries are buying them for the same features these three appliances provide. Prior to purchase, companies should consider whether an XML firewall appliance would be more convenient.

XML firewalls free application developers from having to protect their apps against every possible type of attack. They also ease the task of managing cryptographic operations on XML. Key management and security is enhanced because the keys and certificates are concentrated in the appliance and stored in hardware-based, hardened key stores rather than being distributed throughout the various applications.

The firewalls I examined provide very similar features. All do a good job of filtering XML traffic according to various rules and conditions. Where they differ significantly is in their approach to XML security, which is reflected in their user interfaces.

DataPowerXS40 XML Security Gateway

Configuring the DataPower XS40 requires creating a virtual firewall for every service you want to expose to the outside world, which forms a path through the firewall to the back-end server that supplies Web services. The virtual firewalls can include a custom URL rewrite rule for transforming URL-based requests and doing “service virtualization,” where the real URL of a service is hidden behind a URL designed for public consumption. This adds a layer of protection.

Each virtual firewall is configured with a custom firewall policy, a pipeline of actions to be performed on each XML message passing through the firewall. Policy actions are implemented via XSL stylesheets, and can include XML filtering, digital signing, signature verification, schema validation, encryption, decryption, transformation, and routing. While not required in the XS40’s standard configuration, modifying or creating new stylesheets will customize the actions of the firewall to fit your unique needs.

The XS40 provides a command-line interface via the serial port or SSH (Secure Shell). Once the initial configuration is complete, a Web-based management console provides full support for configuring the appliance. Both the Web-based and command-line style interfaces are full-featured, and either can be used exclusively in configuring the appliance. The Web-based management console, however, does an excellent job of exposing the conceptual model of the XS40 in a logical way, making virtual firewall creation much easier. An extensive list of roles gives administrators precise control over the functions of each user.

The XS40 also sports a proprietary, hardware-based XML processing technology called XG3 (XML Generation 3). With XG3, the XS40 has wire-speed XML processing capabilities almost 10 times faster than software-based XML processing solutions. This speed makes XML schema validation for every message a reasonable goal, significantly reducing risk from malformed SOAP messages or XML data packets.

Forum Sentry 1504

Although the XS40 can be completely configured using a single interface, the Forum Sentry requires three different management consoles: an IOS (Internetwork Operating System)-like command line interface for configuring the device, a Web-based server administration interface for managing the policies on the appliance, and a Java-based Workbench interface for security policy authors.

I found the proliferation of user interfaces confusing, partly because I was playing three different roles at the same time and flipping back and forth among the various interfaces. The Java-based Workbench application was buggy; the “open file” dialog boxes didn’t work and were even misleading in some cases, leading the user to open a file on the disk when the application really wanted a file from the document store in the Workbench. I found myself wishing that Forum had just supplied a Web-based configuration tool for creating security policies.