Cloud-native breaches occur when an adversarial actor gains access to a cloud customer’s resources, locates valuable data, and steals that data. The mechanics of how a cloud-native breach occurs differ greatly from the on-premises data breaches that we see targeting data centers, networks, and devices. Let’s start with the fundamentals of security in the cloud to get to the core of the difference.

When a company becomes a customer of a cloud service provider (CSP) for compute, storage, database, and many other fundamental elements of IT infrastructure, they agree to a “Shared Responsibility Model” for security. The divide of responsibility between the CSP and the customer looks like this:

Cloud Security Shared Responsibility Model

In all cases of public cloud services, the CSP is responsible for securing the cloud itself, and customers are responsible for how they use it. With software-as-a-service (SaaS), that use is refined to user access and the data that enters the cloud. As you move to platform-as-a-service (PaaS) and infrastructure-as-a-service (IaaS), the customer responsibility grows, as they are now building their environment from the network up, inclusive of operating systems and applications, all of which are the customer’s responsibility to configure and use securely. CSPs can’t predict how every individual customer will use their environment. Only customers know the intricacies of what they put in the cloud.

This freedom to build with the scale and agility of the cloud also comes with limitless opportunities for error. Cloud-native breaches capitalize on those errors and leverage the native features of the cloud to execute their attack, often without the cloud customer ever noticing. Let’s now move on to a more detailed definition:

Cloud-native breaches are a series of actions by an adversarial actor in which they “Land” their attack by exploiting errors or vulnerabilities in a cloud deployment without using malware, “Expand” their access through weakly configured or protected interfaces to locate valuable data, and “Exfiltrate” that data to their own storage location.

In on-premises attacks, the most common method of entry is landing malware on a victim device and expanding from there. That works because of the prevalence of operating systems with well-documented vulnerabilities. In the cloud, there may not be a Windows, macOS, Linux, or even Android operating system to compromise. Instead, attackers more frequently exploit errors in configuration or use stolen credentials for direct access.

Three stages of cloud-native breaches

  1. Land by gaining a foothold into the IaaS/PaaS environment.
    1. Leverage compromised/weak credentials to gain access as a legitimate user.
    2. Exploit a vulnerability, such as server-side request forgery (SSRF), in deployed software.
    3. Capitalize on misconfigurations of ingress/egress security groups.
  2. Expand by finding ways to move beyond the landing node.
    1. Leverage privileges associated with a compromised node to access remote nodes.
    2. Probe for and exploit weakly protected applications or databases.
    3. Capitalize on weak network controls.
  3. Exfiltrate data while staying under the radar.
    1. Copy data from the storage account to anonymous nodes on the internet.
    2. Create a storage gateway to gain access to the data from a remote location.
    3. Copy data from the storage accounts to a remote location outside the virtual private cloud (VPC).

Cloud-Native Breach (CNB) attack chain

To understand how companies are vulnerable at each stage, let’s look at a few statistics:

  1. Land: 99% of the misconfigurations in enterprise IaaS environments go unnoticed. Companies think they have 37 misconfigurations every month, yet actually experience closer to 3,500.
  2. Expand: 58% of companies experience privileged user threats every month, averaging seven per month in IaaS.
  3. Exfiltrate: Companies actively assessing their data exfiltration attempts in IaaS currently see an average of 5,314 events each month.

Three recommendations to help prevent cloud-native breaches in cloud environments

We’ve entered a new reality for enterprise infrastructure, and we should expect it to change more rapidly than ever before. The capacity to upgrade, innovate, and deploy new technology is no longer a constraint. Instead, companies have access to the global CSP teams at AWS, Microsoft, Google, and other companies that are rapidly upgrading, innovating, and making it easier and faster to deploy infrastructure than ever before.

Build IaaS configuration auditing into your CI/CD process
Do it early—preferably at code check-in—to minimize the misconfigurations that make it into production. Look for security tools that integrate with Jenkins, Kubernetes, and others to automate the audit and correction process.

Evaluate your IaaS security practice using a framework like “Land-Expand-Exfiltrate”
This helps you check controls against the entire attack chain, increasing your likelihood of stopping a breach.

Invest in cloud-native security tools and training for security teams
Cloud tools and training help security teams understand cloud infrastructure at the same level as their DevOps counterparts. Security tools, like cloud access security brokers (CASBs), cloud security posture management (CSPM), and cloud workload protection platforms (CWPPs) are built to work within DevOps and CI/CD processes but are not replications of on-premises data center security. They require new knowledge that goes hand in hand with cloud transformation.