Threat Model Approach

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.

Asset-centric Approach

  • 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

Disadvantages are:

  • 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.

Attacker-centric Approach

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)

Application-centric Approach

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
  • 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
Links to this page