SOA Security: How a Lil’ Irish Luck Went a Long Way

From a security perspective, service oriented architecture (SOA) is a tricky thing. It’s not hard for bad guys to compromise it with SQL injection, capture-replay and XML denial-of-service attacks, which they can ultimately use to bust through walls around a company database.

As Acumen Solutions’ Igor Khurgin, SOA practice manager, and Saurabh Verma, director global services, explained in a recent CSOonline column: “Adopting services oriented architecture (SOA) in your enterprise without thinking through IT governance can cause something like the Gold Rush in the 1800s; extreme rates of growth and minimal law and order which produce unexpected outcomes.” Mark O’Neill, CTO at XML network management company Vordel, also spells out the risks in SOA Security: The Basics.

The EBS Building Society, one of Ireland’s largest financial services companies, wanted SOA for its ability to quickly model (and change) business processes. And it’s IT Head David Yeates’ responsibility to secure the resulting architecture. Below, he explains the process his company took to achieve secure SOA.

CSO: Why did SOA make sense despite the security concerns?

Yeates: SOA has the potential to be an extremely important strategic business tool. The future IT emphasis will be on process-driven development and component-based solutions like Siebel component assembly, Oracle fusion, IBM’s component business models, and so on. Future complex financial IT applications, meanwhile, may span multiple organizations in real time with organizations acting as both suppliers and consumers in such an environment and exposing applications to B2B customers as Web services. This has major implications for an IT organization which must now seriously consider the following areas: governance and service management, and an integrated security infrastructure to address Web Services and XML security.

With those security issues in mind, describe the implementation process EBS followed.

Yeates: In implementing an application infrastructure based on SOA principles, we had four distinct phases:

• Simple Internal Integration (tactical — technology driven): This focused on application and platform level peer-to-peer communication; elements of coarse and fine-grained services.
• Rich Internal Integration (technology driven): Addressed the complexity and cost of distributed applications, the application spaghetti environment, rudimentary service business technologies, elements of routing and transformation and multi-channel applications.
• External Partner Integration (business driven): Extending an SOA-based application infrastructure to consume (and) or provide B2B services.
• Core Business Functionality (strategic — business driven):Process driven development — Web services integration and orchestration; business process modelling and monitoring.

We recognized we needed a loosely coupled SOA which addressed areas such as the reality of long-running transactions with complex routing and transformation; the notion of compensating transactions for transaction integrity; service choreography; the need to integrate with human workflows systems; and the potential for process-driven development. We also needed to address data semantics, data modelling and operational data stores and needed a comprehensive security architecture to underpin the future operational environment.

Dive deeper into how you reached the conclusion that the security architecture was needed.

Yeates: Service-oriented applications are fundamentally different from traditional monolithic applications. Web services are dynamic, they look up, discover and bind to each other at run time. This means that the internal network has also to be considered a dirty environment. A process-driven development creates dynamic applications where business processes can be easily created and changed. This presents major change management, service management and compliance challenges for an organization. Transactional security becomes very complex, very fast.

What did you ultimately decide to do about it?

Yeates: We found the ideal solution was to abstract the security, auditing and control functionality away from individual applications and into the network fabric itself. The strongest approach was to embed security within the services infrastructure itself, provide consistent security policy enforcement and to protect all endpoints, not just the perimeter.

Editor’s note: To achieve the security he was looking for, Yeates went with XML network management company Vordel’s product line for such security functions as identity management, policy control, and monitoring of the environment for suspicious activity. Other SOA vendors to be considered in this area include Parasoft, Oracle, IBM, Layer 7 and Bloombase.