Threat Modeling Methodologies

Threat modeling is a structured discipline within cybersecurity risk management that systematically identifies, categorizes, and prioritizes potential threats against a system before they are exploited. This page covers the principal methodologies in professional use, their structural mechanics, classification boundaries, and the regulatory frameworks that reference or require threat modeling activities. It serves as a reference for security architects, risk analysts, and compliance professionals navigating the threat modeling service landscape.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix
• References

Definition and scope

Threat modeling is defined by NIST SP 800-154 as a form of risk assessment that models aspects of the attack and defense sides of a particular logical entity, such as a piece of data, an application, a host, a system, or an environment. The discipline operates at the intersection of software security, enterprise risk management, and security architecture — making it applicable from individual application components up to enterprise-wide infrastructure.

The scope of threat modeling encompasses four primary analytical objectives: identifying assets worth protecting, enumerating threat actors and their capabilities, mapping attack vectors and potential abuse scenarios, and generating prioritized mitigations. NIST SP 800-30 Rev 1, which governs risk assessment for federal information systems, frames threat identification as a prerequisite to any risk response determination — situating threat modeling as a foundational input to the broader risk management lifecycle.

Regulatory mandates referencing threat modeling appear across multiple frameworks. The Payment Card Industry Data Security Standard (PCI DSS), managed by the PCI Security Standards Council, introduced an explicit threat modeling requirement in version 4.0 (published March 2022), specifically under Requirement 6.3.2. The OWASP Threat Modeling Cheat Sheet is among the most widely referenced public resources in application security practice.

For professionals navigating service providers in this space, the InfoSec Providers provider network covers firms specializing in threat modeling engagements across industry verticals.

Core mechanics or structure

Every threat modeling methodology — regardless of brand or origin — operates through a shared structural sequence: system decomposition, threat enumeration, risk prioritization, and mitigation mapping. The mechanics differ in how each phase is executed and what artifacts are produced.

STRIDE (developed at Microsoft and documented in Adam Shostack's Threat Modeling: Designing for Security, 2014) decomposes threats into 6 categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category maps to a violated security property — for example, Spoofing violates Authentication, and Tampering violates Integrity. STRIDE is applied element-by-element against a Data Flow Diagram (DFD), producing a per-element threat list.

PASTA (Process for Attack Simulation and Threat Analysis) operates across 7 stages — from defining business objectives through vulnerability analysis to residual risk scoring. PASTA is attacker-centric rather than component-centric, aligning threat analysis with business impact rather than system structure.

LINDDUN addresses privacy threats specifically, mapping 7 threat categories (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance) to DFD elements. It is documented by the KU Leuven DistriNet research group and referenced in privacy-by-design engineering contexts.

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), developed by Carnegie Mellon University's Software Engineering Institute (SEI), focuses on organizational risk rather than individual system components, making it suitable for enterprise-level threat assessments where asset ownership and operational context drive prioritization.

Attack Trees, formalized by Bruce Schneier, represent threat scenarios as hierarchical tree structures where the root node is the attacker's goal and child nodes are attack sub-components. They are used in combination with other methodologies rather than as standalone frameworks.

Causal relationships or drivers

The adoption and formalization of threat modeling in enterprise and government contexts is driven by four primary forces.

Regulatory mandate is the most direct driver. PCI DSS 4.0 Requirement 6.3.2 requires organizations to maintain a bespoke software inventory and perform threat modeling as part of the secure development lifecycle. The NIST Cybersecurity Framework (CSF) 2.0, under the Identify function, frames threat modeling as part of risk assessment. Federal agencies subject to FISMA are guided by NIST SP 800-30 to conduct threat identification as part of system authorization.

Software development integration is a structural driver. The migration of threat modeling into DevSecOps pipelines — where it is performed during design sprints rather than as a post-deployment audit — has increased demand for lightweight, automatable variants of STRIDE and Attack Tree methodologies.

Breach cost economics compound both of the above. The IBM Cost of a Data Breach Report 2023 found that organizations with a high standard of security testing in the development lifecycle had a mean breach cost $1.68 million lower than those without — creating a measurable financial incentive for pre-deployment threat analysis.

Insurance underwriting requirements represent an emerging fourth driver. Cyber insurers have begun requesting evidence of threat modeling activities during policy underwriting, particularly for coverage categories involving software liability and application-layer breaches.

The provides additional context on how threat modeling fits within the broader security engagement landscape.

Classification boundaries

Threat modeling methodologies are classified along three primary axes:

Focus unit — component-centric (STRIDE, Attack Trees), process-centric (PASTA), privacy-centric (LINDDUN), or organization-centric (OCTAVE). The focus unit determines what the model treats as its primary analytical object.

Attacker posture — defender-perspective methods (STRIDE) enumerate threats from the defender's enumeration of system elements; attacker-perspective methods (PASTA, Attack Trees) simulate attacker objectives and work backward to system vulnerabilities.

Output artifact type — some methodologies produce threat lists (STRIDE), others produce risk registers (OCTAVE), attack simulations (PASTA), or tree diagrams (Attack Trees). The artifact type determines how the output integrates with downstream risk management processes such as those defined in NIST SP 800-37 Rev 2 (Risk Management Framework).

A fourth classification dimension is formality level: OCTAVE and PASTA are structured, documentation-heavy methodologies suitable for compliance-driven contexts; STRIDE and Attack Trees are lighter-weight and more commonly embedded in agile engineering workflows.

Tradeoffs and tensions

The central tension in threat modeling methodology selection is coverage versus velocity. PASTA's 7-stage process and OCTAVE's organizational scope are comprehensive but require 40 or more person-hours per engagement in typical enterprise deployments. STRIDE applied to a single DFD can be completed in under 4 hours but may miss organizational risk dimensions entirely.

A second tension exists between attacker realism and structural completeness. STRIDE guarantees coverage of all 6 threat categories against every DFD element, but critics — including perspectives documented in OWASP's Threat Modeling Manifesto (published 2020 by a group of 15 practitioners) — argue this produces an exhaustive but low-signal output that buries critical threats in routine ones.

Automation compatibility is a third axis of tension. Tools exist (Microsoft Threat Modeling Tool, OWASP Threat Dragon) that partially automate STRIDE analysis, but they require DFD inputs that must be maintained as systems change. In rapidly iterated microservices environments, the DFD artifact itself becomes a maintenance liability rather than an asset.

Privacy threat modeling via LINDDUN sits in tension with security threat modeling — the two disciplines share methodology structure but differ in legal framework alignment. Security threat modeling feeds into FISMA and PCI DSS compliance; privacy threat modeling feeds into GDPR Article 25 (data protection by design) and CCPA obligations, which carry distinct regulatory stakeholders and remediation authorities.

Common misconceptions

Misconception: Threat modeling is only applicable to software development. The OCTAVE methodology was designed explicitly for organizational risk assessment, not application security. NIST SP 800-30 applies threat identification to all information system types including infrastructure, third-party services, and operational technology environments.

Misconception: A completed threat model remains valid over time. Threat models are point-in-time artifacts. PCI DSS 4.0 Requirement 6.3.2 specifies that threat models must be reviewed when significant changes occur to the in-scope system — reinforcing that threat modeling is a recurring activity, not a one-time certification artifact.

Misconception: STRIDE and PASTA are interchangeable. The two methodologies answer different questions. STRIDE asks "what can go wrong with this component?" PASTA asks "how would a threat actor achieve this attack objective against this business process?" Selecting between them is a function of the analysis goal, not preference.

Misconception: Threat modeling requires specialized tooling. The OWASP Threat Modeling Cheat Sheet explicitly documents that threat modeling can be performed with whiteboard diagrams and structured worksheets. Tooling accelerates documentation and consistency but is not structurally required.

Misconception: All threat actors must be modeled. Most professional methodologies, including STRIDE and PASTA, scope threat actors to those with plausible motivation and capability relative to the target system. Modeling all conceivable threat actors produces unbounded scope and is not standard practice in any published framework.

Checklist or steps (non-advisory)

The following sequence reflects the canonical phases common across STRIDE, PASTA, and NIST SP 800-30-aligned threat assessments. This is a structural reference, not a procedural prescription.

Phase 1 — Scope definition
- Define the system boundary (application, service, infrastructure segment, or organizational unit)
- Identify assets within scope and their sensitivity classifications
- Document system entry and exit points, data flows, and trust boundaries

Phase 2 — System decomposition
- Produce a Data Flow Diagram (DFD) at Level 0 (context) and Level 1 (process)
- Identify all external entities, processes, data stores, and data flows
- Annotate trust levels at each boundary crossing

Phase 3 — Threat enumeration
- Apply the selected methodology (e.g., STRIDE per element, PASTA attack simulation, LINDDUN per data flow)
- Document each identified threat with its category, affected component, and threat actor assumption
- Cross-reference the MITRE ATT&CK framework for technique-level threat specificity

Phase 4 — Risk rating
- Score threats using a consistent risk rating system (DREAD, CVSS, or organizational risk matrix)
- Prioritize by likelihood × impact, constrained by threat actor capability assumptions

Phase 5 — Mitigation mapping
- Map each threat to a control or mitigation from a recognized control catalog (NIST SP 800-53, CIS Controls)
- Classify mitigations as: mitigate, transfer, accept, or eliminate
- Assign ownership and remediation timelines

Phase 6 — Documentation and review cycle
- Record the completed threat model in a format referenced by the system's security documentation
- Establish review triggers: major architecture changes, new data types, new integration points, or annually at minimum
- Archive prior threat model versions for audit trail purposes

Additional guidance on how this service category is structured for practitioners is available through the how to use this infosec resource reference page.

Reference table or matrix