XML Web services need a firewall

Today, application integration is the single biggest challenge facing IT organizations. With business imperatives driving an increasing need for cross-organization integration, this challenge is getting ever more complex.

XML Web services is a term referring to a set of related standards that enable program-to-program communication. Acceptance of these standards is a key step in changing the economics of executing loosely coupled application integration. As an industry, we need to reduce the time and expense required to enable organizations to work together. Achieving those efficiencies requires the kind of standardization we are currently seeing in the XML Web services initiatives.

IT managers see security as the single biggest obstacle to deploying XML Web services. For example, Business Week  recently reported that a survey of IT managers found that 45.5 percent considered security their single biggest Web services concern.

To address this concern, a new category of infrastructure software is appearing. Sometimes referred to as a network gateway or XML switch, but more frequently described as an XML application firewall, this new class of software is addressing the security and network monitoring needs of emerging XML data networks that firewalls today do not address.

Actually, in some ways "XML application firewall" is a confusing term, as this type of firewall is clearly distinct from existing IP-level network firewalls. In other ways, however, the term is very appropriate. XML application firewalls are like network firewalls in that they are focused on securing and monitoring your network. However, unlike network firewalls, they work at the application level using an in-depth knowledge of the Web services, service requestors, and message content. It is the XML Web services standardization of application-level data that makes application-level firewalls practical. Network firewalls are the key component in the previous generation of security infrastructure. The rationale behind this kind of infrastructure went something like this:

We cannot depend on all our systems being secure. Therefore, let's define a perimeter using network firewalls that hides those systems. In addition, let's set up the following mechanism:

• Define which specific IP addresses are in the perimeter.
• Don't trust anything outside that perimeter,
• Trust only what's inside the perimeter.
• Assume that the ports that are left open to handle specific protocols don't compromise system security too much.

In other words, the typical question that is resolved by a network firewall is: "Should this packet of data going from a sender IP to a specific port at the target IP be allowed to pass through?"

Application-level security raises different questions and requires a different solution. The typical question resolved by an XML application firewall is: "Should this SOAP message, sent with the given confidentiality and non-repudiation protections on the behalf of a service requestor with a given identity (as confirmed by the required authentication authority) be delivered to the target operation of the target Web service?"

The rationale behind the deployment of XML application firewalls goes something like this: "We cannot depend on all our underlying systems being provably secure. Therefore, let's require that all requests for services pass through an XML application firewall that provides defined levels of access to different categories of service requestors while enforcing consistent and auditable security/monitoring practices across multiple business systems."

Organizations are beginning to realize that the old worldview is no longer sufficient. While network firewalls will clearly continue to be central to network designs, they don't address all of today's requirements and realities, which include the following:

• Most security breaches come from within the firewall
• Business imperatives require cross-firewall access and integration
• Ports intended to pass specific protocols are being used for a wide variety of purposes
• XML Web services SOAP messages were specifically designed to easily pass through existing firewalls by being carried over transport protocols (HTTP, SMTP, and so on) that are commonly carried through open firewall ports
• New code written with modern tools (.NET, current J2EE apps servers, and so on) will be the minority of nodes in an XML Web services data network. Legacy applications and packaged applications will be the majority of nodes. Legacy and packaged applications have dramatically varying levels of application security and it is often difficult to verify and manage the security functions they do have.

XML application firewalls are designed to address these requirements, while working with (not replacing) existing network firewall infrastructure.Building application security into the specific application node that implements a given business system has some fundamental limitations. It's hard to:

• Add to legacy code and packaged applications
• Implement and maintain consistent policies across all nodes
• Prove that a given security policy has been implemented

Implementing application security in the network infrastructure addresses these limitations. An XML application firewall is an example of such a network infrastructure.

Initiatives aimed at building application security into the business system node have often included:

• Post-development security reviews of the design and source code
• Training for developers
• Improved development tools

While these initiatives are productive and should be continued, they do not address the full range of requirements. Organizations have generally found it difficult and inefficient to build in security after the fact. The issues are the same as when trying to build in quality after the fact. It is an established principal of software engineering management that the later in the development process a change is made, the more costly the change will be and the more likely that it will have unintended consequences. Therefore, even though an after-the-fact security review is an extremely valuable assessment tool, it does not work as a primary mechanism to achieve application security.

In general, better training and management of developers is extremely valuable. However, this approach does not address the full need. In practice, deployed environments always contain applications that were built under varying development procedures by varying teams at various times. Therefore, better training for the current in-house team does not provide the breadth and consistency of coverage required.

Similarly, capabilities such as encryption libraries and connections to authentication authorities, that are built in to a single development environment or runtime application server are insufficient to meet an organization's full security needs. While those capabilities would then be available to developers writing new code for a given application server or development environment, they do not address legacy or packaged applications that do not use those tools.

Furthermore, simply providing an underlying mechanism isn't enough. It was still being left to the developer to write code that provided the logic that determined for a given combination of operations, service requests, and message content which specific security mechanism should be used.

For example, it's useful to have libraries built in to an application server for producing XML encryption and SSL encryption. However, that is only half the battle. You still need logic that determines whether or not encryption should be used, and, if so, what type of encryption, which key should be used, where to access that key, and so on.While there are compelling reasons to build application security into the network infrastructure, until now that has been unrealistic because the access to those key business systems was not being expressed through a consistent malleable interface. Programmatic interfaces to business systems were expressed through DCOM or CORBA, or through language-specific libraries. Simply the fact that there were multiple interface mechanisms was a barrier.

Beyond that, these mechanisms did not lend themselves to non-invasively providing application security between the requestor and the service. Rather, they assumed a tight coupling, unlike the loosely coupled model of XML Web services, so it was difficult to insert additional functionality into the message stream without modifying one or both of the nodes.

By contrast, XML Web services provide an easily parsable syntax with well-defined schemas and transformation mechanisms that support intermediate value-added services. By contrast, older technologies implemented closed binary formats for their in-transit messages.

The adoption of XML Web services is both dramatically increasing an existing need and creating a new opportunity to address that need. By opening up business systems to much broader programmatic access, both internally and cross-organization, XML Web services are driving the need for highly functional and provably consistent application-level security. However, by providing a standard for loosely coupled program-to-program communication, XML Web services have created the environment that enables the deployment of XML application firewalls as the standard infrastructure that meets this need.

A basic functionality within any XML application firewall is authentication and access control. This includes the ability to:

• Confirm the identity of the entity (person, program, organization) for whom this service is being requested
• Recognize to what level of access that requestor is entitled

The methods used to authenticate an identity may include:

• Checking a username and password with an LDAP directory
• Confirming the identity of a certificate or digital signature with a PKI
• Checking a SAML ticket that was generated by a single-signon tool

Even a single organization will need to use multiple mechanisms. Depending on such factors as:

• The level of security a particular operation requires
• The preferred mechanism of partners and customers
• Standard industry agreements and conventions
• The requirements of a regulatory scheme, such as HIPAA, GLBA, or FISMA
• The desire to leverage existing infrastructure

It's also crucial to ensure the confidentiality, integrity, and non-repudiation of service requests and responses. Organizations want to make sure that this critical data is not read, modified, or faked. Again, there are multiple methods available to accomplish this, including:

• Transport level encryption (such as SSL)
• Message/element level encryption (such as XML Encryption)
• Transport-level certificate-based hand-shaking (such as SSL)
• Message/element level digital signature (such as XML Signature)

As with authentication, a single organization will most likely use multiple mechanisms, depending on which entity is making the request, which service operation is being called, what specific message content is being passed, and other criteria.

Another functionality area for XML application firewalls is protection from malicious attacks, such as password dictionary attacks or denial-of-service attacks. Since XML application firewalls will be used in combination with network firewalls and other existing network infrastructure, they will not need to replicate the protections that are already provided by those tools. However, they will be able to take advantage of their detailed knowledge of the specific profiles of individual operations and requestors to implement protections that cannot be enforced by a network-level infrastructure.

We believe that XML application firewall technologies are the right approach to meet this need, and that they will eventually become as pervasively deployed as network firewalls are today.

Kerry Champion is president of a Westbridge Technology.

Have security concerns held back your company from deploying XML Web services? TalkBack below or e-mail us with your thoughts.