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 Matrix
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.
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.
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.name=%user.name
user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline %container.info
evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid 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
group.gid=%group.gid group.name=%group.name container.id=%container.id
container.name=%container.name
image=%container.image.repository:%container.image.tag)
priority: warning
Tags:
- container
- MITRE_TA0008_defense evasion
- MITRE_TA0002_execution
- MITRE_T1204_user_execution
- MITRE_T1204.003_malicious_image
source: syscall
append: false
Exceptions:
- 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.
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
"\"allowBlobPublicAccess\":true"
output: >-
Anonymous access to blob containers has been allowed on storage account
(requesting user=%jevt.value [/identity/claims/http:~1~1schemas.xmlsoap.org~1ws~12005~105~1identity~1claims~1name],
storage account=%jevt.value[/resourceId])
priority: warning
Tags:
- 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 D3FEND
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:
- 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.
- 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.
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).
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.
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.
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.
Conclusion
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.