Go Back

Cyber Threat Intelligence Frameworks: 5 Rules for Integrating These Frameworks

January 29, 2020
Cyber Threat Intelligence Frameworks: 5 Rules for Integrating These Frameworks

 

As the cyber threat intelligence (CTI) industry continues to grow, so does the discipline’s thinking tools. Whether your intelligence team is using the cyber Kill Chain, the Diamond Model, or MITRE ATT&CK, there is now no shortage of frameworks that can assist security teams in capturing and organizing intelligence.

What’s more… we are likely to see even more frameworks emerge in the near future as the CTI community continues to develop.

In many ways, this is something to be celebrated and the proliferation of frameworks highlights how the CTI industry is growing. Building common vocabulary and concepts to articulate what are often highly complex threats ultimately makes CTI more digestible. This is why Digital Shadows uses frameworks, including MITRE ATT&CK, to provide actionable intelligence on the back of high-profile incidents, such as the United States’ indictment of the Russian GRU and recent concern surrounding the potential cyber threat posed by the killing of Iranian General Qasem Soleimani.

 

ASD Essential 8 mappings for initial access and execution

Example: ASD Essential 8 mappings for Initial Access and Execution

 

But the growing role of these frameworks also poses challenges to the industry. There is a risk that analysts focus too much time measuring different frameworks against each other, rather than appreciating the specific benefits of each approach. Ultimately, CTI thinking tools shouldn’t be seen as a zero-sum game.

We don’t need one framework to rule them all.  

There is also a risk that analysts embrace CTI frameworks without a clear sense of why they are doing so or the problems that they solve. It’s all well and good going full whack on MITRE ATT&CK integration, but it’s vital that this is done for a real and tangible purpose.

This blog discusses how different CTI frameworks can co-exist, and suggests some practical rules to bear in mind when integrating these frameworks into intelligence practices.

 

Embarking on creating and building a threat intelligence capability? Check out our Threat Intelligence Deep Dive.

Threat Intelligence: A Deep Dive

 

Building a conceptual cookbook

Frameworks are, ultimately, thinking tools. Each framework is unique and different design decisions have been made related to their degree of abstraction and focus.

Therefore, it’s far more productive to view different frameworks as part of a “cookbook”: an approach where we have a variety of frameworks at our disposal, and can pick those most appropriate for the situation at hand or based on the problem that needs to be solved.  

This is an approach widely recognized elsewhere in the industry. After all, there’s no one way to perform penetration testing or malware analysis. Instead, red teamers and malware analysts possess a cookbook (or toolkit) of different programs and techniques. Depending on the challenge at hand, it’s up to them to decide which tools would be most useful and appropriate.

Although it’s important to understand the strengths and weaknesses of different CTI frameworks, the more fundamental issue to grasp is an understanding of the type of contexts in which each framework is appropriate (or not). This shift in mentality means that different frameworks can peacefully coexist and be used in a more agile way.

 

5 rules for integrating CTI frameworks

Despite the clear benefits of using CTI frameworks, there’s a risk of applying them in the wrong way. The following set of rules provides a practical checklist for practitioners looking to integrate these thinking tools into their intelligence processes.  

  1. Know your audience. CTI frameworks should always be audience centric. This is where the idea of a cookbook is vital. On the one hand, a C-suite audience will almost certainly struggle to follow along with even frameworks considered straightforward in the industry (good luck walking an impatient CEO through all seven stages of the kill chain). Intelligence teams should always be aware of the danger of overwhelming non-techies and senior stakeholders.

    On the other hand, there might be other contexts where even more detailed frameworks are considered too simplistic. As Juan Andres Guerrero-Saade has eloquently argued, the industry’s current thinking tools risk steering CTI down a piecemeal approach to intelligence―one that takes consumers further away from a full understanding of attacks and risks breeding complacency.
  2. Avoid the reverse-engineering trap. Intelligence teams should ideally look at the challenges they face and ask how they might be solved. This is then the time to consider how various CTI frameworks might help (or not). CTI frameworks should ultimately address a problem and improve a team’s products and services. There’s a danger that intelligence teams go the other way round by first integrating CTI frameworks and then trying to reverse-engineer the problems that they might solve to as a way to justify why this has been done.
  3. Frameworks aren’t a magical elixir. As useful as they can be, CTI frameworks are rarely a substitute for hard work. Analysts can’t just tag something against a certain tactic category, pat each other on the back, and crack open a couple of cold ones. While it might make analysts’ lives easier, intelligence is not the same as tagging. Intelligence is an ongoing and dynamic process that often requires nuanced assessment and tradecraft. Threat actors change and refine their tactics over time, meaning the use of frameworks needs to be regularly reassessed. This highlights the importance of more dynamic forms of adversary profiling. Frameworks can absolutely play a role in capturing the tactics of threat actors, but they can be implemented in good or bad ways.
  4. Not everything needs a framework. As great as frameworks can be, they should be enablers, not straitjackets. Using a framework for the sake of using a framework helps no one. Intelligence requests are often best presented via frameworks, but analysts shouldn’t be afraid to go off-piste. Analysts should abandon frameworks if intelligence can be presented in a more digestible and straightforward way for the audience at hand.
  5. Don’t dismiss DIY. Unlike plastic, single-use frameworks don’t have a carbon footprint. Frameworks, fancy tables, and flashy infographics can all be developed to present a very particular problem, never to be used again. They can be thrown away, reassembled, and modified in whatever way makes the most sense. As long as such an approach improves the delivery of intelligence, flexibility should be embraced.

The cyber-security industry is now a vast space that comprises different audiences, communities, and problems. A variety of CTI frameworks should reflect this reality. The growing role of conceptual frameworks within the CTI community presents opportunities to improve the intelligence provided to consumers. But there’s also a risk that these thinking tools are misused. By ensuring that the use of frameworks is focused on solving problems and improving the delivery of intelligence, the industry can ensure that the thinking tools we use play a central role in improving security.

 

Further Cyber Threat Intelligence Framework Resources

Curious to see how we’ve used cyber threat intelligence frameworks in our own assessments here at Digital Shadows? Check out some of the examples below and let us know what you think.

Mapping Iran’s Rana Institute to MITRE Pre-ATT&CK and ATT&CK

Mapping the ASD Essential 8 to the Mitre ATT&CK™ framework

Mapping the Tyurin Indictment to the Mitre ATT&CK™ framework

Purple Teaming with Vectr, Cobalt Strike, and MITRE ATT&CK

SamSam But Different: MITRE ATT&CK and the SamSam Group Indictment

The 2017 FSB indictment and Mitre ATT&CK

MITRE ATT&CK™ and the North Korean Regime-Backed Programmer

Mitre ATT&CK™ and the FIN7 Indictment: Lessons for Organizations