Breach Path Prediction: Getting Ahead of Cloud Breaches

According to IDC, spending on cloud IT infrastructure will reach $95B in 2023 and will account for 58% of total IT infrastructure spend. We expect this number to be higher as this estimation was prior to the Covid-19 pandemic, which has accelerated the journey to the cloud for many organizations. Moreover, cloud infrastructure is evolving from traditional network, storage, and comput to include new technologies such as serverless, containers, and servicemesh.

Along with the rapid adoption of cloud infrastructure, more than 30 billion records have been exposed in cloud breaches over the last two year. While it may appear that enough has not been done to curb these breaches, it is quite the contrary. Cloud service providers continue to bolster capabilities that enable organizations to implement tighter controls, and many organizations have invested in one or more cloud security tools.

The crux of the issues lies in the fact that as the cloud native stacks become more complex, the attack surface increases and it becomes harder to detect and remediate potential breach paths. While on the surface it may appear that many cloud breaches are the result of simple misconfigurations of cloud infrastructure such as storage services, the underlying attack kill chains are fairly complex. For example, in the 2019 breach at Capital One where over 100 million individuals were affected, an attacker got hold of a set of AWS access keys by exploiting a server vulnerability. The keys were associated with an IAM role with excessive permissions that enabled the attacker to find a S3 bucket and exfiltrate the data within it.

Our research team released a research report on the “State of DevSecOps” to study current cloud security practices across organizations. Amongst other findings, the research revealed that high severity risks such as open security groups, overly permissive IAM roles, and exposed cloud storage services constituted 67% of the issues.As we mentioned earlier, these types of risks have been at the core of many cloud breaches and are particularly worrisome. This prompted our team to take a deeper look at cloud deployments and uncover potential breach paths. In this and subsequent blogs, we will share details of breach paths that organizations should be mindful of. This blog in particular focuses on a potential breach path that we have dubbed as “network route drift”.

Quick Primer on Breach Path Prediction

A kill chain is a representation of the tactical landscape of an attack in phases or sequences. Figure 1 below illustrates the phases of the intrusion kill chain which begins with reconnaissance and ends with actions on objective.

Figure 1: Phases of the Intrusion Kill Chain

A breach path is an attack path aligned with kill chain phases that ultimately enables attackers to achieve their objectives which may include operational or financial damage, data exfiltration, or hacktivism/activism.

A threat model provides visibility into risks by analyzing cloud architectures and existing security controls. Gaps in security controls are mapped to attack techniques/vectors. Common frameworks used for threat modeling are the MITRE ATT&CK® Matrix for Enterprise covering cloud-based techniques as well as the Common Attack Pattern Enumeration and Classification (CAPEC). Accurics researchers leveraged these frameworks as well as proprietary threat models for their breach path research.

Breach path prediction involves building threat models based on the existing cloud architecture and security controls, and mapping against the various phases of a kill chain. The results are then further enhanced with third party threat intelligence data to predict an attack path that can provide adversaries a breach path to accomplish their goals.

The “Network Route Drift” Breach Path

Most organizations today use Virtual Private Clouds (VPC) that consist of multiple subnets to host their applications. Typically within the VPC, there is a public subnet which is attached to an internet gateway and the application resides here. A private subnet within the VPC is used to create a demilitarized zone (DMZ) and sensitive resources such as databases are placed within it. In order for the application in the public subnet to communicate with the database in the private subnet, a route must be created between them.

As organizations move to infrastructure as code (IaC), the resources in the above architecture (VPC, subnets, and routes) are defined through code. All it takes is a simple misconfiguration in the code to accidentally change a route (i.e., create “route drift”) and expose the private subnet containing the database to the internet and create a breach path.

This type of breach path is rather difficult to detect by simply monitoring for violations of policies based on best practices such as CIS benchmark. Instead, context is required to trace the attack path from the route change which is associated with the private subnet that contains the database. This can be very challenging as organizations often have numerous VPCs, subnets, and route tables to manage.

The “route drift” breach path was identified using the following steps:

Connected to the code repository where the infrastructure as code is hosted and scanned it to render a near real-time topology of the cloud infrastructure. Below is a snippet of the code that was used to provision the route table and subnet for the infrastructure described above. While the sample code is fairly easy to understand, the challenge lies in the fact that cloud native architectures are becoming more complex and there are hundreds of lines of such code. This makes it difficult to visualize topologies, connect the dots between resources, and develop a threat model by assessing existing security controls to identify potential breach paths.

Figure 2: Sample Infrastructure as Code

Assessed the existing security controls and built a threat model using attack frameworks such as Mitre, CAPEC, and proprietary data to identify exposures as illustrated below. In this example, we uncover a number of threats resulting from missing security controls such as SSH port is exposed to the internet and RDS (database) encryption is not enabled. This is a good first step towards understanding the risk factors in the cloud architecture. However, it still does not answer the question whether or not there is a full breach path in the architecture.

Figure 3: Real Time Threat Modeling

Mapped the threats to an attack kill chain and determined if a clear path exists that progresses from the reconnaissance stage to the actions on objective stage. In this example, a sample breach path may involve an attacker getting access to the cloud deployment through the open SSH port (reconnaissance) and delivering a malicious payload (delivery). Then the open route from the public subnet to the private subnet with the RDS (database) enables exploitation. In this instance, the database is not encrypted, enabling easy data exfiltration.

Figure 4: Map Threats to Kill Chain to Identify Breach Path

Assessed the downstream impact and the blast radius of the potential breach path by reviewing adjacent resources and dependencies. In this example, we used the threat graph below to trace the threat using the connected pathways emerging from the internet gateway. We see that there are a number of connected resources to internet gateway such as subnets, route tables, and eventually EC2 and RDS instances, indicating high severity risk.

Figure 5: Blast Radius Assessment

Key Learnings

As organizations move to provisioning and managing infrastructure through code, it creates an opportunity for organizations to programmatically detect potential breach paths in the code before cloud infrastructure is provisioned. IaC should be continuously monitored in order to ensure that as soon as a change is made to the code that introduces a breach path, it is detected and remediated. This dramatically reduces the attack surface and provides an opportunity for organizations to finally get ahead of cloud breaches. The challenge is that cloud native architectures are becoming more complex which makes it difficult to visualize topologies, connect the dots between resources, and develop a threat model by assessing existing security controls to identify potential breach paths. Organizations should invest in tools that can provide this capability in an automated fashion.

The Accurics’ research team will continue to study cloud deployments and share learnings about emerging breach paths as we uncover them. Read the “State of DevSecOps” report for more research and best practices from the team.