Some of the methodologies below are Risk Analysis/Threat Analysis methodology. Still it’s good to know about them from a threat modeling perspective.
All the modeling methodologies below are asset or application-centric methodologies (see Threat Model Approach).
Methodology depends heavily on the team, the organization and the set goals. As a general rules of thumb, though, for an asset-centric modeling, PASTA is a good fit (business integration). For an application-centric modeling, the Microsoft Threat Modeling is a good fit.
While the number of steps differ from one threat model methodology to another, the generic process is almost always the same:
- Set scope
- Analyze target
- Identify threats
- Rate threats
- Process for Attack Simulation and Threat Analysis.
- Approach: asset-centric
- Methodology: Threat analysis and threat modeling (which means one needs the input of threat intelligence and to evaluate the threat continuously)
PASTA is good for medium to large size companies, mature companies and companies that have lot of security knowledge.
It needs executive sponsorship and is an iterative, maturing process. It’s geared towards management.
- Define Business Objectives
- Define Technical Scope: identify which components are in scope
- Decompose Application: dataflow diagram (DFD)
- Analyze Threats: input from sources (threat intelligence)
- Identify Vulnerabilities: assert viability of vulnerabilities and rank them using a scoring system
- Enumerate Attacks: attack tress, attacks that are mapped to vulnerabilities
- Perform Impact Analysis: analyzes the residual risks, or whether the risks are acceptable for the company.
- Great for business integration
- Mature, well described processes
- Tooling available
- Specialized input necessary
- Time consuming
- Each step generates lot of output
- Lot of intermediate models
- Dependent on dynamic input
Microsoft Threat Modeling
- Not to be confused with STRIDE (threat classification system)
- Approach: application-centric
The Microsoft Threat Modeling framework is a simple and lightweight developer-driven framework which focuses on technical risks. It is easy to understand even to non initiate and it’s practical (uses plain English). It is best used in the development life-cycle.
- Identify assets: what you are trying to protect
- Create architecture overview: document architecture of app, including subsystems, dataflow, Trust Boundary and Entry Point
- Decompose application: find configurations and vulnerabilities
- Identify the threats: using the vulnerabilities found in the previous step. With a threat actor in mind, one can…
- Document the threats
- Rate the threats: using a scoring like DREAD, CVSS or OWASP risk rating methodology to prioritize the threats
The output is a document listings threats as well as diagrams of the application.
- Easy to pick up
- Easy to use in software Development life cycle
- More practical than academic (not rigid)
- STRIDE methodology is redundant
- Does not factor risk for the business. it revolves around the application
Not a pure threat modeling methodology but a risk analysis framework.
- Operationnaly Critical Threat, Asset and Vulnerability Evaluation
- Evaluate organization rather than applications
- Geared towards big company
- OCTAVE-S for smaller company
- OCTAVE Allegro focus primarily on information assets
- “Asset-centric approach” (in “ because not a pure threat modeling methodology )
- Establish drivers (measure risks)
- Profile assets: what is in scope
- Identify threats
- Identify and mitigate risks: mitigate risk in contrast to pure threat modeling methodology
OCTAVE focuses on organizational risks rather than technicals risks. It is flexible and self-directed.
- Improve risk-aware corporate culture
- In depth
- Lot of paperwork
- Require investments
- Methodology as well as a tool.
- High level of automation are possible: threats are automatised, not brainstorming involved
- Asset-centric approach
Focus on defensive side, on how to protect assets.
Roughly two phases: System analysis phase (first step) and security analysis phase (the rest of the steps).
- Model system: Systems analysis phase. Systems and their security goals are described here.
- Identify threats
- Investigate threats
- Identify mitigations
- Investigate mitigations
Outputs three models:
- Requirements model
- Implementation Model
- Risk model
- Automatically generates threats
- Consistent results
- Built-in tool
- Does not scale well
- Not maintained anymore (or so it seems)
- Visual Agile Simple Threat Modeling
Two threat model types:
- Application threat model
- Operational threat model
- Process flow diagram (instead of data flow diagram)
VAST is targeted towards agile companies and is very scalable.
- Process flow diagrams might be easier than data flow diagram
- Not open
- No free documentation or guidance