This post kicks off our new weekly Peer Perspectives series!
Each week, we’ll explore a fresh threat modeling topic and open it up for community discussion. For the next few weeks, we’ll dive into key findings from the newly released State of Threat Modeling Report 2024-2025.
Hello friends!
The State of Threat Modeling Report 2024-2025 shows that STRIDE is still the most common framework – about a third of respondents use it, while one-fifth follow Shostack’s 4-question framework. Interestingly, most organizations mix in elements from 3+ other methods.
Curious to hear from you:
How does your approach to threat modeling use STRIDE? What are the highs, the lows and everything in-between?
We use STRIDE per Element and like the simplicity and that it really spawns good ideas for threats.
One downside is that the order doesn’t make too much sense except for being a word.
We approach ITD - SE - R or SE - ITD - R.
With SE, there’s good support from Attack Trees. With R, there’s some redundancy with Detect from MITRE Cyber Security Framework. That’s where the blending kicks in…
I think STRIDE is one of the best ways to introduce threat modeling to people, it provides a straight forward map and structure which facilitates consistency.
One of the most important benefits to STRIDE is that it helps with the classic question: “did we do a good job?“ - it helps timebox and guide coverage of a design in a consistent way. Some things I have had success with are (probably all from Adam Shostack’s book):
Finding one threat for each category/letter in STRIDE. This is great for light weight initial threat models.
STRIDE by element or data flow helps dive deeper into the design but still gives you a stopping point.
The category does not matter as much as finding the threat and doing something about it. Move a tampering threat over to spoofing if you have too many of one and just move on.
I find once people are more familiar with threat modeling under STRIDE what becomes more important are the outcomes, and not following STRIDE specifically. People are seem to naturally follow and stay within the four question framework, but threat model more freely and even more creatively.
I have also had a good success using a questionnaire format based on the common threats identified and mitigated by threat modeling the system over time. How it works is you have PM’s or Engineers complete a short survey in the context of their Story/Epic etc, and answer Y/N to to a set of questions and this becomes your threat model. Based on the answers you can decide if you want to dive deeper into DFD assisted threat modeling, STRIDE, whatever. An example for an API change might be:
Are you adding a new API endpoint.
Does the endpoint handle sensitive data?
Is the API endpoint public facing?
Does the API deviate from standard authn/authz annotations in code?
IMO, STRIDE is popular because its so ingrained into traditional threat modeling and most of the threat modeling tools we use.
As a classification system, I think its really good for teaching people about threat modeling. My concern with STRIDE is when I interview seemingly senior security engineers and architects and STRIDE is the only approach they know.
In some ways, I think the tools we use get in the way and prevent some folks from moving beyond STRIDE.
Yes, I think if senior people are only comfortable (or familiar) using STRIDE it can mean a few things. Some insights that I have found either during interview stages with potential candidates or with other peers can be categorized in a few general ways:
Have not actually done much threat modeling, at least not frequently, so STRIDE is their substitute for muscle memory. More exposure, more creative approaches helps.
Love a consistent framework and are prone to rules based and procedure driven processes. Let them have STRIDE! Haha. As long as they have useful outcomes it’s just their preferred framework. There are also still PASTA people and DREAD people out there too, to each their own as long as they are efficient and effective I can work with it! Haha. Show these folks LINDDUN! Expand their frameworks a bit!
Have been poorly taught or have been in an environment that does more “check box” threat modeling, these folks just need to come back to “what can go wrong” and “what will we do about it”.
Think a threat model is complex, it has a big table of contents and diagrams and categorized threats and the size and importance of this artifact is what seems important. Take STRIDE and threat modeling way too far here, this is not whiteboard hacking.
I typically focus on repudiation threats in my systems as what can we not account for that could cost us money or liability. Threats like
A customer says we throttled them but they were under their licence limit, we can’t prove they weren’t so they get a X dollars refund.
A customer says an admin account password must have been breached or something to perform X operations, the admin in no way has malware or a compromise on their system because we have AI based XDR. We don’t audit time and location data for admin access and actions so this can’t be easily denied. FYI breached is not a term legal teams appreciate to see in threat models haha. So let’s use “potentially exposed”
The other type of repudiation threats we just categorize differently, or they are related to the initial issue. Something like:
Information Disclosure: An API key is used to exfiltrate customer data from the system to an unknown and untrusted IP address because there is no protection or detection mechanism to identify trusted systems. Also there is no logging to determine how much data was exposed or how long the access persisted.
we would not be concerned recording the repudiation as well here separately because it’s implied. The mitigations will be likely broken out, but the threat is typically kept as one scenario.
What are some of the threats you see that are kind of looking like they should be doubled up? Maybe it’s an good indication of a common/shared system library or something? I’m curious!
I don’t think threat modelling can avoid STRIDE in principle, because it covers the basic security design threats we should be looking for in virtually any system.
However, I never had much success communicating STRIDE to devs, and frankly some of the threats are not relevant for every flow or even system. DoS threats are not usually handled by the software dev teams, and usually handled by the infra team, so I don’t ask the devs about that. Repudiation threats I typically just make sure they have logging in place. There are always exceptions where these threats are more relevant for some systems.
That leaves me with STIE which is no fun, so I prefer to just talk to teams about Confidentiality, Integrity, Authentication and Authorization, which people are inevitably more familiar with.
Thinking about if DoS really is mostly infra. DoS Attackers love endpoints with low pre conditions, little request effort, high server side effort. Perfect example: WebMention sender without limit in how much it downloads when it tries to discover the WebMention endpoint? “Hey, this is internet stranger. Could you please download that 5 Terrabyte resource 1000 times?”
One of the definitions of Repudiation that I’ve seen is:
A (threat) actor can claim “I didn’t do it” and there’s no way to prove them wrong.
Now what’s the “it” in “I didn’t do it”? Probably a malicious action. So we can combine the “I didn’t do it” / “It wasn’t me” generic threat with all other threats and see if there’s a match. Which is close to thinking about Detect.
I think STRIDE is just a good basis. If you don’t threat model and are trying to start - STRIDE is probably the best choice, given the abundance of learning materials and the wide coverage of threats by the framework. But it doesn’t have to be the only thing, doesn’t have to limit you.
For example, if one has more time to do a deeper analysis, then MITRE CAPEC could be used as a detailed source of threat definitions. I use it from time to time in pair with STRIDE. The train of thought usually goes like this: take a STRIDE category, brainstorm what can go wrong, then search CAPEC for more specific threats.
There are always some systems where DoS is a dev concern, just not that many in my experience. The way I see DoS attack actually happening is just generic networking flooding of a target. A threat actor needs to work a lot harder to DoS a system if it requires a custom app-specific attack. Even if a threat actor targets a technology for DoS (i.e. a common framework) then you really need the framework to fix it, and it’s more about secure defaults for using the framework. I would say my “default” attitude is not to worry about DoS attacks unless I see a reason to (through my analysis of the system for the threats that I do care about or if the business is very sensitive to performance/latency).
If you want evidence of actions then you probably care about many actions, which means you would have a control that can generate that evidence generically for numerous actions e.g. logging. Sure you can view it as the number of threats doubling, but the control is same for all those additional threats, so I would do myself (and my devs) a favour and aggregate all those threats together, and talk about it as a class of threat with specific controls.
It depends on the CONOPS, definitely. Operational technology systems, systems sensitive to performance/latency (e.g. a trading platform) all require more due care on DoS threats than say, typical IT systems like e-commerce websites.
Happy to start the conversation! 
