We’ve covered a lot of different angles to threat modeling. The main takeway for me is that there is no “best approach” – pick what makes sense to you! How you justify that is up to you, and hopefully less controversial than John Lennon’s denial that “Lucy in the Sky with Diamonds” was about LSD. Here we’re talking about the Diamond Model of Intrusion Analysis. This model describes an active event under investigation, but it is mentioned here because it is helpful to understand how this information so directly links to the other models we’ve discussed before. So what makes the Diamond Model a useful threat modeling tool for analysts on the front line?
This model was created by 3 researchers from the now defunct Center for Cyber Intelligence Analysis and Threat Research (CCIATR) in 2006. Sergio Caltagirone, Andrew Pendergrast and Christopher Betz were frustrated by the linearity of the Kill Chain model and looking for a more flexible model that would not only assist threat researchers but also help guide incident handling in real time. The Diamond Model is their opus.
How does the Diamond Model support Analysts?
The resulting scientifically-oriented model describes how “an adversary deploys a capability over some infrastructure against a victim.” By tying these vertices or “features” together using “edges”, which represent the fundamental relationships between each of the features.
You’ll hear real physical diamonds characterized using cut, color clarity, and carat. Four features! And they have the added benefit of a common first letter – but now I am getting picky. Need a different analogy? It’s like a detective’s magnifying glass for digital threats, breaking down incidents into four key features and connecting the dots to show how they relate. Think of it like a game of Clue, but with hackers and malware instead of Colonel Mustard and candlesticks.
Like its physical namesake, an event’s diamond has four “core” features:
- Adversary: What is the identity or known characteristics of the threat actor targeting your environment? This information may be incomplete, but can help anticipate next steps.
- Infrastructure: What sorts of resources did the adversary use that can be detected? IP Addresses, domain names, email address and more all offer some atomic indicators that may be useful.
- Capabilities: What did the adversary do in this particular event? Did they leverage exploits, deploy payloads, deny service, or some other impact?
- Victim: What do we know about the victim or victims? What was compromised? How was the impact felt? How many and what sort of users, hosts, or data was impacted?
Getting “meta” and adding context to the Diamond Model
Just like any diamond purchase or game of Clue, there are always other factors at play. Those other factors might not be primary concerns, but add to the story. These”Meta-Features” make their appearance on top left of the example below. These aren’t repeatedly gathered for every event in a chain of events like the core four, but occasionally as the story of an intrusion evolves.
As you and your team leverage the Diamond Model, you may string multiple diamond representations together to help describe a full chain of events in an attack. As you proceed, this can help quickly orient new investigators, reveal trends or patterns, and provide accounting of the investigation for forensics folks. Some SOC tools will format their databases in this fashion to ensure all of your teammates are using this model to stay in synch.
When is the Diamond Model’s threat modeling approach helpful to analysts?
I should probably have provided an analysis of each approach and where it best applies, but let’s start now. What are the Diamond Model’s strengths? It shines in its simplicity and flexibility. It’s a straightforward framework that can adapt to various types of cyber threats, from pesky malware to full-blown state-sponsored cyberattacks. We can build diamonds on the fly (cool garage band name!), unlike MITRE’s ATT&CK, Attack Trees, or Data Flow Diagrams. This adaptability makes it Diamond Model a useful threat modeling tool for analysts and a handy tool for a wide range of reactive cyber applications. These traits make it quick, so you’ll see some SOC tools use it heavily.
But, like anything else, it’s not without its weaknesses. the Diamond Model’s simplicity, while a strength, can also be a downfall. Sometimes the model might oversimplify complex cyber threats, leading to gaps in analysis. It focuses exclusively on the atomic side of things. Tying multiple Diamonds together to explain a playbook can get ugly fast. If we do, we combine it with other threat modeling styles to help keep it organized, like the example below (combining with the Cyber Kill Chain) Rarely do we share CTI through this model – it just doesn’t convey overarching APT behaviors the same way as an ATT&CK emulation plan. Lastly, the model heavily relies on quality data. If the data is sketchy, the analysis might be as reliable as a chocolate teapot.
Mike