The good news about XML and Web services is that they're easier than ever to develop and deploy - inside the firewall between internal applications, on the Internet with your customers and partners...anywhere.

The superb new development tools from companies like Microsoft, BEA, IBM, and others, combined with the simplicity and openness of the standards, are providing real dividends to enterprises today. The examples are numerous: financial services companies outsourcing employee compensation, high-tech manufacturers integrating their supply chains, and global banks integrating their trading systems with partners, just to name a few.

But the bad news about XML and Web services is this: because they're so much easier to develop and deploy and for your customers and partners to connect to, it's that much easier (1) for your customers and partners to connect to them in ways you don't like, and (2) for everyone else to connect to them in ways you really don't like. With your critical systems exposed on the Internet, there are many new ways they can be vulnerable to any number of new threats (see Figure 1).

What's exhibiting itself here is an age-old tension between ease-of-integration concerns and security concerns. In general, the easier you make it to integrate your systems, the harder it is to secure them, and vice versa.

As an example, consider e-mail. E-mail was originally designed for ultimate interoperability, and has evolved to be able to work on any system, regardless of technology. It uses plain, unencrypted text (or sometimes simple HTML) and very little in the way of security techniques. Efforts to make e-mail infrastructure more secure (like digital signatures) have largely failed because they broke the interoperability aspect of the system. As a result, e-mail has become the single most exploited entry mechanism for malicious attacks on individual and enterprise systems, with the Sobig and Blaster attacks this summer and the NIMDA and the Code Red viruses in the recent past causing significant personal and professional disruption.

At the opposite end of the spectrum, think about a technology like public key infrastructure (PKI). Designed first and foremost to provide strong cryptography for a variety of security concerns, PKI has proven extremely difficult to use in practice - in particular, in getting different systems to interoperate with each other and managing distributed certificates. It's the opposite of e-mail: very secure, but not very easy to use or maintain.

So what can you do? Integration concerns are of primary importance; and speed of integration is becoming more important every day. But privacy and security remain key. Understanding the specific tensions between integration and security provides some insight into solutions along four key areas of tension: verbosity, time, metadataa, and standards.

Verbosity
Verbosity refers to the amount of information that systems share with each other; in particular, the amount and type of information they share with each other in error conditions. For example, consider Web site log-on where a user enters the correct username but an incorrect password. The Web site could respond in many different ways. It could simply say "Incorrect Login," which doesn't differentiate between a problem with the username or password, and conveys nothing about how to log in correctly. On the other end of the spectrum, it could respond with something like "Incorrect Password." In that case, the user gets a little information about how to make the system work (fix the password), but it is a little bit less secure because it confirms that the username is a valid one.

In the Web services version of this scenario, you'd like very verbose error messages when you're integrating two systems with WSDLs and SOAP to be able to ascertain what's happening and fine-tune the system. Once in production, however, it's best to reduce the amount of information returned to failed responses so that hackers are not inadvertently given information they could use against the service.

A good, crisp example in today's development tools can be found in Microsoft's Studio.NET. For each service, you can set a flag called "IncludeStackTrace" so that when errors occur in the response message, it will also include detailed information about why the error happened. For development, this makes a lot of sense, but for actual deployment, security is best served by disabling this flag.

Time
Time creates another tension between interoperability and security - specifically, the rate of change of systems. For ease of integration, developers endeavor to put programming interfaces in place (described by WSDLs, in the case of Web services) that rarely or never change because the more you change the interfaces, the more the consumers of your services will need to change their own code.

On the other hand, for security, you have to assume a state of constant change for a number of reasons. Most obviously, you want to do things like change passwords, certificates, and the like periodically in order to reduce the risk of attacks that may compromise the system. More acutely, you need to monitor and constantly update patches at all levels of your system to fill security holes. As the waves of Code Red attacks show, vulnerabilities may persist long after solutions are made available when organizations are not diligent about patches and updates. To reconcile these competing needs, enterprises must carefully weigh the impact of each change made for additional risk prevention versus the amount of business disruption it may cause.

Metadata
The concept of metadata is central to making XML and Web services work. WSDLs, XML Schemas, and UDDI are all systems for providing data about the data in Web services systems. XML draws on a long heritage of SGML (the Standard Generalized Markup Language), and as the name implies, SGML is a very generic way to describe syntax and markup languages. As a result, XML contains a wide variety of mechanisms for metadata or ways to describe the data contained in the document.

One example is how XML documents can specify what schema they should conform to. For instance, a purchase order might have information embedded in its XML message indicating that it is a certain type of purchase order which is defined by a schema file on a different server. At a more fine-grained level, XML allows documents to define entities in terms of other entities in the document, and even allows recursive definitions (defining terms in relation to themselves).

For the purposes of easy integration, this is a fabulously powerful idea - messages that you've never seen before can describe to your system exactly how to interpret and use them. For security, though, self-description poses a problem: what and who to trust? Letting messages determine their own schema is a little bit like allowing automobile drivers to define what they consider would be an appropriate driving test, practical exam, and license. It's pretty good for having lots of people drive, but not such a good idea for safe and secure roadways.

In order to implement a secure system, architects must be a bit more prescriptive about what messages are allowed to look like, and take self-description with a grain of salt. The standards bodies are starting to catch up here, too: the WS-I (a Web services interoperability body), for example, has started by disallowing entity definitions as well as doc type and processing instructions. For security devices dealing with Web services, architects must be even more prescriptive, disallowing documents that point to their own schemas, and instead applying what are known to be appropriate and valid schemas, irrespective of what messages point to.

Standards
Standards are the key point of Web services: by having simple, standard ways for applications to interact with each other, whole new worlds of application integration open up. Systems are easier to understand, they're more predictable, and they are a lot easier to get to work well with each other.

But establishing standard ways of integrating systems also means there are standard ways of attacking systems. Because the interfaces are so open, structured, and well defined, it's easier than ever to build hacks that exploit standard vulnerabilities. A Web-based version of this is the so-called script kiddies, the Web's version of a pack of wild dogs. Increasingly, tools are available for download on the Web by relative novices, enabling them to look for standard vulnerabilities that have yet to be patched and attack these Web sites in standard ways. The tools are, unfortunately, so simple that it doesn't take more than a few minutes for first timers to get started. We expect Web services to be targeted in much the same way.

The best way to address the tension on standards is to put tools and practices in place that let you stay current with the industry's best countermeasures and enforce the security policies of your organization.

How to Cope
The bottom line is this: you want to be able to build systems that are easy to integrate when you're setting them up, but act in an extremely secure manner when they are running over time. The only real way to do that is to consider both integration and security concerns from the beginning, and abstract their implementation and management from development efforts.

A proven successful strategy for balancing integration and security is to introduce the new breed of XML firewalls into your organization. XML firewalls act as the Internet-facing gateway to all your Web services, and take care of many of the security tasks that are tedious or impractical for application developers to implement. By moving the responsibility for some of the security tasks to a device at the edge of the network, the XML firewall can catch problematic messages before they're inside your network, and deal with them before they can do any damage.

XML firewalls can provide robust integration and interoperability points. There are several XML firewall products on the market - one example is the Reactivity XML Firewall, which maximizes interoperability of XML Web services while providing robust and dynamic security policy management (see Figure 2). Using an XML firewall, security architects and business managers can define the level of security enforcement they need to protect the enterprise and also meet their business requirements.

Conclusion
At many levels, the interests of ease of integration and security will always compete - there are simply too many divergent concerns. As a practical matter, though, technologies such as XML firewalls can provide a way for businesses to develop applications that have both ease of integration and best-of-class security designed in from the start.