SOA Security (Part 3)

In SOA Security (Part 2), after dropping a book shelf on my head preparing for a move to Asia, I promised to tell a “war story” and discuss how one of my past experiences in IT security applies to SOA Security.  The theme of this post is Don’t Let Technology Get in the Way of a Good Solution, often known by another old saying, The Enemy of Good is Great.

So, we embark on this story, nearly 8 years ago, with about 120 Air Force bases world-wide and a quasi-public Air Force Internet that connected the bases together, together with defense mega-centers and other critical sites.   Like other large organizations they had network management traffic, email, web traffic, and myriad other network traffic running across the net.   

As the most senior trusted network advisor / consultant to the USAF at the time, we thought it was time to build a fully-meshed virtual private network (VPN) connecting all the sites together that would provide confidentiality, integrity and authentication to the network traffic IPSEC

Althought the solution architecture is not classified, I am not comfortable discussing the technical details of our solution.   However, I can say that my architectural design was the foundation for the largest fully-meshed operational VPN in the world.  

At the time, many of the technologies associated with automatically keying the VPN were immature and expensive.    I rejected all of the “immature complexity” and used an approach we called “Defense-in-Depth“.   In this methodogy, we architect a solution based on risk and the appropriate compensating controls to manage risk.

To secure an SOA, we need a similar approach.  You will need to look at your requirements for authentication, authorization, integrity and confidentiality based on the risk-profile of your business.  One size does not fit all.   

Don’t get trapped (or wrapped) in the blind alleyway of immature, confusing and less-than-proven  security “standards” like SAML, XACML, WSS, WS-Federation, WS-Security, WS-SecureConversation, WS-SecurityPolicy, WS-Trust, XML-Encryption, or XML-Signature (to name a few).   Take a step back (or maybe two) and look at your risk and exposure and the available compensating controls (i.e. your VPN) for the AIC (authentication, integrity, and confidentiality) triad.

In Part 4, I will begin to discuss how to use a Defense-in-Depth approach to SOA security.


2 Responses to SOA Security (Part 3)

  1. David Kearns says:

    Had you said “don’t use standards you don’t understand,” I would be happy to agree but to claim the standards “immature” simply because you don’t understand them is, well, immature…..

  2. Tim Bass says:

    Hi David,

    I have been “doing SOA” for many years, including almost two years of service as the “lead SOA-guy “on the US Federal CIO Council on the Components Subcommittee, Architecture and Infrastructure Committee, representing the USAF (quite a few years ago, I might add, before the current SOA-over-almost-everything push).

    For you to imply that I don’t understand SOA standards is simply wrong.

    I can teach you many things, if you are willing to listen. Many years of experience actually working complex issues is not something to discount so quickly.

    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: