Mitigate threats with the new threat matrix for Kubernetes
Today, we are glad to release the third version of the threat matrix for Kubernetes, an evolving knowledge base for security threats that target Kubernetes clusters. The matrix, first released by Microsoft in 2020, was the first attempt to systematically cover the attack landscape of Kubernetes. Since then, the project has received great attention and interest from the Kubernetes security community and was updated last year to keep up with the evolving threat landscape. The latest version of the matrix comes in a new format that simplifies usage of the knowledge base and with new content to help mitigate threats. The new matrix is available at: http://aka.ms/KubernetesThreatMatrix.
What’s new
Mitigations methods
Understanding the attack surface of containerized environments is the first step of building security solutions for these environments. In addition to helping organizations measure and assess coverage of threats with matching detections, the updated threat matrix for Kubernetes can now also help organizations with a systematic approach to apply mitigation techniques that prevent attacks from being successfully launched.
In this third version of the threat matrix, we introduce a collection of mitigations specific to Kubernetes environments and associate each with relevant threat techniques. Those mitigations, as displayed below in Figure 1, provide practical tools to prevent the various attack techniques, using built-in Kubernetes and cloud tools.
When reviewing the different threat techniques in the matrix, a list of relevant mitigations is provided so that organizations can see if they are taking all the necessary steps to prevent a threat. Additionally, when looking at a specific mitigation, a list of relevant threat techniques is displayed and can help organizations prioritize their mitigation implementation plan according to their threat assessment and detection coverage in each area.
Mapping to MITRE ATT&CK techniques
Last year, MITRE added a container matrix to the MITRE ATT&CK framework. MITRE ATT&CK for containers matrix, inspired by Microsoft threat matrix for Kubernetes, is a result of a joint effort between MITRE, Microsoft, and additional companies in the industry. The differences between Microsoft’s and MITRE’s matrices are described in this blog. In the new version of the Microsoft threat matrix for Kubernetes, we include a mapping between the Microsoft matrix and MITRE ATT&CK techniques and mitigations, as displayed below in Figure 2. This can help organizations to efficiently use the two frameworks.
MITRE ATT&CK matrix for containers does not have an equivalent technique for each of the techniques in the Microsoft threat matrix for Kubernetes. When there is no equivalent technique in the MITRE matrix, the Microsoft techniques might be mapped to a MITRE technique that is not part of MITRE’s containers matrix but shares the same principle. For example, the Backdoor Container (MS-TA9012) technique explains that attackers can use Kubernetes controllers (such as daemonsets) to run their code and survive reboots of the podsnodes. This is very similar to MITRE’s Create or Modify System Process technique (T1543), which is about using servicesdaemons for the exact same purpose. Another example is the mapping between Malicious Admission Controller (MS-TA9015) and MITRE’s Event Triggered Execution. Although MITRE doesn’t talk about containerized environment, those two techniques share the same idea. In cases when there is no matching MITRE technique with the same principle, the Microsoft technique will not point back to a MITRE technique.
New techniques
The new version of the matrix also introduces two new techniques and additional re-categorization of existing techniques:
- New technique: Static pods
A persistence technique which allows attackers to deploy pods that aren’t managed by the Kubernetes API server.
- New technique: Collecting data from pod
Kubernetes-native technique which allows attackers to extract data from running pods.
- Extending existing technique: Container service account
Attackers may create new service accounts or steal tokens of existing service accounts for future use from inside and outside the cluster. Therefore, we also added this technique to the persistence tactic.
- Extending existing technique: Exposed sensitive interfaces
Attackers may use management interfaces for discovery purposes, after gaining initial access to the cluster. By using the network reachability between pods, attackers can connect to management interfaces from the internal network, allowing them to get valuable information about the workload. Thus, we also added this technique to the discovery tactic.
New web interface
As new threats were added to the Kubernetes matrix and additional content was introduced, it became increasingly harder to effectively deliver the breadth of information included in the matrix as a blog post. Looking for ways to make it easier to use the Kubernetes threats and mitigations matrix as reference material for day-to-day security operations, we are releasing the matrix as a web site, shown in Figure 4 below.
The new version of the threat matrix for Kubernetes is now available at: http://aka.ms/KubernetesThreatMatrix
The threat matrix for Kubernetes can help organizations to have visibility to the unique attack surface of Kubernetes and help them to measure their coverage to those threats. With the new mitigation section, organizations can now understand the measures required to prevent those threats.
Microsoft Defender for Cloud can help detect and mitigate threats in your Kubernetes environments. Learn more about Microsoft Defender for Cloud support for container security.
The post Mitigate threats with the new threat matrix for Kubernetes appeared first on Microsoft Security Blog.
Source: Microsoft Security