Using Cloud Securely — The Config Doom Question – Source:

using-cloud-securely — the-config-doom-question-–

Source: – Author: Anton Chuvakin

Using Cloud Securely — The Config Doom Question

First, “Use Cloud Securely? What Does This Even Mean?!” and “How to Solve the Mystery of Cloud Defense in Depth?” (and “Where Does Shared Responsibility Model for Security Breaks in the Real World?” too) would make for good “recommended reading” here.

Use Cloud Securely? What Does This Even Mean?!

At this point, it is clear that most discussions on using cloud securely or secure use of cloud computing include the dreaded configuration question — or, rather, a misconfiguration one. According to most industry reports, a vast majority of cloud security incidents and data breaches stem from misconfigurations. Cloud misconfiguration is a broad term that refers to any error in the configuration of a cloud environment that could lead to a security incident or has other security implications [A.C. — from the style of this, you can probably tell that Bard wrote this 🙂]

By the way, as others wisely point out, talking about “the cloud” and “cloud security” is often counter-productive, but here it actually works: this issue spans IaaS, PaaS, SaaS and whatever in-between models we have.

Now, let’s couple this with the classic Gartner line that “99% of data breaches in the cloud are customers’ fault.” To me, these statements together indicate that customers do not know how to configure cloud services securely (and naïve and “blamy” view is: this is their fault).


Let’s explore this together! I promise it will be fun.

First, what is interesting about this issue is its age. Technology underlying modern hyperscale cloud environments changes rapidly, but security misconfigurations became the key cloud security problem at least 10 years ago, and possibly 15–17 (!) years ago, and stayed “top of the charts” for all this time (public cloud computing was born, depending on who you ask, in 2006–2008).

In fact, 10 years ago, the very first vendors that looked at these problems were born; they were later called CSPM for cloud security posture management (Bard thinks that the term “CSPM” was born in 2013, but I have a sneaking suspicion that my former colleagues cooked it up a bit earlier).

Today, this movement gave birth to many “SPM acronyms” — such as data security posture management (DSPM), SaaS security posture management (SSPM) and even a recent application security posture management (ASPM). Aren’t you happy that we don’t have Posture Management Security Posture Management yet? The original CSPM focused on identifying security configuration problems in cloud environments, mostly looking at the cloud infrastructure (not workloads, that’d be CWPP; later CSPM and CWPP got together with some AppSec and formed an unholy marriage called CNAPP, but who am I to judge?).

This means we have been aware that insecure configurations ruin your secure cloud experience for at least 10 years. What is actually going on here? They’re several schools of thought about this.

Those Pesky Humans Will Misconfigure Anything

Let’s start from a very general “people will misconfigure anything” argument.

Have we truly fixed Linux and Windows server misconfiguration? No, we have not. Yet I reckon that while they play a role in security incidents, they don’t plan an outsized role that cloud misconfigurations do. Similarly, to compromise a modern mobile device, you probably would use social engineering or an exploit, not a configuration weakness. Thus, this explanation is not “the Answer.”

Insecure Defaults

The lack of security defaults comes up a lot. If only they (well, in this case “they” includes “us”) would ship cloud services that are magically secure out of the box. This is fair, to an extent. However, “secure but usable” is occasionally very tricky — one can always pick easy examples (“how can those idiots make it public by default”), but for every easy case, there are probably 10 cases where “it depends” reigns supreme. Still, to me, secure defaults are a big part of the answer, but likely isn’t the Answer.

1990s IT Practices in 2020s Cloud

Other explanations focused on the fact that many organizations practice cloud computing the way they practiced data center IT. This means that they’re trying — unsuccessfully — to apply their mental models from the 1990s to the 2020s environments. A quarterly “scan -> report -> scream at IT” security workflow never truly worked in the “sloth-slow” world of data center IT, and it very obviously will never work in the lightning-fast world of cloud. So, slow manual approach + fast cloud = things don’t get configured securely in time. To me, this explanation is probably part of the answer.

Lotta Cloud

There is a lot more cloud now compared to 10 years ago when CSPMs were born. Cloud providers release new services at an impressive pace. So the cloud today is a lot larger and a lot more diverse which causes more knowledge gaps with how to secure it.

Ultimately, if you had several years to learn how to secure a particular cloud service (even a complex one like say BigQuery or, I dunno, Azure Cosmos DB), the outcome would likely be achieved. However, major cloud providers have hundreds of services and new ones appear every year. This is definitely part of the answer.

Cloud Changes

This has a scary side-angle: cloud changes. While I often make a throwaway remark “learn cloud IAM” (and that is still good advice BTW!), the reality is that I should have said “start learning cloud IAM and keep doing that” as IAM changes (it is also quite different across the 3 “real” public clouds). And, yes, misunderstanding the role of IAM for cloud security hurts too. Rapid pace of cloud changes likely is part of the answer.

It’s Developers Fault

Some people attribute misconfiguration challenges to the fact that the cloud is ultimately a developer-led environment (“blame developers”). While this is hotly debated — the view that developers don’t care about security — it is very clear that environments that are not just programmable, but also run by programmers who program them a lot are harder to secure [A.C. as you can judge by the style, Bard did not write this]

We Know the Problems, But We Can’t Fix Them…

This comes up a lot, and this is scary! Some would say that cloud misconfigurations are in fact not that difficult to discover [Exhibit A CSPM again .. so 2013, yet so now!] but in many environments they are hard to remediate. This is even more true in places that never figured how to add “Sec” to “DevOps” [laugh all you want at SecDevOps and DevSecOps terms, but unless your DevOps includes security, you really are screwed…]

What to do?

What are possible solutions to this conundrum? This is going to be a bit vague and incomplete, because, hey, this is a personal blog and all that…

  • Naturally, secure defaults. However, secure defaults aren’t the entirety of “secure by design” and they are a big step, not the journey.
  • Making security controls dramatically easier to deploy — this applies to both cloud service providers and third party security vendors.
  • Various frameworks and guardrails, secure landing zones and other “inevitably secure” tools in the cloud would play a role as well.
  • IaC and PaC play a big role due to easier “automatability” of security.
  • Finally, shared fate aka “cloud providers helping clients more with security on their side of the shared responsibility” is also a big part, I think.


Related blogs:

Using Cloud Securely — The Config Doom Question was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from Stories by Anton Chuvakin on Medium authored by Anton Chuvakin. Read the original post at:——2

Original Post URL:

Category & Tags: Cloud Security,Security Bloggers Network – Cloud Security,Security Bloggers Network


Leave a Reply

Your email address will not be published. Required fields are marked *

ciso2ciso editor´s picks

More Latest Published Posts