Our development teams are getting the hang of STRIDE threat discovery, but one issue that remains is related to threat decomposition.

The way we see threat analysis is that it consists of identifying applicable threats and then determining what types of attacks (be it attacks like XSS, or misuse of poorly-designed control flow) can realize those threats.

This threat decomposition is tricky, as the quality of this task is determined by the target of analysis, the knowledge (and even something as trivial as mood) of the group performing the analysis, and the time dedicated to this activity. We quickly determine "low-hanging fruit" issues, and then as times go on fewer and fewer credible attack vectors are determined.

What are the acceptable approaches for determining the stopping condition of threat decomposition? Is it simply a time? How are organizations handling this?

  • Risk Management -> you modulate the stopping condition of your analysis of the different part depending on how much it would cost (money, image/trust) to have security breach in that components (and those who might get contaminated also), how much do you cost to fix and your own time/budget.
    – Walfrat
    Sep 14, 2018 at 8:25

2 Answers 2


I'll answer this with a quote from Adam Shostack's 2014 book Threat Modeling - Designing for Security.

There are three ways to judge whether you’re done finding threats with STRIDE.

The easiest way is to see if you have a threat of each type in STRIDE.1 Slightly harder is ensuring you have one threat per element of the diagram.2 However, both of these criterion will be reached before you’ve found all threats. For more comprehensiveness, use STRIDE-per-element3, and ensure you have one threat per check. Not having met these criteria will tell you that you’re not done, but having met them is not a guarantee of completeness.

If your team is already modelling with STRIDE they should know this, but I will mention it either way: STRIDE is obviously an acronym which stands for: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. These are also the types of threats.

Shostack explains that before you start to threat model you should build a diagram of your research object. That is what he's referring to when he's talking about a diagram.

STRIDE-per-element is - as far as I understand - a more microscopic approach to threat modelling. You take elements of your diagram and only examine certain threat types for every element. Here's a blogpost kinda explaining the whole thing. From a quick glance, this seems to have its advantages.


I am hard pressed to argue with an answer that quotes me, so I'll just add that sometimes the risks, the sensitivity of the data, the impact of breach, can inform how far you go.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.