Threat Modeling for Containers

The most suitable threat modeling methodologies for containers are STRIDE and Attack trees.

STRIDE

STRIDE is a threat modeling methodology for categorizing application security threats that were developed in 1999 and implemented in the Microsoft Security Development Lifecycle in 2002. It is the most mature threat modeling methodology that is based on analyzing known threats.

STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, and Elevation of Privileges.

Spoofing occurs when somebody or something is pretending to be somebody or something that it is not. An example could be when an attacker sends a phishing SMS or email to a customer of a bank asking for the PIN code of their bank card.

Tempering threat is the risk that somebody who should not be able to modify something actually is able to do that. For example, somebody modifies the real DNS name of the website on the network and you end up on a phishing website.

Repudiation is the ability to perform actions that do not leave tracks, an example could be a web application that does not log user actions.

Information disclosure is the exposition of the data to individuals that should not see it.

Denial of service is a type of attack that blocks a system from providing services to legitimate users.

Elevation of privileges is a type of attack that allows a user with low privileges to perform actions as a high privileged user.

Attack Trees

An attack tree is one of the oldest methods to build a threat model. It is a tree diagram where the goal of the attack is the root, and the leaves are the methods or steps to achieve the goal. Each attack is a separate tree. An entire system analysis consists of multiple attack trees.

What are the characteristics of an effective/good threat modeling method for container security?

According to the library research, containers can be analyzed based on their architecture and configurations. Software-centric and asset-centric methodologies can be applied to identify container threats. Software-centric approaches involve the design of the system and its analysis, an example of a software-centric approach is STRIDE. Asset-centric methodologies involve identifying assets of an organization and identifying the ways it can be attacked using attack trees (ThreatModeler, 2016, ref. 35).

A good and effective threat modeling method for container security is the one that is easy to apply and to understand for developers, security guys, and operation teams. Since containers and threat modeling for them is something new for most of the companies there is a small amount of research about it. Since containers are just infrastructure where an application is running, we can create architecture models. There are also organizations and vendors that define best practices for container security that mitigate their threats. 

Another characteristic of a good and effective threat modeling method is one that can help identify and mitigate threats on software/system architecture diagrams. It should also be effective for  DevOps or Agile software development approaches. It should be structured so people can apply a structured way of thinking to find real threats (Maritza Santillan, 2015, ref.23). Most of the threat modeling methodologies consist of steps that are not relevant or can’t be applied to containers. A description of different threat modeling methods can be found in Appendix G.

The result of the informal talk with Geoffrey Hill is that a good threat modeling method should be easy to understand and apply for developers. Another characteristic of a good threat modeling method is the ability to map the threats to the Common Weakness Enumeration (CWE) database. STRIDE is the method that has these characteristics.

In conclusion, there is no best threat modeling methodology. The choice for a threat modeling methodology depends on expected results and who is involved.

What threat modeling methodologies can be used for containers?

If we assume that the application that is running in a container is already threat modeled it means that all the containers will have the same threats regardless of what application they host. The containers run on a container runtime on a lower level of the system, the container layer. There are known threats for containers known as misconfigurations. If we already know the threats, then we don’t need to perform threat modeling for a container without the software that it hosts. We must apply best practices to avoid misconfigurations that could lead to container escape, denial of service attacks, and information disclosure. In this case, the misconfigured container runtime could be a threat.

The threat modeling methodology STRIDE can be applied for containers to identify misconfigurations, and attack trees can be applied for Kubernetes. Attack trees can help identify ways an attacker can attack and compromise the system using one or more vulnerabilities. We can use attack tries to identify potential ways how an attacker can compromise a Kubernetes cluster.

Containers are a separate layer of OS where applications are running. We must apply best practices like Docker CIS and Docker benchmark to mitigate potential container threats.

Container threats according to OWASP:

1. Container image threats
2. Registry threats
3. Host Kernel threats
4. Orchestration threats
5. Runtime threats

The picture below displays how a container image is created from a Dockerfile until it runs in the container orchestrator.

Below are the best practices that mitigate potential threats in each stage. Each threat is mapped to STRIDE.

1)

• Don’t store secrets in the Dockerfile (Informational Disclosure)
• Use a non-root user (Elevation of privileges)
• Perform static analysis on Dockerfile (potentially could create multiple threats)

2)

• Use an official base image (potentially could create multiple threats)
• Sign and verify signatures of the images (Spoofing)
• Harden images (potentially could create multiple threats)
• Squash images after building them. This will erase the build history (Information Disclosure)

3)

• Use a private registry (Information Disclosure)
• Use trusted vendors for base images (potentially could create multiple threats)
• Lockdown the registry (Denial of service)

4)  

• Monitor and perform logging for containers during runtime (Repudiation)
• Set read-only root file system (Tempering)
• Never mount the Docker socket inside a container (Elevation of privileges)

The picture below illustrates the infrastructure where a container is running and locations where there could be potential threats.

1)

• Scan the images for known vulnerabilities (potentially could create multiple threats)

2)

• Harden the images to reduce the attack surface (potentially could create multiple threats).

3)

• Don’t use the default docker0 bridge, if network communication between containers is not needed (Information disclosure).

4)

• Use Seccomp and AppArmor/SELinux (Elevation of Privileges)
• Limit the resource for each container using Control Groups (Denial of service)

Main Kubernetes threats:

1. External Attacks
2. Compromised containers or nodes
3. Compromised credentials
4. Misuse of privileges

The picture below displays an attack tree for Kubernetes. It displays the process of how an attacker can get access to the cluster API and compromise the whole cluster.

A Kubernetes Cluster can be compromised by an external attacker by getting a shell into a pod. If the cluster is misconfigured and the pod storage contains a default service account token, then the attacker can communicate to Kubernetes API using this token. The attacker can also install custom tools and identify if the cluster API needs authentication. If there is no authentication and authorization, the attacker can freely control the cluster.

In conclusion, containers don’t need to be threat modeled. By applying best practices, most of the threats will be mitigated. Using threat modeling and building threat models will help developers, and other interested individuals understand why best practices should be used. The threat model should be built by someone experienced with containers and orchestration tools. They should know the best practices and what threats they are mitigating. The threats can be mapped to STRIDE because it is applicable to containers and it is easy to understand. Attack trees can be used for the orchestrator because they reveal the bigger impact of multiple vulnerabilities being exploited. Multiple threats that can have a small impact on a cluster can cause a big impact if they are exploited together. The threats in the orchestrator can be found using STRIDE.