[ Standard disclaimer applies: views below are strictly personal and is a rant written in one go – you have been warned – you continue reading at own risk ]
Recently, I had the honor to be the only engineer in a round table discussion with CXOs from the DACH region. The topic of cloud security came up. There, I “learned” from some of the participants that there is NO shared responsibility model, the responsibility for security falls entirely into the client, who by the way has no negotiating power, that cloud providers have been “owned” by APTs and that they suffer outages and that good ole old school thinking and processes will save the day when things go awry with your cloud provider, who inherently has no resiliency, be it from a security or reliability perspective, yada yada.
Until that point I was an active participant in the discussion but given the time limitations AND the sheer shock of hearing these statements, I could have done a better job to attempt to refute this.
Before moving forward, a short repetition of my standard disclaimer – opinions my own, not representing anyone, you know the drill.
Moving workloads to the cloud is not an easy process. You have to be prepared to spend money (managed services and staff with the relevant knowledge), plan carefully and execute *even* more carefully. There are multiple dimensions to moving to the cloud, with engineering being just one of them and all have to be considered.
When cloud providers speak about shared responsibility, they do not mean that they are automatically co-responsible for *your* workloads nor that if their part of the stack is secure, it automatically means that yours is too. It means that their part of the stack follows certain demonstrable security baselines. What goes above their respective layers (and that depends on the service itself, to the extent that is managed) is the client’s part. Seems obvious but I guess it is not for everyone. Usually, in the event that they deviate from these SLAs, their means of saying “Sorry” is a credit refund and a visible postmortem, for breach of reliability SLAs. This information and T&Cs are extremely easy to find and you can see them below:
Negotiating power in the cloud for most companies can be summed up as “take it or leave it”. A lot of SMEs are used to that, be it on bare metal or in the cloud but I guess for some major players, this power imbalance does not sit well. If you are building a long-term partnership with a vendor of any kind based on who has the best lawyers, you are starting off in a wrong foot. Anecdotally speaking, I have seen companies with real money on the line using happily the cloud and establishing a nice symbiotic relationship.
But Athanasios, I can hear you, was not only recently that a major cloud provider suffered a major outage and another suffered a yet-to-be-determined-fully security breach? Let’s dig into this argument further by using an analogy I overheard: Banks around the world are robbed every single day, yet people use financial products daily, as opposed to keeping money under the mattress. To move back into the sky, using a cloud provider does not automatically mean the provider itself is immune to severe outages and breaches (with variable blast radius). Your Business Continuity Plan and your Threat Model (you do have a threat model, right?) MUST account for items like this, even if the only possible response to such a catastrophic event is “call it an early day and drink pina coladas and pray we still have a job to go to tomorrow”. Assuming this can and will never happen is ignoring a danger, however, depending what is on the line, designing specifically from day 1 to address such a catastrophic failure might be a suboptimal use of resources (again, YMMV depending according with what is on the line).
My biggest pet peeve with some of the commentary I heard was a war story on how “old school thinking and processes saved the day”. I have no reason to doubt the authenticity of this story. Yet, one of the biggest misconceptions when it comes to cloud security is that you do not have to adjust your workflows and processes – you put your workloads into the cloud/container/Kubernetes and whatnot and magically they are more secure.
Cloud providers provide security countermeasures across the whole stack – most of them invisible to the end user such as internal use of cryptography, software security for the backend components, you name it (remember: shared security model) and a number of them available to the end user, sometimes as a free configuration option, sometimes with a cost attached (again, shared responsibility model). While sometimes these defenses are cumbersome to configure and quite often cloud providers do not default to secure defaults (Hello S3 until recently!), they are there to be utilized. By splitting the cost of developing and maintaining said defenses across clients, each client pays a little on one hand and gets access to defense capabilities that normally would have been out of pocket. This requires a paradigm shift from the “old world”, a thorough understanding of what is on offer and a proper risk analysis. “Lift and shift” (including processes) just will not cut it. Furthermore, when the 0-day du jour appears (and remember, these days not even CPUs are immune to 0-days), cloud providers potentially will have a much better response and centralized coordination than your local ISP.
Last but not least, stating that the cloud has no resiliency is inflammatory at best and I will treat it as such, giving no further comment.
Is the cloud a magical panacea? No. Is every workload suitable for the cloud? Again, no. The cloud itself can draw significant criticisms in multiple dimensions, complexity, cost, whatever you pick. But at least, let’s try to make an informed argument. We need it.
Athanasios Kostopoulos 
1 comment