Securing Service Oriented Architecture:Ready, Shoot, AimBy Jonathan G. Gossels

It is almost impossible to pick up an IT technical publication these days without seeing articles touting the virtues of Service Oriented Architecture (SOA). SOA offers the promise of reduced development cost and faster time to market primarily through code reuse. The critical topic that is lost in all of this is security – and securing a SOA environment is challenging.

The term Service Oriented Architecture is frequently bandied about, but it is not broadly understood. A recent survey noted that approximately 50% of IT professionals professed to have some familiarity with the term. Yet, those same respondents overwhelmingly failed to associate the defining attribute, code reuse, with the term. Those findings simply underline that we are in the very early stages of a major technological change.

Now is the time for security professionals to step up and lead their organizations in finding creative solutions to a wide range of problems including:

- The size of applications shrinks in proportion to the number of services available. In order to accomplish the maximum code reuse, services must be designed to be as general as possible. This pressure to produce general purpose services conflicts with application-specific security requirements.

- There is a well established body of best practices for maintaining a secure processing environment. Formal change control procedures are used when new software or systems are added. Only specifically authorized personnel are allowed to implement changes. The opposite is the norm (and vision) for many SOAs.

- In many implementations of SOAs using SOAP and MQ Series, by default, no authentication is performed. However, even if a developer enables Web Services Security, determining what authentication means in the loosely coupled SOA environment is still required.

- One of the problems organizations face with SOAs is that they provide no end-to-end security. In larger SOAs, software infrastructure is used to create a bus processing model that aids in dynamically connecting, mediating and controlling services and their interactions. The beauty (and danger) of this model is that each of the components in the chain is (relatively) unaware of the processing that occurs in the other components; there is no concept of end-to-end control over a SOA processing path.

- It is not uncommon for organizations deploying SOAs to begin by selecting popular infrastructure products. While this approach maximizes application integration, it eliminates business requirements and information security requirements from the selection process – this is a mistake. Often, these requirements cannot reasonably be retrofitted into the environment.

Service Oriented Architectures are a new ballgame and require creative solutions to a wide range of problems. The most important of these solutions are architectural in nature – common infrastructure or replicated infrastructures by security level, how to accomplish mutual authentication, how to manage keys, how components are added to the environment, and who controls data. Our challenge over the next several years is to develop practical solutions to the inherent security problems of SOAs to enable our organizations to reap the benefits of code reuse, shorter time to market, and any-to-any processing interaction. As security professionals, we need to provide leadership now.