“We must not be hampered by yesterday’s myths in concentrating on today’s needs.”
– Harold S. Ganeen, former president of ITT, U.S. business leader and IT pioneer
In every field and in every age, there are myths that develop over time. Some are instructive while others are destructive. There are many myths about security in the cloud. I cannot think of one more pervasive than “public cloud is more secure than an on-premises data center.” I should know because for the longest time I believed this myself.
But after working with hundreds of businesses around the world and laboring with the Unit 42 cloud threat research team to analyze petabytes of data, I now know it’s simply not true. Let’s dive in together and discover a better path forward.
Myth #1: The public cloud is more secure than an on-premises data center.
This is one that has been proclaimed by the cloud service providers (CSPs) for well over a decade. When organizations are surveyed, typically one of the top fears around security has to do with the cloud. So it plays well to sell the notion that the cloud is more secure than on-prem, where most compute exists today. But let’s be clear, CSPs have a largely stellar track record when it comes to securing their portion of the shared responsibility model. Instances like what is cited in this recent “Forbes” article are few and far between. This is the security of the cloud versus what customers are responsible for in the cloud.
I distinctly remember once in a previous role our CSO asking me, “Do you really think the cloud is more secure than our data centers?” To which I confidently responded, “Absolutely!” In retrospect, I was dead wrong. Because although the public cloud has the potential to be more secure than a traditional datacenter, most organizations do not have these environments configured that way.
In the 2019 Unit 42 Cloud Threat Report, Unit 42 researchers found that 65% of all cloud security incidents were the result of customer misconfigurations. Again, the cloud providers have done a good job at providing secure services (APIs, etc.) to cloud consumers. But they have room for improvement when it comes to offering integrated, comprehensive, platform-level controls back to cloud consumers.
In terms of the shared responsibility model, many organizations conceptually understand that they have security work to do in the cloud. However, they often fail to put the necessary processes and controls in place to make it happen consistently. Could there be an underlying psychological basis in this myth, or is it something else?
Myth #2: DevSecOps is just about adding “security” or “scanning” to DevOps.
I’ve included this one here because, from my experience, DevSecOps is synonymous with public cloud. Yes, it can include on-premises as well. However, we see this only in some of the most advanced environments that run API-driven workloads in highly customized private clouds (think entire data centers, which were purpose-built around specific workloads such as gaming).
DevSecOps is way more than simply running security scanners. DevSecOps is about completely changing how security, as a function, is planned and executed. In most organizations today, security is a distinct, isolated function. There is not much interaction happening between developers and security – except for when a new app is scanned a few days before a production launch and a slew of critical vulnerabilities are found.
The wheels begin to move toward DevSecOps when security teams, developers and IT teams alike advocate and deliver infrastructure and security as code. This is primarily done through immutable infrastructure such as Infrastructure as Code (Iac) templates such as AWS CloudFormation, HashiCorp Terraform and Azure Resource Manager (ARM).
Historically speaking, security teams and code did not go together. But in the cloud native age, it is imperative. And organizations are certainly moving in this direction. In the Unit 42 Cloud Threat Report: Spring 2020, researchers identified more than 199,000 vulnerabilities in IaC templates. CloudFormation templates were found to be the most vulnerable, with 42% registering at least one or more high- or medium-severity vulnerabilities. Certainly, IaC templates are a key component of a DevSecOps program. However, if a template itself is configured incorrectly, this then means the issue, unfortunately, will be replicated at scale.
Organizations looking to transform from DevOps to DevSecOps should concentrate first on people and process. In a recent webinar, I recommended five strategic steps organizations could take when making this move.
Myth #3: CSPs natively deliver all the security controls a company needs.
This myth is closely related to No. 1 but has a different rub. While the first is split with varying degrees down the shared responsibility model, this one hits squarely on what’s in the scope of the customer’s control (and concern).
When any service is provided to a customer, the business providing it has a duty to ensure adequate protections are in place from day one by default. Although cloud consumers have largely shirked their accountability in the shared responsibility model, CSPs could do more while still aggressively pumping out new features.
New functionality is the lifeblood of any platform, and businesses have come to depend on the innovation CSPs provide. However, if there aren’t equally useful and embedded security features with secure defaults as part of new functionality, something is amiss. Yes, CSPs have some basic security controls on their platforms, and they continue to enhance them over time. However, organizations need more than CSPs can deliver natively. In a recent Gartner survey of public cloud users, 81% of respondents said they are working with two or more CSPs. Enterprise-grade security requires visibility and controls that span multiple cloud providers as well as hybrid clouds. This is why an entire industry sprang up around Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) security as early as 2013, with startups such as Evident.io, RedLock and Twistlock having led the pack.
Defeat the Myths About Security in the Cloud: Never Trust, Always Verify
As Ganeen said: “We must not be hampered by yesterday’s myths in concentrating on today’s needs.”
This certainly holds true for the cloud. As security professionals, it is our duty to move our organizations forward into the cloud native world. This means we must do three things:
- Advocate for Zero Trust security models, which follow the mantra “Never trust, always verify.”
- Promote and encourage automated and scalable security through IaC templates.
- Adopt cloud native security platforms that work cohesively with multiple cloud service provider APIs, as well as integrate organically into development pipelines no matter where the pipeline lives.
In order to reap all the business benefits cloud has to offer, we must ensure that myths are dispelled with both facts and action.
There are countless other myths about security in the cloud. Which ones did I miss? Connect with me on LinkedIn and let me know.
For more insights from cloud security thought leaders, view sessions from the Cloud Native Security 2020 Virtual Summit for free and on-demand.
This post originally appeared on The New Stack.