Securing SOA

Given that I’m currently at IBM’s SOA Impact conference in Las Vegas, I though it would be appropriate to post a blog about the security aspects of SOA (Service Oriented Architecture). Judging by the amount of coverage given to security in the keynotes and analyst sessions, one might be led to think that security was not an issue; meanwhile however, one only need to have a cursory understanding of Murphy’s Law to know that security should not be taken for granted, in SOA or elsewhere.

So, what are the risks? There most obvious of these lies in areas such as confidentiality breach and service compromise. At its heart, SOA is about developing and delivering distributed computer systems – that is, software applications and components that communicate across a network. The potential for a confidentiality or service breach is therefore quite high, particularly if communications take place on the wrong side of the corporate firewall.

Risks such as these are well known and frequently documented, so I shall say no more here. Meanwhile, however, there are the risks involved in the development process itself. There has been talk about the “insider threat” in terms of the users of computer systems – people who, through stupidity as much a malice, can cause a security breach. Less consideration has been paid thus far on the developers of said systems. In SOA development environments there are a number of risky areas – not least of course on the code, which needs to be constructed in such a way as to minimise the potential for compromise. There is also the data involved in the development process. SOA requires interface definitions to be published, but such interface data may well contain information that should b kept confidential – for example, specific business rules or even the need for them. And finally we have the security of the development process itself. A number of drivers including the continued reliance on subcontracted development resource requires vetting and monitoring of developers, such that the resulting code has not been written to be compromised.

What’s all this got to do with SOA? Truth be told, some of these aspects are true for all kinds of development, not just SOA projects. What SOA brings is the increased risk due to the distributed nature of the resulting software. In traditional development, the resulting application silos would likely exist behind the firewall, but with SOA there is no such guarantee. As many organisations start to move down the SOA track, they will need to ensure that they have the security bases covered in advance of application delivery. Should security be treated as an afterthought, as it has so often been treated in the past, it may already be too late.