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.

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.