Web Services: Careful, It’s a Circus Out There...
A SERVICE TO SECURITY
- Web services blur the boundaries between network and software functionality
and data by making access dynamic.
- As a result, access control becomes far more complex as applications are
exposed as services over a network.
- For most companies, offering sensitive Web services in high volumes is
still over the horizon.
Over the past year, Northern Trust took its first steps toward building a service-oriented
architecture. According to Audra Lind, a vice president with the corporate operations
and technology unit, the goal was to develop a framework that would ultimately
make it faster and cheaper for developers to build new applications, such as
providing composite data views to traders. “It will open the doors for
sharing and reusing across different lines of business,” she said.
Although Northern Trust’s SOA project, currently covering investment
and cash transfer systems, is confined behind the firewall, security is a paramount
concern. The firm’s first goal was to develop a single sign-on system
so that users could work with data from multiple systems without having to enter
multiple passwords. The enterprise manages end-user roles using an identity
management system from Oblix (recently acquired by Oracle) and AmberPoint, a
system that brokers Web services requests for authentication and authorization.
Identity management and access control are only the first steps in securing
Northern Trust’s SOA infrastructure. “We need to understand security
vulnerabilities so we can position ourselves to communicate internally and externally
over time,” Lind says. “If we open up to the outside world, we want
to make sure that everything is nailed down.” As the next step, the bank
is determining how to secure the endpoints, the parts of the system that dispense
the actual services.
Prior to the advent of Web services, organizations could afford to follow a
tiered approach to security, focusing on authenticating the end user, authorizing
access and maintaining audit trails for back-end systems; anti-virus and similar
protection for desktop clients and Web servers; and intrusion prevention at
the firewall and network devices out on the periphery. The tasks of maintaining
security were often split by tier, with the network admins handling external
protection, and systems or database administrators managing access to the back
end. (See related story, “No
Even as enterprises opened back-end systems to the Internet, access and access
control were relatively simple, static functions. With only a narrowly prescribed
range of tasks supported, Web access shared many of the same access control
disciplines developed with internal systems.
However, Web services blur the boundaries between network and software functionality
and data by making access dynamic. In place of selected discrete functions made
available through a portal, Web services can dynamically interact with other
services or requests originating elsewhere in the network cloud, making interaction
far less predictable. As application functions are exposed as services, multiple
services could proliferate as application processes are deconstructed and recombined.
For instance, in a preliminary tally, SAP counted well over a thousand discrete
services that could be exposed from its core applications. As a result, access
control becomes far more complex as applications are exposed as services over
Web services are designed to operate in the heterogeneous federated environments
that are blossoming across the business world. As a result, Web services requests
and deliveries could pass through multiple intermediaries that may aggregate
or split messages, dictating closer, more nuanced scrutiny of the user’s
identity and the integrity of the message. “You could easily spoof an
identity or service request if you don’t use proper encryption or signature
standards,” warns Christopher Crowhurst, VP and principal architect for
Thomson Learning, the educational unit of Thomson, the financial and publishing
SOAP, the most popular Web service messaging protocol, uses HTTP—which
is designed to pass through firewalls—and that could make Web services
especially vulnerable to exploits that traditional perimeter devices might stop.
XML messages are bulkier than binary code, which invites the possibility of
servers bogging down while parsing the payloads of denial of service attacks.
Another potential channel for attacks are binary attachments to SOAP messages,
which would allow viruses to hitch rides the way they currently do with e-mail.
(See related story, “Web
services not a draw for virus writers, yet.”)
Significantly, the thrust of most Web services security standards to date has
centered on authenticating the requestor, vouching for the integrity of the
message, and providing the headers for specifying security policy. But if you
adopt those standards and build your defenses accordingly, will that provide
Keeping the lid on
These problems are clearly solvable as long as you don’t take a one-size-fits-all
approach. For instance, there are many approaches for encrypting and signing
messages. Secure Sockets Layer (SSL), which is highly familiar from its broad-based
use over the Web, may be relatively easy to implement, but not as efficient
as XML Signature, a newer technology developed specifically for Web services.
The use of public key encryption, which was long considered the gold standard,
has decreased because of its complexity. Regardless of which option is used,
if a system is to process a high volume of Web services transactions, resorting
to an appliance can prevent this resource-intensive process from bringing a
network to its knees.
In many cases, layered defenses may make sense because a single external device
can’t be counted on to check for suspect intrusions plus handle encryption,
inspect the payload and perform policy decisions all in one pass. For instance,
while a firewall checks for general intrusions, encrypted Web services messages
might pass to a second dedicated gateway that would decrypt and authenticate
the message and identity of the sender. In some cases, policy enforcement regarding
what requests, from which entities, are acceptable under which conditions might
be entrusted to yet another layer of software or device. For virus detection,
there are links with anti-virus programs.
There is also the business context to consider, Wagner says. For instance,
if services are exchanged between a known circle of trusted partners, an approach
that validates the sender by organization might be adequate. “The likelihood
of problems increases with the number of endpoints,” Wagner says, referring
to the recent debacle with ChoicePoint, a national provider of personal credit
and financial data, which discovered last fall that the privacy of its 10-billion
record consumer database had been compromised by access from 50 bogus companies.
“If you deal with the unwashed masses, you may have to handle it with
a standard Web session,” Wagner adds. In addition, the volume and complexity
of Web services processed could affect the defensive measures to be employed.
For most companies, offering sensitive Web services in high volumes is still
over the horizon. At Thompson Learning, which is implementing its Web services-based
commerce system with partners, the concerns are payload-based denial of service
attacks and similar threats. Although XML is bulky, even small amounts can wreak
havoc if the transformation instructions embedded inside the schema direct the
system to perform a series of endless conversions that become, in effect, the
equivalent of dividing by zero.
That’s primarily what Thomson Learning is scanning for in an extranet
offering computer-based testing services to commercial training center customers,
for which the company has garnered roughly 18 months of experience. Thomson
is supplementing the usual perimeter measures with specialized XML appliances
from vendors, such as Reactivity, to inspect the contents of every incoming
SOAP message. “At the moment, there aren’t XML viruses, so we’re
primarily looking for something that exploits the SOAP stack, such as entity
expansion or poorly formed schema,” said Thomson Learning’s Crowhurst.
In many cases, security issues are due to the immaturity of Web services technologies,
as best practices and holes in the standards gradually get filled. “Every
iteration of the standards is getting better,” Crowhurst says. For instance,
he points to improvements in the WS-I Basic Profile, which is used for testing
the exchange of messages between systems from multiple vendors. He also singles
out Security Assertion Markup Language (SAML), which specifies how message senders
declare their identities.
“The latest versions are a huge leap forward in dealing with federated
identity,” he says, adding that having such capability is crucial for
offering services commercially in a world where there are always going to be
multiple sources of identity information. “We need standards to develop
trust exchange mechanisms. In a distributed world, you can’t put everybody
in one big global directory.”.
ILLUSTRATION BY PETER FERGUSON
Sidebar: Web services
not a draw for virus writers, yet
More on ADTmag.com:
Congress looks at enterprise ID
Sidebar: No soup-to-nuts
By John K. Waters
Startup puts Web services security
in developers' hands
By John K. Waters
IBM Global Services unveils SOA
By John K. Waters