The SaaS provider’s reputation is in a large part based on the security of customer data, which makes SaaS vendors more motivated to keep that data secure. This is opposed to organisations themselves that store that data on-premises, where IT and infomation security primarily is not seen as a core area business.

At the same time, SaaS vendors can achieve economies of scale with regards threat mitigation, regular risk assessments and 24 x 7 incident monitoring and response.

You could ask if email is more secure scattered across thousands of laptops in an organisation without any form of end point security as PSTs, or are they better stored in a centralised email server from which you can build some form of centralised policy and enforcement regime? – it is the same sort of on-premise vs SaaS argument.

One of the biggest threats is SaaS vendors who are, in effect, really just hosting providers. These vendors take off-the-shelf commercial products and then just strap several of them together with some form of management framework (billing, provisioning, etc) to form a ‘solution’.

The SaaS vendor is this situation has no control over the underlying technology, in fact they may not even truly understand it. The several different point solutions they use often have gaps between each and the overlaid management layer adds an additional attack vector.

Traditional on-premises vendors are also moving in the SaaS space, often with products that are not designed with multi-tenancy in mind – causing more potential threats.

Potential buyers should look carefully at what they are buying, not all SaaS solutions are alike. Customer should look for someone who has considered the risks of centralisation and multitenancy and then worked to mitigate them – rather than just throwing some software on a publicly accessible server and calling it SaaS.

Customer’s anxieties at storing data off-site made sure that when we were designing our SaaS service we designed a distributed data store from the ground up, it was the only way we could have control over the entire lifecycle of the customer data, including its confidentiality and integrity.

You cannot build a SaaS service that doesn’t offer customers the granularity to determine their own security policy, you end up enforcing the lowest common denominator on all your customers.

SaaS security is the fun challenge for the 21st century – embrace it!

I have yet to see a fully transparent open-source, open-process SaaS company, let alone one with a proven security track record. Until that happens, I’ll roll my own thank you very much.

When you aggregate petabytes of juicy data under a single service, it is reasonable to expect that the service will be attacked, again and again. And do you think the operators will tell you when your data is compromised?

The security model is often shared. The security of the server depends on the security of the individual clients, while the security of the individual clients depends on the security of the server they are interacting with.

In a similar way, the SaaS security model is shared between itself and its clients. And we all know what too much sharing leads to.

Thanks for your blog – I read it on and off and find it useful.

You’re right to suggest that SaaS concentrates customer data and access in one logical system via the public Internet. In some sense SaaS does feel like it lowers the (unauthorised) barrier to entry , but on the other hand, central data stores with juicy data from multiple orgs are not new. In the past they would have been hidden behind some kind of partner network. But reading the recent Verizon report on breaches, partner networks feature heavily in compromises so will the SaaS approach make a real difference to breaches?

My view is that for SaaS providers, the very public nature of running a public SaaS means that intrusions are more likely to get widely reported. Even if the SaaS provider fails to detect the intrusion, when the data gets out and gets abused all roads lead back to the SaaS provider.

We know that orgs often fail to report breaches for fear of reputation damage (amongst other things). Regulators now require reporting for certain categories of incident but that is limited and specific to certain industries. However a web facing SaaS provider is now under the glare of all. There isn’t any hiding when they get 0wned.

In the end, this may ultimately lead to either better security practices or SaaS providers requiring all customers to sign NDA’s that include clauses to limit notification of breaches…

This is a good topic and its given me an idea for a future blog post :-). Anyway, if you are interested in cloud security stuff, then check out http://cloudsecurity.org.

Cheers

Craig