I ask Jay if he recalls an aftershave commercial from a few years back where a man gets
a crisp slap on the face but responds by saying, “Thanks, I needed that!” I tell him
that’s how I feel whenever the subject of SOA security comes up. It’s a slap of cold,
hard reality that wakes us up to the kinds of serious challenges we have to overcome to
fulfill the vision of the SOA. Indeed, from this point on the book deals with the pragmatic
but crucial considerations brought on by developing and implementing an SOA
in real life. Yet, we should welcome the slap on the face. We need to know what stands
in our way. So now that we have spent eight chapters building up the SOA, we have to
look at a very real and troubling issue that has the potential to be a “showstopper” for
the entire trend: security.
Although the IT community is embracing service-oriented architecture because of
its promise of efficiency and improved IT management, security problems are causing
many to proceed slowly, or not at all, with SOA implementations. Security has always
been a concern for IT managers at large companies. Major systems have typically
been designed to protect against unauthorized use, intrusion, and viruses. Today,
however, the issue has taken on even more seriousness in the wake of terrorist attacks
and global viruses.
While SOA security concerns abound, virtually all IT managers are realizing that
they must soon identify and implement security solutions for SOAs because their
developers are exposing applications as web services using the new generation of development
tools. A pressing need exists, therefore, to solve the security risks in the SOA.
RISKS OF LOOSE COUPLING
The SOA’s inherent security problems stem from the ways in which the SOA replaces
traditional security parameters with new, open standards. The security problem is
twofold in that not only are the new standards completely open-no one owns
them-but they were also developed without security in mind. Web services were
developed over a period of years by industry consensus as a way to, among other
things, enable the creation of reusable code, simplify development, and streamline
system integration. While these goals were met, the open standards that emerged have
not yet fully addressed security. Specifically, XML, SOAP, WSDL, and UDDI are open
standards that enable the transmission and description of data and procedure calls
between systems. However, none of these open standards contain any inherent security
aspects of their own. If left alone, they are completely nonsecure. In fact, web services
were designed to be able move efficiently through firewalls. This very loose
coupling actually decreases their usability in this regard. In the past, a company’s own
employees could hardly access needed data, let alone the “bad guys.” Now, with open
standards, any 12-year-old with an Internet connection can access openly exposed
transactions as readily as your authorized personnel.
To illustrate the security problems inherent in SOAs, let’s look at the example of
a supply-chain management process that involves a manufacturer and three vendors.
Figure 9.1 represents the traditional B2B security environment. Each trading partner
communicates with the manufacturer using a private network. Encryption may be
used, but the manufacturer and vendor can both be fairly confident that their communication
is private. Authentication (the user is who he says he is) is coded into the
application, so the manufacturer can be relatively confident that Vendor A is actually
Vendor A. Authorization (the user is allowed to use the system) is coded into the
applications themselves as well as being handled by the security infrastructure of the
entity originating the transmission.
Though secure, this traditional setup is costly and complex to maintain. Modifications
to the manufacturer’s application will automatically require custom revisions
to the vendor’s application or else they will not be able to communicate. Flexibility
in extending the functionality of these connected applications is limited to the
amount of custom interface development that each trading partner wants to finance.
If the manufacturer and its vendors decide to expose their applications as web services
in an SOA, depicted in figure 2, they benefit from greatly increased flexibility
Figure 1 Traditional security arrangements in an architecture that
connects a manufacturer and its suppliers might involve a separate
firewall and proprietary security interface for each system.
but face security risks. Applications developed in this environment have numerous
potential functional advantages over the traditional model, including “pulling” order
data out of the system based on anticipated demand. Unfortunately, however, the
SOA shown in figure 2 also contains a variety of security risks. Let’s look at each of
these risks in turn.
Machine to machine
To get a good grasp of SOA security issues, it important to understand that most security
infrastructure is geared to human-to-machine interactions while web services
involve scalable machine-to-machine interaction. Until recently, the majority of
attention and product development has been given to the fairly well-understood
human-to-machine web access space. This includes products that provide identity
Figure 2 This is an unsecured SOA version of the EA shown
in figure 1. It is completely open, and as a result is vulnerable to
security problems related to authorization, authentication, privacy,
integrity, and auditing.
Figure 3 Contrast between human-to-machine and machine-to-machine
communication. In most machine-to-machine scenarios,
security is more coarse-grained than in human-to-machine
interactions. The result is a less secure infrastructure.
management and single sign-on (SSO) solutions for users accessing systems via a web
browser. The machine-to-machine interactions have received less attention, relying on
their essential obscurity, a network security apparatus, or a binary security mechanism
such as super-user access or key exchange, both of which are typically embedded in
the applications themselves.
The reason for this is simple-the majority of applications were monolithic,
thereby minimizing the number and complexity of machine-to-machine interactions.
If organizations begin deploying an SOA without giving due consideration to alternative
security mechanisms, unauthorized users may find it simple to penetrate and
evade detection because the systems are now directly exposed in a standards-based
manner and the security mechanisms used are either nonexistent or very simple and
“large-grained.” When we refer to a system as being large grained, we mean that its
ability to discern subtle differences in security situations is limited. Figure 3 illustrates
the contrast between the human-to-machine communication in a traditional
security environment and the increasingly common machine-to-machine communication
in the SOA that causes so many security issues.
Authorization and authentication
In the traditional security model, the system’s security apparatus, such as a firewall or
virtual private network (VPN), screens out unauthorized (human) users. However, an
SOA demands that the architecture be more flexible and open to access from multiple
systems to facilitate reuse and composition of new applications. If the systems are
exposed as services but a new security mechanism is not enforced, a hacker could
configure a machine to impersonate a vendor’s system and make erroneous or fraudulent
service calls. Because of the large-grained nature of the security mechanism, the
manufacturer has no way of knowing that the machine requesting the user of the
Figure 4 In the unsecured SOA, the often coarse-grained security
mechanisms of machine-to-machine interaction raise the risk of
unauthorized use of web services.
web service is neither authorized nor authenticated. Figure 4 illustrates the structure
of this risk. Obviously, unauthorized use of a mainframe computer is a serious
security breach.
Authentication, the process that verifies identity, is a distinct issue but one that is
related to authorization. In authorization, you establish whether a particular user has
the permission to proceed with the task it is requesting. In authentication, you prove
that the user is actually the user it claims to be. In the unsecured SOA, achieving reliable
authentication is difficult. In the example shown in figure 4, the unauthorized
machine user might also be faking its identity.
Privacy and integrity
Privacy, the ability to conduct business without unwanted eavesdropping, and integrity,
the ability to have confidence that messages are not modified in transit, are major
factors in IT security. As we have seen in numerous incidents, hackers and others
often listen in on message traffic and modify those messages for purposes of mischief
or crime. An infrastructure that cannot guarantee a high level of privacy and integrity
is not adequately secure.
In an unsecured SOA, as shown in figure 5, an unauthorized machine can intercept
and “listen in.” This unauthorized SOAP-intercepting machine can pass the messages
along to other unauthorized users for the purpose of fraud or malicious
mischief. For example, if the manufacturer were making something related to
national security, then it would be concerned that information about inventories,
delivery dates, materials and so on would fall into the wrong hands. The unauthorized
SOAP-intercepting machine can also modify the SOAP message in transit and deliver
Figure 5 Unauthorized interception, rerouting, and modification of
SOAP messages in a nonsecure SOA.
a false message to the requesting machine. Therefore, the potential for fraud and misuse
in this scenario is great.
This scenario highlights the need for encrypting the SOAP messages between systems.
In the past, this has typically been handled by a network security apparatus like
a VPN. However, due to the open and distributed nature of an SOA, it quickly
becomes impossible to secure each machine-to-machine interaction in this manner.
In the absence of SOAP encryption, an intercepted SOAP message can be understood,
literally, by everyone. SOAP was designed to be universally understood, so a SOAP
message can be received by a legitimate user or hacker without any distinction.
Flooding
With an unsecured SOA open to all comers, malicious, unauthorized users can “flood”
it with service requests and render it inoperable. In the same way that hackers brought
down such websites as Amazon.com with bogus requests, a malicious, unauthorized
user can bring about a denial of service (DoS) attack on an unsecured SOA. Figure 9.6
illustrates this risk. One factor that makes the risk of DoS very serious is the inability
of the SOA to monitor or assure the service levels of its web services. (A web service’s
service level is a defined measurement of the web service’s performance. For example,
a web service might have to adhere to a service level of responding to a SOAP request
in 10 milliseconds.) If hackers attack, the unsecured SOA has no inherent way of telling
if it is being overloaded. The unsecured SOA cripples the ability of system administrators
to identify and respond to security problems in a timely manner.
Auditing
An audit log is a fundamental tool of IT security. To examine security performance
and diagnose security problems, security personnel must have access to accurate logs
of system behavior. The unsecured SOA has no message and transaction logging
mechanism. After a service has been invoked, there is no way to determine who has
used the service and from where the request originated. As a result, no audit trail exists
Figure 6 Unauthorized “flooding” of web service requests in an
unsecured SOA.
that can be used later to investigate possible breaches in security; there is no way to
determine who has done what and at what time.
LAYERS OF SOA SECURITY
From another perspective, each aspect of SOA security outlined above should be
addressed as a separate layer of security. In my discussions with clients, I have found
the following three conceptual categories to be quite helpful in sorting out the major
challenges in securing an SOA. If you engage in a discussion of security with a vendor,
partner, or colleague, you may hear security issues referred to in this framework.
Before we look at actual SOA security solutions, let’s go over security policy, message level
security, and governance.
Security policy and provisioning
Security policy refers to the issues that arise around authentication and authorization. In general terms, any SOA security discussion is going to have a component of security policy. Who is allowed to use the web service, and who is not? How can you establish
the identity of a user (or a machine that functions as a user)? How can you systematically
manage the policies that you have created for security? For example, you might
set a policy that all users with the role of VP can use a specific web service. How do
you enforce that policy? Another way you may hear this question is in terms of “provisioning”-
that is, who will be provided with a specific web service. Many vendors
and analysts talk about provisioning issues and systemic provisioning capabilities.
Message-level security
Message-level security is a group of technology issues that relate to the integrity of the actual web service that is traveling across the network. Message-level security is the
necessary other half of security policy. Think about it: It’s all well and good to ensure
that only authorized and authenticated users are accessing web services. However, you
also want to be able to ensure that the web services they are using provide accurate
information that has been neither tampered with nor eavesdropped on without
authorization. Not only is this good business, it’s also becoming part of the law in
such areas as privacy and regulatory compliance. Message-level security, which
involves such technological functions as encryption, keys, certificates, and signatures
tackles the challenges of securing the specific web service
interaction from meddling and eavesdropping.
Governance
At a high level, we have governance. Governance addresses how enterprise IT systems
are run by people who report to corporate boards and answer to auditors. Governance
refers to the broad combination of security policy, provisioning, message-level security,
corporate IT policies, human resources (HR) policies, compliance, and other
administrative aspects of managing enterprise IT. Governance affects many areas of IT,
and with SOA, governance has particular relevance for security. In the age of Sarbanes-
Oxley, corporate boards and auditors are quite interested in knowing that the
information they use to run the company is drawn from IT systems of high integrity.
The goal of SOA security in the context of governance is to provide assurance that the
SOA can deliver verifiable data that will stand the test of an audit.
Moving forward
Part two of this series will appear on this site on Friday, May 19th. It will offer information on
- Solutions to SOA security
- The savvy manager cautions: don’t let security paralyze you
About the Authors
Eric Pulier is a pioneer in the software and digital interactive industries. A frequent public speaker at technology conferences around the world, Eric has helped establish cutting-edge technology companies in media management, professional services, voice systems, and peer-to-peer networking.
Hugh Taylor is an SOA marketing executive who writes, teaches, and promotes the business value of SOA and web services to major companies. The authors live in Los Angeles, California.
About the Book
Understanding Enterprise SOA
By Eric Pulier and Hugh Taylor
Published: November, 2005, Paperback: 280 pages
Published by Manning Publications
ISBN: 1932394591
Retail price: $39.95
This material is from Chapter 9 of the book.
