I was curious on how people scope their threat models. I think it is interesting that often we have a particular set of threats we want to consider e.g. STRIDE, OWASP Top 10 etc., and we might ‘know’ that a particular threat is one that should be relevant to the system we are threat modelling e.g. a web application should worry about denial of service (DoS) attacks.
So when I’m scoping my application, potentially drawing a DFD with relevant components, it seems to me there is a choice to make:
Since I know I want to include DoS threats, I will make the scope of my threat model include the components that would be responsible for handling DoS attacks e.g. load balancers, CSP services, firewalls etc. You could call this “threat driven scoping”
Although I want to consider DoS threats, the components that handle that are owned by different team than the one that writes the web application, so I’ll worry about DoS attacks in the other team’s threat model, and I’ll just focus on threats specific to the web application. You could call this “scope driven threats”.
I’m curious if people see their own approaches matching the “threat driven scoping” or the “scope driven threats”, or something else entirely?
It’s a really fair point, but I do wonder if that’s just true in principle rather than in practice. We all know STRIDE is commonly used, and so before you even start your threat modelling activity you have already decided that you will focus on the security threats covered by STRIDE e.g. spoofing, tampering etc. So in practice you have decided on “what can go wrong” before you have finished “what are we working on”.
Moreover, the fact that you are looking at the STRIDE threats is going to affect how you gather data as part of “what are we working on”, for instance you know you will frame “what are we working on” as a DFD, as opposed to an attack tree, or a table of assets or something else.
It seems to me there is a pretty good argument that threats can drive scope, at least in practice. I think this makes sense as well, because to make the threat modelling process more efficient we often want to just focus on certain threats, and we’ll design the threat modeling activity to be good at finding those threats.
When we say “what are we working on”, this is arguably the most important part of threat modelling. Questions we can ask go around the level and depth of a threat model (e.g. a system-level threat model versus a web application versus a component-based threat model).
The framing should indeed be a DFD before we apply a methodology, whichever you prefer.
On the topic of threats driving scope, a high-level understanding of the customer’s operating environment and model (at least for system-level threat models) will provide a good amount of clarity over what they are most concerned about. For example, a shipping company with many distributed international nodes will have a much more complex attack surface and trust boundary designation compared to say, a company who operates from a single on-premise site with perhaps, employees connecting back via a VPN.
I suggest cutting a complex threat model into multiple parts, prioritize, investigate one by one, realize.
With a threat model scope that is too comprehensive, you risk [1.3.2] Too detailed scope → [2.1.4] Stuck in threat discovery / “admiration for the problem” / [2.1.5] Never-ending threat discovery.
Threat model parts can scope more narrow and also focus on particular kinds of threats - your “threat driven scope”.
Let’s take deployment flows and supply-chain attacks as another example: You could certainly include those in the main threat model, but it would also distract and overfill, when you are otherwise taking the business functionality perspective. So I believe this is a good candidate for a threat model part and separate investigation.
When you are concerned about a particular type of threat with big impact and special properties, that’s probably also worth an investigation on it’s own.
At the end, it is a question about how you like to divide and conquer and organize your process and outputs.
@hewerlin I may not be understanding you point entirely because you mention the ‘size’ (or “too comprehensive”, which I would interpret as ‘too many things in-scope’) being a consideration. I agree that size plays a big role in how you divide up a threat model into smaller more manageable threat models.
However, I don’t think size affects scope. However I decide something is ‘in-scope’, then it needs to be threat modelled, and to make things easier I may create 1 or more threat models in order to cover the in-scope parts. But I don’t think I would remove something from scope (overall) just because there were a lot of things in-scope, if you see what I mean?
So whether I take a “threat driven scoping” or a “scope driven threats” approach, I don’t think size would affect how I decide which approach to use (but size would still affect whether I split the task into smaller chunks).
But perhaps you were trying to make a different point? or my reasoning is off from some reason?
And you can only threat model so much in a given time. So there must be some planning and considerations how to best tackle a big scope anf what is the focus at first.
Part of that is that we won’t threat model everything today.
@irene221b with her Incremental Threat Modeling has a great mantra for out of scope: “Not our problem right now!”
Why is this?
Not even a problem? Good for us.
Not OUR problem? So who’s is it? Do they maybe need a hint?
Our problem, but not right now? So how is our general strategy when to tackle what? (And in the special context of Incremental Threat Modeling, which is a lot about threat modeling the new, how will we catch up on threat modeling for the existing?)
[1.3.2] Too detailed scope → 
new, how will we catch up on threat modeling for the existing?)