From the bare bones stateful packet-inspection engine to sophisticated application-layer proxy firewalls, firewall...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
vendors are adding new features to keep hackers in check. However, these firewalls are behind the curve when it comes to securing XML messages and Web services. A new breed of firewall is emerging that specializes in securing XML data and Web service transports to enforce policy across the enterprise.
Web services and XML messages do not fit the old Web security model. They demand a new model to account for the challenges of using the Internet for application-to-application invocation and data communication. The dominant design today in XML and Web service security is to reuse the HTTP/SSL mold that secured the first generation of the Web. At a fundamental level, the HTTP/SSL model does not decouple security and transport, nor does it secure the XML messages themselves. SSL basically provides a secure pipe between two points. Furthermore, traditional firewalls are not designed to understand the XML message-level security, nor can they defend against a myriad of new XML message-based attacks. Since most packet-inspection firewalls are geared to secure and apply policy to the transport level, they generally don't scan for content in SOAP, UDDI, SAML or other Web services protocols.
The primary difference between an XML firewall and other firewalls is that much of the features in an XML firewall exist at the application layer and within the data payload or content, as opposed to the transport and session layer. Many modern XML firewalls act like high performance proxies. They can approach wire speed performance by offloading crytpo and XML validation functions to dedicated hardware. In this role, the XML firewall performs security services such as authentication, authorization, auditing (AAA) and XML validation at a message level. Features such as message routing, encryption and forwarding to diverse systems are commonplace. These features do not act as transport-level connection security like SSL. The features are a separation of message-level security from transport-level security.
A good example of message-level security exists with PGP-encrypted e-mail. The actual network transport need not be encrypted to ensure message security. The mail can be sent using a non-secure transport over a hostile channel, because the body of the message is encrypted for confidentiality. A message hash ensures integrity and the digital signature provides identification and authentication (even non-repudiation functions). Web services and XML security is similar in that a variety of non-secure transport methods (FTP, HTTP, SMTP, NFS and others) can be used without compromising security, because the message itself is secure.
XML firewalls generally protect Web services while residing in the DMZ between the hostile Internet and protected services. It is from this location they provide security policy enforcement for Web services and XML messages. To enforce security policy, the XML firewall validates message source, reads and modifies message headers, inspects the message content and validates message elements/attributes to enforce fine-grained security policies. Just as traditional firewalls protect the private IP addresses and ports from hackers, the XML firewall protects the Web service listener, XML parser and Web service application from a variety of attacks.
One such attack that traditional firewalls offer no protection against is an XML message-based denial-of-service attack. The attack involves sending extremely large messages or overflowing values of message fields. A malicious user can exhaust XML parser resources and thereby create a denial of service (DoS) condition. It is also possible to launch SQL injection attacks against Web services by inserting SQL commands into the XML messages.
The XML firewall counters these threats by intercepting the XML messages and inspecting them before they get forwarded to the Web service applications. This is done with a high performance parsing engine that applies a message security policy, as well as heuristics that learn the characteristics of messages common to the Web service application. For example, if a Web service application receives messages no greater than 100 KB in size for a period of time and suddenly a 900 KB message is received, the XML firewall can take a variety of admin-prescribed actions, including dropping the message and alerting the admin.
Keeping tabs on message volume and time-to-parse statistics can also thwart denial of service attacks. If the volume and statistics increase, an alert can be triggered or the XML firewall can throttle processing to protect the Web service application. The XML firewall also can scan SOAP message attachments for hostile payloads and executables before they reach the private network and Web service applications. By stripping binary data and other indicators of executable code, the XML firewall is able to stop a variety of payload attacks.
Perhaps the greatest benefit of the XML firewall exists in the ability to manage Web service policy from a single point of control. Doing it at the application level for each Web service can be time consuming, and the cost of implementation and maintenance is high -- not to mention the risks of errors and omissions in the configuration. And with the already high overhead of processing XML messages on the application server, it's impractical to try to take care of XML security server side.
XML firewall technology is maturing fast, and many players are already in the game. Here are a few products on the market worth mentioning:
- Sarvega's XPE 2000
- Forum Systems' XWall
- DataPower's XS40 XML Security Gateway
- Westbridge Technology's XML Message Server
- Vordel's VordelSecure
- Reactivity's Reactivity XML Firewall
XML firewalls are no longer a curiosity. Anyone serious about securing Web services and XML messages needs to consider this new breed of security appliance. The old packet filter firewall just doesn't cut it.
About the author
George Wrenn, CISSP, is a technical editor for Information Security magazine, a graduate fellow at the Massachusetts Institute of Technology and a director of security at a financial services firm.