3 Myths About Cloud Security – InApps Technology 2022

Prisma, from Palo Alto Networks, sponsored this post, following its Cloud Native Security Live, 2020 Virtual Summit held Feb. 11, 2020.

“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. In the case of cloud security, there are many. 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 datacenter

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 datacenters?” 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 datacenters, which were purpose-built around specific workloads e.g., 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 e.g., 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.

Insecure Terraform template: SSH service on port 22 exposed to the entire Internet.

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 #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 customers’ 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 IaaS & PaaS security as early as 2013 with startups such as Evident.io, RedLock and Twistlock having led the pack.

Conclusion: Never Trust, Always Verify

As Ganeen said: “We must not be hampered by yesterday’s myths in concentrating on today’s needs.”

Ganeen’s words certainly hold 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:

1. Advocate for zero-trust security models, which follow the mantra “Never trust, always verify”.
2. Promote and encourage automated and scalable security through IaC templates.
3. 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 insight from security thought leaders, Cloud Native Security Live, 2020 Virtual Summit is your opportunity to learn from the experience and expertise of developers, DevOps pros and IT leaders who all have so much at stake in container technologies and DevSecOps. Hosted by Prisma, from Palo Alto Networks, in partnership with InApps Technology, you can still virtually attend this event held Feb. 11, 2020, for a full day of discussions about cloud native security — brought to you online wherever you may be.

Image from Pixabay.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Unit.