Shifting Threat Modeling Left: Automated Threat Modeling Using Terraform

In this talk, Om looks at how to perform Architecture Risk Analysis and Automated Threat Modeling using Terraform code for container orchestration (Nomad) and service mesh (Consul) configuration code. You’ll also see how security vulnerabilities, misconfigurations, and compliance violations—when analyzed in the context of trust boundaries—can help uncover attack paths and risks.

Transcript

Welcome to HashiConf Digital 2020. I'm going to talk about Shifting Threat Modeling to the Left with Terraform today. A bit about me; My name is Om Moolchandani. I'm co-founder and CTO at Accurics. I'm a security enthusiast. I've been in the security space for over 15 years. I've worked in various security disciplines, such as DevSecOps, red teaming, compliance, audit, and threat intelligence. My favorite adversity technique for attack is waterhole attack. I love mechanical keyboards, especially zilents, switches and SA keycaps.

A little bit about Accurics: we provide codified cloud native security products that self-heal cloud infrastructures. That's why you're seeing a jellyfish out there, which reflects self-healing. We are a Bay Area-based company, and we are the primary contributor to the open source tool Terrascan. We also are a HashiCorp partner.

What Are We Going to Talk About Today?

We're going to talk about threat modeling. We're going to also talk about how we can perform threat modeling for cloud infrastructures using Terraform. We'll also be able to discover today how the rich data contained in Terraform code can be used as input for threat models. We're also going to see some demos on security analysis of Terraform code. We are also going to talk about threat modeling processes and how we can map threats to kill chains and breach paths — we're also going to look into a demo for that.

Threat Modeling

Let's jump in. We're going to quickly see the history of threat modeling. We're going to talk about what is a threat; we're going to look into what is a threat defense. We're also going to talk about — at a high level — how a threat model looks like. Oh, by the way, if you can notice the killer sea turtle, they are the top threat for the jellyfish. The jellyfish can self-heal if the turtle's attacking them.

What's The History of Threat Modeling?

Threat modeling techniques have been used in the context of attack and defense for a very long time. But in the computing space, threat modeling has become popular only in recent times. In 1977, the concept of architectural patterns was introduced by Christopher Alexander. That was a seminal work that introduced this concept of architectural patterns based on which — Robert Barnard, in 1988 — performed the first attacker profile-based analysis on an architectural pattern.

In 1994, we had Edward Amoroso creating the concept of threat-tree in his famous book called Fundamentals of Computer Security Technology. Then came our favorite threat modeling technique; STRIDE from Loren and Praerit in 1999. The time kept on passing by. Then, in 2020, we had a Russian gang approaching a Tesla employee and offering $1 million to plant malware.

What has that got to do with the history of threat modeling? Well, that's what the threats are. Did they threat model for this scenario? We're going to see a lot of different ways the threat models can be built and threats can be dealt with. In this talk today, you will see how the threats can be analyzed and how the threat modeling can be performed just by looking into Terraform code.

What Is a Threat?

Classical thought says a threat is something that can cause harm. But the more modern thought uses analytical nuances to define and describe the threat as something which has the intent, the capability, and the opportunity to cause harm.

But as a threat modeling practitioner, over time, I have taken the liberty to add my own nuances to it. In my opinion, a threat is a phenomenon or situation that is adversarial in nature and realization of which can cause damage or impact to the target. But then there is something else called a threat agent. An entity that can possess the skill, intent, motivation, and capability to project threats to cause harm or impact to the target. The examples are malicious cloud admin or internet based attacker.

What Are Threat Defenses?

They are defensive techniques that are countermeasures that can protect you against threats. They can be built into designs, whether software or hardware. The countermeasures can be implemented as security controls — such as preventive security controls, patching, hardening, access controls, encryption, etc. Detective security controls such as enabling logs, monitoring, IDS, etc. and also corrective security controls such as backup, recovery, and healing.

How Is Threat Modeling Performed?

Essentially a threat model is nothing but a matrix of assets, threats, and control countermeasures. In the context of cloud environment, what are the assets? These are your compute, network, storage resources, and other resources you build or provision using technologies like Terraform. Threat modeling process requires you to build flow diagrams and also identify trust boundaries and build them.

If I were to quickly talk about trust boundaries. A trust boundary — you can see on the right side — is a context which allows free flow of communication between the entities that are part of the trust boundary.

In this case, you can see a subnet, which is a trust boundary containing two assets, A and B. They can communicate with each other. That is a trust boundary. Trust boundaries can be formed based on network, identity, access, or privilege. But then the threat modeling process also requires you to identify security gaps and map them to attacker capabilities.

What Are the Attacker Capabilities?

They are reconnaissance, weaponization, delivery, exploitation, exfiltration, and others. When these security gaps are mapped to attacker techniques and when they are analyzed by plotting the trust boundaries and the flow diagrams together — that is when you can identify threats. These threats can then be identified for cloud infrastructures as well — which we'll see in the next few slides — how we can use Terraform to discover threats and perform threat modeling.

This is an example of an untrusted group, a subnet, which has an asset A — but the asset B is located outside of the subnet. Then you have a subnet. Which, if has access to a malicious admin — then the threat, which is available for this subnet, will be available for all the entities. That means a threat which is available to a trust boundary will be available to every asset located in that trust boundary.

What Are the Popular Threat Modeling Strategies?

Well, STRIDE — we all know about STRIDE; Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. These are some of the strategies which we can identify and apply to our threat modeling processes.

Then you have CAPEC, Common Attack Pattern Enumeration, and Classification. It's a project from MITRE, which is a very good library of attack patterns and can be used to identify threat techniques. It can be used as an attack library as well.

CAPEC is good for analysis of attacks and threats. MITRE also has another project called ATTACK, which is a very interesting framework, which also extends to the cloud now. It allows to map the tools, techniques, and procedures — otherwise also known as TTPs — from attack groups to attack phases.

Lastly, the kill chain from Lockheed Martin —  very popular technique again — it’s used to determine if you have different types of attack phases available in your model, which also maps to the attacker capabilities.

We're going to discuss today how we can use kill chain and ATTACK frameworks later in our presentation to identify threats and map them to these attacker capabilities and try and detect breach patterns.

Why Do We Want to Threat Model Using Infrastructure as Code?

First, we can gather data required for performing threat modeling on the cloud using Terraform code. In the next few slides, we will see how we can create asset inventory, relationships, configurations, identify network identity access and privilege-based relationships, and trust boundaries — just by analyzing the Terraform code.

And that's not all. Terraform code is also very useful in detecting security issues. We will be using open source tools today to identify those security issues and apply them to our threat models.

Resource Configurations

First things first; asset inventory and resource configurations. How do we identify that using the threat model? In this sample, you are able to see that the Terraform code contains the resource definitions and the configurations. If we were to build a database of all these resources and also these configurations, we can build a very good representation of all the assets that are being managed and built using Terraform code.

Resource Relationships

We need to identify various types of relationships to build context around the threat modeling process. In this example, there are two different Terraform files that I'm referring to — both for building an AWS environment.

One holds the information about a VPC, and the other one holds a relationship that the VPC has with the defined security groups. The second Terraform file on the right holds the information about the security group. This relationship later will allow us to build a network relationship diagram between the assets and the peered networked assets — because we understand how the security groups allow the communications to flow between one asset and the other. This is a specific example that we are talking about with respect to Terraform for AWS.

Network Relationships

How do we build network relationships? In this example, you can see the file on the left side contains a compute instance with the relationship to a subnet. Then the subnet is present in the other file. This allows us to identify if a given asset is based out of a particular subnet or not. If we record the subnet — we treat the subnet as a trust boundary — we know that this asset is part of this trust boundary. We take a record of it, and then we work more on that for analysis purposes.

Identity Access and Privilege Relationships

Next, is how to identify identity access and privilege relationships that are shared between different assets? In this example, we have a Terraform code — again from an AWS point of view — and we have an EC2 instance with an instance profile defined. The instance profile now has a role, and the role has a policy. This policy basically allows the S3 bucket access. So we can determine that, in this case, we have an EC2 instance which has an identity and access relationship to another S3 bucket.

This is very important information. As I was previously explaining, it is important to identify these relationships because the attackers are also spending a lot of time in your network to identify and detect exactly these relationships.

Once they identify these relationships, they take advantage of these relationships. Then they take advantage of the security gaps, which are available on these resources — which are sharing these relationships. That's how the attackers also move forward in their attack phases. As defenders, all we do is discover these relationships before the attackers do and uncover the security weaknesses that could have made any attacker successful. That is the threat modeling process — that's where threat modeling helps.

How Do We Identify Trust Boundaries Using Terraform Code?

In this example, we're going to talk about two Terraform files. One is instance.tf, the other one is route.tf. We note that the instance definition has a reference to a subnet ID. The subnet ID is associated to a route table, and then the route table association has a route. This route could have our internet gateway attached to it — or any other route that could be exposed to the internet. This way, we identify whether this EC2 instance is exposed to the internet or not. If it is exposed, it is part of which trust boundary? We exactly know what is a subnet which is containing this EC2 instance.

This relationship and this information is used to build the trust boundaries. This is very important when we are identifying security weaknesses on this EC2 instance — or the other resources — how these weaknesses can help attackers take advantage of these relationships.

KaiMonkey — An Open Source Resource

All the examples I was showing in the previous slides can be tried and tested and can also be played around with using our open source offering called KaiMonkey. KaiMonkey is a purposely built vulnerable library of Terraform code. This project allows you to provision a two-tier architecture on any cloud environment. Then it allows you to play around with the wonderful code. You can do this testing, and you can play around and identify the relationships that I was previously describing.

Security Analysis of Terraform

How do we identify security problems on all these different assets or resources that we've been discussing? Primarily we need to identify misconfigurations, vulnerabilities, and exposures on all of these assets that we've been discussing.

Once we have identified the relationships and created trust boundaries — and we have the asset inventory — we need to identify security misconfigurations so that we can superimpose on top of them to move forward in our threat modeling process.

Security Scanning and Analysis Using Terrascan

How do we perform that on Terraform code? Well, we have an open source offering —Terrascan — which can help you in this. Terrascan comes with 500+ security checks. It supports both Terraform as well as Kubernetes YAML files that you can use for performing the scanning.

In this quick demo, we're going to see how Terrascan works. You can see, we have a library of Terraform code — we did the ls on it. All the Terraform code is going to undergo the scanning using Terrascan. A simple command — terrascan scan – t aws — performs the scan, and it results in the violations. All the violations have reported for the Terrascan, and the scanning process that has continued.

These violations can be utilized for performing further analysis. If these violations that are reported against each asset. If you notice, we found some ports are open, VPC flow logs are not enabled, and many others. All these violations can be used for performing further security analysis, using the relationships that we have done previously.

Security Scanning and Analysis in Terraform Cloud

For all our audiences who love to use Terraform Cloud for provisioning their Terraform code and their cloud environments, we have integration available with Terraform Cloud as well, using a free tool at app.accurics.com.

I'm going to show you a quick demo, how the integration works. You will be able to integrate with your Terraform Cloud and perform the security scanning much in the same way how you saw Terrascan can perform security scanning of infrastructure as code. All you have to do is go to your TFC, copy your tokens, paste them into our free tool at app.accurics.com and integrate with your running plan on your TFC. Then let the plan run. Once the plan runs automatically, it will scan for all the security violations and security checks. If the checks are failing, it's going to fail the plan and report the violations.

We are adding a quick Sentinel policy there, which is going to connect with our free tool. The free tool is ready and integrated. We have run the plan, the plan is running, and we are seeing the results are going to be available. The policy check is queued. If the policy check fails, that means the security checks failed, and you are able to see the security results. That's our integration with TFC as well.

Vulnerabilities

How do you identify vulnerabilities for your assets that you have identified from Terraform code? One way to do that is to identify — in the case of AWS — your AMIs and then figure out if your AMIs have vulnerabilities using several different scanners out there. Then use that information for determining more attack vectors and attacker capabilities. That's how you can utilize vulnerability information as well if you can gather that information by looking into Terraform and the EC2 instances, as well as the AMI IDs.

Exposures

It's so important to determine exposures because that is going to help us map the kill chain phases like reconnaissance and delivery. If the exposure is detected, it will also allow us to determine the impacts of the threats that are detected.

How do we identify exposures in your architectures? You can use Terrascan for performing the scans that we previously showed. You'll be able to identify ports which are exposed. You'll be able to identify wide open security groups. You'll be able to identify S3 buckets, which have public access. You'll also identify other services that have overly permissive IAM policies such as principal and *. Very important.

Once you've identified these exposures, these exposures are going to be extremely useful for plotting them against the trust boundaries, as well as the security violations that we have been talking about.

Thank you very much for the time today. If you have any questions, feel free to send them over to me. You can contact me on LinkedIn, Twitter, my email. Feel free to use our free tools and open source tools, Terrascan, KaiMonkey. Make sure that you are using our free tool at app.accurics.com for performing the full threat model. Thank you.