MITRE ATT&CK: Threat Model Thursday
Threat model Thursday, let's dive deep into a detailed approach to using ATT&CK
For Threat Model Thursday, let’s look at Threat Modeling with ATT&CK from the Center for Threat Informed Defense at MITRE. As always with Threat Model Thursday, my goal is to respectfully engage with interesting work and ask what we can learn from it. This one is particularly interesting because I’ve been teaching threat modeling with kill chains, including ATT&CK, for many years.
First, it’s incredibly nice to see an overview graphic, and nice to see another system that adopts the Four Question Framework, and has a condensed view up front of what you need to know.
I think most of my comments are about how to fit various activities
into the framework. For example, step 2 is “Identify critical
components and dataflows that, when impacted, would result in
mission failure.” Do we need to do that as identifying what we’re
working on, or can we get there via a structured approach to what
can go wrong? Similarly, the split between analyzing the
DFD with a structured tactic technique and then looking for ATTACK isn’t
how I do it. I tell people to look directly for where the
ATT&CK techniques (the categories on the top of the ‘waterfall’)
can apply. For example, we can directly look across a diagram and
ask:
- where does delivery happen?
- Where does exploit happen?
- Where would something be installed? (etc)
MITRE's approach has a fascinating tie-forward from threat to techniques observed in the wild to fixing the issues. If your threat modeling is constrained to systems that you acquire from vendors and integrate, then fixing those issues first is a sensible approach. (If you’re building the tech, there are lots of strategies for selecting what to fix first. It would be a massive digression to explore those here, but a sample alternative is “fix the things that’ll be hardest to fix later.”)
As we get into the details, there’s an overlap between what I think of as the technical aspects of threat modeling, like “using ATT&CK to identify threats,” and the organizations ones, such as assembling your team (on page 6). The choice to include it makes for a more prescriptive document, which is good, and covers things that are covered elsewhere, which can make it harder to see the unique contributions. (This is why I created the Jenga Model of threat modeling.) The use of a pre-mortem to find participants is fascinating. I usually think of it as a technique for considering “what can go wrong,” rather than finding participants. It also implies an operations framing (“unable to provide a key service to your customers.”)
The “theory vs evidence” breakout on page 12 is thought-provoking. On the one hand, it’s hard to argue with. On the other, the “has not happened” is a bar that depends on level of abstraction..people have spoofed, tampered, etc, but perhaps they haven’t applied that to a particular system. Is that a “has not happened?” Should you waiting until threat group X is using the exploit before treating it as high priority? [On the flip side, “has happened” is also a really useful bar. If it’s happening and making it into the ATT&CK framework, you probably should get on it.]
The Mappings from ATT&CK to defensive frameworks is useful if you’re using one of those frameworks, and is a helpful lens into ‘what are we going to do.’
I also have a few nits:
- I’d like to see more advice about how to engage in mission decomposition. MITRE’s main government customers are unusual in having actual missions, and I’d like to see how that plays in with more details.
- I don’t like the juxtaposition of “structured” and “brainstorming.” Either it’s brainstorming, or it’s a structure. Perhaps this ties to the mistaken framing that the relationship between “brainstorming” and “formal” is a binary choice rather than a spectrum. (Irony alert: Yes, I am claiming that brainstorming/structure is a binary, and there’s a clear line of “if there’s a structure, it’s not brainstorming, the totally unstructured way of working.)
- I don’t like the “threat + defense = risk” pseudomath. I think you might assert that threat minus defense is risk. I don’t think that’s right either, since it elides impact and likelihood (possibly because likelihood of a known-to-be-in-use technique is one).
But overall, it’s a very interesting approach with a degree of repeatability and justification that’s unusual.
[Update: Since publishing, I’ve had some great conversations with the MITRE team, who pointed out that I got technique vs tactic wrong (oops!) and the value of covering things attackers are actually doing, which I seem to be discounting in the ‘theory vs evidence” paragraph.]