Threat Modeling: Methodologies and Practical Application

Threat modeling is a structured security engineering discipline used to identify, classify, and prioritize potential threats against a system before those threats are exploited. This page covers the principal methodologies in active professional use, the process phases that define a threat modeling engagement, the scenarios where threat modeling is most frequently applied, and the decision boundaries that separate threat modeling from adjacent practices such as penetration testing and vulnerability management. The discipline is codified in federal guidance, software security standards, and sector-specific regulatory frameworks across US critical infrastructure.

Definition and scope

Threat modeling is the systematic process of identifying assets, enumerating potential adversaries and attack vectors, and generating prioritized mitigations before a system enters production or undergoes a significant architectural change. NIST SP 800-154 defines data-centric threat modeling as a method for "identifying and prioritizing threats to data assets and the countermeasures to address those threats." The broader practice is referenced in NIST SP 800-53 Rev. 5 under control SA-15 (Development Process, Standards, and Tools), which requires that development processes include threat identification as part of system engineering.

The scope of threat modeling spans 4 primary domains of application: software and application design, network and infrastructure architecture, cloud and containerized environments, and operational technology (OT) systems. The discipline is explicitly required or recommended in the following regulatory and standards contexts:

PCI DSS v4.0 (Payment Card Industry Data Security Standard) requires threat modeling as part of the software development lifecycle for bespoke and custom applications (PCI Security Standards Council, Requirement 6.3.2).
NIST Cybersecurity Framework (CSF) 2.0 maps threat modeling activities to the Identify function, specifically under the "Risk Assessment" category (NIST CSF 2.0).
DoD RMF (Risk Management Framework, governed by DoDI 8510.01) incorporates threat modeling in the Categorize and Assess steps for defense systems.

The output of a threat modeling exercise is a threat model document — a structured artifact listing identified threats, their severity ratings, associated system components, and recommended controls.

How it works

Threat modeling follows a repeatable 4-phase process regardless of the specific methodology applied:

Decompose the system — Define the system under analysis, draw data flow diagrams (DFDs) or architecture diagrams, identify trust boundaries, entry points, assets, and data stores.
Identify threats — Apply a classification framework (STRIDE, PASTA, LINDDUN, or attack trees) to enumerate credible threats against each component and trust boundary crossing.
Analyze and rate threats — Score identified threats using a rating system such as DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or CVSS (Common Vulnerability Scoring System, maintained by FIRST.org).
Define mitigations — Map each rated threat to one or more countermeasures: design changes, security controls, monitoring requirements, or accepted residual risk with documented rationale.

The 4 most widely adopted methodologies differ primarily in their threat enumeration approach:

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) — Developed at Microsoft; categorizes threats by the type of violation they represent. Best suited for software and service design.
PASTA (Process for Attack Simulation and Threat Analysis) — A 7-stage risk-centric framework that aligns threat modeling outputs to business impact. Documented in VeraCode and OWASP literature.
LINDDUN — Focuses specifically on privacy threats; maps to the 7 LINDDUN categories (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of Information, Unawareness, Non-compliance). Maintained by KU Leuven researchers and referenced in ENISA privacy engineering guidance.
Attack Trees — A hierarchical decomposition method originating in Bruce Schneier's 1999 work; used extensively in OT and ICS security and critical infrastructure threat analysis.

STRIDE and PASTA together account for the majority of threat modeling engagements in US enterprise environments, according to OWASP's Threat Modeling Cheat Sheet (OWASP Foundation).

Common scenarios

Threat modeling applies across the full system lifecycle, but concentration is highest at 3 operational junctures:

New system design — Threat modeling conducted during the design phase costs substantially less to remediate than findings discovered post-deployment. NIST's Building Secure Software guidance (SP 800-218, Secure Software Development Framework) positions threat modeling in the Prepare and Design phases of the SSDF.

Architectural change — Adding a new API integration, migrating to cloud security infrastructure, or introducing a third-party component triggers a scoped re-analysis of affected data flows and trust boundaries. This is particularly relevant in supply chain security contexts where new upstream dependencies introduce non-obvious attack surfaces.

Compliance-driven assessments — Regulated industries including healthcare (HIPAA Security Rule, 45 CFR §164.308), financial services (FFIEC IT Examination Handbook), and federal contracting (NIST SP 800-171 for CUI environments) incorporate threat modeling implicitly or explicitly in their security assessment requirements. The application security sector treats threat modeling as a prerequisite for secure code review and static analysis.

Organizations operating security operations centers use threat model artifacts to tune detection logic — mapping threat categories identified in design-time models to SIEM correlation rules and alerting thresholds.

Decision boundaries

Threat modeling is not a substitute for penetration testing, vulnerability scanning, or threat intelligence operations — each addresses a distinct phase and scope:

Practice	Phase	Scope	Primary Output
Threat Modeling	Design / pre-production	Architectural, hypothetical	Prioritized threat list + mitigations
Penetration Testing	Post-build / operational	Technical, empirical	Validated exploitability findings
Vulnerability Management	Operational (continuous)	CVE-based, asset-level	Patch priority queue
Threat Intelligence	Operational (continuous)	Adversary-centric, external	IOC feeds, TTPs, actor profiles

Threat modeling operates on hypothetical threats against a designed system; penetration testing validates whether those or other threats are exploitable in a deployed system. Organizations engaged in devsecops integrate threat modeling into CI/CD pipelines so that every significant pull request or infrastructure change triggers an automated threat model review against a baseline architecture.

Practitioners with the following credentials commonly lead threat modeling engagements: Certified Information Systems Security Professional (CISSP, ISC²), GIAC Defensible Security Architecture (GDSA), and Certified Threat Modeling Professional (CTMP, offered by the Threat Modeling Institute). The Threat Modeling Manifesto — a 2020 practitioner consensus document endorsed by 15 security leaders — establishes four key questions as the canonical framing for any threat modeling activity: What is being worked on? What can go wrong? What actions are planned to address it? Was an adequate job done? (Threat Modeling Manifesto)

Threat modeling outputs feed directly into cyber risk management programs, providing the structured threat inventory that risk quantification methods such as FAIR (Factor Analysis of Information Risk) require to produce defensible exposure estimates.

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator