To Err is Human, and That is What Hackers are Counting On

Originally published January 20, 2022 on Fugue’s website.

Written by Josh Stella.

Read the first blog in this series here.

It’s understandable if you’ve made thwarting ransomware your top cybersecurity priority for 2022. The number of successful ransomware attacks, which encrypt computers until victims pay the attackers to unlock their data, surged last year. Ransomware payments reported by banks and other financial institutions totaled $590 million for the first six months of 2021, surpassing the $416 million for all of 2020.

When it comes to protecting your data center and endpoints (e.g., employees’ laptops and mobile devices), ransomware should be top of mind. But when securing your cloud environments, don’t worry about ransomware — worry about the misconfigurations that lead to devastating data breaches.

It’s a lesson that companies like Twitch learned the hard way in 2021. In just the past year, 36% of companies suffered a serious cloud security leak or breach due to cloud misconfiguration, according to The State of Cloud Security 2021 Report. Gartner expects that through 2023, at least 99% of cloud security failures will be the customer’s fault, mainly in the form of cloud resource misconfiguration.

These frightening statistics should raise a couple of questions in the minds of all business leaders and security professionals: “What are cloud resource misconfigurations?” and “How do we identify and eliminate misconfigurations?”

A New Security Paradigm

First, it’s critical to understand just how different the cloud infrastructure is from the data center. Developers and engineers build their own cloud infrastructure when they need to without requiring any assistance from the data center team. They can make and constantly change their own infrastructure decisions, including security-critical configurations. Every change creates the risk of a misconfiguration left open to attack.

Cloud computing is driven by application programming interfaces (APIs) — the software “middlemen” that allow different applications to interact with each other. This eliminates the requirement for a fixed IT architecture in a centralized data center. It also means that you cannot apply the data center security model of creating an outward-facing barrier around the network perimeter to identify and block incoming attacks.

The control plane is the API surface that configures and operates the cloud. For example, you can use the control plane to build a container, modify a network route, and gain access to data in databases or snapshots of databases (which are actually more popular among hackers than breaking into live production databases). Put simply, the API control plane is the (ever-growing) collection APIs used to configure and operate the cloud.

Why the Cloud Can Be Immune to Ransomware

The qualities that make cloud infrastructure so different from the on-premises data center are also what make it virtually impossible for hackers to launch successful ransomware attacks against your cloud systems.

The goal of using ransomware isn’t to steal your data; it’s to lock you out from accessing it until you pay the attacker. The cloud is built on extremely high levels of making sure you know data doesn’t get corrupted and making sure that data is accessible. The priority for all cloud platform providers like Amazon, Google and Microsoft is to ensure your data is robust and resilient.

For example, Amazon Web Services’ S3 data storage service boasts “11 9s” (99.999999999%) of reliability. Amazon stores your data in multiple physical data centers to ensure redundancy. Your data remains easily accessible even if one or more of Amazon’s sites go down. Creating so many copies negates the ransomware attacker’s ability to lock you out of your data.

But in your data center, your resiliency and redundancy are likely much lower because it’s prohibitively expensive to try to replicate what cloud providers offer by constructing private networks and multiple data centers.

That’s why security in the cloud is a function of design and architecture, not monitoring and intrusion detection. By the time you’ve detected something, the damage has already been done a long time ago. One hundred percent of the time, hackers are trying to find and exploit misconfigurations in order to get to the control plane APIs.

Misconfigurations Minor and Major

A misconfiguration is anything that proves ineffective at stopping a hacker. These vary from individual misconfigurations including simple, small things such as leaving a dangerous port open or not patching a server to significant architectural problems.

Usually, when you see large blast radius attacks such as the 2021 Twitch breach, which crossed over source code, business secrets, and user data, the cause was not that a single thing was configured improperly. The design of the system architecture was deeply flawed, and that is also considered a misconfiguration. That’s what another name for misconfiguration is — naive or bad design.

The bad news: I guarantee that your organization has both kinds of misconfigurations in your cloud environments. The good news: All are 100% preventable.

The More You Know

If you really want to know what’s going on with your cloud security posture, pay close attention to the news. Every time you see reports of a new breach, ask your security team to prove that your cloud environments are not vulnerable to that style of breach.

Consider the 2016 breach Uber suffered after the attackers discovered long-lived API keys residing in GitHub repositories. After that news broke, you would have asked for assurance that no API keys — not a single one — that are more than a month old present any potential value to hackers. If the security team can’t provide that, you are vulnerable to an Uber-style breach.

That requires more than simply running down checklists that your security solutions vendors provide. Checklists are reassuring. People like ticking off boxes. But too often, that does little more than breed overconfidence among security personnel. And the checklist of things to examine to ensure there are no misconfigurations in your cloud resources would be very, very long.

Ninety percent of hacking is discovery, and more than 90% of defending is knowledge. To gain knowledge, you must understand the threats. The only strategic way to do so is with Policy as Code.

Policy as Code

When developers build applications in the cloud, they’re also building the infrastructure for the applications as opposed to buying a pile of infrastructure and shoving apps into it. The process of building cloud infrastructure is done with code, which means developers own that process, and this fundamentally changes the security team’s role.

In a completely software-defined world, security’s role is that of the domain expert who imparts knowledge to the people building stuff — the developers — to ensure they’re working in a secure environment. The way you can do that is with Policy as Code, which enables your team to express security and compliance rules in a programming language that an application can use to check the correctness of configurations.

Policy as Code is designed to check other code and running environments for unwanted conditions or things that should not be. It empowers all cloud stakeholders to operate securely without any ambiguity or disagreement on what the rules are and how they should be applied at both ends of the software development life cycle (SDLC).

Automate Misconfiguration Remediation

At the same time, Policy as Code automates the process of constantly searching for and remediating misconfigurations. There are no other approaches that in the long run are successful at this because the problem space keeps growing. The number of cloud services keeps growing, the number of deployments you have, and the amount of resources keeps growing. And so you must automate to relieve security professionals from having to spend their days manually monitoring for misconfigurations and enable developers to write code in a way that is flexible, that can be changed over time, and that can incorporate new knowledge, such as the latest big data breach that makes news headlines.

To have a holistic response, one that actually works and isn’t merely security theater, you need to use Policy as Code at the development phase, in the continuous integration/continuous delivery (CI/CD) pipeline, and in the runtime. And as you gain maturity, these things can then be institutionalized and built into your processes so that it’s all automated.

What Success Looks Like

Organizations that have implemented effective cloud security programs share some characteristics that any enterprise can emulate to harden their cloud security postures.

First, they deploy automated tools to gain constant situational awareness about what is happening in the cloud. After all, the hackers use automation too so they can quickly search for and identify misconfigurations. The enterprise that still relies on manual processes and checklists gives the bad guys a significant advantage. Knowing the environment is critical to securing cloud infrastructure.

Second, they prioritize prevention over passively monitoring for and reacting to possible intrusions and other suspicious activities. Today’s hacks are too fast and too difficult to notice as they’re occurring.

They also enlist the developers and engineers — the people actually building these applications and systems — in the process by empowering them with tools, specifically, Policy as Code.

Finally, successful organizations quantify how successful they are at preventing hacks that could potentially happen and using that data to improve their processes.

---

About the Author

Josh Stella is a technical authority on cloud security and chief architect at Snyk, the leader in developer security. Josh brings 25 years of IT and security expertise as founder and Chief Technology Officer at Fugue (acquired by Snyk), Principal Solutions Architect at Amazon Web Services, and advisor to the US intelligence community. Josh’s personal mission is to help teams and organizations think differently about cloud security and prevent modern cloud attacks and data breaches. He wrote the first book on Immutable Infrastructure (published by O’Reilly), holds numerous cloud security technology patents, and hosts educational Cloud Security Masterclass video series. Connect with Josh on LinkedIn and via Fugue.