“We need to move to an application security model that is external to the applications themselves, standards-based, and centralised.  Service Oriented Security?  RSA Conference London 2007.”

Now one has to admit that, as a proposition, the idea that security can be ‘bolted-on’ to an application, after it has been developed, is the Holy Grail (with apologies to the many and various writers of similar religious fiction works from Mallory onwards) of security products manufacturers.

Surely, they say, security is just another service, like networks, that you add on (granule by granule) as you happen to need it.  After all, the OSI model said that you can apply security to each layer, so Service Oriented Security (SOS?) MUST be right.

Unfortunately, like many industry mantras, it is a concept with some truth in it, but not enough to fulfil the grand plan being presented.

Why?

Well, for one thing, the greater part of application security has to be performed by the application.  Only the application can possibly ‘know’ what information should be presented to whom, and in what circumstances.

But, much more importantly, security is actually just one component in an overarching business process.  And the security of the business process is achieved by many different methods, some manual, some procedural, some covered by insurance, some addressed by transferring liability for error.
 

You can’t retrofit technical mechanisms into business processes without making a significant change to underlying applications, because they usually do not even begin to understand the overarching security processes in place.

(And that was the problem with the OSI model, actually.  Each layer had its own security potential, but there was no possible way for the layers to communicate with each other.  So it did not matter which layer you were, you had no idea at all what security – if any – the surrounding layers had or had not provided, you were on your own.  So, naturally, each layer was either totally defensive, or totally uninterested.  After all, if you look at the vast majority of SSL implementations, which are supposedly secure, they make no verification of the parties being connected and report few if any errors to the user, to avoid confusing them.  And, which joker was it dreamed up the idea of having SSL certificates with wild cards in them to give you absolute site authentication?)

So given all that, how do you propose to move security outside of the application?
 

Well, if you’re a database, you might well think that the important thing is the security of the connection of the application to the database.  This kind of ignores anything to do with the data in the database, and the security implications it may possess, or if that data is right, but when you have a hammer, every problem is nail shaped. And I guess the same goes for being a web application, the important thing there is usually thought to be the connection to the user of the web system.  But again there is no real understanding of security, just the small technical matter of connecting two points together.

And that is what appliances have been doing for some time now.  Connecting disjoint bits of overall business processes together.  But if that is all that SOS is offering then it isn’t a revolution, and just barely an evolution.

There was mention of standards based and centralised operation.
 

Well, take it from me, that if you want an international standard to back you be prepared to wait at least five years from starting the process.  If you can put up with an industry standard it will be quicker, but may suffer from patents that prevent any real competition (and consequent lowering of price) except when it suits the major manufacturers that created it.

And why centralised operation?  This is the most confusing requirement of all.  It flies in the face of how commerce and industry are organized.  Admittedly, centralized and decentralized models for enterprises are as much a matter of fashion as the provision of IT methods and techniques, but why limit oneself to a centralized model?  And why make it a fundamental?  Well, again, if you are a database, and therefore the centre of the universe (sic) then it becomes obvious that you ‘need’ to be in charge of the security system.  But what do you do when there are several databases?  Do you happily combine them into a single central point of failure (sorry, point of control) or do you decentralize them.  And if you do, what happens to the SOS solution?  After all, security is also about not putting all your eggs in the one basket – consider defence in depth.
 

In sum, security is not a trivial subject about providing a couple of mechanisms for connecting two Internet locations together.  If you want to do that standards are already available, and how you choose to implement them will be the most significant factor in what you achieve, how they work, and how easy an attacker finds it to blow them away.  If you want to talk about real information security where you get down to linking access and use to specifically authorized individuals with appropriate auditing and monitoring, then don’t hold your breath because we are going to be a while getting there at the application level.

At the information shifting level, using standards such as OpenPGP (RFC 2440) we (as an industry) are already there delivering authenticity and secrecy of information transfer.
 

So it’s a bit difficult to see exactly what value add SOS delivers, but, maybe like PKI, it will prove an exciting journey?