SOAP/XML Firewalls

Web services are already a reality for many organizations and are just around the corner for most of the rest of us. Web services rely heavily on Simple Object Access Protocol (SOAP) and XML technologies to tie heterogeneous business systems together. (For an overview of Web services, see the sidebar "The Promise of Web Services," page 36.) However, SOAP and XML expose a new attack surface to your organization that could potentially let intruders penetrate to the core of your crucial business systems. Packet-level firewalls can't help you secure Web services traffic because they can't detect SOAP and XML traffic. For example, because SOAP typically uses HTTP or SMTP, it easily passes through traditional firewalls—a phenomenon known as the port 80 problem.

So, just when you thought firewalls had matured and you could move on to other security concerns, a new kind of firewall has appeared: the SOAP/XML firewall. Let's explore this new segment of the firewall market and its key players.

XML and SOAP
Before I explain what a SOAP/XML firewall is, let's talk about what XML and SOAP are. Like HTML, XML is a markup language that provides a platform-independent standard for exchanging information between systems on the intranet and Internet. XML differs from HTML, however. HTML is static: It provides a finite set of ways to structure text information. When new needs arise, the HTML standard must be updated to accommodate them. In contrast, XML is a more abstract markup language that provides built-in extensibility through a schema that you define.

XML provides a way to format or structure data and commands or transaction requests. Two applications that support the same XML schema can easily exchange data and request transactions. But although XML lets you assemble a message, it doesn't address getting the message from the client to the server and back again. That task is the job of a protocol—SOAP, in the case of Web services.

SOAP gives applications a way to send XML-based messages over a network within HTTP or SMTP. When one application needs another application's services, the first application formats a service request (i.e., a function name and parameters) into XML, then packages the request in a SOAP envelope and sends it. The target application opens the envelope, executes the request, then uses SOAP to return a response. Environments such as Windows .NET Framework let the application developer work at a high level of abstraction, but the Framework still relies heavily on SOAP and XML, so related security concerns still come into play.

SOAP/XML Risks
Because of XML's platform-independent nature and its ability to let disparate systems interface easily, most Web services use well-known XML schemas and consequently are vulnerable to a much broader variety of potential attacks than are narrower technologies such as Distributed COM (DCOM) and EDI. As a result, you face a greater likelihood of people sniffing the data, nonauthenticated clients directly connecting to and trying to retrieve data from your Web services server, and Denial of Service (DoS) attacks that use malformed messages to exploit a well-known schema. Web services that expose the functionality of core applications (e.g., SAP R/3) and organizations that implement Web services without taking care to secure them expose their soft underbelly to the world. You might even have Web services active in your network and not know it—for example, SAP R/3, which covers everything from purchasing and financials to human resources (HR), natively supports more than 2000 SOAP/XML interfaces.

Traditional firewalls, which look at the world in terms of IP addresses, ports, and protocols, address risks that occur at a much lower level than the level at which SOAP and XML reside. Instead of determining whether to pass a given packet to the internal network, SOAP/XML firewalls validate traffic in terms of Web services, individual messages, and data elements and evaluate whether to let a given requester access a specific operation. XML-embedded malware, such as worms, Trojan horses, and DoS attacks, are risks with SOAP and XML.

Securing SOAP/XML
You can address SOAP/XML security concerns three ways. First, if your use of SOAP/XML is light and limited to a stable set of partners, you might be able to get by with a classic firewall. However, the vendor must enhance the firewall so that it can at least recognize SOAP within HTTP and other protocols. You can then enable SOAP and XML content between your organization and its trusted business partners and block everything else.

Vendors of traditional firewalls are starting to recognize their products' shortcomings with regard to SOAP and XML. For example, about a year ago, Check Point Software Technologies announced support for SOAP/XML security in its FireWall-1 product. A longtime heavyweight in the classic firewall market, FireWall-1 can now recognize SOAP messages and XML content and block SOAP messages based on criteria such as source and destination. FireWall-1 lets you enable access on a Web-service—by—Web-service basis and can validate XML content against a schema that you specify, helping FireWall-1 trap suspicious SOAP messages and potential DoS attacks before they reach your Web service.

A second option for SOAP/XML firewalls is to build your own. Although probably not an appealing alternative for most organizations, building your own firewall is possible, and tools exist to help you do the job. For example, Microsoft Internet Security and Acceleration (ISA) Server 2000 lets you write Internet Server API (ISAPI) filters on an ISA server, and Microsoft provides a model ISAPI filter for validating SOAP/XML messages while they're at the ISA server. (To learn more about Microsoft's model ISAPI filter, go to http://www.microsoft.com/isaserver and select Ensuring trusted Web services.)

The third, and usually best, option is an application-level firewall that operates behind your classic firewall to validate only SOAP/XML traffic. Similar to a proxy, this type of product receives the Web service message as though the application-level firewall were actually the Web service. These products inspect the message; authenticate the person, program, or organization that sent it; then verify that the sender is authorized to the Web service and the requested operation. Authentication can use a simple username and password, a certificate, or a federated system that uses Security Assertion Markup Language (SAML).

An application-level firewall can authenticate credentials against sources such as a Lightweight Directory Access Protocol (LDAP) directory (e.g., Active Directory—AD) or a Remote Authentication Dial-In User Service (RADIUS) server. Then, the firewall checks the requested Web service and operation and the data elements (i.e., parameters) within the message to make sure the request is valid and authorized for the user. Either before or after authentication, depending on the product, the firewall weeds out malformed messages and DoS attacks by ensuring that the request's format complies with the corresponding schema. The firewall forwards messages that pass these checks to the appropriate Web service.

Most SOAP/XML firewalls also provide some type of audit functionality and logging so that you can monitor what's happening with your Web services. Because encryption and XML parsing are CPU-intensive, this more complex proxy architecture is important to implementing SOAP/XML firewalls in high-security and high-volume Web service scenarios. Because SOAP/XML supports security at the transport level, a SOAP/XML firewall can use Secure Sockets Layer (SSL) and Transport Layer Security (TLS) to encrypt the entire HTTP-based message stream.

But sometimes you need to be able to encrypt or digitally sign portions of an XML document—to facilitate multiparty transactions, for example. The XML Encryption and XML Signature security standards meet these intradocument cryptography needs. Because a SOAP/XML firewall functions as a proxy Web service, all authentication, encryption, and decryption take place at the firewall, letting you centrally and consistently control authentication, encryption, and policy checks even if Web services are scattered on servers throughout your network. Another advantage is that, because only decrypted traffic can be inspected, encrypted content is decrypted at the firewall and compared against the firewall's policy.

Firewall Implementations
Vendors can implement SOAP/XML firewalls either as an appliance or through server-side software on the Web server. Both approaches have trade-offs. Because appliances are designed and optimized for one purpose, they usually offer better throughput. Appliances such as Westbridge Technology's Westbridge XA2500 Security and Management Appliance and DataPower Technology's XS40 XML Security Gateway promise wire-speed processing of traffic and better reliability than server-side software. The Reactivity XML Firewall acts as a proxy that you deploy in the demilitarized zone (DMZ). Forum Systems' Forum Sentry 1500 appliance supports several deployment modes, including a nonintrusive inline mode in which the appliance functions as a network bridge with transparent TCP/IP packet forwarding.

Server-side solutions usually have a cheaper initial entry point, but as your Web services grow, maintaining consistent security standards and policies across all servers becomes increasingly difficult. Westbridge offers its XML Message Server (XMS) product both as server software that you can co-locate on the server that hosts your Web service and in the company's XA2500 Security and Management Appliance. Quadrasis's Quadrasis/Xtradyne SOAP Content Inspector is an application-layer security gateway whose strong suit is support for SAML. Flamenco Networks' Flamenco WSM is a Web services management and firewall solution that consists of a controller and multiple proxies and is available as a managed service as well as licensed software. An interesting variation on a software-based SOAP/XML firewall is Vordel's VordelSecure 2.0, which you can deploy either as a standalone firewall on a Windows, Sun Microsystems' Solaris, or Linux server or by deploying agents on firewalls and Web servers throughout your organization.

For large implementations, appliances are less costly to maintain and give you better manageability by providing a centralized view of your Web services network and its policies and activity. However, appliances must support all the standards and technologies that your combined Web services require. When you shop for a SOAP/XML firewall, whether it's implemented as an appliance or as software, be sure you evaluate standards support. You should familiarize yourself with the current and emerging standards in the Web services sector and identify those that your organization is most likely to need. Before you buy, make sure the product that you want supports those technologies. Table 1 lists common Web services standards.

Getting Ready
Sooner or later, Web services are coming your way, and you need to prepare your security infrastructure for their arrival. When you're ready to get a SOAP/XML firewall, you'll find the market crowded with a variety of offerings. As you sift through them, look for strong standards compliance and support for the Web services technologies that your organization uses (e.g., Framework, IBM's WebSphere platform, BEA Systems' BEA WebLogic Server) as well as support for management tools you use (e.g., IBM Tivoli, Microsoft Operations Manager—MOM). Finally, make sure the product you're considering provides the scalability you need.