My thoughts on using the MITRE ATT&CK framework for SIEM detection’s

I posted on twitter the other day about my thoughts on the MITRE ATT&CK framework and its usage as part of SIEM detection’s. Here is an extended take of that, as I had more to say than I could really fit in some tweets. Before I get into the discussion, two things which are important.

Firstly, the team at MITRE do a fantastic job on providing resources to the cybersecurity community. On top of the ATT&CK framework, there is also MITRE Shield which I highly recommend checking out. In their words, Shield is “An active defense knowledge base MITRE is developing to capture and organize what we are learning about active defense and adversary engagement. Derived from over 10 years of adversary engagement experience, it spans the range from high level, CISO ready considerations of opportunities and objectives, to practitioner friendly discussions of the TTPs available to defenders.“. There is also ATT&CK for ICS (Industrial Control Systems) which I recommend checking out if you are interested in / involved in protecting environments with Industrial Control Systems.

Secondly, this post is just my view on the MITRE ATT&CK framework and how I believe it should be utilised when creating SIEM detections. If you disagree or have other thoughts, please discuss with me on twitter as I am always open to new ideas and ways of thinking. Right, lets get into what we are here for.

What is the MITRE ATT&CK framework?

The MITRE ATT&CK framework is, in their words; “A globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.

So the site is pretty much a vast repository of well known tactics and techniques used by attackers. For every one of these tactics, techniques and sub-techniques there are examples, mitigation steps, detection ideas and references.

To start with, the 14 different tactics –

  • Reconnaissance – Consists of techniques that involve adversaries actively or passively gathering information that can be used to support targeting.
  • Resource Development – Consists of techniques that involve adversaries creating, purchasing, or compromising/stealing resources that can be used to support targeting
  • Initial Access – Consists of techniques that use various entry vectors to gain their initial foothold within a network
  • Execution – Consists of techniques that result in adversary-controlled code running on a local or remote system
  • Persistence – Consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access.
  • Privilege Escalation – Consists of techniques that adversaries use to gain higher-level permissions on a system or network.
  • Defense Evasion – Consists of techniques that adversaries use to avoid detection throughout their compromise.
  • Credential Access – Consists of techniques for stealing credentials like account names and passwords.
  • Discovery – Consists of techniques an adversary may use to gain knowledge about the system and internal network.
  • Lateral Movement – Consists of techniques that adversaries use to enter and control remote systems on a network.
  • Collection – Consists of techniques adversaries may use to gather information and the sources information is collected from that are relevant to following through on the adversary’s objectives.
  • Command and Control – Consists of techniques that adversaries may use to communicate with systems under their control within a victim network.
  • Exfiltration – Consists of techniques that adversaries may use to steal data from your network.
  • Impact – Consists of techniques that adversaries use to disrupt availability or compromise integrity by manipulating business and operational processes.

You may hear these tactics referred to overall as a “Kill chain”. This term originally comes from Lockheed Martin, a defense contractor, coining the term “Cyber Kill Chain” around 2011 / 2012. This still exists today and is a more structured and strictly defined 7 step definition of how attackers perform recon, through to actions on objections, see more here.

For each of these tactics, there are various techniques; 206 in total currently for the Enterprise section (Excluding iOS / Android). Under techniques there are also sub-techniques. For example, the tactic Persistence has a sub technique called Event Triggered Execution. This in turn has 15 sub-techniques.

Don’t worry – I’m not away to go through all of them. This takes me to one of core the points of this post though. The MITRE ATT&CK framework is a fantastic resource. But it is also extremely vast and extensive when you include all the sub-techniques especially. I have seen a few vendors and other people in the industry promoting, or backing, 100% MITRE ATT&CK framework coverage using SIEM detections and other security devices. I’m here to tell you that I don’t think you should be doing this with your SIEM. This is due to the fact it is an unreasonable goal for the majority of us, and time can be spent better with other efforts.

MITRE ATT&CK framework – A guide, not a goal.

I believe the MITRE ATT&CK framework should be used as a guide when researching and creating SIEM detection’s, but not used exclusively; lets discuss why.

Firstly, it was never designed to be used as a SIEM rule repository. It is an extensive, in depth library of a large number of scenarios an attacker may exhibit during an attack. Your SIEM likely won’t be able to collect the logs to cover all of these sub techniques. Even if it can (which is unlikely) you may not even need to cover all of the mentioned techniques and sub techniques as your business may not be using certain applications, OS’ etc that they relate to.

The next reason is a false sense of security. Just because you create a detection for a particular tactic, technique or sub-technique, does not mean you are fully covered against it. Many of the tactics and techniques are so varied that it is implausible to create detection’s which will alert you to every possible attack.

Even though it is vast, it may also not covering everything for your particular organisation. Those weird side cases you need to account for, specialised use cases for your in house application that nobody else even uses. Following it exclusively may ignore these cases.

Finally, is this whole new attitude to. “Our product can provide you with 95% MITRE ATT&CK Coverage” or “You must aim to cover every single tactic and technique” This thought process is, in my opinion; extremely flawed. If you attempt to create a detection for every single tactic, technique and sub technique there is – how robust are these detection’s going to be? How much are they going to be tested, what are the playbooks going to look like for responding to them?

Rather, I believe MITRE ATT&CK should be used as a part of your SIEM detection strategy. Also a source of research, and for mapping (when possible) rules to the framework, so analysts can see clearly when an attack is taking place – which stage the attacker is potentially at. It should not however, be the only focus of your strategy.

How should it be used as part of your SIEM detection strategy.


To make it clear again – I am not counting the MITRE ATT&CK framework out here. It should form part of your strategy, not define it; here is how.

  • Use it for research. Pick out tactics and techniques which you feel you may be missing in your detection’s; or which suit your business, environment and log sources well.
  • Map your detection’s to it. As I mentioned in my SIEM – USE CASE WRITING post, I recommend mapping your use cases to the framework when possible. This wont be possible in every case, but it can aid analysts when they trigger – as it can help them to see patterns, and when an attacker may performing various stages of the kill chain in order.

You should compliment the above with other methods of research and detection methodologies to create a better balance and coverage in your SIEM.

The majority of SIEM platforms come with good out of the box use cases, such as –

There are also some other open source, free repositories of detection’s, such as –

On top of the above, you should also be running test’s against your SIEM platform to gather data indicative of an attack, insider threat etc. This can be done using a professional red team exercise; or for free using tools such as Atomic Red Team.

Your SIEM engineering / detection / operations team should also be keeping up to date with sites such as The DFIR Report to see which new TTPs you should be monitoring for.

Last but definitely not least, consider custom applications, software and the like within your environment. There will not be any out of the box, or open source rules for this; but you should definitely still be monitoring it. To do this, have discussions with the teams in charge of these platforms and find out more. What are they used for, what is normal behaviour on them; what data do they contain. If you can get logs for these platforms in your SIEM, try to build detection’s using the information you have gathered from these discussions.

So, I saved 10000 hours not implementing every sub technique; what should I do with this time?


You will likely save a lot of time not fruitlessly trying to implement each and every tactic, technique and sub technique. Use this time to improve your existing detection’s and your overall SIEM setup. This could include, on top of the above –

  • Review the logic of your existing detection’s and fix any errors.
  • Test your existing detection’s and keep sure they actually detect what you expect them too. (Is the payload a bit different than you thought, can another method be used to bypass your detection’s)
  • Review the existing playbooks for your detection’s. Do they make sense? Would they lead to the resolution you would hope for? Test these playbooks when testing the detection’s and see if things are dealt with correctly following them.
  • Train analysts about your SIEM detection’s. Do they understand them? Explain to them why they exist and how they work.

So those are my thoughts and feelings on the MITRE ATT&CK framework in relation to SIEM detection’s. Do you disagree or agree with me? Lets chat about it on twitter.

If you enjoy the content on this site and want to support me, please see

Leave a Reply

Your email address will not be published. Required fields are marked *