Securing Container using Threat Modelling— STRIDE

The increased adoption of containers has given rise to a wide range of potential threats to microservices apps that run in containers. If you are working in an organization and your workload is over containers then this blog is more targeted for you. This is about how effectively you can secure containers by not just following a structured and more specific threat modeling approach but focussing on introducing tools at different stages of the model to prevent container security issues before you actually ship them.

Threat modeling is a structured process through which IT pros can identify potential security threats and vulnerabilities, quantify the seriousness of each, and prioritize techniques to mitigate the attack and protect IT resources.

Understanding the technologies involved, their way of working, functionalities it serves, the methodologies it involves, understanding the environment, identifying vulnerabilities, and framing the potential attackers helps you identify, quantify the threats, and thus creates a systematic and structured Threat Model.

In points, Threat-modeling is used to create:

1. An abstraction of the system.
2. Profiles of potential attackers, including their goals and methods.
3. A catalog of potential threats that may arise.

There are various threat-modeling methods that have been developed. From the most popular STRIDE model to PASTA, LINDDUN, CVSS, we have so many. Some of them are specific to application security, some are specific to certain IT disciplines, some methods focus specifically on risk or privacy concerns while some are abstract. Choosing a threat model or building your own threat model depends entirely against the system you’re modeling the threat for.

That said, threat modeling is still in some ways an art as much as a science, and there is no single canonical threat modeling process.

But it’s important to know that there are a wide variety of threat modeling frameworks and methodologies out there. I have been working a lot on creating/evaluating a custom/existing framework that could not only cover all the edge cases but also at the end, firewall a container from security threats.

As we refine our strategy and needs, what seems the best approach was adopting the STRIDE (invented in 1999 and adopted by Microsoft in 2002) acronym approach for container security. STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial Of Service, and Escalation of Privilege.

Let’s break down each acronym in the context of the containers—

SPOOFING → The most widespread attack against docker container is Phishing. Most of these phishing attacks involve the abuse of container images to carry out malicious functionalities like botnet infection, crypto mining, etc. Hackers just upload phished docker images and trick developers into using them. To solve this, the following checks can be integrated to prevent spoofing at build time —

1. Checking Dockerfiles FROM directives pointing to a smart whitelist of base images. This whitelist contains only the verified, official, and trusted Docker standard library and some inhouse approved images. Thus if scanning the Dockerfiles FROM directives found to be using the image that is not in the whitelist, it will reject them.
2. Enabling docker content trust using Notary (a tool for publishing and managing trusted collections of content). Publishers can digitally sign collections and consumers can verify the integrity and origin of the content and trusted publishers to ensure pulling cryptographically signed base images are pulled.

TAMPERING →If an attacker changes an image stored in a registry without changing its associated metadata or by tampering metadata of an associated tag for an image that will result in pulling the unexpected image. To tackle this —

1. Docker Content Trust should be enabled to ensure that only pulling cryptographically signed, untampered, original base images are pulled.
2. Checking for the tag version in the Dockerfiles’ FROM directives rather than the generic “latest” tag for full traceability. This can be achieved by either scanning the dockerfile or using Dockerfile linter like hadolint and dockerfilelint.
3. Checking the Dockerfiles for Docker directive COPY and not, ADD. The danger of using ADD is that it automatically performs decompression of local files. You may end up downloading malicious software and decompressing them which you didn’t intend to.

REPUDIATION →It happens when an application or system does not have proper controls to track and log users’ activity, thus permitting malicious manipulation or forging the identification of actions. Below steps can be followed to combat it —

1. Making sure that you have complete audit logging enabled in your docker registry. It should capture events that could questions like when an activity is performed, who are the actors, and the timeline.
2. Setting up auditd in your docker host (a userspace component to the Linux Auditing System) responsible for writing audit records to the disk.

INFORMATION DISCLOSURE → It can happen if the application or tool is misconfigured. Most of the data breaches take place when the tools are left at their default setting exposing sensitive data to the public. Ways to combat —

1. Disable experimental features while you are setting up your docker.
2. Looking for sensitive volume mount like /proc, /opt, and rejecting the image from building if it's found to be present in dockerfile.
3. Running automated dependency scanners to check that we are using the latest, most secure version of our code dependencies. Using scanners like OWASP Dependency Check, RetireJS, Synk, OSSIndex can be effective.

DENIAL OF SERVICE →Vulnerabilities in a docker image can itself cause a denial of service to Docker containers. Thus scanning images for the security vulnerabilities becomes a critical aspect of its security.

1. Scanning docker images for vulnerable third party libraries, binaries, and dependencies for any critical open CVE and rejecting the image if it is found. Clair, Anchore, Dagda, Falcao are some of the tools which can be used to scan Docker image in the pipeline.
2. Docker CIS Benchmark recommends having HEALTHCHECK command in dockerfile to make sure the application base process is running correctly. Simply scanning the dockerfile for the HEALTHCHECK directive would do this.

ESCALATION OF PRIVILEGE → There could be many ways by which privilege escalation can occur. Let’s jump into ways to prevent escalation issues —

1. If the user is privileged enough to run docker, i.e. being in the docker group or being root, they can run the container with host mounted volumes like /etc mounted in and get the root access. A straight forward check is to scan the dockerfile to find if the root user or ‘docker’ group is being used.
2. Dockerfile linter also helps to check if the root user is being used to execute the program inside of the container and there on you can reject such images within your pipeline.
3. One of the Docker CIS Benchmark recommendations is to remove setuid and setgid privileges if not needed.

Thanks for reading!

~Logicbomb ( https://twitter.com/logicbomb_1 )