Threat Modeling Frameworks

Threat modeling is the discipline of systematically identifying what could go wrong in a system, who would benefit from making it go wrong, and what to do about it before it happens. The field has been the subject of formal study for roughly four decades and operational practice for longer than that; over the last twenty years it has accumulated a substantial library of frameworks, taxonomies, and methodologies, with each one optimized for a specific kind of analysis at a specific level of abstraction.

The accumulation has been useful — different jobs really do benefit from different frameworks — but it has also produced confusion. Practitioners new to the discipline often encounter ATT&CK, STRIDE, PASTA, the Kill Chain, the Diamond Model, and OCTAVE in rapid succession without a clear picture of how they relate, when each applies, and whether they are competing or complementary. The short answer is that they are mostly complementary, addressing different layers of the problem, and the right practical posture is to know several of them rather than to pick one as universally correct.

This page is the umbrella introduction. The subpages linked at the end go deep on individual frameworks. The scope here is the lay of the land: what threat modeling actually is, the major frameworks at the survey level, how they relate to each other, and how to choose the right tool for a given piece of work.

What threat modeling actually is

Threat modeling is the structured process of answering four questions about a system:

1. What are we building or operating? The scope of the system, including the assets it handles, the trust boundaries it spans, the components it integrates, and the data flows that connect them.
2. What can go wrong? The set of adverse events that could occur — both adversarial (someone deliberately attacking) and non-adversarial (errors, failures, accidents) — that would harm the system or the stakeholders depending on it.
3. What are we going to do about it? The mitigations, controls, and defenses that reduce the likelihood or impact of the identified threats to an acceptable level.
4. Did we do a good enough job? The verification that the modeling captured the threats that matter and that the mitigations actually reduce them as intended.

These four questions are the four-question framework that Adam Shostack codified in his canonical threat modeling work, and they hold across essentially every threat modeling methodology in active use. The frameworks differ in how they help answer the questions, not in what the questions are.

Threat modeling is not the same as risk assessment, though the disciplines overlap. Risk assessment is the broader practice of evaluating the likelihood and impact of adverse events across an organization; threat modeling is the narrower practice of analyzing how specific threats apply to a specific system. The output of threat modeling typically feeds into risk assessment, but the two activities have different abstractions, different stakeholders, and different time horizons.

Threat modeling is not the same as penetration testing. Pen testing is empirical — actually trying to exploit a system to see what works. Threat modeling is analytical — reasoning about what could be exploited based on the system’s design and the adversary’s likely capabilities. Both are valuable; they answer different questions and produce different outputs. A threat model gives you the map of where to look; a pen test tells you what was actually there.

Threat modeling is not the same as following a compliance checklist. Compliance frameworks specify controls that must be present; threat modeling reasons about whether the controls actually defend against the threats that matter. A system can be fully compliant and entirely vulnerable; a system can be highly defended in ways that no compliance framework asks about. The two activities are independent.

Why the field has multiple frameworks

The proliferation of threat modeling frameworks reflects three legitimate sources of variation:

Different levels of abstraction. Some frameworks (ATT&CK, D3FEND) operate at the level of specific adversary techniques and defensive countermeasures. Others (STRIDE, LINDDUN) operate at the level of system-design threat categories. Others (the Kill Chain, the Diamond Model) operate at the level of attack lifecycle and intrusion analysis. Operating at the right level for the work in front of you matters enormously; trying to use ATT&CK for a system architecture review is the wrong tool for the job, just as trying to use STRIDE for incident response is.

Different intended audiences. Some frameworks are designed for security architects analyzing systems during design (STRIDE, PASTA). Others are designed for SOC analysts triaging alerts (ATT&CK, the Diamond Model). Others are designed for executive risk owners making budget decisions (OCTAVE). The vocabularies, the outputs, and the workflow assumptions all reflect the intended user.

Different problem domains. Most threat modeling frameworks were developed for general-purpose information systems. LINDDUN is specifically for privacy threats. The ATT&CK Cloud matrices are specifically for cloud environments. The ATT&CK ICS matrix is for industrial control systems. Domain-specific frameworks handle the threats that matter in their domain better than general-purpose frameworks do.

The combination produces a landscape where multiple frameworks coexist not because the field cannot agree on a winner, but because the field has correctly recognized that no single framework can simultaneously serve every purpose. The practical implication is that mature security organizations use several frameworks in parallel — typically one or two for system design review, one or two for incident response, and at least one for organizational risk assessment.

The major frameworks at a glance

A survey of the frameworks that show up most often, with brief descriptions of what each does well and where each has its limits. Each will get a dedicated subpage with substantially more depth.

MITRE ATT&CK

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is the operational catalog of how real adversaries actually behave. The framework organizes documented adversary techniques into a matrix of tactics (the goals adversaries pursue: initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, impact) and the techniques used to achieve them (over 200 techniques and sub-techniques in the enterprise matrix as of mid-2026).

ATT&CK is grounded in empirical evidence — every technique in the matrix is documented in actual observed adversary behavior, typically attributed to specific threat groups. The framework is maintained by MITRE based on contributions from the broader security community and is updated continuously as new techniques are observed.

Where ATT&CK excels: detection engineering, threat intelligence, red team planning, purple team exercises, SOC analyst training. The framework’s vocabulary has become the de facto standard for discussing adversary behavior across the industry.

Where ATT&CK does less well: system architecture review (it’s about adversary behavior, not system design), executive risk communication (the techniques are too detailed for that audience), and any analysis that requires reasoning about novel attack patterns not yet in the catalog.

MITRE D3FEND

MITRE D3FEND (Detection, Denial, and Disruption Framework Empowering Network Defense) is the defensive counterpart to ATT&CK. The framework organizes defensive countermeasures into a structured taxonomy and maps them to the ATT&CK techniques they address.

D3FEND is substantially newer than ATT&CK (the framework was released in 2021 and is still maturing) and is less broadly adopted, but it fills a real gap: ATT&CK tells defenders what adversaries do, D3FEND tells defenders what to do about it.

Where D3FEND excels: defensive control inventory, gap analysis against ATT&CK coverage, security tool evaluation, defensive architecture review.

Where D3FEND does less well: anything outside the scope of mapped countermeasures (the framework is still building out coverage), and anything requiring deep operational detail on specific tools (D3FEND describes countermeasure categories, not specific product configurations).

STRIDE

STRIDE is the system-design threat categorization framework developed at Microsoft in the late 1990s. The acronym stands for the six threat categories the framework organizes:

• Spoofing — impersonating something or someone.
• Tampering — modifying data or code.
• Repudiation — denying having performed an action.
• Information Disclosure — exposing information to unauthorized parties.
• Denial of Service — making the system unavailable to legitimate users.
• Elevation of Privilege — gaining capabilities beyond authorization.

STRIDE is applied at design time: walk through each component, each data flow, and each trust boundary of the system, and ask which of the six categories apply. The output is a list of design-level threats that the architecture must mitigate.

Where STRIDE excels: system architecture review during design, threat modeling for new applications and services, training engineers in security thinking.

Where STRIDE does less well: post-deployment analysis (the framework is design-oriented), reasoning about specific adversary capabilities (STRIDE categories are agnostic to who the adversary is), and threat modeling at scale (the manual walkthrough doesn’t scale well to large organizations with many systems).

PASTA

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage risk-centric threat modeling methodology developed by Tony UcedaVélez. The seven stages move from business objective definition through technical scope definition, application decomposition, threat analysis, vulnerability analysis, attack modeling, and risk impact analysis.

PASTA is more structured and more business-aligned than STRIDE. The framework explicitly connects technical threats to business impact, which makes it useful for organizations that need threat modeling outputs to drive executive decisions about security investment.

Where PASTA excels: enterprise threat modeling programs, threat modeling that needs to align with business risk priorities, situations where the threat modeling output needs to be defensible to non-technical stakeholders.

Where PASTA does less well: rapid threat modeling during development sprints (the seven-stage process is heavyweight), pure technical architecture analysis (the business-alignment overhead can be unnecessary), and small organizations without the personnel to maintain the methodology.

The Cyber Kill Chain

The Lockheed Martin Cyber Kill Chain, published in 2011, models adversary operations as a sequence of seven stages: reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. The framework was the first widely-adopted attempt to systematize adversary behavior across the full attack lifecycle.

The Kill Chain’s enduring contribution is the framing that defenders can disrupt an attack at any stage, and disruption at earlier stages is more economical than disruption at later stages. The model has been criticized for being too linear (real attacks don’t always proceed cleanly through the stages) and too focused on perimeter-style intrusion (it doesn’t handle insider threats or lateral movement as cleanly as later models), but the underlying intuition remains valuable.

Where the Kill Chain excels: communicating attack lifecycle to non-specialists, organizing detection content by where in the lifecycle each detection fires, framing investment in early-stage detection.

Where the Kill Chain does less well: post-perimeter analysis (the model is heavily intrusion-oriented), modern attack patterns that don’t fit the linear sequence cleanly, and operational use against attacks that have moved beyond the initial intrusion stages.

The Diamond Model

The Diamond Model of Intrusion Analysis, published in 2013 by Sergio Caltagirone, Andrew Pendergast, and Christopher Betz, models any malicious activity as a relationship between four nodes: adversary, capability, infrastructure, and victim. The four nodes form a diamond, with edges representing the relationships and the model providing a structure for tracking what is known and unknown about each element.

The Diamond Model is the standard framework for cyber threat intelligence analysis. Analysts use it to organize what they know about ongoing activity, pivot from known elements to discover unknown ones, and connect related activity across time.

Where the Diamond Model excels: cyber threat intelligence analysis, attribution work, tracking adversary campaigns across multiple incidents, intelligence pivoting and enrichment.

Where the Diamond Model does less well: any analysis that doesn’t have the four-node structure (asset-only risk analysis, design-time threat modeling), and any work that requires more structure than the model imposes (the model is a relationship structure, not a methodology).

OCTAVE

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is the asset-driven enterprise risk assessment methodology developed at the CERT Coordination Center at Carnegie Mellon. The methodology has evolved through several variants: OCTAVE-S (small organizations), OCTAVE Allegro (streamlined version), and OCTAVE FORTE (newer enterprise version).

OCTAVE works from the assets the organization needs to protect, identifies the threats to those assets, and produces risk-prioritized recommendations. The methodology is heavyweight by design — it’s intended to produce defensible enterprise-wide risk assessments — and is the dominant framework in some regulated industries.

Where OCTAVE excels: enterprise risk assessment programs, regulated industries that need defensible documented risk analysis, organizations that need to prioritize across many assets and threats.

Where OCTAVE does less well: rapid technical threat modeling, software development workflows, organizations without the personnel to maintain a heavyweight methodology.

LINDDUN

LINDDUN is the privacy-focused threat modeling framework developed at KU Leuven. The acronym stands for the seven privacy threat categories: Linking, Identifying, Non-repudiation, Detecting, Data Disclosure, Unawareness, Non-compliance.

LINDDUN is structured similarly to STRIDE but addresses privacy threats specifically. The framework has become substantially more important as privacy regulations (GDPR, CCPA, and successors) have created legal requirements that map onto specific privacy threat categories.

Where LINDDUN excels: privacy threat modeling for systems handling personal data, GDPR/CCPA compliance work that needs structured threat analysis, privacy-by-design programs.

Where LINDDUN does less well: traditional security threat modeling (privacy and security threats overlap but have different vocabularies), and threat modeling for systems with minimal personal data handling.

Other frameworks worth knowing

A few additional frameworks that appear in specific contexts:

VAST (Visual, Agile, and Simple Threat modeling) emphasizes integration with development workflows and process-driven threat modeling at scale. Used in some large-scale enterprise threat modeling programs.

Trike is an audit-oriented threat modeling methodology built around stakeholder-driven requirements for security properties. Less widely deployed than STRIDE or PASTA but used in specific consulting practices.

Attack Trees, originating with Bruce Schneier’s work in the late 1990s, model attacks as tree structures with the attacker’s goal at the root and sub-goals as branches. Useful for systematic enumeration of attack paths against specific high-value targets; less useful as a general-purpose threat modeling framework.

MITRE CAPEC (Common Attack Pattern Enumeration and Classification) catalogs attack patterns at a level between ATT&CK techniques and general threat categories. Used as a reference resource more than as a standalone framework.

OWASP Threat Modeling resources include the OWASP Threat Modeling Cheat Sheet and several methodology variants; not a single framework but a useful collection.

How to choose

The practical question for a security practitioner is not “which framework is best” but “which framework fits the work I’m doing.” A rough decision tree:

For system architecture review during design: STRIDE for general security threats, LINDDUN for privacy threats, PASTA if the output needs to align with business risk priorities. STRIDE is the right choice for most software development organizations because the lightweight methodology fits well into development workflows.

For detection engineering and SOC operations: ATT&CK for adversary behavior coverage, D3FEND for defensive countermeasure mapping. The pairing is the standard modern approach for SOC programs.

For threat intelligence analysis: The Diamond Model for organizing analytical work, ATT&CK for tactical-level activity description. Both are essentially required for any serious CTI program.

For incident response: ATT&CK to characterize observed adversary behavior, the Kill Chain to communicate attack progression to non-specialists, the Diamond Model to track relationships across the incident.

For enterprise risk assessment: OCTAVE for asset-driven risk programs, PASTA for risk programs that need to link technical threats to business impact. Both are heavyweight; the choice depends on the organization’s existing risk management maturity.

For privacy-specific analysis: LINDDUN, supplemented with general-purpose frameworks for the security-overlap threats.

For high-value asset targeted analysis: Attack trees for systematic enumeration of attack paths, combined with ATT&CK for technique-level detail.

Mature organizations typically use three to five frameworks in parallel: one or two for design-time work (STRIDE + LINDDUN), one or two for operational work (ATT&CK + D3FEND), one for intelligence analysis (Diamond Model), and one for enterprise risk (OCTAVE or PASTA). The frameworks are not redundant; each operates at a different level and serves a different purpose.

How the frameworks relate

The frameworks are not competing standards. Most pairs of frameworks are complementary, operating at different levels of abstraction or in different problem domains:

ATT&CK and D3FEND are deliberately paired — D3FEND maps defensive countermeasures to the ATT&CK techniques they address. Using both together is the intended pattern.

ATT&CK and the Kill Chain operate at different levels. The Kill Chain describes attack lifecycle phases; ATT&CK describes the specific techniques used within each phase. Many organizations map ATT&CK tactics roughly to Kill Chain phases (initial access maps to delivery/exploitation, persistence to installation, etc.) as a unified taxonomy.

STRIDE and PASTA address the same level of analysis (system design) at different methodology weights. STRIDE is the lightweight design-time tool; PASTA is the heavyweight enterprise-aligned methodology. Some organizations use STRIDE for sprint-level work and PASTA for major architecture reviews.

The Diamond Model and ATT&CK combine naturally — the Diamond Model’s “capability” node corresponds to ATT&CK techniques, with the model providing the relationship structure and ATT&CK providing the technique vocabulary.

LINDDUN and STRIDE are explicitly designed as parallel frameworks — STRIDE for security threats, LINDDUN for privacy threats. The walkthrough methodology is the same; the threat categories differ.

The practical lesson: when reading about a framework, ask what level of abstraction it operates at and what problem it’s designed to solve. Most apparent conflicts between frameworks dissolve once the levels are clear.

Operational use

A few places threat modeling shows up in real defender work, with notes on which frameworks tend to apply:

During architecture review for new services. STRIDE (or STRIDE + LINDDUN if personal data is involved) is the standard tool. Output is a list of design-level threats with planned mitigations, attached to the design review documentation.

In the SOC, when triaging an alert. ATT&CK provides the vocabulary for describing what the alert is detecting. Detection rules increasingly carry ATT&CK technique tags so analysts can immediately see the adversary behavior the alert is responding to.

During incident response. ATT&CK characterizes the adversary’s observed techniques across the incident timeline. The Diamond Model organizes intelligence pivots — known infrastructure leads to suspected capability, suspected capability leads to attribution hypotheses, and so on. The Kill Chain framing helps communicate incident progression to executives.

In CTI report writing. ATT&CK technique tags are now expected in CTI reports. The Diamond Model structure is the standard format for capturing what’s known about an ongoing campaign.

During red team planning. ATT&CK is the standard reference for technique selection. Red team operations are increasingly designed to exercise specific ATT&CK techniques against the organization’s defenses, with purple team exercises that combine red team execution with blue team detection coverage measurement.

In compliance and audit contexts. The relevant compliance framework dictates the threat modeling approach. PCI DSS expects threat modeling but doesn’t specify methodology. NIST SP 800-53 references multiple frameworks. ISO 27005 specifies its own risk-management approach that maps loosely onto OCTAVE.

In executive risk communication. OCTAVE or PASTA outputs are appropriate. Technical-level frameworks (ATT&CK, STRIDE) don’t communicate well to executive audiences; the business-impact mapping that PASTA emphasizes is the right level for board-level discussions.

Persistent pitfalls

A short list of the failure modes that recur across threat modeling programs regardless of which framework is in use:

Treating the framework as a checklist. Threat modeling produces value through the analytical work of thinking through what could go wrong. A team that fills in a STRIDE template without genuinely reasoning about each threat is producing paperwork, not security. The framework is a structure for the thinking, not a substitute for it.

Picking the wrong level of abstraction. Trying to use ATT&CK to model a system architecture, or STRIDE to characterize an ongoing incident, produces frustration. The right framework for the work is the one operating at the appropriate level.

One-time threat modeling without iteration. Systems change. Threat models need to update with them. A threat model from three years ago for a system that has since added new integrations and new attack surface is mostly outdated.

Treating threat modeling as a one-person activity. The best threat models come from groups with mixed perspectives — architects, developers, security engineers, sometimes operations and product managers. The group dynamic surfaces threats that any single perspective would miss.

Conflating threat modeling with risk assessment. A threat model identifies threats; a risk assessment evaluates likelihood and impact and prioritizes. The two activities are complementary, and confusing them produces output that’s not quite useful for either purpose.

Ignoring the “what could go wrong” question outside adversarial threats. Most frameworks emphasize adversarial threats. Real systems also fail due to component failures, configuration errors, software bugs, and natural disasters. A threat model that ignores non-adversarial threats misses a substantial fraction of what could go wrong.

Treating compliance as threat modeling. Compliance frameworks specify minimum controls, not actual threat coverage. A system can be compliant and entirely vulnerable; threat modeling is the activity that determines whether the controls actually address the relevant threats.

Where to go next on this site

The subpages under Threat Modeling Frameworks will go deeper than this overview can:

• MITRE ATT&CK — the operational catalog of adversary behavior, with the technique landscape and the practical workflows for defenders using it.
• MITRE D3FEND — the defensive countermeasure catalog and how it pairs with ATT&CK.
• STRIDE — the system design threat categorization framework with practical guidance for applying it during architecture review.
• PASTA — the seven-stage risk-centric methodology with its strengths and operational requirements.
• The Cyber Kill Chain — the attack lifecycle model, its enduring contributions, and its limits.
• The Diamond Model — the cyber threat intelligence analytical framework with its four-node structure.
• OCTAVE — the asset-driven enterprise risk assessment methodology and its variants.
• LINDDUN — the privacy-focused threat modeling framework.

Adjacent material on this site:

• Cryptography — the cryptographic primitives that show up as mitigations in many threat models.
• Quantum Computing — the technology shift that is already affecting threat models for long-lived data protection.

Threat modeling is one of the parts of the security discipline where the depth of writing about methodology far exceeds the depth of operational practice in most organizations. Every framework has its devoted advocates; few practitioners use any single framework consistently in real work. The goal of these pages is the opposite of advocacy: an honest map of what each framework does well, where each has its limits, and how to pick the right tool for the work in front of you.