Ask 5 different people what threat modeling is, and you’ll likely get 5 similar, but different, answers. GRC, dev, SOC analyst, IR, red team – there’s overlap but it’s difficult to get to a common model. As someone with more of a detection engineering focus, I have goals for threat modeling that may not line up with any of these. I wouldn’t necessarily say a common model is required, but the biggest issue I find with the different approaches is that you are left with vagueness and a sense of dread. Sure, you feel better because “threat modeling”, but there isn’t a clear path forward.
So, how do you make threat modeling more than an exercise in futility?
Where do we begin with threat modeling? The simplest method may just be asking “what if”? I love the what if game. I trend pessimistic, so I can come up with a rather terrifying set of what ifs. It’s a starting point, and I suppose better than nothing. But it’s unlikely to lead to much action beyond maybe we should do more with this. But if FUD gets the ball rolling, it can be useful.
So you play “what if” and convince the powers that be that threat modeling to give our FUD a little more structure would be helpful. Now what? I’ve used most of the typical threat modeling approaches – STRIDE, PASTA, OCTAVE, etc. This blog covers a lot of options in a short space to give you an idea of the different options out there. All of these have their strengths, but I’ve found them kind of lacking for various reasons. Digging around, I think Katie Nickels nailed the frustrations with a lot of these in her blog for red canary. I wanted something practical, efficient, actionable, and directly linkable to threats. I also wanted something you could zoom in and out with as needed so you aren’t switching methods all the time.
First up, what are you threat modeling? This will drive later questions like who needs to be there and what deep dive approach should be taken. An important question to ask is if you are approaching the thing at the right level. Do you want to look at an entire system (say a SaaS product you use) or a specific type of thing (like an AWS Lambda) or maybe even the org. Each will need a slightly different approach, but there are commonalities you can use to keep the threat modeling program consistent and focused(ish).
Along with the what, determining the business objectives and integrations in place is needed. I’m big on asking what is the point of this. If something is worth threat modeling, you should be able to articulate specific needs associated with whatever it is. If you can’t, maybe this should be a discussion about deprecating rather than protecting. The integrations should inform this. Can the thing meet the business need with the existing integrations? How risky are those integrations? Does this innocuous seeming thing provide an easy path to the crown jewels? I like to include a system/data/integration model of some sort too. How detailed you get will be driven by what you are doing. If your org uses data classification, adding those to the model would be helpful. This helps you find integrations you might have missed and can help identify movements paths you might not think of otherwise. The threat modeling lead may be able to complete part of this, but your SME should be contributing. Use existing documentation (and link to it) wherever you can to avoid redundant work.
With the lead and SME introduced, the next question is who needs to be in the (virtual) room? A minimum of 3 is good to ensure coverage – lead, SME, attacker. I think someone in the detection and response space is a good person to lead the meeting. This person preps the threat model and guides the meeting. If your org has a threat modeling team, they would lead, but I find few orgs have a dedicated team. You need at least one person (the SME) who is very familiar with what you are addressing. If possible include an attack focused person, especially if your lead isn’t strong on the offensive side. I want to keep the group to 5 or fewer. More than that you run into issues with scheduling and chasing rabbits. The documentation produced can (and should) be reviewed by others to spot potential gaps.
When you start getting in to the threat model, I start with threat actors. Most of the time, these will be general and fairly consistent. The general ones you should be able to identify from an org level threat model (or looking at info for your sector). Internal and external should be considered. I don’t spend much time here unless there’s a reason the threat actor might be unique or different.
Since I’m generally acting as the lead, from threat actors I go into biggest concerns (AKA what keeps me up at night about this thing) and a deep dive into the appropriate threat modeling approach. I tend to use MITRE ATT&CK to guide the deep dive because of the expansive coverage. It forces you to think about more things – many may be N/A or of low concern, but at least you’ll give them a passing thought. I might go STRIDE or PASTA for a development threat model or OCTAVE for org level, but most of the time ATT&CK helps me derive focused action items. Once I do the deep dive, I’ll use that information to expand on the main concerns and identify the key areas to address. Discussion of these things will make up the bulk of the threat modeling meeting. When you work through the concerns, you should be collecting action items related to hardening and detections. There may be things that fall into other categories as well. Link the detections to whatever framework you link to (like ATT&CK) and put them into your detection pipeline. The hardening items will end up with the system (or whatever) owner.
Initial work done, time for the meeting. Generally 50 minutes is sufficient, but you may find a follow-up meeting is necessary. Ideally people would review the prepped threat model prior to the meeting (possibly with their teams) and bring feedback. I like setting aside 10 minutes at the beginning of the meeting for review because even when people have done the pre-work, the review time helps shift gears and remind everyone what you’re doing. During the discussion, the lead should be jotting down action items for hardening and detections. I’ll either use a desktop-size whiteboard or have the threat model document open to the action item area in a second window (others on the meeting may not love the switching during screen share – using a separate screen is better). After the meeting, the lead will need to generate the action items in whatever system you use and help drive those to completion.
Now comes the hard part of following through, but you should have a tangible to do list rather than just doom.
There are some disadvantages – it’s a heavier workload for the person prepping the documentation, the deep dive part can vary, and there can be things missed (that’s a risk with any approach). But the advantages of asynchronous development/review with a shorter, more focused meeting makes it easier to actually get threat modeling done and done in a way that you can do something with it beyond filling a pretty report. I’m finding total time for initial prep to generally be an hour-ish for things I’m familiar with and a couple hours for things I’m not familiar with. I find that acceptable though since I’m probably going to need to write detections for whatever it is anyways. Total time investment for prep and action item creation can be as little as 4 hrs (1 hr prep, 1 hr x 3 for meeting). That’s really not a lot of time to get valuable information. And it keeps the time commitment down enough that people don’t groan when you recommend (or insist) on doing a threat model – well, at least not to your face. I’ve also found the prep work makes for a more fruitful meeting. That synchronous time is high cost, so I want it to also be high value. This is an evolving approach. But I’m liking it. You can argue this goes beyond threat modeling. Maybe that’s a good thing? I consider threat modeling without actionable outcomes to be…unsatisfactory.
Documentation outline:
- People
- Lead
- SME
- Attacker
- Thing being modeled
- Business objectives
- Diagram
- Threat actors – general internal/external, anything specific?
- Top concerns/threats
- Deep dive – matrix of whatever specific approach works for you
Pre-meeting:
- Lead preps threat model
- SME and team review
- Attacker and team review
Meeting agenda: 50 min
- Threat model review 10 min
- Threat model discussion 30 min
- Wrap up and action items 10 min
Post meeting:
- Hardening efforts by SME and team
- Detections enter detection lifecycle
- If available, engage in purple teaming to validate detections
- Revisit threat model as needed – when an impacting change occurs and/or on a scheduled basis
apageinsec 