Cloud Security is not Cloud Security!
Queen of the Application Delivery Space, tech geek and accomplished blogger, Lori Mac Vittie wrote this weeks invited guest post. The subject she chose - Cloud Computing Security is close to my heart and given some of the ass backwards reasoning going on right now this is a prime topic to de-FUD! Thanks Lori!
Technical Marketing Manager for F5 Networks.
Immediately after Twittergate broke pundits began (predictably) to use the resulting “breach” of Google Apps as reinforcement of the notion that “cloud security” is a widespread issue surpassed only in impact and reach by world hunger. One of the problems with this (because there are quite a few but we don’t have the time to get into all of them) is the use of the moniker “cloud” as an umbrella term and the application of the security issues of one model to all models.
Google, Salesforce, Facebook. These are “cloud” only in the very loosest sense of the term. They are hosted services that have taken up the cloud banner because, well, it’s effective marketing these days. But when it comes down to it there is a much similarity between SaaS and IaaS and PaaS as there is between a car and a boat. Sure, they’re essentially made of the same material, but their uses, architecture, and implementation are so vastly different that equating them under a single moniker of “vehicle” makes absolutely no sense.
WHO IS RESPONSIBLE FOR WHAT and WHERE
There are certainly security issues with all kinds of “cloud”, but the security issues that need to be addressed by Amazon AWS or BlueLock or GoGrid are vastly different from those that need to be addressed by Facebook and Google and Salesforce.
In the case of SaaS, all security – from layer 1 to layer 7 – are the responsibility of the service provider. Google and Facebook and Salesforce provide the network, the infrastructure, and the application. They are responsibility for all aspects of security. The provider owns the entire stack including the software, and is therefore responsible for ensuring isolation (multi-tenancy), application security, and security of the overall network.
In the case of an IaaS provider like Amazon or BlueLock or GoGrid the situation is vastly different. The provider is responsible for the network security, for the security of its infrastructure and management systems, but the rest is up to the customer. The security of the applications the customer deploys in an IaaS cloud are solely the responsible of the customer and it is the customer that is beholden to its customers if something goes wrong, i.e. a breach in application security. The provider is responsible for any breaches that are successfully perpetrated through the exploitation of its underlying architecture and infrastructure, but if it happens through a customer’s deployed application then it’s solely the responsibility of the customer.
In the case of a PaaS provider like Microsoft and its Azure cloud, the distinction is a bit fuzzier. Microsoft is certainly responsible for the network and application network security of its infrastructure, and of the platform, but again the applications developed and deployed are the responsibility of the customer. Isolation (multi-tenancy) needs to be assured by PaaS providers to ensure against cross-contamination between customer applications, to be sure, but in the end it is the customer of the PaaS provider who is ultimately responsible to its customers to ensure the security of its applications. The provider could – and should – be held responsible for successful breaches via the network infrastructure or via the exploitation of vulnerabilities in the platform, but not the applications its customers build and deploy.
THE RED HERRING THAT IS “CLOUD” SECURITY
“Cloud security” means different things in different environments. Using a breach in Google Apps to question the security of “the cloud” is like using a bad seam in a boat to question the construction of a car engine. It’s utter #fail and the fallacy inherent in the logic should be obvious to anyone with even a smattering of technical understanding of cloud computing models. Just as there are different types of clouds in the sky, there are different types of clouds in the ether. Each cloud has its very own risks and while the dark ominous cloud may be in danger of bursting open the white fluffy one is not. Such is also true of clouds in the ether; each comes with its own unique security risks and they should each be treated as individual models, not as an undifferentiated group.
Pointing to vulnerability in Google Apps or any other SaaS provider as proof positive that there are security problems “in the cloud” is nothing more than a red herring; it’s FUD, plain and simple, and if cloud is ever going to be what pundits hope it will be such blatant misconceptions must be put to rest sooner rather than later.
