A practical approach to threat modeling

It’s easy to get overwhelmed with all the cyber threats your organization faces. On a daily basis, new research pops up about the latest threat group or malware, and it’s easy to feel like you’re buried in reporting about threats. No team can fully understand or track every threat out there, so you have to prioritize what matters so you can focus on defending against that. Luckily there’s a methodology that can help you: threat modeling! In this post, I’ll outline a practical, intelligence-driven approach you can use to get started with threat modeling. (If you prefer videos, check out this presentation I gave at this year’s Shmoocon.)

What is threat modeling?

Like me, you might have heard the phrase “that’s not in my threat model” being thrown around, but I felt like this was a term I didn’t fully understand, so I started digging. From my research, I found that threat modeling is a concept commonly used by software or system engineers who are trying to design securely. There are many different threat modeling approaches out there, and most of them take a system-centric or software-centric approach. They consider all of the potential threats that a system could face and try to account for that when developing software or a system.

As I started reading about these different approaches, I realized that following these methodologies was no easy task! If followed thoroughly, any one of these models could take a team months to apply. As a threat intelligence analyst, I was overwhelmed by the idea of considering all threats—there’s just no way I could possibly keep up with everything out there!

Yes, considering all threats is hard! 

Considering existing approaches and inspired by content in the SANS course I teach (FOR578: Cyber Threat Intelligence), I wanted to simplify what could be a lengthy process and make it more accessible for defenders and analysts. My approach to threat modeling isn’t new—it’s a simplified, practical version of what’s already out there that brings in a threat intelligence perspective.

I define intelligence-driven threat modeling simply: it’s the process of figuring out what you have that adversaries care about. It’s all about examining what your organization has (“us”) and how adversaries might come after you (“them”). Expressed in a Venn diagram, it looks something like this:

Simplifying the process

Here are the four steps I suggest to get started with intelligence-driven threat modeling:

• Know your organization
• Know your threats
• Prioritize and match them up
• Make it actionable

Threat modeling can get complex quickly, but I recommend starting simply and iterating from there. I’m a fan of the quote “Don’t let perfect be the enemy of good enough”—that definitely applies here.

Know your organization

You need to have some sense of what your organization has so you can figure out the threats that matter most. Having an accurate asset inventory is notoriously difficult (if not impossible), but you can start thinking at a higher level than each individual host. If you do have any kind of asset inventory or network map, that should give you the types of systems and operating systems on your network (even if it’s not 100 percent accurate), and that’s a great place to start.

To really get to know your organization, you’re going to have to go talk to people. I recommend finding that quiet system administrator who’s been there for 20 years (you know, that person who is the only one who knows a certain obscure database? Yeah, them). Sysadmins sometimes know networks better than anyone! Go find that person and talk to them about how your network is laid out: what faces the internet? What kinds of operating systems do you have? What are the areas of the network most security people ignore?

Another way to think about what’s important to your organization is to imagine worst-case scenarios. If you’re in retail, maybe it’s your website going down on Black Friday. Resources like MITRE’s Crown Jewels Analysis can help you try to identify these “crown jewel” assets that are critical for the operation of your organization’s mission.

Take whatever information you have, even if it’s high level, and document it. I’ll use mind mapping to give high-level examples. In our fictional organization, a retailer, we’ve gathered some high-level information about operating systems, a web server we care about and the fact that we have point-of-sale (PoS) systems in our stores.

Know your threats

Now that you have some sense of what your organization has that’s important, take a look at threats. There are thousands (if not millions…*shudder*) of different threat groups and malware families out there, so start by accepting that you simply can’t focus on them all.

A simple way to understand what threats matter to you is to talk to your peers. Go find people who work at organizations like yours and ask them the top threats they’re tracking. Formal information-sharing groups like Information Sharing and Analysis Centers (ISAC) can be a good place to find peers, but don’t overlook the power of informal groups you might find through interacting on social media, attending (virtual!) cons, and networking in other ways. Many people are open to sharing, even companies you might consider competitors—I’ve been inspired by the common attitude that “we’re all in this together.”

If you’re taking a technique-focused approach to threats, our 2020 Threat Detection Report is another resource you can use to look at a sector-by-sector breakdown of top techniques.

You should also ask around your organization about whether anyone knows of threats you’ve faced in the past. Even if you don’t have a formal cyber threat intelligence team, maybe someone from your security operations center (SOC) remembers the malware family from a previous ransomware incident.

You should also keep an eye on the multitude of publicly available sources of information about threats published by researchers, vendors, and many others in this community. Any RSS feed reader can help you do this, as well as Twitter and weekly threat round-ups and emails provided by different sources. such as SANS NewsBites.

Here’s a notional mind map of the results of doing all of the above. After talking to our notional SOC, they tell us we’ve previously seen the threats listed in red. In orange are threats we learned are affecting our partner retail orgs, and in yellow are threats we read about on Twitter this week.

Prioritize and match them up

Now that you have a little understanding of both “us” (our organization) and “them” (our threats), let’s dive into how they overlap. As you do this, think about what threats you’ve identified and what assets those threats are likely to affect in your org. It will be tough, but remember that it’s okay if this isn’t perfect.

As we look at the notional threats we found earlier, we start to prioritize and weed out the ones that may not be relevant. We learn that APT1 targeted us almost 10 years ago, so we decide to set them aside for now. xHunt has mostly targeted Middle Eastern orgs, and our fictional org is in North America, so we decide they’re not a top priority. Similarly, APT32 has mostly focused on Southeast Asian victims, so we set them aside. Again, we’re not saying these threats don’t matter at all or that they’ll never matter, but rather that they aren’t a top priority for us right now. You should also remember that by addressing your top threats, you’re likely taking care of many other threats as well, since different actors share tactics, techniques, and procedures (TTP).

With our remaining threats that we think matter, let’s validate that they do by connecting the threat and the asset we think they’d be likely to target. As we do this, we realize that Shlayer is a threat affecting macOS, and because we don’t have any Macs in our environments, we decide to deprioritize it for now.

Make it actionable

Now you have a mind map (or diagram or spreadsheet or database—whatever works for you) with a list of assets mapped to threats:

• Ryuk → Windows
• FIN7 → Windows and PoS systems
• Emotet → Windows
• TA505 → Windows
• Cobalt Group → Windows and PoS systems

What does that do for us? Not much, unless we take action.

Having this prioritized list lets you determine what you should defend against. What a threat has done in the past isn’t necessarily indicative of what it will do in the future, but it’s a good place to start. For each of your prioritized threats, build out information on malware, tools, TTPs, and/or indicators, depending on what your defenders need. Next, make recommendations to them about how to defend against this threat considering your organization’s assets. For example, we determined FIN7 has targeted Windows in the past, and our organization is trying to write behavioral analytics for detection right now, so we might provide a list of TTPs that FIN7 has used in the past on Windows.

Your recommendations will depend on your org and your team’s sophistication, but might include things like collecting a new log source, creating a new query, or writing new behavioral analytics (you can get lots of ideas for those in the 2020 Threat Detection Report). A great resource for thinking about making recommendations, especially at a technique level, is the ATT&CK for CTI Training Module 5 from my former teammate Adam Pennington.

You can also look for commonalities in what threats are doing and prioritize defensive recommendations on what those threats have in common. If you’re using a structured framework like ATT&CK, it’s pretty easy to look for these. Below is a graphic of how you could create a heat map of common techniques by using the ATT&CK Navigator to compare techniques used by different threats (the most frequently used techniques are in red). This gives you an easy way to prioritize the techniques that you should focus on detecting or mitigating based on the threats that matter most to you.

Rinse and repeat

One of the toughest parts of the above process is being okay with the fact that it isn’t perfect. While this simplified threat modeling process won’t give you a complete view of all threats, it will help you get past the “analysis paralysis” of being too overwhelmed to act. Once you’ve tried this at a high level, you can go back and expand upon it. Perhaps you want to go more granular on the software you’re running, since you can then map CVEs used by various threats to software versions. Perhaps you want to focus more on the threat side and add in new threats you read about every week. Each organization will differ in how they get value out of threat modeling, so starting simple helps you do something, and then you can iterate from there.

In closing

Simply stated, threat modeling is all about figuring out what your organization has and how adversaries might come after that. There are many approaches out there, and many formal threat modeling methodologies can take months—but it doesn’t have to be that way. By taking the simple steps I’ve described above, you can use an intelligence-driven perspective to prioritize the threats that matter most to you. The point of doing this is to help you focus on what’s most important to drive better security outcomes for your organization.