Cloud Security: 12 Myths vs Facts

By, Gui Alvarenga, Cloud Security Product Marketing

As cloud technology expands in both worldwide use and the complexity of offerings, some myths persist. At Check Point, we put our heads together and created the following list of the most common cloud security myths, followed by the conflicting realities.

1. The More Security Tools You Have, the Better

On the contrary, more security tools simply don’t equal more security. According to The Oracle and KPMG Cloud Threat Report 2020, 70% of those surveyed report too many tools are needed to protect public cloud environments. On average, each uses more than 100 discrete security controls. Multiple security vendors, providing disparate solutions, blocking on different attack vectors all results in gaps. And those gaps create access points for attackers.

Too much cloud complexity +
Too many different security solutions +
Solutions not cooperating =
No shared intelligence or architecture, gaps, and risk

To overcome these gaps, it is imperative to implement tools and resources to help simplify the security management of the cloud and take control of security.

2. Security is the Cloud Provider’s Responsibility

As a cloud customer, the end user organization retains responsibility for securing the data they put in the cloud in the well-known, “shared responsibility model.” In securing cloud native infrastructure, it’s vital to understand exactly where the responsibilities lie, considering your responsibilities vary depending upon the services you’re consuming.

There are many different ways to protect your data in the cloud, and organizations are failing to do the vast majority of them.

3. Successful Breaches Result from Sophisticated Attacks

While it’s true that highly sophisticated attackers exist, the reality is that their growing sophistication is not the reason behind most successful attacks. Errors and misconfiguration on the part of the end users are what drive the vast majority of attacks.

Gartner predicts that, through 2025, at least 99% of cloud failures will be the customer’s fault.

Movies may portray a Mission Impossible-style thrilling scene with attackers ducking under lasers and successful cracking the code to the vault door. But reality is more akin to a lucky thief simply encountering an unlocked door at the opportune moment – because the last person who closed the door failed to spin the dial.

In fact, Sergio Lourerio, cloud security director at Outpost24, said: “We are still in the early days of cloud infrastructure security and what we are seeing is a prevalence of opportunistic, not very sophisticated attacks, such as looking for publicly accessible AWS S3 data buckets.”

4. Cloud Visibility is Easy

You’re paying to use cloud resources, so you must know precisely what those resources are, as well as all the relevant info, such as:

  • How many accounts do we have?
  • Did the developers add machines, new functionality, or connect to the outside world?
  • Who put that there?
  • Is it configured properly?
  • Does it have vulnerabilities?
  • Can I stop them before it hits runtime environment?

Unfortunately, all this info is much harder to keep track of than many realize. Without visibility into how resources should behave, you can’t observe when that behavior deviates. Without consolidated dashboards, it’s very difficult to identify and act on threats in a timely manner.

(And that’s saying nothing of the importance of visibility in ensuring you achieve compliance with laws and relevant industry standards. Oh, and the little issue of money – making sure you’re not paying for more than you’re using.)

5. Security is Best Left to Security Pros

As opposed to isolating security to the purview of dedicated security pros, best practices include making security everyone’s problem. For example, shift security left in the software development lifecycle, implementing security during development, rather than waiting for deployment, or worse, after deployment. Make developers part of the process rather than taking an adversarial approach. Offer developers self-service functionality to assess security of a stack they’re about to deploy, and provide tools to auto-remediate issues before they go into production..

6. The Cloud is Inherently More Secure

Actually, this one isn’t really a myth, but rather a factoid: a bit of truth, and a bit of falsehood all wrapped together.

Truth Fueling the Myth:

Cloud providers are generally more reliable at tasks like patching servers. Leaving it up to them makes sense and trust in cloud service providers is deservedly high. In, The Egregious 11, The Cloud Security Alliance (CSA) outlines the top threats to cloud computing. Recent survey responses showed a significant drop in the ranking of traditional cloud security issues under the responsibility of cloud service providers. Concerns dropped so low that CSA chose to exclude them from the latest report.

Cloud Security Concerns Busting the Myth:

Securing everything across multiple clouds involves securing access, managing identities, and constant auditing, to name just a few. Increasing sprawl of workloads across multiple public and private clouds results in difficulty obtaining visibility and a lack of end to end context around risk. These challenges are only exacerbated by the security gaps inevitable with disparate solutions.

Additionally, serverless technologies fragment your app to smaller components that are callable. This shift, coupled with the use of event-based triggers from diverse sources (such as storage, message queues, and databases) means attackers have more targets and more attack vectors.

7. You Must Slow Down Developers to Be Secure

Taken from an article in Computer Business Review, “Developers should be empowered with plug-ins that trigger security and compliance controls at every step of the DevOps process, exposing the results right within the tools they commonly use to enable rapid remediation of the vulnerable code.”

In addition, remediation steps must be automated whether to fix issues or streamline security processes. Enable developers to do their jobs securely, without adding work, like providing tools to automate tasks, such as generating permissions for serverless functions. Take steps to remove friction as opposed to slowing things down.

8. Security Automation is Ideal, Rendering Human Oversight Archaic and Unnecessary

Again, a “factoid” here that mixes truth and fiction. The true security ideal is a combination of automation and human oversight.

The 2020 State of Pentesting report examined which web application security vulnerabilities can be found reliably using machines versus human expertise. “The study found that both humans and machines bring value when it comes to finding specific classes of vulnerabilities. Humans ‘win’ at finding business logic bypasses, race conditions, and chained exploits, according to the report.”

9. Security of SaaS Apps is Managed by the SaaS Provider & Requires None of Your Attention

Unlike IaaS, SaaS apps indeed don’t require your efforts to patch servers. As the end-user, you simply grant access to the employees of your organization and let them run.

However, many SaaS apps will necessarily contain sensitive information. Users are often able to interact with files, including sharing and configuring access. And users granting access to others and not having that access rescinded when they leave your organization are indeed security problems that require your attention.

10. S3 Buckets Are Secure by Default

As a default setting, Amazon S3 buckets are private and can only be accessed by those who’ve been granted access. So, yes, they are secure. However, much like seatbelts, they’re of no help if not used.

And many data breaches result from misconfigurations such as merely making buckets public, or other errors like storing passwords in clear text in GitHub or S3 buckets.

According to Symantec’s 2019 Internet Threat Report, in 2018 “(AWS) S3 buckets emerged as an Achilles heel for organizations, with more than 70 million records stolen or leaked as a result of poor configuration.”

11. Containers and Serverless Functions are Inherently More Secure

Containers and serverless functions are designed to be ephemeral and tend to have short lifespans, which strengthens security. Attackers are unable to easily achieve long-term presence in your system.

While in essence, this statement is true, the use of event-based triggers from diverse sources means attackers have more targets and more attack vectors. Configured properly, these cloud native technologies absolutely can be more secure… but only if configured properly.

12. CVE’s Are the Only Vulnerabilities I Need to Care About

As already stated, growing sophistication is not the reason for most successful attacks. Therefore, it’s logical to focus on mitigating the risk of the most common attack vectors.

However, deliberately choosing to neglect security outside the scope of CVEs will, by definition, lead to increased risk. According to a report from Balbix, one of the 5 Kinds of Vulnerabilities that are NOT CVEs include misconfigurations, which, as stated, are the driver of many successful breaches.

As you can see, cloud security is riddled with myths, but once you unravel the myths, it is easy to uncover the facts and identify the strategies required to transform your business security into the cloud.