Security-Oriented Architecture

Like Roth, I never miss an opportunity to recycle a good sound bite. The opportunity at hand is the chance to finally build security into the corporate world’s application development process, riding on the tide of service-oriented architecture (SOA). We haven’t missed this opportunity yet. But it’s hard to fight off the sense that we’re going to miss it, and the buffer overflows will keep on flowing as they have through client/server applications and Web apps and every other version of networked computing. Presented with a new technical platform to adopt and new code to write, the corporate world (just like the software vendors we all love to criticize) generally has chosen quick adoption rather than thoughtful and secure adoption.

SOA basically means that network resources are written as services that can be accessed in a standard way. This makes software more modular, flexible, reusable. SOA adoption seems to be ramping up quickly. Our sister company IDC predicts SOA services spending will more than double in 2006. Now you can find differing opinions on how revolutionary SOA really is. Some dismiss it as a buzzphrase. Regardless, a lot of legacy applications are going to be either rewritten or at least wrapped in new code—an SOA-style integration layer.

This presents a golden opportunity for the world’s IT shops to put a fresh eye to the application development process and inject security-minded practices up front. It’s cheaper and more effective to write secure code the first time than to keep following the failed build-now-secure-later model.

Recently I spoke with two companies that are building service-oriented architectures. MedicAlert and Thomson Learning are customer references for two vendors that make SOA security gateways (Forum Systems and Reactivity, respectively). MedicAlert and Thomson Learning both use gateway appliances to handle encryption and digital signatures and various kinds of policy enforcement (and to offload those rapacious computing tasks from the data servers). And that’s a good start, but you can’t stop there. Christopher Crowhurst, vice president and chief architect for Thomson Learning, says his company has developed best-practice documents concerning SOA encryption, authentication, formal threat analysis and more. They’re disseminating those practices through training sessions, webinars and the corporate intranet.

You can create just as many bugs in SOA as in any other model. As Crowhurst says, security “still comes down to human beings doing the job right.”

What I’m hearing from folks like SystemExperts consultant Richard Mackey is that we’re following the pattern of history. A few are doing the job right, using the shift to SOA to improve their processes. But many more are missing the opportunity. Some companies are using SOA to interconnect fundamentally insecure legacy systems (an activity Mackey neatly describes as “creating a big bug shuttle”). Others will create even bigger risks through insecure SOA interactions with business partners.

There’s another famous quote about those who fail to learn from history. If David Lee Roth can land another radio gig, maybe he’ll recycle that one too.

Correction: In the April story “Value Made Visible,” the formula should have read as follows: VP=(NE)/N, or Value Protection equals the quotient of (normal operations costs less event impact costs) divided by normal operations costs.