SOA: Watching the In-Between Spaces

Many organizations are embracing service oriented architecture (SOA) as a way to increase application flexibility, make integration more manageable, lower development costs, and better align technology systems to business processes. The appeal of SOA is that it divides an organization's IT infrastructure into services, each of which implements a business process consumable by users and services. For example, a service may expose the functionality to add a new employee to the employer's payroll and benefits system. To make services usable in multiple contexts - for both lowered cost and increased process consistency - each service provides a contract describing how it may be used and what functionality it contains.

Few development methodologies have embraced the principle of interoperable contracts as tightly as SOA. To ease collection and the discovery of new contracts, in many SOA architectures each service possesses a method for clients to query and retrieve the contract. This method for retrieving contracts is often standardized, if not by the application framework vendor, then by SOA practitioners themselves. Standardized contracts and contract retrieval methods make SOA systems more discoverable. And therein lies one of the new security risks of SOA. Such freely available contracts are very helpful for developers as they build new services and reuse existing services across the enterprise. Unfortunately, what works for the developer is equally helpful for attackers looking to understand the enterprise and its services. Attackers can collect these contracts and use them to easily create an internal treasure map of an organization.

To identify high-value targets, the attacker uses the map and reviews the contracts for services that have weak authentication or are responsible for high-value services such as security management. SOA practitioners might try to make it harder for attackers to build such a map by disabling anonymous exposure of service contracts in favor of authenticated or offline distribution. Although this is a solid security decision, it does not work for all services and all organizations. That's because, by restricting the distribution of contracts, it becomes more difficult for legitimate users to discover services and becomes less likely that development tools can seamlessly import contracts.

Ironically, the use of message layer security is another related SOA vulnerability. Message layer security enables developers to pick and choose the portions of the message to be signed and/or encrypted. To support addressing and routing on the ESB, the destination information of a message is often excluded from the encrypted portion of the message. The selective encryption/signing approach differs from other point-to-point or transport layer security protocols, such as SSL, that protect the entire connection.

With message layer security, an attacker passively monitoring the network can gain deep information about the application layer messages being sent between senders and receivers. Selectively applied security increases complexity and the probability of developers or administrators failing to apply critical security protections to portions of a given message. Service information disclosure may not be a high risk in some environments, but it is not to be taken lightly. The more informed the attacker, the more targeted the attack will be. Before SOA, there was a certain amount of obscurity gained by having disparate systems using a wide range of protocols. Attackers had difficulty finding and understanding all the systems in an environment. SOA has removed this barrier and greatly improved the attacker's ability to perform thorough reconnaissance.

Messaging Intermediaries
SOA makes systems more dynamic by moving away from monolithic software to self-contained, reconfigurable components that can be assembled and orchestrated as needed. To manage this orchestration of components, SOA encourages the use of message routers and service registries that operate on messages as they travel across the ESB. For message routers to be able to operate on a message, portions of the message must be unencrypted, or the message router must have access to a key to decrypt the message. This approach means you cannot use transport layer security between a service provider and a service consumer. And it means that attacker could exploit these message management and orchestration intermediaries to compromise the behavior of the end points.

At first glance, you might think that carrying routing information in the clear is not that different from the clear IP and TCP headers on packets protected using a protocol such as SSL. But they are different: SSL provides intermediaries with very little information about the contents of the messages flowing through them and does not expect intermediaries to do little more than forward messages with the guarantee that the entire message is signed and encrypted. But SOA intermediaries are typically more invasive and often modify the message itself without invalidating signatures. This manipulation window provides a tool for attackers to use when trying to change the SOA environment. It's true that WS-Security can provide SSL-like guarantees over message security, but the flexibility and complexity of the WS-Security standard increases the risk that sensitive information within the message will not get appropriate encryption or integrity protections. Likewise, service registries are a risky intermediary that the SOA approach depends on to function. They are similar to a DNS for services. When a service consumer wants to find the appropriate service provider, the consumer will query the service registry to find the current address of the provider. In many deployments, the service registry can be dynamically updated by administrators or by the providers themselves. This provides the SOA benefit of easy reconfiguration as the addresses for services change due to movement of services. But that configuration control is what makes service registries an attractive target for attackers. For example, attackers could manipulate the registry to return addresses pointing to services hosted by the attacker. If the attacker targets the correct service, such as the security service, the attacker may be able to craft custom responses to clients trying to use the security service. In one case, an attacker was able to hijack the security service and issue blanket approvals for all access requests. To deploy a secure and dynamic SOA, developers and architects must consider which portions of the system to make dynamic and which portions to keep static. The configuration elements of the SOA that enable reconfiguration must be reviewed for security issues that would let the attacker orchestrate the environment.

At the center of any significant SOA deployment is an ESB that handles message routing and provides required basic services. Often, organizations have several ESBs, connected via a bridge. Whether you have one ESB or several, the very use of an ESB eliminates the traditional 'soft' firewalls, making the ESB an attack target - especially because it  hosts critical services, such as logging and authentication. 'Soft' firewalls are artificial restrictions on communication that occur when all connected parties are not speaking the same protocol. So, even if an attacker gains access to one system, the lack of protocol compatibility limits the reach of an attack. For example, an attacker who has compromised the Web server may not be able to reach the mainframe because the mainframe uses Token Ring, but the Web server sits on a TCP/IP network with no bridge between the two. ESBs are designed to remove communication barriers, which means an attacker can likely reach the mainframe from the Web server in a SOA deployment. The same connectivity that enables the SOA approach ends up assisting the attacker. The high connectivity of an ESB increases the importance of having solid application security process for internal, external, and ESB services. Before connecting traditionally weakly protected systems such as mainframes to the ESB, review their security properties to make sure the systems are capable of operating in a hostile environment.

Consider the new communications environment implemented in your SOA from the perspective of an attacker and model the distance an attack could spread from a compromised server. Then design a mitigation plan to control and stop the spread. Engineering flexible systems such as SOA is a real security challenge - but it's not an impossible one if you take the right steps from the beginning .