Microsoft's Kubernetes Threat Matrix: Here's What's Missing

The MITRE ATT&CK threat matrix is a valuable tool for security professionals to understand the various tactics and techniques employed by adversaries to exploit software and networks, from initial access to impact. The matrix covers the various stages commonly involved in a cyberattack, and the tactics exploited by attackers in each stage. Organizations can use the matrix to understand their attack surface and make sure they cover all their bases.

In April, Microsoft Azure Security Center released a threat matrix based on the MITRE ATT&CK model that identifies tactics and threats unique to environments running in Kubernetes, the most popular container orchestration platform used by cloud-native application builders today.

The Azure Kubernetes matrix adapts and translates the tactics found in the original MITRE ATT&CK framework to the challenges of Kubernetes. For example, in the MITRE ATT&CK matrix, "initial access to the computer" translates to "initial access to the cluster" in the Azure matrix, reflecting the different technology involved in that access. Azure's matrix is a major milestone in capturing the difference between traditional IT security and cloud-native security, and expanding security left and right.

However, platform engineers and security operations teams shouldn't rely solely on Azure's Kubernetes threat matrix. While Azure's matrix allows security teams to think about Kubernetes security along the same lines they do for generic enterprise IT security, there are constructs specific to Kubernetes that do not exist in traditional IT environments. Ultimately, the Azure framework is new, and security researchers are still uncovering vulnerabilities in Kubernetes.

For example, the techniques used in the recently discovered threat CVE-2020-8555 were not captured in the Azure MITRE ATT&CK threat matrix for Kubernetes. This vulnerability allows attackers to escalate access from the Kubernetes control plane to the hosting cloud environment, potentially gaining access to sensitive data from services connected to the hosting environment.

For applications on Kubernetes, the threat and risk vectors can be divided to two main areas:

● Application-level threats and risks
This should be familiar territory, but with a distinct difference from traditional monolithic applications. Applications designed to run in Kubernetes are distributed and consist of multiple ephemeral moving parts that have varying risk and threat profiles, and are usually made from a combination of first- and third-party components and tools.

● Kubernetes cluster operations threats and risks
These risks and threats are associated with:

○ The software supply chain, build, and continuous integration (CI)-related risks and the delivery automation and continuous delivery (CD) tool chains used to deploy into the cluster. CI and CD both represent initial access points in the software supply chain where threats can be introduced into the cluster.

○ Kubernetes infrastructure automation tooling, such as application and infrastructure monitoring and microservices life-cycle autonomous controllers.

○ Human operators (DevOps/site reliability engineering staff) who have privileges to perform actions within the cluster.

With that in mind, let's unpack important security elements missing from Azure's Kubernetes threat matrix. In the edited matrix below, items in bold represent noteworthy threats not found in the Azure matrix:

Source: Gadi Naor

One notable component Azure's threat matrix leaves out is the "Command & Control" (C2) threat category, which was found in the original MITRE ATT&CK Matrix. As it turns out, C2 should still be a concern for Kubernetes users, and it should be a part of a Kubernetes threat matrix.

Kubernetes relies heavily on DNS as its critical infrastructure for service discovery. A common practice for establishing covert channels is to exploit inherent weaknesses in the DNS protocol messages exchange. For this reason, it's important to monitor DNS activity within your Kubernetes cluster to detect and potentially prevent C2 channels from establishing covert channels.

The Azure Matrix also has gaps surrounding privilege escalation. Recent CVEs have shown that privileges can be escalated from the node to the entire cluster, or from the cluster to the hosting cloud environment. Admission controllers and Kubernetes operators can also be compromised, and should not be an afterthought when it comes to security.

Another gap in the Azure Matrix is in Kubernetes threat persistence. Attackers can spin up containers directly on the node, which would not be managed by Kubernetes and would be a blind spot for DevOps. If attackers compromise an admission controller, they can also inject malicious sidecar containers to any pod of their desire. Lastly, attackers can execute and persist attacks by plugging scripts into the container life-cycle hooks, a Kubernetes mechanism to run scripts at predetermined points in time.

With a fuller picture of the Kubernetes threat matrix, security teams can begin to implement mitigation strategies to protect their cluster from threats. Fortunately, strong security hygiene can go a long way for addressing threats across the matrix in Kubernetes. But new threats and vulnerabilities come to light every month, and security teams need to remain vigilant in monitoring both their Kubernetes clusters and the broader threat landscape.