SOA Security (Part 4)

Tim Bass
Thu, 18 Oct 2007 03:44:41 +0000
My apologies for dropping off the blogosphere! We just landed at the Sheraton Royal Orchid in Bangkok after weeks of packing, moving, plus time with friends and family.
Eventually, I plan to get to the topic of event processing in SOA security and blog about how CEP can help reduce the risk in security issues related to distributed computing environments. First, kindly permit me to elaborate on why defense-in-depth is an important concept for SOA security.
The core security triad for information systems is often called the AIC triad by IT security professionals (CISSPs, for example): authentication, integrity and confidentiality. We can go a bit farther and talk about authorization, availability and non-repudiation; but starting with AIC is both prudent and expediant.
When you think about AIC for SOA you should always look to the security services that are provided by the network layer (and other layers) in the context of your (administrative) domain architecture. In other words, there is a big difference between creating federated, cross-domain AIC controls and AIC controls in a single organization with one security domain. In addition, there are huge differences between multi-domain organizations under an umbrella governance policy versus a federated approach, where each domain is nearly, if not totally, independent from the other.
Most SOA implementations are state-0f-the-art versions of organizational EAI implementations, in a single administrative domain, that start small and (hopefully) grow over time, adding other administrative domains that are under the same corporate flag. Additionally, most of the complex SOA security standards are designed for the �utopian view� of SOA, envisioned to operate in complex federated, multi-organizational environment.
When you examine your AIC requirements for �the new SOA�, modular distributed computing, don�t forget that you can go back to basics and get your projects off the ground much quicker than striving for nirvana. For example, much of your AIC requirements for SOA can be met with a good VPN and in tunnel model with combination of host-based and user-based authentication.
Time and time again, over a long career of operational IT experience, we have seen the same implmentation pitfalls, which are often summarized, �The Enemy of Good is Great.�
If you are working on grass roots SOA EAI implementations, don�t let your projects come to a grinding slowdown trying to build a utopian infrastructure for SOA security with immature and unnecessary SOA standards when your AIC requirements can be met using other compensating controls (either logical, physical or administrative).
Keep in mind that most SOA implementations are simply organizational EAI that can benefit from AIC basics, so don�t rush into vendor snake oil SOA security tools that promise more than they can deliver.
In my next post, I will begin to discuss how CEP and event processing can serve as a control infrastructure in more complex SOA federations. If you would like for me to elaborate on AIC for SOA or defense-in-depth, please don�t hesitate to comment or ask!
Sawatdee Krap Pom!

Source...