How to integrate MITRE ATT&CK into official security documentations
I was a bit surprised this week about how well my short presentation at the ATTACKcommunity workshop was received. To illustrate my thoughts, as well as document the part that I only mentioned while talking, this post goes into more details.
The concept of including a formal derivation for all security measures based on threats is very common for companies following the ISO27001:2013 standard or in the German speaking region the “BSI IT Grundschutz Standard 100–2” — Chapter 4. I have not checked on more formal standards where this is specifically asked for, but the relevant controls are mapped to the following controls of the NIST-CSF
The traditional threat catalogues (in this example the taxonomy from ENISA) are there addressed, and the relevant threats are listed in the documentation, including what measures are taken to prevent that threat or reducing the likelihood of it occurring. MITRE ATT&CK is a technical threat catalogue that unfortunately is too complex to explain to most employees, still it’s a very important source of technical threats as it’s describing threats on a level we can differentiate and benchmark technical measures and plan them into our actions. By merging the traditional threat catalogue with MITRE ATT&CK, we can find a way the engineers can document the recommendations by the SOC and address the measures taken (and if they do not, the process to document the risks for the deviation is also already clear).
We best merge the MITRE ATT&CK tactics into the Nefarious Activity/Abuse threats by ENISA.
The logic applied is: techniques are too specific, but the tactics are not as dynamic and therefore a great base and can more easily be integrated into the current threat catalogue that exists in your company.
To decide what threat should be rated by what application responsible, the applications are grouped into three different groups. This groups are based on the general threat landscape they face.
A Internet facing Applications/Systems
B All (general) applications (this really means each application)
C User/admin devices
The above table shows which MITRE ATT&CK Tactic is relevant for what application group. The logic is that for most applications only the tactic will be evaluated (similar as in vulnerability management, where in the process usually the system responsible also can give feedback if the vulnerability is a problem or if for some reason, that detection was actually a false positive). By having the application responsible document that “A adversary is trying to run malicious code” (Execution tactic) on his system “is a threat” he thinks it is relevant, and he can now explain why he cares to run AV (M1049) on that system, application control is needed (M1038), command line or PowerShell logging needs to be activated on his systems or why he really took care of his privileged account management (M1026), restricted his file and directory permissions (M1022), et cetera and why the SOC needs to have logs of all relevant activities.
The logic is that if the engineer agrees the threat to be relevant, all of the recommendations by the SOC, based on relevant APT techniques (or more if you reach for full coverage) are best to be implemented. Every recommendation you don’t implement should be documented with a risk. If he does not think it is relevant he is ok to not implement measures, but also clearly documented that this was based on his threat analysis (which should be reviewed in existing security management processes).
The tactics Initial Access as well as Exfiltration have to be assessed by the responsible for “Internet facing Applications/Systems”, as well as the “User/Admin devices” responsible. Exfiltration should be included on tactic level for every application as well (by including the threat in your catalogue for “The adversary is trying to steal data”). If the application does not include critical data and we are not upset about it being released to the public, we are fine. In case that would be a problem, the measures recommended should be followed up with as well.
The one tactic relevant for all applications is Impact.
Hell yes we want to know if the application responsible sees it as a threat if an attacker for example stops a service in a uncontrolled matter (T1489) or if data is manipulated (T1565), data is destructed (T1485) or we suddenly loose access to the machine (T1531). Addressing these threats this way should initiate basic hardening recommendations like Network Segmentation (M1030), restricting registry permissions (M1024), user account management (M1018) is done in a reasonable way and also build the bridge to why we need availability monitoring (Impact Type).
Including Reconnaissance and Resource Development in the assessment might only make sense for certain companies. The more federal your company’s structure is, the more sense it makes to make the relevant teams accountable for the information they publish to the Internet, control registration details (like WHOIS, etc) or enforce usage of certain certification authorities. In your organisation it can possibly also be controlled in a centralized manner.
The benefit of including the MITRE ATT&CK tactics in the security documentations are clear and with the newest release by MITRE and the Center for Threat-Informed Defense (as well as: https://github.com/center-for-threat-informed-defense) it has become super easy to build catalogues on what security measure or detection capability addresses what threat. The only job left to the companies is to translate those capabilities to local supporting services.
In this context I also created a mapping of the ENISA Nefarious Activities to the MITRE ATT&CK tactics. It shows how little adjustment is actually needed from a threat point of view if you already implemented the ENISA threat catalogue.
Thank you to @FDezeure for motivating me to giving this talk and for everyone that accepted it and organised this lovely event.