SOA Security (Part 4)

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 very, if not totally, independent from the other.

Most SOA implementations are state-of-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 in tunnel mode 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 implementation 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!


2 Responses to SOA Security (Part 4)

  1. vaibhav says:

    Could you please concisely state what are the security requirements of SOA that you don’t see fulfilled in right way or for which the available solutions are too complex?

  2. Tim Bass says:

    Dear Vaibhav,

    My posts on SOA security have started to discuss the known situation where the emerging standards for SOA security are immature versus other security standards or security controls that may satisfy the same (or very similar) requirements from a defense-in-depth perspective.

    These security requirements include authorization, authentication, availability, confidentiality, integrity and non-repudiation. One size does not fit all; therefore, it would be more efficient if you would discuss your requirements in the context of your business or use case. In addition, the requirements for authorization, authentication, availability, confidentiality, integrity and non-repudiation (as required) can be meet with logical, physical or admistrative controls. This means that the discussion on SOA security is not purely technical or generic, as every organization has varying capabilities, maturity, existing infrastructure (etc) in compensating controls.

    As a CISSP with years of operational, architecture and policy experience, I do not shy away from developing or discussing security strategies for SOA.

    Would you describe your operational scenario or environment, including business model, use case, risks, threats and potential vulnerabilities? If not, what parts of your SOA enviroment can you share?

    Yours faithfully, Tim

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: