Section 01

Threat Modeling

Threat modeling is the process of identifying potential security threats and vulnerabilities in a system during the design phase. This proactive approach helps teams build security into systems from the start rather than bolting it on afterward.

Why Threat Model?

Studies show that fixing security issues during the design phase is 30-100x cheaper than fixing them in production. Threat modeling is your first line of defense.

STRIDE Methodology

STRIDE is Microsoft's threat modeling framework that categorizes threats into six categories. Each category maps to a specific security property that the threat violates.

Threat Description Security Property Example
Spoofing Pretending to be something or someone else Authentication Attacker uses stolen credentials
Tampering Modifying data or code without authorization Integrity SQL injection modifies database
Repudiation Denying having performed an action Non-repudiation User denies making a transaction
Information Disclosure Exposing information to unauthorized parties Confidentiality Sensitive data in error messages
Denial of Service Denying or degrading service to users Availability Resource exhaustion attack
Elevation of Privilege Gaining capabilities without authorization Authorization Local user gains admin rights

STRIDE per Element

Apply STRIDE to each element in your Data Flow Diagram (DFD):

External Entities

Vulnerable to: S, R

Users, external systems, third-party APIs

Processes

Vulnerable to: S, T, R, I, D, E

Application logic, services, functions

Data Stores

Vulnerable to: T, R, I, D

Databases, files, caches, message queues

Data Flows

Vulnerable to: T, I, D

Network connections, API calls, IPC

PASTA Framework

Process for Attack Simulation and Threat Analysis (PASTA) is a seven-stage, risk-centric threat modeling methodology that aligns business objectives with technical requirements.

Stage 1

Define Objectives

Identify business objectives, security requirements, and compliance needs. What are we protecting and why?

Stage 2

Define Technical Scope

Document the technical environment: infrastructure, applications, dependencies, and data flows.

Stage 3

Application Decomposition

Create DFDs, identify trust boundaries, entry points, assets, and privilege levels.

Stage 4

Threat Analysis

Research attack patterns, threat intelligence, and relevant threat actors for your industry.

Stage 5

Vulnerability Analysis

Map vulnerabilities to threat scenarios. Use vulnerability databases, SAST/DAST results.

Stage 6

Attack Modeling

Build attack trees, simulate attacks, and determine attack probability and impact.

Stage 7

Risk & Impact Analysis

Quantify risk, prioritize mitigations, and develop countermeasures aligned with business impact.

DREAD Risk Rating

DREAD is a qualitative risk rating model used to prioritize threats. Each category is rated 1-10 and averaged to produce an overall risk score.

Factor Question Low (1-3) High (8-10)
Damage How bad is the impact? Minor data leakage Complete system compromise
Reproducibility How easy to reproduce? Requires rare conditions Always reproducible
Exploitability How easy to exploit? Requires expert skills Script kiddie can do it
Affected Users How many users affected? Single user All users
Discoverability How easy to find? Requires source code access Obvious in UI/docs

DREAD Score Calculation

Risk = (D + R + E + A + D) / 5

0-3: Low Risk | 4-6: Medium Risk | 7-10: High Risk

LINDDUN (Privacy Threats)

LINDDUN is a privacy-focused threat modeling framework, essential for GDPR compliance and privacy-by-design requirements.

Linkability

Ability to link two or more items of interest about a data subject

Identifiability

Ability to identify a data subject within a set of subjects

Non-repudiation

Inability to deny a claim (can be privacy-negative)

Detectability

Ability to distinguish whether an item of interest exists

Disclosure of Information

Exposure of personal data to unauthorized parties

Unawareness

Data subject is unaware of data collection or processing

Non-compliance

Not complying with legislation, regulations, or corporate policies (GDPR, CCPA, HIPAA)

Attack Trees

Attack trees are hierarchical diagrams showing how a system might be attacked. The root node is the attacker's goal, and child nodes represent ways to achieve that goal.

Attack Tree — Steal User Credentials

graph LR Goal["🎯 Steal Credentials"] Goal --- Phishing["OR: Phishing"] Goal --- WebVuln["OR: Web Exploit"] Goal --- CredStuff["OR: Credential Stuffing"] Goal --- SocEng["OR: Social Engineering"] Phishing --- P1["AND: Convincing email"] & P2["AND: Harvesting site"] WebVuln --- S1["SQLi on login"] & S2["XSS session steal"] CredStuff --- C1["AND: Breached creds"] & C2["AND: Automate logins"] SocEng --- E1["Helpdesk reset"] & E2["Impersonate IT"] style Goal fill:#dc2626,color:#fff,stroke:#991b1b style Phishing fill:#f59e0b,color:#000,stroke:#d97706 style WebVuln fill:#f59e0b,color:#000,stroke:#d97706 style CredStuff fill:#f59e0b,color:#000,stroke:#d97706 style SocEng fill:#f59e0b,color:#000,stroke:#d97706

OR Nodes

Any child node can achieve the parent goal. Attack succeeds if ANY path works.

AND Nodes

All child nodes must succeed for the parent goal. Attack requires ALL conditions.

Use the Attack Tree Builder Tool

Check out our interactive Attack Tree Builder to create visual attack trees with MITRE ATT&CK mappings, probability calculations, and export to PNG.

Threat Modeling Process

1

Identify Assets

What are we trying to protect? Data, functionality, reputation, compliance status.

2

Create Architecture Diagrams

Build Data Flow Diagrams (DFDs) showing processes, data stores, data flows, and trust boundaries.

3

Identify Threats

Apply STRIDE to each element. Consider who might attack, their motivations, and capabilities.

4

Rate Threats

Use DREAD or CVSS to prioritize threats by risk. Focus on high-impact, high-likelihood threats first.

5

Determine Mitigations

For each threat: mitigate (reduce risk), eliminate (remove feature), transfer (insurance), or accept.

6

Validate & Iterate

Verify mitigations are implemented. Update threat model as architecture evolves.

Methodology Comparison

Choose the right methodology based on your context. Most organizations combine STRIDE for technical analysis with PASTA for business-risk alignment.

Methodology Focus Best For Complexity
STRIDE Technical threats per element Developer-led, application-level Low-Medium
PASTA Risk-centric, business-aligned Enterprise, compliance-driven High
LINDDUN Privacy threats GDPR/CCPA, healthcare, fintech Medium
DREAD Risk rating/prioritization Scoring supplement to STRIDE Low
Attack Trees Goal-based decomposition Red team planning, specific threats Medium

Practical: Threagile Threat Model as Code

Threagile lets you define your architecture and threat model in YAML, then auto-generates risks and a PDF report. Great for CI/CD integration.

threagile-model.yaml
yaml 
title: E-Commerce Application Threat Model
date: 2026-01-15
author:
  name: Security Architecture Team

# Define data assets
data_assets:
  customer-pii:
    description: Customer personal data (name, email, address)
    usage: business
    origin: customer
    owner: product-team
    quantity: many
    confidentiality: confidential
    integrity: critical
    availability: important

  payment-data:
    description: Credit card and payment tokens
    usage: business
    origin: customer
    owner: payments-team
    quantity: many
    confidentiality: strictly-confidential
    integrity: mission-critical
    availability: critical

# Define trust boundaries
trust_boundaries:
  internet-boundary:
    type: network-cloud-security-group
    description: Internet to DMZ boundary
    technical_assets_inside:
      - cdn-waf
      - load-balancer

  application-boundary:
    type: network-cloud-security-group
    description: Application tier
    technical_assets_inside:
      - web-app
      - api-service
      - auth-service

# Define technical assets
technical_assets:
  web-app:
    type: process
    usage: business
    technologies:
      - web-application
    internet: false
    machine: container
    encryption: none
    communication_links:
      api-call:
        target: api-service
        protocol: https
        authentication: token
        data_assets_sent:
          - customer-pii
        data_assets_received:
          - customer-pii

  api-service:
    type: process
    usage: business
    technologies:
      - web-service-rest
    internet: false
    machine: container
    encryption: none
    communication_links:
      db-query:
        target: customer-db
        protocol: jdbc-encrypted
        authentication: credentials
        data_assets_sent:
          - customer-pii
        data_assets_received:
          - customer-pii
title: E-Commerce Application Threat Model
date: 2026-01-15
author:
  name: Security Architecture Team

# Define data assets
data_assets:
  customer-pii:
    description: Customer personal data (name, email, address)
    usage: business
    origin: customer
    owner: product-team
    quantity: many
    confidentiality: confidential
    integrity: critical
    availability: important

  payment-data:
    description: Credit card and payment tokens
    usage: business
    origin: customer
    owner: payments-team
    quantity: many
    confidentiality: strictly-confidential
    integrity: mission-critical
    availability: critical

# Define trust boundaries
trust_boundaries:
  internet-boundary:
    type: network-cloud-security-group
    description: Internet to DMZ boundary
    technical_assets_inside:
      - cdn-waf
      - load-balancer

  application-boundary:
    type: network-cloud-security-group
    description: Application tier
    technical_assets_inside:
      - web-app
      - api-service
      - auth-service

# Define technical assets
technical_assets:
  web-app:
    type: process
    usage: business
    technologies:
      - web-application
    internet: false
    machine: container
    encryption: none
    communication_links:
      api-call:
        target: api-service
        protocol: https
        authentication: token
        data_assets_sent:
          - customer-pii
        data_assets_received:
          - customer-pii

  api-service:
    type: process
    usage: business
    technologies:
      - web-service-rest
    internet: false
    machine: container
    encryption: none
    communication_links:
      db-query:
        target: customer-db
        protocol: jdbc-encrypted
        authentication: credentials
        data_assets_sent:
          - customer-pii
        data_assets_received:
          - customer-pii

Run Threagile

docker run --rm -v $(pwd):/app/work threagile/threagile -model /app/work/threagile-model.yaml

Generates: risks report, data flow diagram, technical assets diagram, and PDF report.

Threat Modeling Tools

Microsoft Threat Modeling Tool

Free tool for creating DFDs and auto-generating STRIDE threats

Free • Windows

OWASP Threat Dragon

Open-source threat modeling tool with diagram editor

Free • Cross-platform

STRIDE Modeler Tool

Interactive STRIDE threat modeling tool built into Hacker's Manifest

Built-in • Interactive

Threagile

Agile threat modeling as code — YAML-based with auto-generated risk reports

Free • CLI • CI/CD friendly

IriusRisk

Automated threat modeling with questionnaire-driven analysis and Jira integration

Commercial • Enterprise

pytm (Python Threat Modeling)

Define system architecture in Python, auto-generate threats and DFD diagrams

Free • Python • Programmatic

📋 Framework Alignment

NIST CSF: ID.RA (Risk Assessment) | ISO 27002: A.5.7 (Threat Intelligence), A.8.25 (Secure Dev Lifecycle) | CIS Controls: CIS 16 (Application Software Security) | OWASP SAMM: Design → Threat Assessment

← Back to Overview Next: Architecture Risk Analysis →