As organizations turn to hybrid solutions, an increasing number of businesses are turning to container orchestration to provide a seamless solution to computing between environments.

“Containers are units of software in which the code and all its dependencies are packed, allowing applications to run quickly and efficiently from one computing environment to another,” Container Journal explains. “They are gaining popularity as they simplify the process of building, packaging and promoting applications and their dependencies at every stage of their life cycle and on different environments, as well as deployment targets.” 

Containers have gained popularity in cloud computing where they add value to cloud storage consistency, improve developer productivity and add efficiency to operations. While there are a number of different container platforms, Kubernetes has become the standard in public cloud environments. 

But as with any software, containers come with security risks. According to a 2019 Tripwire State of Container Security Report, six in 10 organizations dealt with a container-related incident, which occurred during the build or runtime processes or impacted the container contents directly.  

Threat modeling, which is when a company identifies and prioritize potential threats and security mitigations, is one way to address cybersecurity in container orchestration systems. 

Challenges for Container Security

Container orchestration systems have their share of possible security vulnerabilities, which include:

• External attacks coming from anywhere outside of the organization
• Misconfiguration issues
• Vulnerabilities within the applications
• Built-in flaws when containers are not designed with a security-first approach
• Image layers that are not verified
• User access and privileged accounts given to too many people
• Host environment

There are threats unique to container environments that users need to be aware of. For instance, because containers rely on images created by code — either an original base image or a copy — to build new containers, users must remember that code can have vulnerabilities that make the image itself unsecure. A vulnerable image used multiple times ends up spreading a possible security threat repeatedly, putting the container at risk. Or, because containers have such short lifecycles, they are difficult to monitor as closely as one would other types of software or computing process. The lack of close monitoring can result in malicious processes contaminating the orchestration environment.

Threat Modeling Tools

There is no one-size-fits-all model for threat modeling tools. Microsoft threat modeling mapped out a threat matrix for Kubernetes, focusing on similarities in attack tactics used in Windows environments. Using tactics as the guide, the tool then builds on the techniques used by the attackers.

STRIDE threat modeling is a popular option for Docker container security, using an infrastructure threat-perspective approach. STRIDE stands for spoofing; tampering; repudiation; information disclosure; denial of service; escalation of privilege. It is used to work through possible threat scenarios the application could face. 

A researcher at Sweden’s KTH Royal Institute of Technology introduced a threat modeling language designed for Amazon Elastic Container Service, called ALCOL (Amazon eLastic Container Language).

According to that research, the language was developed using multiple literature studies to discover different components in Amazon ECS that should be modeled in the language. It also looked at the different attacks possible to perform against Amazon ECS infrastructures. The developed language is able to accurately simulate cyber attacks against Amazon ECS infrastructures.

These tools aren’t exclusive for one type of container over another. Development teams should use the tools they are most comfortable with. The most important issue is to make security a higher priority in the container orchestration system.

Benefits to Threat Modeling in Containers

With any type of threat modeling, the goal is to discover potential risks during the development and testing phases, adding DevSecOps into the DevOps process. In containers, threat modeling finds data communication problems quickly, but it also lets developers add functionality to an API for future development, eliminating the need for recoding. 

Threat modeling in a Kubernetes container can detect vulnerabilities to image libraries, recognizing where patches are needed throughout the DevOps process.

Perhaps the most important benefit is that threat modeling allows developers to stay on top of security issues continuously with each release and update.

Strategies for Threat Modeling in Containers

Security threat modeling should come as early as possible in the deployment of containers, but if it isn’t done in the beginning, it can still be performed at an otherwise pre-defined part of the process. 

At the 2019 (ISC)2 Security Congress, Micro Focus Product Group Security Lead, Elena Kravchenko pointed out that developers should be able to pinpoint the pattern (authentication, authorization, secure communication and secure storage) they want to protect. They should define the threat to that pattern, determine the risk to the organization and deploy the mitigation strategy.

For example, in authorization, you want to protect a container compromised by stolen credentials of a privileged account. The risk is that this compromise could lead to an unauthorized access into the root kernels. The mitigation technique here is user namespace mapping, which provides isolation within the runtime process. 

Containers are vital to the modern computing environment, allowing users and developers to test and run apps anywhere quickly and easily. But like any technology, security risks are high. Threat modeling addresses those risks, making for a more secure computing environment.