Can You Afford Not to Secure Your SOA - Twenty-Four Seven Security

« Stupidity Trumps Hacker Ability | Main | Trust No One: A Talk With Juniper Networks »

February 13, 2008
Can You Afford Not to Secure Your SOA

Don't forget to sign-up for ebizQ's SOA Security roundtable in two weeks. It'll be hosted by none other than Mike Rothman (who not only knows his stuff, but is just plain entertaining). The industry will certainly be buzzing about it afterwards, so you might as well get it first hand right here.

SOA and SOA Security pressure information from two different directions: SOA from the inside, in wanting information to be opened up, and security from the outside, in which the only perfect security is no information is ever revealed to anyone, even to the person who created it. But in this post-manufacturing world we live in, our use of information is what separates us. You don't want to end up in a position of SOA vs. security, and to do that, here are some traps to avoid (taken from this IEEE Computer Society Document).

1. Assuming the vendor is taking care of security -- when buying a car, you can assume that the seatbelts, the air bags, pretty much all of the auto's security is taken care of. But with an SOA application, that is not true. And just like the baby in the back seat you buy a protective seat for, that's your information you need to protect.

2. Thinking that, because one aspect of security is taken care of, it's all taken care of -- Just because your firewall is up and functioning doesn't mean your secure. With SOA, security is much more than just perimeter and means working security in during the design and implementation phase.

3. Relying on a cursory risk assessment -- business relies on the effective allocation of limited resources, and some companies even rationalize that even though their SOA framework might have flaws, it's far less likely to be exploited then something like an unpatched router. Because even though routers are more popular with hackers now, now is an ever shorter time frame in tech.

4. Incorrectly relying on public metrics -- Some security experts rely on published vulnerabilities and bugs to determine a products quality. A better idea is to ask the vendor about security assurance in the software development lifecycle and if they use touchpoints.

5. Leaving security for later -- many experts recommend the start small and grow approach to SOA. That should be true of SOA security as well.

6. Relying too much on security standards or security features -- Many believe that standards such as SSL (for web servers), S/MIME, or WS-Security will provide security when, while they are definitely important, they don't fully secure the system. Implementation bugs or architectural flaws can still leave vulnerabilities, so think more in terms of software security assurance.