Breach path prediction: Breaking Kill Chains with Policy as Code
Breach path prediction is a way to group a sequence of individual violations or weaknesses into a “breach path” which an attacker can use to compromise your system. The idea is that individual weaknesses may not be exploitable or severe on their own, and identifying breach paths enables organizations to recognize the issues that may lead to a breach – and the easiest way to fix them.
In my last blog, I discussed the importance of automating security best practices, one of the principles of the AWS Well-Architected Framework‘s Security Pillar. One possible way to achieve this early in the development lifecycle is to implement Policy as Code checks on your Infrastructure as Code.
A session at RSA Conference 2020 discussed the top 10 cloud attack kill chains. Among the kill chains discussed there is a common problem which has been seen in many famous cloud breaches: “SSRF → Credential Abuse”. One such example is the Capital One breach in 2019 which exposed the personal information of over 100 million individuals.
In this blog post, I will discuss how to create a vulnerable AWS environment to simulate the above kill chain, use Lockheed Martin’s Cyber Kill Chain® framework for threat/attack modeling, and finally break the kill chain using Policy as Code.
Breach Path Prediction: Building a Vulnerable AWS Environment
The development process for most projects, from development to deployment, is similar to that illustrated above. Developers write Terraform scripts using an IDE, push that code to source code management software such as GitHub, where CI/CD pipelines deploy the environment to AWS.
For many engineers, the best way to learn about security and misconfigurations is through hands-on exploration. Having a “vulnerable by design” project can help demonstrate the problems as well as their impact. We created the open source project KaiMonkey to serve this need, and it includes the vulnerable scenario described in this post. KaiMonkey provides example vulnerable infrastructure to help cloud security, DevSecOps and DevOps teams explore and understand common cloud security threats exposed via Infrastructure as Code.
Identifying Breach Paths
Now that we have a vulnerable environment, we can go through the process of modeling threats and mapping the threats to the Cyber Kill Chain phases to identify the breach path.
1. Identify assets, corresponding entry points, and trust groups
If we look at the architectural diagram for our vulnerable environment, we see the following assets:
- Virtual Private Cloud
- Internet Gateway
- Route Table
- Security Groups
- Elastic Compute Instances
- Web Application hosted on EC2 instance
To model the threats in this environment, we need to consider how an attacker might access these assets. In other words, we need to identify their entry points. Some entry points will be attributes of the assets themselves, such as the security group associated with an S3 bucket, while entry points may also emerge from the relationships between assets, such as network routes. It is important to consider the overall architecture of the environment within which the assets will be deployed.
In our scenario, we have a web application hosted on an EC2 instance. Further, the subnet has a route that points to the internet gateway, so our EC2 is exposed to the internet. Note that some types of assets, such as S3 buckets, do not exist on the network per se, and thus are not affected by network routes.
Once we have identified our assets and discovered their corresponding entry points, it is time to group assets into trust groups based on their entry points. In our case, we have two EC2 instances which both have a route to the internet gateway, share the same VPC, and are in the same security group; they are in the same trust group.
2. Identify the threats
Identifying threats typically starts with asking “what can go wrong?” When you are provisioning your cloud infrastructure using IaC, misconfigurations in your Infrastructure as Code directly relates to threats. The screenshot below shows the threats associated with the assets identified in step 1:
Let’s focus on one of the threats (misconfigurations) in our Infrastructure as Code. In the screenshot below, you can see that our EC2 instance uses an
iam_instance_profile which uses a
role whose a policy allows permissive access with a wildcard
*. This does not follow the principle of least privilege and represents a threat.
3. Map threats to kill chain
The threats identified in earlier steps, when mapped to cyber kill chain phases, can give us a full breach path. The screenshot below shows the mapping of threats in our vulnerable environment, to assets, and then to cyber kill chain phases.
You can see that our threats map to a complete kill chain from Reconnaissance through Actions on Objective. All the capabilities necessary for an attacker to take control of this system are present, representing an extreme breach risk.
This blog post glosses over details for brevity. If you would like to see the full details, along with a demonstration of a successful attack which gains admin access to the AWS environment, please view our webinar recording.
Breaking the Kill Chain Using Terrascan
By recognizing breach paths, organizations can improve their ability to mitigate risks. It is not necessary to fix all of the threats; it is only necessary to break the kill chains so that attackers will not be able to compromise the system. Focusing on breach paths allows you to address the biggest risks with the least amount of effort. We generally recommend fixing threats in earlier kill chain phases, but understanding the entire chain enables you to make intelligent decisions about where you’ll get the most bang for your buck.
In the first part of this post, we described a typical CI/CD process which builds and deploys a vulnerable AWS environment. Incorporating Policy as Code tools such as Terrascan into the development process can help you identify threats early. To prevent such misconfigurations from getting deployed in your cloud environment, Terrascan can be used in the following ways:
- Install it on developer desktops and run before pushing your IaC to your SCM
- Leverage automated pipeline steps in your repository, such as GitHub Actions
- Integrate it into a discrete CI/CD tool such as Jenkins
Policy as Code can automate the process of threat modelling on Infrastructure as Code and help you shift your security left. Terrascan is an open source Policy as Code tool based on Open Policy Agent (OPA). It evaluates your IaC against 500+ security best practices policies and supports all common cloud technologies, including AWS, Azure, GCP, and K8s.
The following image explains how Terrascan policies map to the kill chain phases, enabling you to break breach paths.
We are continuously updating our policy packs to automate the detection of new kill chains as they are identified. If you have a new policy that you would like to see, please open an issue in our GitHub repo