MITRE ATT&CK and D3FEND for Cloud and Containers

By Nigel Douglas - MARCH 1, 2023



MITRE ATT&CK and MITRE D3FEND are both frameworks developed by the non-profit organization MITRE, but they serve different purposes.

  • MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a knowledge base of adversarial tactics and techniques that can be used during cyber attacks. It is used to understand the methods and tools that attackers use and to identify gaps in an organization’s defenses.
  • MITRE D3FEND is a set of guidelines for defending against the tactics and techniques listed in the MITRE ATT&CK framework. It provides a comprehensive set of best practices and recommended actions for improving an organization’s security posture.

If you are new to the MITRE ATT&CK framework and would like to brush up on some of the concepts first, we created a Learn Cloud Native article to help you on your journey. If you want to go further, here’s how Falco’s Cloudtrail rules align with MITRE ATT&CK.

In this blog post, we aim to evaluate the benefits of the MITRE ATT&CK and D3FEND frameworks by providing examples in both.

We will tie open source Falco rules to the various framework tactics so that practitioners can better understand how to defend themselves against the latest threats in containerized workloads and in cloud computing.

Falco can detect and alert on any behavior that involves making Linux system calls and cloud activity logs. This includes container workloads running on Linux hosts. Falco alerts are triggered based on specific system calls, arguments, and properties of the calling process. Similarly, Sysdig Secure’s managed implementation of Falco can detect activity in cloud environments by plugging into the audit logging service of various cloud providers, such as Cloudtrail for AWS, Google AuditLogs for GCP, as well as the Audit Logging Service provided by Azure and IBM Cloud.


MITRE ATT&CK is a powerful tool that can be used in both offensive and defensive contexts.

When used defensively, it can help organizations identify gaps in their security posture and take steps to harden their security methods against known threats. It provides a comprehensive set of best practices and recommended actions for improving an organization’s security posture.


It’s important to note that MITRE tactics across an entire Enterprise Linux landscape are far broader than containers and cloud since they operate differently from one another.

The entire Enterprise ATT&CK matrix looks something like this. Please note the tactics may be subject to change over time as the security landscape evolves.

MITRE ATT&CK Matrix for Containers

Regarding container workloads, we have a clearly aligned matrix for all the popular methods of gaining access to, escalating permissions, and ultimately compromising the containerized workloads – whether that’s through being an Advanced Persistent Threat (APT) or exfiltrating data to Command & Control (C2) server.

MITRE ATT&CK Containers

Unlike the entire Enterprise Linux view, we start the tactics on ‘Initial Access.’ That’s because it’s unclear how an adversary would perform ‘Reconnaissance’ and ‘Resource Development’ on a containerized workload. We could perform active scanning on the server that hosts the container, but not on the container itself. To find the MITRE technique assigned to Falco rules in Sysdig Secure, simply filter for Tag: ‘MITRE’ > Type: ‘Workload.’ This way, we can find the container-related rules that have the relevant MITRE tactics and techniques.

Sysdig Secure MITRE Containers

Deploy Container

You can see that Deploy Container is listed under the ‘Execution’ and ‘Defense Evasion’ columns.
This is because an adversary may want to deploy a container into the environment either to facilitate execution or to evade defenses. We wouldn’t know this immediately.

As a result, tags are added for both associated tactics in the Falco rule:

- rule: Launch Disallowed Container
  desc: >
    Detect initial process started by an unlisted container as allowed
  condition: container_started and container and not allowed_containers
  output: >-
    Container started and not in allowed list (
    user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline
    evt.type=%evt.type evt.res=%evt.res proc.cwd=%proc.cwd|
    proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
    proc.exepath=%proc.exepath user.uid=%user.uid user.loginname=%user.loginname
  priority: warning
  - container
  - MITRE_TA0008_defense evasion
  - MITRE_TA0002_execution
  - MITRE_T1204_user_execution
  - MITRE_T1204.003_malicious_image
  source: syscall
  append: false
  - name: image_repo
    comps: in
    fields: container.image.repositoryCode language: YAML (yaml)

TA vs. TI

You probably noticed either in the official MITRE documentation, or in the Falco rule output, that the acronyms TI and TA are used interchangeably. There’s a good reason why both are added to the MITRE ID’s.

In the MITRE ATT&CK framework, TA (Tactics, Techniques, and Procedures) refers to the specific methods and techniques that an attacker may use to gain unauthorized access to a system or network.

TI (Threat Intelligence) refers to the information and knowledge about current and potential threats to an organization, including information about specific attackers and their tactics, techniques, and procedures.

The two are closely related, as TI can inform an organization about the potential TA that they may encounter, and TA can be used to identify the specific attackers or groups that are attempting to compromise a system or network.

MITRE ATT&CK Matrix for Cloud

Below are the tactics and techniques representing the MITRE ATT&CK Matrix for Enterprise covering cloud-based techniques. The Matrix contains information for the following platforms: Azure AD, Office 365, Google Workspace, SaaS, IaaS. While we won’t be specifically delving into services such as Azure AD, Office 365, and Google Workspace in this article, it’s good to understand how MITRE Tactics tie into the various cloud providers holistically.


Similar to the workload filter in the Sysdig Secure rules library, we can search for a cloud logging service (such as Azure Platform Logs) which tells us the rules that align with the MITRE framework.

Sysdig Secure MITRE Cloud

Azure Access Level Set to Public

Notice how the TI’s T1070 and T1562.001 are used in the following Falco rule to ensure this insecure behavior is correctly aligned with Defense Evasion MITRE tactic:

- rule: Azure Access Level for Blob Container Set to Public
  desc: >
    Anonymous, public read access to a container and its blobs can be enabled
  condition: >-
    jevt.value[/operationName]="MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" and
    jevt.value[/resultType]="Success" and
    jevt.value[/resultSignature]="Succeeded.OK" and
    jevt.value[/properties/responseBody] contains
  output: >-
    Anonymous access to blob containers has been allowed on storage account
    (requesting user=%jevt.value [/identity/claims/],
    storage account=%jevt.value[/resourceId])
  priority: warning
  - MITRE_TA0005_defense_evasion
  - MITRE_T1070_indicator_removal_on_host
  - MITRE_T1562.001_impair_defenses_disable_or_modify_tools
  - Cloud
  source: azure_platformlogsCode language: YAML (yaml)

In the case of aligning cloud tactics with Falco rules, we use a dedicated plugin for each of the cloud providers. In this case, we use the Azure Platform Logs as the ‘Source’ in the Falco rule. In the case of containers, we don’t need a dedicated plugin for Falco. Regardless of whether those containers are running in a cloud service like ECS (Elastic Container Service) or running on a standalone Linux EC2 instance, we can use the existing system call architecture in Linux to see what is happening in the containers that run on the Linux host.

Also, in case there is some confusion on the MITRE tactic T1562.001, the technique provides an ID followed by a (.) and then another ID. This is because the ability to Disable or Modify Tools is a sub-technique of Impairing Defense. It’s important to familiarize ourselves with the layout of techniques and sub-techniques when fully-exploring the threat landscape of the Cloud & Container Matrices.

MITRE tactic T1562.001 Container and Cloud


MITRE D3FEND is a framework in which we encode a countermeasure knowledge base. It is just a shorthand or a way to refer to using the MITRE ATT&CK framework for defensive purposes.

So, MITRE D3FEND is used instead of MITRE ATT&CK when organizations want to focus on the defensive aspect of the framework. They can use it as a reference guide to better understand the tactics and techniques used by attackers and how to defend against them.


This knowledge graph of cybersecurity measures is a great way to easily look up ATT&CK tactics with associated Defensive strategies, such as ‘Harden,’ ‘Detect,’ ‘Isolate,’ ‘Deceive,’ and ‘Evict.’ Unlike MITRE ATT&CK, there are no break-out matrices for Cloud and Containers. These instructions are somewhat generic and all advice should be considered across all matrices.

D3FEND for Cloud

Sysdig Secure can be used to prevent threats in addition to just detecting them. In the case of cloud security, we would want to start by hardening our Cloud environment. Click on the ‘Harden’ column name. At the time of writing, there were 32 techniques in this category. The technique (D3-UAP) is related to User Account Permissions. Whether the user is running on an on-premise system or within the cloud, the general advice is to restrict a user account’s access to resources.

Identity & Access Management (IAM)

In cloud environments, we use an IAM-like service to manage the user permissions. Unfortunately, users are often given more permissions than they ultimately require. Fortunately, from the Sysdig Secure user interface you can quickly ascertain risks from two different angles:

  1. User-Focused Risks: This is where the users and roles are allocated with excessive permissions. In this case, Sysdig Secure can suggest a new IAM policy to remove these unnecessary permissions. If a user account is inactive for a long period of time (i.e., an employee has left the company), Sysdig Secure can also recommend inactive users to be removed.
  2. Resource-focused Risks: This identifies the admin who can access specific resources, and alerts on any suspicious cloud resource activity from a user with excessive permissions. If there are any recent permissions changes, we can remediate the risk by suggesting an improved policy, based on users’ actual activity, which you can immediately paste into your AWS policy in the linked AWS console. As you can see, the wildcard (*) statement means all resources are removed and replaced with the screenshot on the right allowing only specific historically-used resources.
Sysdig Secure Policy Recommendation

D3FEND for Containers

As mentioned earlier, while there’s no D3FEND table specifically for containers, we can certainly apply the logic into our containerized workloads. The ‘Isolate’ tactic, for instance, creates logical or physical barriers in a system which reduces opportunities for adversaries to create further access. The Isolate category is broken down into:

  • Execution Isolation
  • Network Isolation

Execution Isolation

Execution Isolation techniques prevent application processes from accessing non-essential system resources, such as memory, devices, or files. For example, Sysdig Secure does a great job of Kernel-based Process Isolation (D3-KBPI).

Kernel-based process isolation

In Sysdig Secure, open source Falco rules are encapsulated in another abstraction layer known as a ‘Policy.’ Policies allow us to define actions when a rule or collection of rules are triggered. By defining conditions for rules, we can ultimately reduce alerting fatigue, provide additional security context, and more importantly, take remediation actions when a container triggers a suspicious system call or creates some unwanted process activity.

Sysdig secure Process isolation

Policy actions occur asynchronously. If a policy has a container action and matched activity, the agent asks the Docker/Cri-o daemon to perform the stop/kill/pause action. This process takes a few minutes, during which the container still runs and the connect/accept/etc. still occurs.

Network Isolation

Network Isolation techniques prevent network hosts from accessing non-essential system network resources. Since Sysdig is a Cloud Detection & Response (CDR) platform, it utilizes open source, cloud-native constructs such as Network Policy to provide Network Isolation at the container level.

Sysdig Secure Network isolation

By creating a dynamic network topology graph for all container connections, Sysdig Secure can restrict network traffic originating from a private host or enclave destined towards untrusted networks, as seen above. This way, we can use a Generate Policy to address the D3fense tactic ‘Outbound Traffic Filtering’ (D3-OTF).

Learn more about best practices you need for configuring and securing your network in your AWS cloud in our AWS Security Groups Guide.

Network Security Policies Sysdig Secure


In summary, MITRE ATT&CK is focused on understanding the attacker’s perspective and identifying vulnerabilities in an organization’s defenses, while MITRE Defend is focused on providing guidance for hardening those defenses against known threats.

If you are looking for a true Cloud Detection & Response (CDR) platform that can detect MITRE tactics across containers and cloud, try out Sysdig Secure today.

Subscribe and get the latest updates