Security is a negative feature.
What I mean by that is that you will never get kudos for implementing a secure system, but you certainly will get a lot of flak for an insecure system, as the recent LinkedIn incident shows. Therefore, security is a distraction for most developers; they’d rather focus on their core business of implementing features.
Where have we heard that before?
Cloud Computing to the Rescue: SecaaS
Cloud computing promises to free businesses from having to buy, install, and maintain their own software and hardware, so they can focus on their core business.
The alternative of using libraries, while infinitely better than rolling our own, is less attractive than the utility model. We’d still have to update the libraries ourselves. Also, with libraries, we depend on a language level API, which segments the market, making it less efficient.
There are some hurdles to tackle before SecaaS will go mainstream. Let’s take a look at one issue close to my heart.
Security as a Service Requires Standards
The utility model of cloud computing requires standards. This is also true for SecaaS.
Each type of security service should have one or at most a few standards, to level the playing field for vendors and to allow for easy switching between offerings of different vendors.
For authorization, I think we already have such a standard: XACML.
We also need a more general standard that applies to all security services, so that we have a simple programming model for integrating different security services into our applications. I believe that standard should be REST.
Update: The market seems to agree with this. Just see the figures in this presentation.
This is one of the reasons why we’re working on a REST profile for XACML. Stay tuned for more information on that.
So what do you think about SecaaS? Let me know in the comments.