Why Not Detect Every TTP in the MITRE ATT&CK Framework?

Before the MITRE ATT&CK framework was publicly released in 2015, security teams used multiple frameworks to develop an effective security strategy: ISO-17799, its successor ISO-27000, Cobit, NIST, and others. These frameworks are an analytical approach to defense, lacking the realistic testing and process improvements SecOps has needed for some time. 

MITRE ATT&CK fills this gap with a knowledge base of real-life adversaries and their processes. It gives a foundational understanding of adversaries that security teams can leverage to improve their defense against real-world attacks. 

The question is, why not try to detect every TTP in the MITRE ATT&CK framework? Won’t that guarantee complete coverage? The answer is more complicated.

Why not detect every TTP in the MITRE ATT&CK framework?

One could argue that, if you can detect all the TTPs in ATT&CK, you should also be able to defend against all of the adversaries in ATT&CK. While technically true, many TTPs are not inherently malicious. 

For example, Account Discovery (T1087) could be any of 33 different actions, including ones as benign as running “net user /domain". If you were to alert every time “net user /domain” occurred, you’d drown SecOps in false positives. There are many TTPs in ATT&CK that, when used legitimately, are benign.

It’s important to strike a balance between alerting on every TTP and maintaining SecOps efficiency. By alerting on every TTP in ATT&CK without context, your team will inevitably suffer from alert fatigue, until they ultimately tune out certain alerts and miss actual attacks.

To address this, low fidelity alerts should be used only in context, such as who ran the process, what its parent process was, whether remote access was involved, and other factors that can be used to identify if a TTP is part of an attack or just benign behavior. 

The low fidelity example “alert me when net user /domain is run” put in context becomes this higher fidelity alert, “alert me when net user /domain is run by a non-shell process or by a domain user under a shell whose parent tree doesn’t contain explorer when that user is not a member of domain admins”.

A chain of TTPs that tie malicious activity together is known as an Indicator of Behavior, contrasted by adversary emulation plans (AEPs), which are a full document of the TTPs used by a specific adversary group.

Instead of alerting on every TTP in ATT&CK, a more effective approach is to test your environment against a fully developed attack simulation that takes into account the TTPs of an attack. The attack simulation gives your team actionable feedback on where you may need additional logging or where you should add new policies and technologies. 

To learn more about enhancing SecOps with MITRE ATT&CK,  download the white paper.