To cyber security analysts, the MITRE ATTACK framework is the de facto standard for the security operations center (SOC). With it, they can assess and view known malicious actors’ tactics and techniques.

This is of immense value when SecOps want to strengthen their security posture. SecOps are facing an increasing set of threats to address, on top of a growing attack surface to manage.

Getting help from a knowledge base such as those provided by the MITRE attack framework improves their ability to take a step back and think about the whole picture regarding strategy and coherence.

Using standardized frameworks helps analysts’ ability to discover, prioritize, and remediate vulnerabilities, improve operationalization of external threat intelligence, and improve the ability to combine and enrich multiple security data sources to provide more context around security events.

However, learning and benefiting from frameworks takes time that is already overcrowded in analysts’ daily schedules. One of the most frequent complaints regarding time spent is the portion dedicated to performing high-priority tasks. This leaves little to study and implement frameworks in their process, like building a workflow dedicated to detecting and mitigating a particular technique. Doing this the old way assume that this person would be entirely dedicated to design from scratch ad hoc automation.

Consequently, most analysts are doing it manually. Looking for Indicators of Compromise (IoCs), performing searches in their environment, depending on the type of IoC, enriching, confirming, and then moving on to the remediation phase.

SOARs (Security Orchestration, Automation, and Response), thanks to their orchestration and automation capabilities, became a SecOps staple. The new generation of SOARs, maximizing accessibility with a low to no-code environment, are pushing this even further. This allows greater adoption and bigger emulation around playbook design. Companies that took the orchestration and automation turn have increased their faith in such tools. Now that they're more capable and intelligent, we're to combine it with knowledge bases such as the MITRE ATTACK frameworks.

The case for the MITRE ATTACK framework

The MITRE ATT&CK framework is one of the most used frameworks by cyber professionals among NIST and Lockheed Martin's Kill Chain. The MITRE ATT&CK is a globally accessible knowledge base and model of adversary Tactics, Techniques, and Procedures (TTPs) based on real-world observation. It reflects the various phases of an attack lifecycle, from recon to impact and the platform they target.

One of the main benefits is delivering a common taxonomy of attackers’ actions and ways to defend against them. Let's look at something that analysts know too damn well, the pyramid of pain.

The Pyramid of pain, D. J. Bianco, 2013

According to this pyramid, the bottom IoCs are the easiest to replace for the attacker. On the opposite, the higher you go in the pyramid, the IoCs you’re targeting are more challenging to replace for the attacker.

Hashes can be dramatically different due to just single bits variations. IPs can be changed at will, even unconsciously, when using proxy services, for instance. Domain names are, in principle, harder to change, but, in practice, many DNS providers aren't paying attention to who’s asking to register a domain name … some of them are even free!

In the end, targeting Hashes, IPs, or Domain names can show some effectiveness especially if you successfully automate the process of detecting it and remediating it, but it remains limited. Determined attackers will make the changes needed and proceed with their attack.

However, if you move up to Network and Host artifacts section, you're starting to look for things that, if the attacker wants to pursue the attack, will make them go back to their lab and reconfigure their tools. Let’s take the case of a hunter listening on ports. By looking at the registry for altered keys or capturing data packets to decipher known HTTP containing malicious content can force the attacker to reconfigure their HTTP recon tool after having understood that their attack had been discontinued because of this detection.

About tools, knowing AV or Yara signatures, you're forcing attackers into finding a similar tool or creating a new one. Achieving this stage is considerably slowing your attackers.

Finally, TTPs are top-notch when it comes to disrupting attackers’ actions. By looking at behaviors rather than tools used, you're disrupting their whole chain of attack. To proceed, they need to reinvent a TTP to reach their final goal. This implies the costliest cost of opportunity to them. From that point, two choices: quit or reinvent themselves.

Threat Intelligence databases list known IoCs. The MITRE ATT&CK (sometimes included as a way to assess the criticality of a given IoC in TI database) comes in by adding contextualization to a given IoC. This is the job done by Threat hunters when they go and hunt on your network for undetected threats. We've already demonstrated that this task could be automated for noticeable benefits.

In short, using the MITRE ATT&CK framework, defenders can understand how the bad guys are attacking them. From then, they can develop threat models to determine where they're vulnerable according to the framework and how they can extend their coverage.

Also, suppose they are to detect an incident. In that case, the MITRE ATT&CK can be of help to determine if this incident is part of a wider process of an attacker following a documented playbook.

Thus, you can understand where you are, the meaning of a gathered IoC, and what the attackers’ next move could be.

Moreover, when performing root cause analysis, mapping yourself in the MITRE ATT&CK framework helps you understand where your defenses were weak and what you can improve on.

As of today, lots of tools are somewhat bringing the MITRE ATT&CK straight into their product. For example, some provide a tagging feature to help analysts map incoming incidents regarding the MITRE framework.

As said above, benefits are about the visibility of an ongoing attack, where the attackers stand on the kill chain, from where they're coming, and where they're headed.

To us, this isn't taking the full benefit of the extraordinary knowledge base that the MITRE ATT&CK framework is, especially considering that movement between stages takes less and less time.

The industry isn't taking the full advantage of the framework for now

To the defender, the MITRE ATT&CK provides techniques to monitor to decipher attempts or ongoing attacks. On top of that, besides giving you intel on where you're going to be hit, it also delivers mitigation techniques. Besides the MITRE ATT&CK, you also have its little brother, the MITRE D3FEND, entirely focused on the defense side.

Most analysts still advocate for using ATT&CK instead of D3FEND for the main reason that it allows you to think like the attacker. Indeed, defenders are often narrow-minded, thinking that no one would ever try a particular thing, so it's not worth the pain to design the code according to this eventuality.

However, attackers won't see the code written like the defender. To them, it will be seen as a vulnerability akin to exploitation. Consider buffer overflow vulnerabilities, even though modern operating systems have developed runtime protection.

A programmer who designed a buffer for log-in credentials would expect that username and password wouldn't exceed a certain amount of bytes. However, someone could play around and overflow the capacity of the memory buffer. As a result, the program may be attempting to write the overflow adjacent memory locations and potential executable code. From then on, the program can behave unpredictably. Attackers can exploit this to introduce extra code and send malicious instructions.

So, adopting the attacker's viewpoint helps you see where you're likely to get hit. Thus, MITRE ATT&CK (and D3FEND) provide mitigation and detection techniques.

As a result, you have the defenses you need to put in place and specific data sources to monitor.

Let's take the example of a phishing link. The attacker knows someone's role in your org; they're targeting them to steal their cred and hack into your exchange web app. When looking at the MITRE ATTACK, you will have a catch at what you have to put in place to mitigate the risk (ie, phish).

Detection-wise, you will find what kind of data source you want to monitor, such as application log (third-party app logging, messaging, and other artifacts), file creation, network traffic content, and flow, correlated to anomalous processes being run.

In some sense, your incident response plan is starting to get designed before you. You must bring your services behind these instructions to create your detection workflow (your mail client, EDR, or SIEM).

True operationalization goes by building remediation workflows as followups

Tagging incidents is post-mortem. You're reacting when the damage is being done, or worse, ex-post, when the damage is already done and the attacker is out.

Don't get me wrong, seeing the global picture of an attack is of substantial value to the analyst but only informative as to where the attacker is on the framework.

Ideally, you want to prevent such things from happening, or if they do happen, you want to decrease the lap of time between the detection and the remediation to the shortest possible.

We've seen that MITRE attack frameworks’ immense value resides in the knowledge of the pyramid of pain. To benefit fully from it, you need to transfer the value brought by the MITRE directly onto your security processes.

Knowns IoCs from hashes to TTPs can be transferred and operationalized into dedicated workflows, accompanied by standardized mitigation techniques, as disposed of by the MITRE D3FEND.

Operationalizing the MITRE frameworks can help you design and strengthen your security architecture. Your initial set of playbooks increases your coverage of known and listed techniques, thanks to the MITRE ATT&CK framework. It enables you to move on to the remediation phase, where you can harness MITRE D3FEND, for instance.