Service-oriented architecture changes the security landscape; are you prepared to change with it? by Gunnar Peterson
Service-oriented architecture (SOA) changes the game for information security. Its strategic goals of interoperability, integration, service virtualization and reusability require a radically new approach to security architecture.
Interoperability and integration mean that the business offers services based on the value they add for service consumers and providers (such as printing boarding passes from the Web) instead of based on the IT silo, such as proprietary CRM or ERP systems. Virtualization in a Web services context means that the location of the service implementation is irrelevant at the time it runs, enabling partners in Tokyo, Bangalore and Chicago to collaborate on a business process. Reusing business logic enables a more reliable and cost-effective platform, removing the need to start from scratch on every project. This applies to reusable security services as well.
The adage that security must be a proactive business enabler applies more than ever with SOA. Overcoming the perception that it inhibits commerce is mandatory.
How will this happen? Security services require design, development and operational support, so they must be targeted at high risk and/or high business value areas. Over the course of time, integration patterns emerge in the enterprise, and security leadership can help determine the most cost-effective security investments, leveraging reusable shared security services. This moves security away from an auditor role and into a business champion as a service builder.
Let's examine the key guidelines security officers need to consider in mapping out this 21st-century architecture.
- Partner with security stakeholders. This often ignored lesson becomes essential in a world dominated by SOA. IT security's future is in partnership with the business, software development (even if outsourced) and customers. The earlier security gets involved, the more likely the mechanisms that enforce security requirements will be implemented when the system is deployed, not tacked on later.
- Tie risk to the business. There's inherent technical and business risk in any integration--compound this many times over with SOA, which is all about platform and process interoperability across business, geographic and technical boundaries.
This works to your advantage; in customer and partner integration, the business benefits and risks are easier to quantify in risk management terms, because they are tied to a business service, rather than the IT infrastructure as a whole.
Put your security budget to work where the business is investing its dollars.
- Do it by the numbers. Risk is about numbers. Quantify how you're doing and measure progress over time. Given the distributed, heterogeneous nature of SOA, unifying security concerns with metrics gives the security team a way to "see" the system's security posture objectively and helps stakeholders make business decisions.