All too often, SOA security is left to individual developers, who may try to do everything they can to build in security features, but cannot address the complexities of internal and externalized security.
I just had the opportunity to moderate a Webcast featuring Anne Thomas Manes of Burton Group and Andrew Brown of AmberPoint, dealing with one of the most pressing issues of SOA: security.
Security is "really hard stuff, and you can’t expect a business developer to understand it all," Anne pointed out. "Even if you have really highly trained business developers who understand security more than the average business developer does, I still wouldn't want to rely on them to make sure they’re implementing the proper security according to corporate policy, and actually writing all this security directly into their application code."
Since SOA introduces a lot of new connections to an infrastructure, security becomes a multi-faceted challenge, Anne said. "If you’ve had any experience with SOA, you realize that it adds a new dimension to the security landscape, and that’s mostly because you’ve got a set of loosely coupled connections which contain a lot of dependencies," she said. "Security threats and the requirements are very complex, and you have to assume that the average developer is not fully cognizant of all these threats and challenges that exist out there. And it’s really not appropriate to assume that the developer is going to capable of managing security all on his own."
The key to instilling security is through effective governance, Anne related. "In order to consistently implement this kind of security requirements, and be able to externalize your security requirements, it’s really important that you have good governance processes in place that ensure that proper security can be applied to each of your services."
Centralization of security functions is the key. Organizations need to "adopt a policy-driven enforcement model which allows the security office to actually make decisions about what needs to be secured, and how things need to be secured, and allows them to externalize security as much as possible," Anne said.
"The core security stuff is pretty hard, but when it comes to actually managing security enforcement, that’s even harder. And that’s because the threats and the requirements change on a regular basis. There are new types of attacks that have been identified. There are new regulations. You have new corporate policies. Or because perhaps you have gone out and deployed some new infrastructure, and you want to make sure that it’s using this new source of identify information."
Listen to the entire Webcast featuring Anne Thomas Manes and Andrew Brown.
This is actually related to the last 2 posts, rather than this one.
If the correct pronunciation of "SOA" is indeed the one symbol (rhymes with "boa") rather than the 3 letters as you claim, why in previous blogs do you use the phrase "an SOA solution"?
Or do you subscribe to the theory that consistency is the hobgoblin of little minds? :-)
Thanks -- and very observant! That's why the S-O-A vs. Soah debate takes on such urgency for me personally. It is difficult to properly use it in a sentence!
Also, I tend to shift back and forth between the two pronunciation modes. When writing, I tend to think more formally, therefor it comes out as the acronym, and when speaking (such as in podcasts), it rolls out as Soah!