I get a never-ending stream of questions that usually amounts to something like “What control tasks do I need to do to be sure that this SaaS service we are going to use will be adequately secure?”
Unfortunately, at this point in time, SaaS providers offer relatively little support for enterprise control over anything. Assuming that the provider allows it (not all of them do), it is possible to manage the user accounts, ensuring that the right people have them, disabling them when somebody goes, and possibly controlling membership in groups or roles. If the provider offers it, and your users will put up with it, a growing number of high-end SaaS offerings allow use of strong authentication, which is increasingly important in face of the growing phishing threat. A small number of products provide some logging and records management, and in some cases, the buyer has made the choice to maintain their own backup copies of the data.
Beyond that, the whole purpose of using SaaS is to offload management onto your supplier. While I do think that we are evolving towards a model in which the enterprise provides a degree of control, and the provider does all the operations, today, we’re not really there. To a great degree, the choice to use a SaaS product is a choice to rely upon their controlling your destiny. If you do not believe that they can provide an adequate level of security, continuity, and recoverability to meet your business needs, then you shouldn’t use them.
The awkward fact in many buying situations is that no adequate determination was made up front as to a vendor’s ability to do this. What usually happens is that a decision is made, and then responsibility is dumped into someone else’s lap to ‘make it secure’. The lapholder is actually being asked to be the scapegoat. They didn’t approve of the use of the thing in the first place, they’ve got no ability to control what people are putting into it, and they’ve got neither budget nor technical mechanisms to oversee the activities, legitimate or illegitimate, taking place within their virtual presence in somebody else’s multi-tenanted service.
When the security failure does occur, or the service goes down and can’t be restored, then it is the role of the scapegoat, who recommended against the thing in the first place, to take the blame for the failure that they predicted would happen. While this may be a nice CYA mechanism for the line of business that dumped their risk into IT’s lap, it hardly seems like the basis for making an optimal economic decision as to how computing services should be delivered.
Category: Applications Cloud IAM IT Governance risk management security Vendor Contracts Tags: backups, BCP/DR, Cloud, cloud security, continuity, disaster recovery, information security, malware, phishing, Trojan horse, vendor risk