|
XML and Web Services: Are We Secure Yet?
Once just a gleam in an architect's eye, Web services have become more secure than ever, thanks to standards
by Mark O'Neill
July 20, 2004
Eighteen months ago "Web services security" was still seen as an oxymoron. One of the principal reasons was that "Web services" was still largely understood as meaning "services on the Web." A CFO overhearing a suggestion that the corporate accounting system be exposed as a Web service may have hit the roof, imagining teenagers accessing accounting data from their bedroom PCs. A CSO overhearing the same suggestion may have experienced a pain in the pit of her stomach and asked her firewall administrator to investigate. The firewall administrator would have quickly realized that Web services almost always involve XML traffic masquerading as Web-browsing traffic, and imagined this to be part of a grand plot to bypass his carefully controlled perimeter security policies. Back then, secure Web services seemed a long way off.
But then a funny thing happened—Web services started to be rolled out anyway. How can this be? There are two reasons. The first reason is that many Web services are deployed internally, without a publicly facing attack surface. The second reason is that when engineers and architects looked closely at the Web services they were developing, they realized that they could take practical measures to make them secure. Best practices have started to emerge. Vendors such as my employer, Vordel, have been implementing them in their products and solutions. Let's examine these best practices.
We start by taking a step back and looking at what being "secure" means (see Figure 1). What does it mean to say that an individual XML message is "secure"? If the XML message comes from a trusted source, does that mean that it is "secure"? But what about Web services that are designed to be publicly available, with no authentication at all; is security relevant for such Web services? The answer to these questions involves the application of well-established security concepts to Web services. We will look at how three established security concepts—CIA security, AAA security, and message-level content analysis—and apply all three concepts apply to Web services.
The Tenets of CIA Security
CIA security stands for confidentiality, integrity, and availability. The first two of the three CIA requirements—confidentiality and integrity—are most often achieved using cryptography. XML Encryption and XML Signature are mature standards that provide, respectively, confidentiality and integrity for XML documents.
The WS-Security standard, ratified by OASIS in April 2004, describes how these two XML security standards apply to SOAP messages, so that part of a SOAP message can be encrypted, or digitally signed, which allows end-to-end confidentiality and integrity across SOAP intermediaries. End-to-end security is especially important in privacy-sensitive applications, such as in the health care field. It is becoming best-practice to encrypt those parts of an XML document that contain personal information, while allowing the rest of the SOAP message to be available to routing and business logic. WS-Security, XML Encryption, and XML Signature are implemented by the WebSphere SDK, which is described by IBM as "an on-ramp to Web services for Java programmers."
WS-Policy is a specification that allows a Web service to indicate to a client which parts of a message must be signed and which parts must be encrypted, as well as which keys to use for encryption and signing. BEA WebLogic Workshop implements something similar, though not identical, to WS-Policy, called a "WS-Security Policy File." It allows a developer to specify encryption, signature, and security token policies for SOAP messages entering and leaving the BEA WebLogic application server.
WS-SecureConversation is another useful specification—it allows a session to be created between a Web service requester and a Web service, using symmetric keys. WS-SecureConversation is analogous to SSL, which also involves the negotiation of a symmetric key to streamline encrypted message transfer. WS-SecureConversation is available in Microsoft's WSE 2.0 toolkit, but no Java implementation is available at present.
Availability is the CIA requirement that is most often overlooked. Availability includes protection from flooding attacks, as well as protection from attacks that bring down the system on which the Web service depends. It is not very clever to concentrate on shoring up the XML interfaces to an application and then discover that the application has been brought down by an attack against the operating system on which it depends. Therefore, patch management, combined with a full understanding of the dependencies of a Web service, is crucial.
Back to top
|