Threat Modeling: STRIDE, PASTA, and SOC Integration

Threat modeling maps a system, identifies how it could be attacked, and produces decisions about which of those risks to treat. Teams that model at all usually do a competent job of it at the design review, then stop there. The data flow diagram is clean, the threat table is filled in, every finding has a ticket, and none of it reaches the people who write detections or run response.

The methods are the easy part. The harder problems sit on either side of them: choosing a method that fits the decision in front of you, and building the path that carries a model's output into detection engineering, hunting, and incident response.

TL;DR:

• STRIDE classifies threats against a data flow diagram but ranks nothing on its own, which makes an unranked STRIDE output unfinished work rather than a finished analysis.
• PASTA earns its cost where security decisions have to be defensible to the business, and rarely earns it on a small team without dedicated risk expertise.
• A threat model that never reaches the SOC is a design artifact, not an operational control. Its outputs belong in the detection backlog, coverage maps, hunting hypotheses, and response playbooks.
• Models go stale because architecture changes faster than review cycles, so updates have to be tied to real architectural events rather than to a calendar.

Four Questions, Many Methods

The four questions that frame threat modeling are simple enough to state: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? Every method below is a competing answer to the second one. OWASP process guidance builds its own four-phase process on the same structure. It is also explicit that "there is no universally accepted industry standard for the threat modeling process, no 'right' answer for every use case." That is worth taking seriously before comparing methods, because it makes the comparison a question of fit rather than of correctness.

STRIDE: Threat Classification Against a Data Flow Diagram

STRIDE is a way of enumerating threats systematically rather than by inspiration, and its usefulness depends heavily on the quality of the diagram you run it against. Its Microsoft origins date to 1999, when Loren Kohnfelder and Praerit Garg documented the company's first formal threat modeling methodology, later built into the Security Development Lifecycle. The acronym maps six threat categories to the security property each one violates, as documented in the CMS Threat Modeling Handbook:

‍

The method runs against four diagram element types: external entities, processes, data stores, and data flows. The analysis concentrates on trust boundaries, the points where data changes its level of trust. Draw the diagram and mark those boundaries before naming threats, then apply the relevant categories to each applicable element, with particular attention to data crossing between trust levels.

STRIDE-per-Element vs. STRIDE-per-Interaction

Each element type takes a different subset of the six categories. In STRIDE-per-Element, processes get all six while data stores, data flows, and external entities get only the subset that can apply to them, which keeps a session from fixating on whichever threats participants think of first. STRIDE-per-Interaction analyzes the interactions between elements instead. On a large system it narrows the review to communication paths, which is a smaller and more tractable set than every element in the diagram.

Where STRIDE Breaks Down

STRIDE has no built-in risk ranking. CMS's methodology evaluation notes that it "can lead to a long list of potential threats, some of which may not be relevant to the specific system or application being analyzed. It rarely incorporates organizational context to those threats." Results also vary by reviewer, since the method structures the search without supplying the adversarial imagination that makes it productive. Teams add a separate scoring model for that reason, and an unranked STRIDE output should be treated as unfinished work.

Coverage depends on the completeness of the diagram, so anything missing from it is missing from the analysis. There is also a gap between the threats a team imagines and the ones adversaries actually use, and closing it is why STRIDE is often paired with CAPEC. Mapping each threat to industry-standard attack patterns gives the model traceability to real adversary behavior, and SEI guidance on CAPEC argues that relying on a standard pattern set this way "brings credibility to the threat modeling process." Classic STRIDE was not designed for prompt injection or agentic AI behavior either, which is why teams working on those systems run an AI-specific framework alongside it.

PASTA: Risk-Centric Analysis in Seven Stages

PASTA is a risk-centric framework of seven stages, developed in 2012 by Tony UcedaVélez. Where STRIDE enumerates by category against a diagram, PASTA works from business objectives down through the technology stack, then tests candidate threats against the environment and scores what survives. It takes an attacker's perspective and produces an asset-centric output in the form of enumerated and scored threats. Its seven stages run as follows:

1. Define objectives. Identify business objectives and security and compliance requirements, and run a business impact analysis.
2. Define technical scope. Capture the boundaries of the technical environment and the infrastructure, application, and software dependencies inside it.
3. Application decomposition. Identify actors, assets, services, roles, and data sources, then diagram data flows and mark trust boundaries.
4. Threat analysis. Build probabilistic attack scenarios from security event data, threat intelligence, and existing vulnerability reports.
5. Vulnerability and weaknesses analysis. Map threats to existing vulnerabilities using threat trees, and analyze design flaws through use and abuse cases.
6. Attack modeling. Analyze the attack surface, develop attack trees, and connect attacks to the vulnerabilities and exploits that would realize them.
7. Risk and impact analysis. Qualify and quantify business impact, identify countermeasures, and analyze what residual risk remains.

The stage list is where PASTA's cost becomes visible, because each stage carries multiple activities and most of them need someone who has run the method before. An SEI comparison of methods for cyber-physical systems found that PASTA "provides the most detailed guidance for the process of threat modeling," and that its risk and impact analysis mitigates the threat-explosion weakness of STRIDE and LINDDUN. CMS reaches the same conclusion from the other direction, noting that PASTA "can be complex and time-consuming to implement effectively" and requires a high level of expertise. In practice that makes it best suited to complex applications and APIs, heavily regulated industries, and programs where business impact has to guide security decisions alongside technical severity.

The two methods sit at different points on the same tradeoff, which is easier to see side by side:

‍

The two also work together, which is the option comparisons tend to skip. STRIDE can do the enumeration inside PASTA's threat-analysis stage, and PASTA supplies the business objectives, compliance requirements, risk tolerance, and prioritization that STRIDE lacks.

Where Threat Modeling Fits in Security Operations

The bridge from a design-time model to SOC operations is MITRE ATT&CK. The CMS handbook is careful to describe ATT&CK as something used alongside threat modeling methodologies rather than as one of them. That distinction is what makes the pairing work. STRIDE names categories of threat at design time, while ATT&CK catalogs behaviors that someone has actually observed in production. MITRE's Center for Threat-Informed Defense formalized the combination in Threat Modeling with ATT&CK, published in July 2024 with enterprise research participants including banks, a hospital operator, and a telecommunications provider.

Detection Engineering and Coverage Prioritization

The first destination for a threat model's output is a prioritized detection backlog: the adversary behaviors most relevant to the organization, ordered by what should get built first. ATT&CK is already the common vocabulary for describing detection coverage, which makes it the natural place to land the mapping.

CTID's Top ATT&CK Techniques methodology gives the ordering some rigor, scoring techniques on prevalence, common attack choke points, and actionability. DeTT&CT and ATT&CK Navigator heat maps then make coverage comparisons legible: modeled behaviors on one axis, existing detections on the other, and the gap between them as the backlog. The October 2025 release of ATT&CK v18 makes that mapping easier to act on. It replaces the old Data Sources with Detection Strategies and Analytics, so a technique now points at what to collect and what to look for rather than at a category of log.

Threat Hunting Hypotheses

A threat model is also a ready source of hunting hypotheses, and a less obvious one than an intelligence feed or a recent incident. ATT&CK technique profiles give those hypotheses concrete shape: if an attacker is attempting credential access through LSASS memory dumping (T1003.001), we should observe abnormal access to the LSASS process. That is a testable statement about a specific data source, which is what separates hypothesis-driven hunting from a general look around.

That closes a loop worth building deliberately: hunt findings become production detection rules. Hunting is also a good instrument for the coverage gaps a backlog cannot absorb, including behaviors too noisy to detect programmatically without burying the team in false positives.

Incident Response Preparation

Modeled scenarios and attack paths should turn into playbook checks and tabletop prompts, which is the cheapest way to find out whether a documented response actually works. Mapping those scenarios against your response frameworks shows which modeled paths have a defined response and which have only a diagram. It runs in reverse too: after an incident, record how the attacker got in and why the activity was not seen sooner, then feed those lessons into the next round of hunts.

Why Threat Models Go Stale

Threat models decay when they are treated as point-in-time artifacts rather than maintained assets. OWASP names the events that should trigger an update: a new feature release, a security incident, and architectural or infrastructure changes. In fast-moving organizations, the failure is rarely that nobody knows the triggers. It is that nothing connects the trigger to the modeling process, so the events happen and the model does not move.

Dependence on a small number of specialists makes that worse, because every update queues behind the same few people. Assigning update responsibility to the teams that design and operate the system, and tying their updates to real architectural changes rather than to a separate review cycle, removes the queue.

Models also go stale in a second way that is easier to miss: the model stays accurate and the detections built from it do not. Vendor-supplied rules are written against a generic environment by design, so they usually need reviewing against a specific environment's APIs, business logic, data flows, and user behavior, whether the team writes those rules in-house or uses outsourced detection engineering. A model that stops at the design review leaves exactly those environment-specific risks outside the SOC's workflow, which is an argument for maintaining each model iteratively rather than waiting for a full-system review.

Choosing a Methodology: Decision Criteria

Choose a method based on the decision in front of you. SEI's 2018 methods summary declines to rank them for exactly this reason, concluding that "no one threat modeling method is recommended over another" and that the choice should follow the needs of the project and its specific concerns. The mapping below is one reading of what those needs usually look like:

• If your team already draws data flow diagrams and needs design-review coverage, use STRIDE, and pair it with a scoring model since it has no risk ranking of its own.
• If you operate in a regulated industry, or need security decisions tied to business impact, use PASTA and accept the staffing and expertise cost.
• If the system processes personal data and privacy obligations drive the risk, use a privacy-focused method such as LINDDUN, which runs six steps over the same kind of diagram STRIDE uses.
• If the concern is organizational or insider risk with limited resources, use OCTAVE Allegro, which SEI's insider threat guidance recommends for assessing risk to the assets such a program is built to protect.
• If you need strict assurance of role-based permissions, use Trike, which builds an actor-asset-action matrix and rates each action an actor may perform on each asset.
• If you need enterprise-wide, agile-integrated modeling across infrastructure, consider VAST, noting that SEI describes it as based on ThreatModeler, a commercial platform, which makes it a tooling decision as much as a methodology one.
• If the outputs have to reach detection and hunting, integrate ATT&CK through CTID's process regardless of which base method you pick.

None of these are exclusive, and the mature version of this decision is usually a combination rather than a winner. What matters more than the choice is that whichever method produces the output, something downstream is waiting to receive it.

From Periodic Models to Continuous, Context-Driven Operations

The Cloud Security Alliance argued in November 2025 that cloud threat modeling has to become continuous, on the grounds that elastic, API-driven, constantly changing environments reshape the attack surface faster than any review cadence can track. Periodic modeling and periodic hunting fail against the same drift, and for the same reason: production stops matching what anyone analyzed.

Staffing is part of why. Continuous practice needs capacity that episodic practice does not, and most teams that want to hunt continuously are constrained by hours rather than by method. Daylight runs threat hunting as a dedicated service on that basis: security experts define the hypotheses, and an agentic execution system tests them across the environment on a defined frequency.

Wherever the capacity comes from, the measure of a threat model is the same. Name the three adversary behaviors you would hate to leave untested, then set a frequency for checking them.

Frequently Asked Questions About Threat Modeling

What Do You Actually Do With a Threat Once You Have Named It?

Record the treatment decision, its owner, and the reasoning behind it. When the treatment is acceptance, document the acceptance rather than leaving the line blank, so that the threat list doubles as a decision log a future reviewer can audit.

Is MITRE ATT&CK a Threat Modeling Methodology?

No. ATT&CK documents adversary tactics and techniques across pre-compromise and post-compromise activity, and complements design-time methods rather than replacing them. The practical use is to map each viable attack path to the ATT&CK behaviors needed to execute it, then read detection gaps, backlog priorities, and hunting hypotheses off those mappings. A single path often spans several techniques, so map it to all of them rather than to the most obvious one.

How Often Should a Threat Model Be Updated?

Update it on events rather than on a schedule: a new feature release, a security incident, and architectural or infrastructure changes are OWASP's named triggers. Cadence alone is a weak control, because the real evidence that a model is current is that its components, data flows, trust boundaries, and owners still match the production system. Tracking when each model was last revised is still worth doing, since a long gap usually means features have shipped without ever entering the model.

Do STRIDE or PASTA Cover AI and Agentic Systems?

Not on their own. Both need an AI-specific framework alongside them, added to the existing workflow rather than replacing it. Use the base method to map components, data flows, trust boundaries, and business impact, then use the specialized framework to test agent-specific threats. OWASP's agentic Top 10 for 2026 covers that ground, including memory and context poisoning, tool misuse, and identity and privilege abuse. Whatever that framework surfaces should then carry into the same scoring, ownership, detection, and hunting workflow as the rest of the model.

Who Should Own Threat Modeling, Security or Engineering?

Engineering should own it and security should support it. Engineers already model the systems they build, so the marginal cost of modeling threats is lower for them than for anyone else. Security's job is to supply the methods, the vocabulary, and enough support that the work happens inside engineering rather than beside it, which also distributes the practice beyond whichever one person currently has the right instincts for it.