Threat Modeling
What threat modeling is, and the inputs it needs
A design flaw found on a diagram costs a sentence to fix; the same flaw found in production costs an incident. That timing gap is the entire case for threat modeling, the structured, proactive way to find those flaws before an attacker does, performed during design rather than after deployment. Built on the threat-vulnerability-risk vocabulary you already have, it produces an enumerable list of what can go wrong, anchored on a diagram and on the trust boundaries where threats cluster.
Definition and the four questions
NIST SP 800-154[1] (Guide to Data-Centric System Threat Modeling) defines threat modeling 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 fundamental principle it states is that security resources are always limited, so you must decide where to spend them, and threat modeling is how you decide. As a security leader the payoff is timing: it is performed during design, when a flaw found on a diagram costs a sentence to fix and the same flaw found in production costs an incident.
Whatever method you adopt, it answers the same four questions (the threat-modeling community's framing): what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. The acronyms in the next sections are just disciplined ways to answer question two without missing categories of threat.
Attack side and defense side
Threat modeling models two sides, and the exam vocabulary maps cleanly onto them. On the attack side: a vulnerability is a weakness; an exploit is the technique that takes advantage of it and an attack is its use; an attack vector is the path or means an attacker uses to reach and exploit the target; and a threat is the potential for a threat source to exploit a vulnerability. On the defense side: security controls reduce risk, and security objectives (commonly the CIA properties) state what those controls must preserve. A threat model is the bridge: it lists the attack vectors that threaten the security objectives, so you can select the controls that close them.
The diagram that makes "what can go wrong" answerable
You cannot enumerate threats against a system you have not drawn, so the canonical first artifact is a data-flow diagram (DFD): a small set of symbols for external entities, processes, data stores, and the data flows between them. Onto that DFD you mark trust boundaries: the lines where the level of trust changes, for example between the public internet and an internal service, or between a user-mode process and the kernel. Threats concentrate at trust boundaries because a boundary is exactly where an attacker tries to cross from a less-trusted context into a more-trusted one; data crossing a boundary is therefore the data you scrutinize first. The figure below shows the canonical DFD shape: an external entity, a process, and a data store joined by data flows, with one trust boundary marking where the internet meets the internal service. This decomposition, not any particular acronym, is the part of threat modeling that turns vague worry into an enumerable list.
The methodologies: STRIDE, PASTA, attack trees, DREAD
The four methodologies CISSP names each put a different thing at the center of the analysis, so you pick by what you most need to get right; building on the DFD with trust boundaries, you organize them by one idea. One split sits above all the others and the figure below makes it visible: three of the four (STRIDE, PASTA, attack trees) discover threats, while DREAD only rates threats you already found.
STRIDE, threat-centric
STRIDE, from Microsoft, walks each element of the DFD against six threat categories, and the testable fact is that each category is the violation of exactly one security property. The mapping, per Microsoft's Threat Modeling Tool documentation[2]:
| STRIDE category | Property it violates | Example countermeasure |
|---|---|---|
| Spoofing | Authentication | Strong authentication, MFA |
| Tampering | Integrity | Hashing, digital signatures |
| Repudiation | Non-repudiation | Secure audit logging, signatures |
| Information disclosure | Confidentiality | Encryption, access control |
| Denial of service | Availability | Rate limiting, redundancy |
| Elevation of privilege | Authorization | Least privilege, input validation |
The mapping is bidirectional and that is the leader's shortcut: if a design must guarantee integrity, STRIDE tells you Tampering is the threat and a signature or hash is the countermeasure. STRIDE's strength is systematic coverage; its limitation is that it tells you what can go wrong but not how likely or how damaging, that is what the rating model below is for.
PASTA, risk-centric and attacker-centric
PASTA (Process for Attack Simulation and Threat Analysis) is a heavier, seven-stage methodology that is risk-centric: it begins from business objectives and carries each technical threat through to its business impact, and it is attacker-centric in that it simulates how a real adversary would attack. OWASP lists PASTA[3] among the recognized processes alongside STRIDE and OCTAVE. Reach for PASTA when leadership needs threats expressed as business risk rather than as a list of technical issues; the cost is that it needs business context and far more effort than a STRIDE pass.
Attack trees, goal-centric
An attack tree is goal-centric: the attacker's objective (for example, "forge a funds transfer") is the root, and branches decompose it into the alternative sub-goals and steps needed to reach it, with AND/OR logic showing which steps must combine. Attack trees are the right tool when you must understand every path to one specific objective in depth; their scope is that single goal, not the whole system, so they complement rather than replace STRIDE.
DREAD, a rating model, not an enumeration
DREAD does not find threats; it ranks the ones you already found, so the costliest are mitigated first. Its five factors are Damage, Reproducibility, Exploitability, Affected users, and Discoverability, each scored and combined into a relative priority. The honest caveat, debunked here rather than left as a trap, is that DREAD scores are subjective and inconsistent between raters, which is why Microsoft itself moved away from it and many teams now use a simpler high/medium/low rating. Know DREAD as the named rating model and know its five letters; do not treat its score as an objective measurement.
Threat intelligence: TTPs, IOCs, the kill chain, and ATT&CK
A model reflects real adversaries rather than only imagined ones when it stays grounded in how attackers actually behave. Building on a method for enumerating and ranking threats, that grounding is what threat intelligence supplies.
Why a model needs threat intelligence
A threat model built only from a checklist drifts from reality because the attack side changes constantly. Threat intelligence, evidence-based knowledge of adversaries, feeds the model two kinds of input. Tactics, techniques, and procedures (TTPs) describe how an adversary operates: tactics are the goals (the why), techniques are the methods (the how), and procedures are the specific implementations. Indicators of compromise (IOCs) are the observable artifacts an attack leaves behind (malicious IPs, file hashes, domains) which are useful for detection but are more easily changed by the attacker than TTPs are. The leader's takeaway: hunting on TTPs is more durable than hunting on IOCs, because an attacker can swap a hash far more easily than change how they operate.
The Cyber Kill Chain, a linear attack lifecycle
The Lockheed Martin Cyber Kill Chain[4] models an intrusion as seven sequential phases: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command and Control → Actions on Objectives (see the diagram). Its value for threat modeling is that breaking an attack into stages lets you place a control to disrupt the chain at the earliest, cheapest phase: stopping a delivered payload is better than responding to actions on objectives. Its limitation is that it is linear and perimeter-oriented, which fits classic malware intrusions better than insider abuse or fast lateral movement.
MITRE ATT&CK, a knowledge base of real behavior
MITRE ATT&CK[5] is "a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations." Where the kill chain is a small linear model, ATT&CK is a matrix: tactics form the columns (the adversary's goals, such as Initial Access, Persistence, Privilege Escalation) and many techniques and sub-techniques sit under each. It is the standard catalog from which you draw realistic TTPs to test a threat model against, and it doubles as a common language for mapping detections and gaps. Use the kill chain to reason about where in the lifecycle to place a control, and ATT&CK to reason about which concrete techniques the control must counter.
Exam-pattern recognition
CISSP dresses the concepts above up in question stems, where the work is to spot the one right answer and name why the distractors fail. Building on those concepts, the patterns below are how the exam recycles them.
Pattern 1: map a STRIDE letter to its property
The most common threat-modeling question gives a scenario and asks which STRIDE category applies, or which property a category violates. Anchor on the one-to-one mapping: Spoofing↔authentication, Tampering↔integrity, Repudiation↔non-repudiation, Information disclosure↔confidentiality, Denial of service↔availability, Elevation of privilege↔authorization. The classic trap pairs the wrong property, for example calling unauthorized data modification "information disclosure." Modification is Tampering (integrity); disclosure is reading data you should not, which is the confidentiality violation.
Pattern 2: pick the right methodology for the goal
Stems describe a need and ask which methodology fits. Match the center of gravity: systematic, per-component coverage during design = STRIDE; tying technical threats to business impact with an attacker simulation = PASTA; analyzing every path to one specific attacker objective = attack tree; ranking threats you already found = DREAD. The trap is choosing DREAD when the stem asks how to enumerate threats: DREAD only rates, it does not discover, so a stem about finding threats wants STRIDE or PASTA, not DREAD.
Pattern 3: when in the lifecycle to threat-model
When a stem asks when threat modeling delivers the most value, the answer is during design, before code is written: flaws are cheapest to fix on a diagram. Distractors that place it only after deployment ("during penetration testing") miss the point: testing validates the model, it is not the model. A related trap treats threat modeling as a one-time deliverable; because the attack and defense sides change, the correct view is that the model is revisited whenever the architecture, data, or threat landscape changes.
Pattern 4: TTPs vs IOCs, and which framework
Stems test whether you can tell adversary behavior from adversary artifacts. An early-warning question about how an adversary operates wants TTPs; a question about observable artifacts left behind (hashes, IPs, domains) wants IOCs, and the sharp follow-up is that TTPs are more durable to hunt on because IOCs are trivially changed. For frameworks: a question about a linear, staged intrusion lifecycle points to the Cyber Kill Chain; a question about a matrix knowledge base of real-world techniques points to MITRE ATT&CK. Confusing the two (calling ATT&CK a linear chain, or the kill chain a technique catalog) is the trap.
Pattern 5: DREAD is subjective
When a stem praises DREAD as an objective or precise risk measure, that is the wrong answer. DREAD produces a relative priority from subjective scores; its known weakness is inconsistency between raters. The defensible statement is that DREAD ranks and prioritizes threats, not that it measures absolute risk, and that many teams replaced it with a simpler high/medium/low scheme for exactly that reason.
Threat-modeling methodologies: center of gravity and when to reach for each
| Dimension | STRIDE | PASTA | Attack trees | DREAD |
|---|---|---|---|---|
| Center of gravity | Threat-centric (per DFD element) | Risk-/attacker-centric (business-aligned) | Goal-centric (one attacker objective) | Rating, not enumeration |
| What it produces | Six threat categories mapped to security properties | Seven staged outputs from scope to residual risk | A tree of sub-goals/paths to one goal | A relative priority score per threat |
| Origin | Microsoft | UcedaVélez & Morana (risk-centric) | Schneier (formalized) | Microsoft (legacy) |
| Best when | Systematic coverage during design | Tying technical threats to business impact | Exhaustively analyzing a single objective | Comparing/ranking already-found threats |
| Main limitation | Says what, not how likely or how bad | Heavyweight; needs business context | Scope is one goal, not the whole system | Scoring is subjective and inconsistent |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Threat modeling is risk assessment done during design, not after deployment
Threat modeling is a form of risk assessment that models the attack and defense sides of an entity (data, application, host, system, or environment) to spend limited security resources where they reduce the most risk (NIST SP 800-154). It pays off because a design flaw found on a diagram is far cheaper to fix than the same flaw found in production. It is proactive and iterative, revisited whenever the architecture, data, or threat landscape changes.
Trap Treating threat modeling as a post-deployment or one-time activity done during penetration testing. Its value is during design, and the model must be kept current.
- Every threat-modeling method answers the same four questions
Regardless of methodology, threat modeling answers four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. The acronyms (STRIDE, PASTA, DREAD) are just disciplined ways to answer 'what can go wrong' and rank the answers. Keeping the four questions in mind prevents mistaking a tool for the whole process.
Trap Treating an acronym like STRIDE or DREAD as the entire threat-modeling process rather than as one disciplined way to answer the 'what can go wrong' question.
- Threats concentrate at trust boundaries on a data-flow diagram
A data-flow diagram (DFD) models external entities, processes, data stores, and the data flows between them; a trust boundary is the line where the level of trust changes, such as between the internet and an internal service. Threats cluster at trust boundaries because that is where an attacker crosses from a less-trusted to a more-trusted context, so data crossing a boundary is scrutinized first. Decomposing the system this way (not any acronym) is what turns vague worry into an enumerable list of threats.
Trap Assuming an acronym like STRIDE is what decomposes the system, when it is the DFD and its trust boundaries that produce the enumerable list of threats the acronym then categorizes.
3 questions test this
- A security team is analyzing a data flow diagram and must prioritize their threat analysis efforts due to limited resources. The DFD…
- During a threat modeling session, a security team is creating a data flow diagram for a web application. The team identifies a point where…
- During a threat modeling exercise using data flow diagrams (DFDs), a security analyst identifies that customer data crosses from the…
- An attack vector is the path or means used to reach and exploit a target
On the attack side, a vulnerability is a weakness, an exploit is the technique that takes advantage of it, and an attack vector is the path or means an attacker uses to reach the target and deliver the exploit. NIST SP 800-154's data-centric method works by selecting which attack vectors to include, then characterizing controls that mitigate those vectors. Distinguishing the vector (the route) from the vulnerability (the weakness) and the threat (the potential) is core threat-modeling vocabulary.
Trap Confusing the attack vector (the route used to reach a target) with the vulnerability (the weakness itself) or the exploit (the technique that takes advantage of the weakness).
- Pick a threat-modeling methodology by its center of gravity
Methodologies differ by what they put at the center of the analysis: STRIDE is threat-centric (per DFD element), PASTA is risk- and attacker-centric (business-aligned), attack trees are goal-centric (one objective), and DREAD is a rating model rather than an enumeration. The data-centric method of NIST SP 800-154 puts high-value data at the center and works outward to its attack vectors. There is no single right choice: pick by whether you need coverage, business alignment, or protection of a specific crown-jewel asset.
Trap Matching the methodology to the wrong center of gravity, such as treating STRIDE as business-risk-centric or PASTA as a per-element checklist, when STRIDE is threat-centric and PASTA is risk- and attacker-centric.
- Each STRIDE category is the violation of one security property
STRIDE (Microsoft) names six threat categories, each defeating exactly one property: Spoofing defeats authentication, Tampering defeats integrity, Repudiation defeats non-repudiation, Information disclosure defeats confidentiality, Denial of service defeats availability, and Elevation of privilege defeats authorization. The mapping is bidirectional: if a design must guarantee integrity, STRIDE says Tampering is the threat and a hash or signature is the countermeasure. STRIDE gives systematic coverage but says what can go wrong, not how likely or how severe.
Trap Calling unauthorized modification of data 'information disclosure'. Modification is Tampering (integrity); information disclosure is reading data you should not (confidentiality).
- Tampering is unauthorized change; information disclosure is unauthorized read
Within STRIDE the two most-confused categories are Tampering and Information disclosure. Tampering is the malicious modification of data and violates integrity; Information disclosure is exposing data to someone not authorized to see it and violates confidentiality. Anchor on the verb in the stem: change/modify points to Tampering, read/expose points to Information disclosure.
Trap Labeling the unauthorized reading or exposure of data as Tampering, when reading points to Information disclosure (confidentiality) and only modification is Tampering (integrity).
- Repudiation is countered by logging and signatures, not by encryption
Repudiation is a user denying an action with no way to prove otherwise; it violates non-repudiation (accountability). The countermeasures are secure audit logging and digital signatures that bind an action to an identity, because they create the evidence that defeats a later denial. Encryption protects confidentiality, not accountability, so it does not address repudiation.
Trap Picking encryption as the countermeasure to repudiation, when encryption protects confidentiality and it is audit logging plus digital signatures that provide the accountability evidence.
- PASTA is a seven-stage, risk-centric methodology tied to business impact
PASTA (Process for Attack Simulation and Threat Analysis) is a heavier, seven-stage methodology that starts from business objectives and carries each technical threat through to its business impact, and it is attacker-centric in that it simulates a realistic adversary. Reach for PASTA when leadership needs threats expressed as business risk rather than a list of technical issues. The cost is that it needs business context and far more effort than a single STRIDE pass.
Trap Choosing PASTA when you only need quick per-component coverage during design. That is STRIDE's job; PASTA's weight is justified only when business-risk alignment matters.
- An attack tree decomposes one attacker goal into the paths to reach it
An attack tree is goal-centric: the attacker's objective is the root and branches decompose it into the alternative sub-goals and steps needed to achieve it, often with AND/OR logic showing which steps must combine. Use it when you must understand every path to one specific objective in depth. Its scope is that single goal, not the whole system, so it complements rather than replaces a system-wide method like STRIDE.
Trap Expecting an attack tree to give system-wide threat coverage, when its scope is one specific attacker goal and a method like STRIDE is what covers the whole system.
4 questions test this
- During a threat modeling exercise, Kenji places 'Exfiltrate Customer Database' at the top of his attack tree diagram. He then decomposes…
- When constructing an attack tree to model threats against a financial trading system, a security analyst identifies that an attacker must…
- During Stage 6 (Attack Modeling) of the PASTA methodology, the security team is developing visual representations of how an attacker might…
- During threat modeling, Marcus is analyzing an attack tree where reaching the goal requires an attacker to both exploit a web application…
- DREAD ranks threats you already found; it does not discover them
DREAD is a rating model, not an enumeration method: its five factors are Damage, Reproducibility, Exploitability, Affected users, and Discoverability, scored and combined into a relative priority so the costliest threats are mitigated first. It needs another method (STRIDE, PASTA) to find the threats first. Its known weakness is that scores are subjective and inconsistent between raters, which is why many teams replaced it with a simpler high/medium/low scheme.
Trap Picking DREAD when a stem asks how to enumerate or discover threats. DREAD only rates, so a discovery question wants STRIDE or PASTA.
- DREAD produces a relative priority, not an objective risk measurement
DREAD's output is a relative ranking derived from subjective scores, not a precise or objective measure of risk. Different raters score the same threat differently, so its reliability is limited. The defensible claim is that DREAD prioritizes threats; calling it an objective or precise risk metric is wrong.
Trap Treating a DREAD score as an objective or precise risk measurement, when its rater-dependent scores yield only a relative ranking for prioritization.
- TTPs describe how an adversary operates; IOCs are the artifacts left behind
Tactics, techniques, and procedures (TTPs) describe how an adversary operates: tactics are the goals (why), techniques are the methods (how), procedures are the specific implementations. Indicators of compromise (IOCs) are observable artifacts an attack leaves, such as malicious IPs, file hashes, and domains. Hunting on TTPs is more durable than hunting on IOCs because an attacker can swap a hash or IP far more easily than change how they operate.
Trap Treating IOCs as the more durable detection signal. IOCs are trivially changed by the attacker, so behavior-based TTPs are the more resilient basis for detection.
- The Cyber Kill Chain models an intrusion as seven sequential phases
The Lockheed Martin Cyber Kill Chain breaks an intrusion into seven sequential phases: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on Objectives. Its value is that placing a control to break the chain at the earliest phase is cheaper than responding at Actions on Objectives. Its limitation is that it is linear and perimeter-oriented, fitting classic malware intrusions better than insider abuse or fast lateral movement.
Trap Assuming the linear, perimeter-oriented Cyber Kill Chain models insider abuse or fast lateral movement well, when those scenarios fit it poorly and are better reasoned about with a matrix like ATT&CK.
- MITRE ATT&CK is a matrix knowledge base of real-world adversary behavior
MITRE ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations, organized as a matrix where tactics are columns (adversary goals like Initial Access, Persistence, Privilege Escalation) and many techniques and sub-techniques sit under each. It supplies realistic TTPs to test a threat model against and serves as a common language for mapping detections and gaps. Use the kill chain to reason about where in the lifecycle to place a control, and ATT&CK to reason about which concrete techniques the control must counter.
Trap Calling MITRE ATT&CK a linear chain or the Cyber Kill Chain a technique catalog. ATT&CK is a matrix of techniques, the kill chain is a linear lifecycle.
- Threat-model during design, before code is written
Threat modeling delivers the most value during the design phase, before code exists, because flaws are cheapest to fix on a diagram. Testing (penetration testing, code review, scanning) validates the model against the real system but does not replace it. Because the attack and defense sides change, the model is a living artifact that is revisited as the system and threat landscape evolve.
Trap Assuming penetration testing or code review can replace threat modeling, when those activities validate the model against the running system but do not substitute for design-phase modeling.
- Threat modeling identifies and prioritizes; it does not compute dollar loss
Threat modeling enumerates and ranks what can go wrong; it does not produce SLE/ALE dollar figures. Quantitative loss math belongs to the risk-management process, which consumes the threat model as an input. A threat model is also one activity within a secure development lifecycle, not a substitute for secure coding, testing, or the full SDLC.
Trap Expecting a threat model to output SLE/ALE dollar figures, when quantitative loss math belongs to the risk-management process that consumes the threat model as an input.
- NIST data-centric threat modeling runs four steps from data to controls
NIST SP 800-154's data-centric method has four steps: identify and characterize the system and data of interest, identify and select the attack vectors to include, characterize the security controls that mitigate those vectors, and analyze the threat model. It puts high-value data at the center, so it is the method to reach for when protecting a specific crown-jewel asset rather than a whole system. It is meant to supplement, not replace, existing methodologies.
Trap Reaching for the NIST SP 800-154 data-centric method to model a whole system broadly, when it is purpose-built to center on a specific high-value data asset and is meant to supplement existing methodologies.
- DREAD rates five factors to prioritize a threat
DREAD scores a threat on five factors - Damage, Reproducibility, Exploitability, Affected users, and Discoverability - and combines them into an overall priority. Microsoft's original model rated each factor on a small scale and summed them; a widely used later variant rates each 1-10 and averages them (sum of the five divided by five) for a 1-10 score, so the exact combining method varies by source. Damage = severity of harm, Reproducibility = how reliably the attack works, Exploitability = effort/skill to pull it off, Affected users = scope of impact, and Discoverability = how easily the flaw is found, which is often rated high since any flaw is assumed to be discoverable eventually.
7 questions test this
- A security analyst is using the DREAD model to assess a newly discovered vulnerability in a web application. After evaluating all five…
- During a threat modeling exercise, an organization is using the DREAD model to rank threats after identifying them with STRIDE. When…
- During a threat modeling session, a security team debates which DREAD factor to prioritize when assessing a newly discovered zero-day…
- A security team is conducting threat modeling for a new API service that will expose customer financial data. Using the DREAD model, they…
- A security analyst is using the DREAD model to assess a SQL injection vulnerability in a customer-facing web application. The analyst…
- A threat analyst evaluating an SQL injection vulnerability using DREAD has determined the following: the exploit requires only a web…
- A penetration tester has identified a buffer overflow vulnerability that requires local administrator access to exploit and works reliably…
References
- NIST SP 800-154 (IPD): Guide to Data-Centric System Threat Modeling Whitepaper
- Microsoft Threat Modeling Tool: Threats (the STRIDE model)
- OWASP Threat Modeling Process (STRIDE, DFDs, trust boundaries, attack trees) Community
- Lockheed Martin: The Cyber Kill Chain (seven phases) Whitepaper
- MITRE ATT&CK: knowledge base of adversary tactics and techniques Community