SOA, Web services security gaining priority at large enterprises
All enterprises will have to find tools to secure Web services as Web-based languages, such as extensible markup language (XML) will be gradually introduced into system architectures.
All enterprises will have to find tools to secure Web services as Web-based languages, such as extensible markup language (XML) will be gradually introduced into system architectures.
In a recent interview conducted at the Burton Group Catalyst conference, Chris Haddad, director of technical architecture at Midvale, Utah-based Burton Group discussed the growing use of XML gateway appliances and other tools enterprises are using to secure service interactions. "Developers today have the tools to produce Web services and there are a multitude of unmanaged, unsecured Web services inside an organisation's datacentre and across its application landscape," Haddad said. "Companies are realising that they have to gain control of this environment." In this Q&A, Haddad talks about the evolution of SOA, the introduction of Web services and how early adopters are choosing to secure the Web-based messages being sent between applications and systems.
|
|||||||||||||||||
Chris Haddad: Over the last two years organisations have been in a planning phase. They've been educating themselves about the security threats and the risks that they have to mitigate against. They have been crafting a service oriented security strategy. They're understanding how their technologies could fill the gaps and when they need to purchase new infrastructure and adopt new security protocols. We've seen in the recent months where organisations are moving out of that planning phase and moving into more of a infrastructure selection and deployment phase. They have gone through an RFP phase and are actually purchasing various products to help secure their service message traffic.
What are some of the Web services security products that enterprises are considering and has security been forefront in their minds?
Haddad: Ever since we started to extend the reach of our business systems to partners, clients, and suppliers, security has been foremost because we're exposing our sensitive business assets to the outside world, outside our normal firewall. When you move towards service orientation the hard walls that you built up around your system suddenly disappear. The boundary and perimeter goes away. Organisations have been very concerned about the risks that they might introduce and have put in place additional technology to secure their service interactions such as the introduction of an [extensible markup language] XML gateway, an XML VPN, an XML firewall, into their infrastructure portfolio.
What is the vendor landscape like and what have been some of the early investments?
Haddad: We've seen significant adoption of XML gateway product offerings by enterprises. We've seen that the volume of product shift in that space has exploded dramatically during the early part of this year and will continue. A lot of the product category growth has been driven by acquisition of leading start-up vendors [such as IBM's acquisition of XML networking vendor DataPower in 2005, and Cisco Systems Inc.'s plans to acquire XML gateway vendor Reactivity Inc. for $135 million in cash, announced in February]. That has brought additional marketing and a very well equipped sales channel to sell those product offerings.
What is an XML gateway and why is it important to a company's Web services security strategy?
Haddad: An XML gateway is a hardware appliance that provides hardware assisted acceleration of encryption and digital signing capabilities. These are very expensive operations that can be offloaded from your service platform to a dedicated device. XML gateways serve as central choke points where they monitor, control and secure Web service traffic and can apply security services to that traffic such as authentication, authorisation, encryption, signature processing, credential mapping, message scanning, and protection from denial of service attacks. These are very full featured, rich devices that are heavily focused on security. In addition to that, they have many other value-add capabilities such as service monitoring, provisioning of policies among clients and services, and they provide a central place to control your security posture through definition of policies in these systems that are then distributed across your endpoints as declarative policies that are enforced throughout your environment.
|
||||
Haddad: We're looking to mitigate these attacks inside the network application platform itself. We're looking to intercept the messages before they reach our application services and inspect these messages at a level above the traditional network technologies. Rather than just having a firewall in place that understands how to prevent denial of service attacks, we're looking to inspect the XML message itself to understand the intent of the message.
Are companies beginning to deploy the WS-Security OASIS standard?
Haddad: Companies are just now adopting WS-Security as a mainstream way of doing business. It's been very difficult for organisations to adopt WS-Security in the past because the tooling to implement the specification had been fairly immature. You had to be a rocket scientist to connect up a .NET service client with a J2EE service using the specification. The introduction of Web services security products such as XML gateways and XML VPNs has enabled teams to implement the specification in a more easy manner.
What is the difference between WS-Security and SSL and are they good enough protocols for securing message traffic?
Haddad: SSL stands for secure socket layer and it's a way to encrypt message traffic between a client and a service. The encryption happens at the network layer and it's only good between a particular client and a particular server. It builds a very tight connection between the two. If the message is taken off the wire or routed to another service provider, the security context disappears. Protocols such as WS-Security enable the security context to span across multiple intermediaries who can inspect the message and might be routing and passing the message along. That's where providing a level above the network enables you to keep the encryption I place even when the message is taken off of the wire.
