SOA Security Challenges
The top 10 in no particular order.
Nowadays SOA Security is the most asked about aspect of SOA, and is becoming the decisive factor in selection of SOA platforms and strategy. It is important. How important? According to Forrester at the end of 2006 86% of SOA infrastructure vendors have firm commitments to support SOA Security and more then 50% of the SOA users are actively looking to implement it. Less then 4% of the users have made a decision not to implement SOA Security [I wonder what their reasons might be]. More importantly, it will be the determining factor in success or failure of SOA implementations undertaken today. Another anecdotal evidence why the time to talk SOA Security is now comes from the meme trend analysis:
As you can see the S-Curve has clearly taken of in the last 10 months yet the inflection point has not been reached. The next picture illustrates a brief idea behind this fascinating analysis tool, and I highly recommend to check out more:
Ok, now we are hopefully in agreement that SOA Security is important, but it is also difficult [to do right that is]. And here are top ten reasons why:
- SOA relies on ubiquitous unsecured technologies. No more [false] comfort in security through obscurity.
- SOA Security implementations have to reconcile and interoperate between multiple security models and mechanisms in real time. And there is never a perfect match between them. And where there is some mismatch between interoperating entities, cracks tend to open. And we all know what can get into cracks…
- SOA opens new vulnerabilities by breaking up and exposing formerly monolithic and hidden applications. The more integration points (some people call them reuse opportunities) your applications have, the more attack surface they present.
- SOA heavily relies on advertising services, formats and access points. In the past businesses tried to hide those things, lest someone figures vulnerability they have missed. Now you have to publish them and open to external parties or even the entire world.
- The ROI fallacy: it is likely that the most important business functions will be SOA-fied first, when some of the technologies that you will use are still young and your experience with them is minimal. The rational way is to do things in reverse and start with the least important capabilities, but we all know the power of the dreaded ROI.
- SOA supports service composition, orchestrations, etc. and, most importantly, facilitates automation of business processes, hence removing existing human oversight and controls. And (at least for now) only humans have the ability to notice things that they were not expecting to see. Just remember what happened with the Barings Bank back in 1995.
- SOA expands the ranks (e.g. business partners) and kinds (humans, systems, processes) of service consumers, so the security mechanisms have to cope with a menagerie of principals, while being able to tie back every action to a specific human being (because they do not send computers to prison – at least not yet).
- SOA breaks the traditional notion of a single easily identifiable consumer: once you start composing and orchestrating services and processes it is at time very hard to figure out whom to authenticate and authorize – the immediate requestor, the ultimate one or perhaps both of them. For example: a client calls a bank employee and asks to wire money to a numbered offshore account – the client is responsible. The same client calls a stock broker and instructs to take a risky short position on an exchange, the broker is responsible before the exchange and has to settle with the client separately. A doctor asks an assistant to access confidential patient information – both need to be cleared to do that. And there can be more then two parties…
- By enabling flexibility, SOA accelerates changes of everything, including: business, IT, technologies, processes, participants, and even change itself. And these changes will be opening new vulnerabilities which were not there even a short time ago.
- SOA replaces compartmentalized security, with a uniform one thus creating a high value target. In the days of siloed applications one needed to compromise a lot of systems in order to be able to achieve anything of value and cover their tracks. Now if they can get around the SOA Security mechanisms you put in place – they are in!
- Standards, but that is a subject for a whole separate discussion.












Posted by Twenty-Four Seven Security on January 16, 2008 at 10:05 AM CST #