Practical Threat Modeling series, part 5 - Design Level, get the thing done!

The major threat for a threat mode (pls excuse me for the wording game) is to feel lost on the vast "sea" of things that can go wrong, and how to prioritize them. This feeling of vastness, or the opinion that everything needs to go inside the TM, is the first enemy or getting the TM done. So, don't panic and get the thing done...so, where to start?
A good place to start is the highest diagram of the architecture of the system itself. It is not something meant to be used to TM but is useful as a starting point for the analysis. You also have limited time, let's focus on the most important things and prioritize them. It is often the case that teams perform threat modeling after the design phase, or when the system is already in production. In this case, this practice could be considered technical debt, and you might find out that already many mitigations and countermeasures are in place to defend against threat agents. In this case, bear in mind that the threat is present and need to be documented even in the case that the risk impact is prevented to happen; we'll see how in the next parts.

This a list of steps that you can follow to get the design level TM done:

1) Define what you care about

...the famous "What are we building?" question we presented in the 1st part. It is useful at this stage to have a high-level diagram of the architecture of the system, the one that engineers usually have. 

Assets and attackers in or out-of-scope

• Divide the diagram in assets and classify them either in-scope or out-of-scope.
• Classify what attackers you are considering (threat agents). E.g. Network attackers, physical access attacker, not honest internal personnel,  cold temperature: < 4 degrees or dust (if you design a resistant hardware system) ... The main point here is to list (put in scope) the type of attackers/threat agents that we want to care about. Even more important to get the thing done is to put out-of-scope the threat agents that you don't want to put in scope. Yes, you can explicitly write that you don't care about the earthquake, dishonest people with a legit credential (crazy admins), infected customers computers. You can put threat agent out-of-scope often, every time someone raises the hand and starts a sentence with "Yes, but..." be ready to explicitly put something out-of-scope. Not because it is a bad observation in itself, but to get the thing done you must start from the most obvious, big, bad attackers. Once you get it done more time can be dedicated to making the system more robust against other, less relevant attackers. The same logic applies to the assets in-scope: "Yes, but the operative system itself on the computers may be hacked by the Chinese/NSA/Russian hardware poisoning guys"... you got the point!

Data flows are actually useful

I'm not an advocate of Data Flow Diagrams (example in part 4), especially when it is the engineering team to threat model a single system. It doesn't mean you don't need to consider data flows in-scope, even when (especially), they come from an out-of-scope asset. I actually consider data flows and trust boundaries essential to threat model! An example will show better this situation:

Architecture example (simple web site):

This kind of documentation should be already available to the developer team and is the starting point of the analysis.

We can annotate it (I usually use https://www.draw.io/ to import the original architecture image and draw on top of it):

At this point we start to have a few assets:

In scope asset:

1. API GATEWAY
2. DF1
3. DF2
4. Server Logic (PHP)
5. DF3
6. DB

Out of scope assets:

1. User
2. User Browser/pc

Attackers in scope:

1. Network attacker without credentials
2. Coordinated DoS attackers
3. ...

Attackers out of scope:

1. Attackers that have remote control of the user pc/browser
2. Attackers that have physical access to the server infrastructure
3. ...

Congratulations, now you can start to use a taxonomy S.T.R.I.D.E. or  C.I.A. and some other techniques to enumerates the threats on the system (and answer the big question "What can go wrong").

Following this approach you will be able  to:

1. Understand what are you caring about.
2. Put a limit in the potentially endless brainstorming list of things that can go wrong "in general".
3. Have a fair understanding of the system (I  usually need to guide teams in doing the TM, not knowing much about the system itself from the beginning).
4. Communicate with counterparts what you are considering when dealing with security, improving risk management and awareness.

In the next parts, we'll explore, among other things: 

• How to leverage common taxonomies of threats and "rapid" techniques to identify them
• How to document threats/vulnerabilities and their countermeasures 
• How to keep the TM updated and useful

At this point, by putting boundaries and limits at the TM, people involved will feel that the task itself is more approachable, and can focus on the most important threats...and get the thing done!