Security in a Loosley Coupled SOA Environment

Friday May 12th 2006 by Eric Pulier and Hugh Taylor
Share:

As you examine your SOA security needs, consider implementing an SOA security solution that enables SOAP message monitoring; federated authentication; application proxy; contract management; certificates, keys, and encryption; and audit logging. It seems like a long list, but the truth is without any one of these in place, all the benefits from your SOA will evaporate.

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



Click here for a larger image.

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.

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved