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 Technology Inc., Forum Systems Inc., and Reactivity Inc. 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. 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 1503
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.
After the Forum Sentry is configured in the IOS interface, the server administrator uses the Web-based interface to create Server Policies. These policies connect service proxies on the firewall to remote interfaces, establishing a path for any traffic hitting the listener, and control authentication, protocols, error handling, and default-traffic policies (allow or deny). The server administrator manages the cryptographic certificates and keys using the Web-based interface.
The Workbench is used to create Security Policies, which are not explicitly connected to Server Policies. The appliance chooses which policy to apply to a particular XML message using a XPath-based document filter. When the XPath filter matches an XML-document passing through the firewall, it applies the associated policy tasks to the document. Each Security Policy can contain multiple tasks, such as archiving, encrypting, processing SAML assertions, and other access control mechanisms, signature verification, and transforming, validating, and processing a WS-Security style header.
Any Security Policy with XPath filter matches can be applied to the XML traffic associated with any Server Policy, which allows a great degree of flexibility in creating general-purpose Security Policies that can be reused on multiple servers. In practice, however, I suspect that many administrators will create Security Policies with XPath filters that tie them to a single server or a small set of servers for easier management.
Reactivity XML Firewall
As with the other products, the abstract task of creating a security policy in Reactivity requires connecting consumers to services and applications through the firewall. The difference lies in how the security policy is presented to the user. The four primary components of a Reactivity security policy are consumer authenticators; handlers, which define security rules for a service or group of services; service descriptors, which describe the service interface; and routes, which connect handlers to the service descriptors they secure. Any consumer can be allowed to consume any service through one or more handlers and routes. For example, you could set up different security policies for different user groups for the same service.
Policies can be created by hand or from a WSDL file. Importing the WSDL file automatically creates a handler, route, and service descriptor for the described service.
These generated components can then be further customized in the handler by an administrator. First, you specify requirements for message validation, header processing, time stamping, encryption, and digital signatures for the requests and responses. Second, you set the logging, alerting, and SNMP traps for the service. And third, you set policies such as access control requirements or IP-address filtering to restrict traffic to specific consumers.
This abstraction of service policies into handlers, routes, and descriptors provides an intuitive interface for managing XML service access. The management console also restricts access to the firewall's various features based on user roles. These roles set boundaries along job lines. Developers can define and test policies, for example, but not deploy them onto the production appliance, while the report manager role can create and generate reports but not manage other policies.
You can also control multiple Reactivity firewalls from the management console. Because many organizations will want to deploy multiple firewalls at different locations for reliability and scalability reasons, this feature provides a way to conveniently create a single, consistent set of XML firewall policies across multiple appliances.
The Difference is Details
All three of these XML firewall appliances do a good job of filtering, transforming, signing, verifying, and handling encryption duties on XML traffic, and each provides scalable and reliable XML security services.
The DataPower appliance is the most hardened of the three -- it looks and feels like a datacenter appliance, with no extra ports or buttons exposed and no rotating media. The hardware-based XML processing allows pervasive Schema validation, a nice benefit. I was impressed with the XS40's extreme flexibility, due to its use of XSL stylesheets that allow almost every feature to be customized.
The Forum Sentry, on the other hand, feels most like a firewall with its IOS interface and policies selected according to XPath criteria. I disliked the multiple user interfaces on the Forum Systems appliance from a navigation standpoint, but I've no doubt that experienced firewall administrators would feel right at home with the Sentry's approach.
The Reactivity appliance is closest in feel and philosophy to other Web service intermediary products. It's a good choice when the goal is to create a secure interface to Web services.
Overall, I liked the Reactivity management console the best because it is the most intuitive.