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.
![]() | ![]() | ![]() | ![]() | ![]() | 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. Chris Haddad,
director of technical architecture, Burton
Group |
| ![]() | ![]() | ![]() | ![]() | ![]() |
| ![]() |
![]() |
Talk about the evolution of SOA deployments. What stage are many
enterprises in and where does security fit into the picture?
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.
Why can't Web services threats be mitigated though traditional
security?
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.