The goal is to be able to general a list of threats.
At a high level, the main advantages and disadvantages of the three approaches are as follows:
Asset-centric approach (good for quantifying risk to upper management)
- \(+\) Quantifying risk for management
- \(-\) Translation from assets to threats (difficult)
Attacker-centric approach (good for penetration testers)
- \(+\) Makes threats modeling tangible
- \(-\) Specialized knowledge necessary (red team)
Application-centric approach (good for developer team)
- \(+\) Most effective for application developers
- \(-\) Developers may have blind spots about their application
A team chooses an approach based on their skill set.
- Create a list of assets
- Draw assets, components and data flows
- For each element, check for threats
Advantages of this approach:
- Centered around assets
- Focused towards business impact
- Well suited for risk assessments
- Not centered around the application
- Mapping assets to threats is difficult
An example of a risk-centric threat modeling approach is PASTA: Process for Attack Simulation and Threat Analysis.
Another one is TRIKE.
Also known as security centric.
- Create a list of threat actors: each of them are to be matched with the following:
- Motives: why would they threaten you.
- Financial and technical means: what impact they potentially have
- Opportunity: how can the threat actor actually perform its attack.
- From the last point we can create a list of threats
- Makes threats and attacks more visible
- Movie-plot-threats brainstorming is fun
- Easy to miss technical threats
- Unrealistic threats
- Biased results (depends on who brainstorm it)
- Attacker “thinking” required (like a penetration tester)
Instead of thinking about risks or attacks first, this approach makes you start with what you are actually working on: the application.
- Draw a diagram of the application, for example a Data Flow Diagram (or DFD)
List threats for each element using a classification model such as
- STRIDE (often used, see STRIDE-per-Something Methodology)
- OWASP Top 10
- Rank threats using classification model above.
- Common understanding of the application
- Spread of knowledge
- Good documentation is necessary
- Difficult to see “own” vulnerabilities
- Threats may sound abstract