9 min read

Section 04

Advanced Threat Modeling

A step past introductory STRIDE coverage: per-element STRIDE analysis, a complete PASTA seven-stage assessment, VAST for enterprise scale, LINDDUN+ for privacy-focused threat modelling, and hybrid approaches that combine methodologies into a single assessment.

Builds On Existing Content

For STRIDE fundamentals and basic threat modeling concepts, see Secure Architecture: Threat Modeling. This section focuses on advanced application within a TRA engagement — deeper methodology walkthroughs, comparative analysis, and hybrid approaches. Use the STRIDE Modeler tool for interactive analysis.

Methodology Selection Guide

Different methodologies suit different TRA contexts. Use this decision guide to select the right approach (or combination) for your assessment.

Methodology Best For Effort Output Quality Automation
STRIDE per-element Individual component analysis, engineering teams Medium Systematic, thorough for technical threats High (Threagile, MS TMT)
PASTA (7-stage) Business-aligned risk, regulatory TRA High Business-contextualized, attack simulation Low (mostly manual)
VAST Enterprise scale, agile teams, dual models Low-Medium Scalable, separates app and infra threats Medium (ThreatModeler)
LINDDUN+ Privacy-focused assessment, GDPR/CCPA compliance Medium Privacy-specific, regulatory alignment Low (manual with cards)
Hybrid (STRIDE+PASTA+FAIR) Comprehensive TRA with quantitative risk output High Most thorough — technical + business + quantitative Medium (partial automation)

STRIDE Per-Element Analysis

Standard STRIDE applies all six threat categories globally. Per-element STRIDE applies specific threats to each DFD element type, producing more precise and actionable results.

DFD Element S T R I D E Focus Areas
External Entity ✓ — ✓ — — — Identity spoofing, action repudiation
Process ✓ ✓ ✓ ✓ ✓ ✓ All six — processes are the most threat-rich element
Data Store — ✓ ✓ ✓ ✓ — Data integrity, disclosure, availability, audit trails
Data Flow — ✓ — ✓ ✓ — Man-in-the-middle, eavesdropping, flow disruption

PASTA 7-Stage Walkthrough

PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric methodology that aligns threat modeling with business objectives. Here's a complete walkthrough using a payment processing platform as an example.

PASTA 7-Stage Process

Stage 1: Define Business Objectives

Align the assessment with business goals, compliance requirements, and risk appetite.

Example: "Ensure the payment platform maintains PCI DSS Level 1 compliance, processes $50M/month without fraud exceeding 0.1% of volume, and achieves 99.99% availability for checkout flows."

Stage 2: Define Technical Scope

Document the technology stack, infrastructure, and integration boundaries.

Example: React SPA → API Gateway (Kong) → Payment Service (Go) → PostgreSQL (encrypted) → Payment Processor (Stripe) via mTLS. Kubernetes on AWS EKS. Entra ID for admin auth.

Stage 3: Application Decomposition

Create DFDs, identify trust boundaries, map data flows, and catalog all entry/exit points. Use the techniques from Section 02.

Stage 4: Threat Analysis

Identify threats using actor profiles and CTI from Section 03. Map to ATT&CK techniques. For payment platform: card fraud, account takeover, API abuse, insider access to cardholder data.

Stage 5: Vulnerability Analysis

Correlate threats with known vulnerabilities. Review CVE databases, past pentest findings, SAST/DAST results, and architecture weaknesses. Identify where controls are missing or weak.

Stage 6: Attack Modeling & Simulation

Build attack trees showing how threats could exploit vulnerabilities. Model attack paths from initial access to impact. Use the Attack Tree Builder tool.

Stage 7: Risk & Impact Analysis

Quantify residual risk for each attack path. Calculate business impact in financial terms using FAIR (see Section 06). Prioritize risks and recommend specific controls with cost-benefit justification.

VAST for Enterprise Scale

VAST (Visual, Agile, and Simple Threat modeling) was designed to scale threat modeling across large organizations with hundreds of applications. It creates two parallel models:

Application Threat Model

For development teams — uses process flow diagrams aligned with agile user stories.

  • • Based on process flow diagrams (not DFDs)
  • • Maps threats to user stories and features
  • • Integrated into sprint planning and backlog
  • • Owned by development team / tech lead
  • • Threats map to acceptance criteria

Operational Threat Model

For infrastructure teams — uses DFDs focused on deployment and runtime environment.

  • • Based on infrastructure DFDs
  • • Covers deployment, networking, IAM, logging
  • • Integrated into infrastructure change management
  • • Owned by platform / SRE team
  • • Threats map to infrastructure controls

LINDDUN+ for Privacy

LINDDUN+ extends threat modeling to privacy threats — critical for GDPR, CCPA, and any system processing personal data. Apply alongside STRIDE for comprehensive coverage.

Category Privacy Threat Example GDPR Article
L Linkability — connecting data items across datasets Correlating anonymized browsing with purchase history Art. 5(1)(b)
I Identifiability — linking data to a specific individual Re-identification from "anonymized" datasets Art. 4(1)
N Non-repudiation — inability to deny actions (privacy risk) Immutable audit logs linking users to sensitive actions Art. 17
D Detectability — deducing existence of data/activity Metadata reveals user is a customer (even without content) Art. 5(1)(f)
D Disclosure of information — unauthorized data exposure Excessive data returned in API responses Art. 5(1)(c)
U Unawareness — data subject doesn't know processing occurs Third-party analytics tracking without consent Art. 13, 14
N Non-compliance — failing regulatory requirements No data deletion mechanism (right to erasure failure) Art. 17, 25

Threat Modeling Manifesto

Principles from the Threat Modeling Manifesto (2020)

The manifesto distills years of community experience into guiding principles. Apply these when choosing and executing your methodology:

Values

  • • Finding and fixing design issues over checkbox compliance
  • • People and collaboration over processes and tools
  • • A culture of finding and fixing over blaming
  • • Continuous refinement over single delivery
  • • Doing threat modeling over talking about it

TRA Application

  • • Use workshops over checklists — get subject matter experts in the room
  • • Start with simple diagrams and iterate — don't wait for perfect architecture docs
  • • Prioritize threats that the team can actually fix
  • • Revisit the model when designs change, not just on schedule
  • • Imperfect threat modeling done early beats perfect modeling done never

Hybrid Approach: STRIDE + PASTA + FAIR

For comprehensive TRAs, combine methodologies to leverage each one's strengths. This hybrid approach is recommended for Tier 2–3 assessments.

Hybrid Methodology Flow

hybrid-tra-workflow.txt 
Hybrid TRA Workflow — STRIDE + PASTA + FAIR

PHASE 1: PASTA Business Alignment (Stages 1-2)
───────────────────────────────────────────────
• Define business objectives and risk appetite
• Document technical scope and compliance requirements
• Identify key business processes and their value

PHASE 2: STRIDE Per-Element Analysis (PASTA Stage 3-4)
──────────────────────────────────────────────────────
• Decompose application into DFD elements
• Apply STRIDE to each element type:
  - External entities: Spoofing, Repudiation
  - Processes: All six categories (S/T/R/I/D/E)
  - Data stores: Tampering, Repudiation, Information Disclosure, DoS
  - Data flows: Tampering, Information Disclosure, DoS
• Map threats to MITRE ATT&CK techniques

PHASE 3: PASTA Attack Modeling (Stages 5-6)
──────────────────────────────────────────────
• Correlate STRIDE threats with known vulnerabilities
• Build attack trees for highest-risk threat chains
• Simulate attack paths through the architecture
• Validate with red team intelligence or past pentest results

PHASE 4: FAIR Risk Quantification (PASTA Stage 7)
─────────────────────────────────────────────────
• For each critical attack path:
  - Estimate Threat Event Frequency (TEF)
  - Assess Vulnerability (probability control fails)
  - Calculate Loss Event Frequency (LEF) = TEF × V
  - Estimate Loss Magnitude (primary + secondary)
  - Run Monte Carlo simulation for risk ranges
• Prioritize by annualized loss expectancy
• Recommend treatments with ROI justification

OUTPUT: Risk Register + Treatment Plan + Executive Summary

Section Summary

Key Takeaways

  • • STRIDE per-element gives more precise results than global STRIDE
  • • PASTA aligns threat modeling with business objectives (7 stages)
  • • VAST scales threat modeling to enterprise with dual models
  • • LINDDUN+ covers privacy threats missed by STRIDE
  • • Hybrid approaches combine the best of each methodology

Next Steps

Evidence to Capture

In a multi-methodology model the artefact must record which method produced which threat, or a hybrid cannot be defended or reproduced.

Methodology per phase: Which framework was used for which stage — STRIDE per element, PASTA, VAST, LINDDUN — and why it was chosen over the alternatives.

Element-level threat table: Every element with its applicable categories, the threat, and the control credited, including the categories deliberately ruled out.

PASTA stage outputs: Business objectives and risk appetite, technical scope, and the attack simulation or vulnerability correlation that produced the scenarios.

Privacy analysis: LINDDUN categories evaluated per data flow, with the lawful basis and retention assumptions used for each.

Assumptions and exclusions: What the model does not cover: supply chain internals, physical access, the provider control plane. An implicit exclusion cannot be reviewed.

Workshop record: Participants and their roles, date, model version, and who owns the model between sessions.

Methodology False Positives

Rigour in method produces volume by default. These are the entries that method generates and the estate does not need.

  • Every category for every element: External entities are not meaningfully denied service and data stores are not spoofed. Blanket application produces entries analysts learn to skip.
  • Already-mitigated threat: A threat with a verified control, credited properly, is closed. Re-rating it each cycle inflates the register and hides new entries.
  • The same threat twice: STRIDE and PASTA both surface the same information-disclosure path. In a hybrid, count and treat it once.
  • Privacy requirement as security threat: Purpose limitation and retention findings belong in the privacy analysis. Migrating them into the security register distorts ranking.
  • Attack tree of the impossible: A simulation assuming a capability the actor does not have yields an impressive diagram and no actionable finding.
  • The design, not the deployment: A model built from the target-state diagram when the running system differs will rank the wrong risks highest.

Route Threats and Reopen the Model

The output is a versioned model with threats routed into delivery, plus the trigger that forces the affected phase to be re-run.

Route threats into engineering

  • • Link each unmitigated threat to an issue with an owner and a target release
  • • Attach the mitigation to the design decision it changes
  • • Verify the control in the deployed system before closing the threat

Keep the hybrid coherent

  • • Record the methodology per phase so a later reader can reproduce the result
  • • Maintain one canonical register entry per threat across phases
  • • Re-run only the affected phase when the architecture change is local

Review trigger

  • • New element, data flow or trust boundary
  • • Business objective or risk appetite changes
  • • New privacy regulation, or a new data category enters scope