to LooselyCoupled.com homepage
 
 Weekly emails: how to advanced search
 Glossary lookup:

 

> stories > platform choice


No single path to web services security

by David Longworth
April 7th, 2003

Web services tunnel straight through conventional network defences, using a port on the network firewall left open for web traffic.

 
• print  • comment
Web services require a new layer of security that companies don't have at the moment. Getting it right takes more than just putting in an XML firewall:
  • Web services bypass conventional firewalls
  • Security software must examine the contents of web services messages
  • It's often best to distribute security throughout the application infrastructure
  • Integration with existing measures is essential
  • Standards and best practices are still being defined


Glossary terms: firewall, SAML, WS-Security, SSL, PKI, lookup tool

It's easy to see why information security professionals feel horridly exposed. But battening down the hatches is simply not an option at most companies. One security chief at a large insurance company decided the best approach was simply to bar any messages in XML format from passing through the firewall at all. Nice idea, but soon there was open rebellion, as developers told him they could not do their jobs under such restrictions.

In-house developers are not the only source of problematic web services traffic. Most enterprise applications either have or will soon have native XML interfaces; integration projects increasingly make web service calls to save time and money; and even the next version of the ubiquitous Excel spreadsheet program will allow you to call a web service, potentially blowing a hole in the company's architecture right through to the desktop.

"It's going to start getting messy and that's why a lot of security officers are worried about web services," says Andy Yang, senior director of marketing and product management at XML security vendor Westbridge Technology.

Companies had initially assumed their current security infrastructure would be adequate — firewalls at the perimeters; secure transaction technologies such as SSL for web sessions; and PKI or a virtual private network (VPN) in circumstances that need greater confidentiality. They are now coming to a realize that an extra layer of security or management is required, and most begin by putting in an XML firewall.

Content inspection
Whereas conventional firewalls police traffic at a protocol level, XML firewalls operate at the application layer. They inspect the header contents of XML messages, and based on what they find — together with the context in which the message was received — they determine what level of access, if any, is granted. By inspecting web services traffic as it passes between different systems, they bring it back into line with the traditional goals of 3A security — authentication, authorization and accountability.

But not everyone feels that a firewall is the right solution, pointing out that having a single "choke point" or point of failure is itself a security risk. They argue that it's often better to examine the XML messages when they reach the application, rather than at a separate gateway device located elsewhere.

"The firewall is one way of looking at it," says Mark O'Neill, CTO of web services security vendor Vordel. "And we do get RFPs for XML gateways. But we also see people who want something they can plug into an application, rather than a piece of infrastructure they route messages through. We look at it with application glasses on."

Anjan Mitra, security product manager at web services management vendor Amberpoint, uses the analogy of a house: "There are different rooms within the house. Some security applications will just have a firewall at the front door — you need some level of security at the front door — but you also need some at closets and safes." Amberpoint provides that capability by embedding security functions in each component of its platform.

The variety of options on offer means there are usually several different ways of fulfilling security requirements in a web services application — but none of them with enough of a track record to easily judge which represents the least overall risk. The picture is further complicated by the need to integrate with existing security systems.

Collaborative approaches
"There's a lot of security in companies already," says Westbridge's Yang. "And if it already works, you shouldn't throw it away. We're not taking existing network security and saying rewrite everything. What we really do is, we say use web services for more forward-looking projects. There are opportunities to figure out how to implement and deploy service-oriented architectures, and the lowest-cost way is using XML application level security."


Security challenges
Vordel CTO Mark O'Neill is author of the book Web Services Security, published earlier this year. "One of the things I've tried to bring across in the book is that it's not introducing disastrous security risks," he says. "It's more about challenges to your security architecture." Examples cited in the book include:
  • A government portal that uses a SAML assertion to pass on user authentication and access rights to the web service, so users never directly access the back-end. Integration with firewalls and routers ensure that the services themselves remain in a private subnet.
  • A merchant bank's foreign exchange facility that adds XML signature validation as a further measure to confirm the trustworthiness of the SAML assertion. Traditional SSL over HTTP is used to transport the message.
  • Implementation of a distributed XML gateway coupled with access control using WS-Security and SAML. Administrators use a security management tool to set security policies for different traffic on a per-service basis.

 
Westbridge claims savings in some projects of up to 30% by leveraging the existing security environment, such as making an LDAP user name and password system talk to a PKI system based on industry-standard X.509 digital certificates. "The whole point is connecting together different things," says Yang.

In Vordel's case, that often means being called in as one of several partners in a joint solution. O'Neill gives the example of a large bank in the UK, where Vordel is being asked to work with RSA and its already installed 3A product. "In that situation, no one wants to re-key user profiles into a new product. So we have to connect to it."

One important characteristic to look out for when purchasing XML application security, then, is just how easily integrated your chosen solution is. It is no use having a top-notch XML firewall in place if, for example, it cannot pass message alerts to your existing network firewall. Equally, the XML products must be able to accept input from other security products, so you have an end-to-end solution, rather than encrypting and decrypting at each "hop".

"Any kind of security or management solution has to be brought into the environment gracefully, without needing any control over partners' web services," says Amberpoint's Mitra. The company's management platform uses distributed agents — which are themselves web services — to manage security. Security officers are then able to configure agents to fit with their security policy. This enables a security context to be given to all management actions, such as logging, encryption and validation (the platform also provides instrumentation, monitoring and reporting).

Security goals
Another key factor to look for is standards support, an essential ingredient when linking up with other parts of the security infrastructure. These include well-established, low-level standards for digital signatures and encryption, as well as SAML, which provides a standard for authentication and authorization. But others higher up the stack are less universally accepted. For example, there are two overlapping messaging reliability standards, one proposed by OASIS and the other by Microsoft and IBM. Nor is existing infrastructure guaranteed to be up-to-date with the latest XML standards.

Whether companies are introducing web services security in a co-ordinated fashion by introducing a management product for their move to a service-oriented architecture, or in a more piecemeal approach, security goals are same as they have always been. But the lack of an established canon of best practice and continued vendor jockeying over higher-level standards means there's no clear agreement on the best way of achieving those goals. Although the technology exists to put in place a satisfactory security infrastructure for web services, this is an area where, for the moment, customers have to rely on their own judgement to select the approach that best meets their needs.


More on this topic


Related

Trusting web services
Security and reliability are overlapping but distinct concepts ...

Inside the citadel
Adding XML and SOAP security to firewalls ...

Security breeds complacency
Participating in a big, digital network ...


Background

WS-I Charters Basic Security Profile Working Group
Press release on the formation of a group to tackle interoperability in web services security.

Web Services Security TC
Home page of the OASIS technical committee (TC) in charge of WS-Security.

Vendors
AmberPoint, Vordel, Westbridge Technology


Books

Web Services Security
by Mark O'Neill Timely introduction to web services security and emerging standards, with advice and examples of implementation strategies. (312 pages, Jan 2003, McGraw-Hill Osborne Media)


 
 


Copyright © 2002-2006, Procullux Media Ltd. All Rights Reserved.