Protecting Kubernetes Against MITRE ATT&CK: Impact

The final part of our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – analyzes a set of techniques that fall under the category known as Impact.

These techniques are aimed at disrupting or destroying resources and activity within the target environment, or in other words, the ultimate goal of an attacker. These include techniques to achieve data destruction, resource hijacking or denial of service.

StackRox helps protect against this tactic and its techniques with a wide range of capabilities that include:

• scanning all container images that deploy into clusters
• enforcing policies for image provenance
• identifying Kubernetes vulnerabilities in clusters
• monitoring Kubernetes configurations, RBAC access privileges, and runtime activity
• and visualizing, simulating, and automatically generating Kubernetes Network Policies

You can find the first eight articles in the series below:

• Part one - Initial Access
• Part two - Execution
• Part three - Persistence
• Part four - Privilege Escalation
• Part five - Defense Evasion
• Part six - Credential Access
• Part seven - Discovery
• Part eight - Lateral Movement

Technique 9.1: Data Destruction

Issue

This technique reflects the ability of an attacker to delete or remove resources in a Kubernetes cluster, including Deployments, configurations, nodes, pods, or other data.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Organizations can protect themselves from this threat vector by monitoring Kubernetes audit logs, which provide a chronological record of cluster events and restricting RBAC access according to the principle of least privilege.

Technique 9.2: Resource Hijacking

Issue

With this technique, an attacker may hijack a Kubernetes resource for unintended purposes. One example of this is using compromised containers to run malicious tasks such as cryptomining.

Real-world example: Microsoft Azure has disclosed the discovery of multiple campaigns, including a large-scale one, where attackers targeted Kubernetes clusters and were able to impact them by running cryptocurrency miners, otherwise known as “cryptojacking” attacks.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Organizations can mitigate the threat of resource hijacking by configuring RBAC access to restrict the ability to create pods.

How StackRox Helps

StackRox helps protects organizations from resource hijacking by scanning all images that are used to deploy containers into the cluster and enforcing policies for image provenance. For example, many reported cryptojacking attacks have arisen from backdoored images stored in public registries containing malicious software. StackRox also monitors runtime activity with a built-in policy to detect cryptomining processes that execute.

Technique 9.3: Denial of service

Issue

With this technique, an attacker may seek to make services unavailable by impacting the availability of components within the Kubernetes control plane including the API server, cluster nodes, or application components in pods, or other resources.

Real-world example: CVE-2019-1002100 is a vulnerability in the Kubernetes API server that allows users with certain write permissions on the Kubernetes API to make write requests that cause the API server to utilize excessive resources, resulting in a denial of service.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Organizations can mitigate this threat by first ensuring they upgrade to the latest version of Kubernetes. Additionally, they can configure Kubernetes Network Policies to permit only necessary connections within the pod network.

How StackRox Helps

StackRox delivers protections to help mitigate this threat by automatically identifying Kubernetes vulnerabilities as well as visualizing, simulating, and automatically generating Kubernetes Network Policies to segment and restrict communication throughout the environment.

Final Thoughts

Kubernetes is enabling organization of every size across every industry in their efforts to modernize applications and infrastructure as part of strategic digital transformation efforts. Using Kubernetes, companies are now able to build and run applications at faster and at greater scale than previously possible. At the same time, Kubernetes creates a new threat environment that is complex and not yet well understood, giving rise to emerging and evolving attack vectors. The Kubernetes attack matrix provides an important, starting foundation for the Kubernetes community and cloud-native ecosystem to effectively protect Kubernetes, and the applications that run on it, from common tactics and techniques that might be used by adversaries.

The rich set of security controls made available by both Kubernetes and cloud provider platforms lend themselves to a set of security best practices that organizations can implement to mitigate the threats described in the Kubernetes attack matrix. This aligns with established frameworks for security such as the shared responsibility model for cloud environments.

To comprehensively mitigate the threats listed in the attack matrix requires a security approach that goes beyond being container-centric. It requires security that is Kubernetes-native: security that is fully architected to integrate with and leverage native security controls within Kubernetes itself.

New Kubernetes attack vectors will continue to be discovered over time alongside the growth of the platform, and organizations should be prepared to expand their Kubernetes security efforts over time to accommodate these developments. StackRox’s Kubernetes-native security is designed to address new threats to Kubernetes applications and infrastructure as they emerge.