What Is Threat Modeling? How to Anticipate Attacks Before They Happen

Threat modeling in cyber security is the structured, design-phase process of identifying, categorizing, and prioritizing security threats to a system before it’s built, rather than discovering them after deployment through an incident or a penetration test.

Unlike vulnerability scanning or pentesting, which evaluate a system that already exists, threat modeling happens at the design stage, when fixing a flaw costs a fraction of what it costs post-release. It produces a shared, structured understanding of a system’s attack surface: what could go wrong, and what you’re doing about each specific risk before a single line of code ships.

The four questions every threat model starts with

Every threat modeling exercise, regardless of framework, answers four questions originally articulated by Adam Shostack: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job.

The Threat Modeling Manifesto explicitly values “a valuable model over a perfect model” and “people and collaboration over checklists.” Running these four questions together as a team for even an hour during a design review produces genuine value, and treating threat modeling as a rigid ritual rather than a collaborative habit is exactly what causes teams to abandon it after one attempt.

Data flow diagrams: mapping how data moves through your system

A data flow diagram maps five elements: processes, data stores, data flows, external entities, and trust boundaries, giving the team a shared, visual answer to the first question, what are we building, before anyone tries to identify threats.

Perfect notation matters less than clarity here. What matters is seeing exactly where data originates, where it travels, and where the assumption of trust changes along the way. A diagram everyone in the room can point at and argue about beats a polished one nobody understands well enough to challenge.

Trust boundaries: the points that deserve the most scrutiny

Trust boundaries are the dashed lines on a data flow diagram separating zones of different privilege, and they deserve the most scrutiny because most real threats cluster specifically around trust boundary crossings, not inside a single trusted zone.

Every point where data moves from an untrusted zone into a trusted one, a public API into your internal network, a third-party integration into your database, is a point where an attacker’s assumptions and your system’s assumptions might not match. Reviewing every trust boundary crossing individually, rather than scanning the diagram as a whole, is what separates a genuinely useful threat model from a decorative one.

Applying STRIDE to each element of your diagram

STRIDE, developed at Microsoft, systematically checks six threat categories against every element of your diagram: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege, each mapping to one specific security property being violated.

STRIDE Category	Property Violated
Spoofing	Authentication
Tampering	Integrity
Repudiation	Non-repudiation
Information Disclosure	Confidentiality
Denial of Service	Availability
Elevation of Privilege	Authorization

STRIDE’s real strength is exhaustiveness over intuition: instead of listing threats “by feel,” you mechanically ask all six questions against every element, especially each trust boundary crossing, catching gaps a purely intuitive review would miss.

Running the workshop: a practical, step-by-step walkthrough

A practical threat modeling workshop runs the four questions in sequence: build the DFD together, walk every trust boundary crossing asking all six STRIDE categories, document mitigations for what you find, then close by asking honestly whether the exercise was thorough enough.

Schedule this at every meaningful architectural trigger point, not on an arbitrary calendar. Revisit the model whenever you add a new trust boundary, a new sensitive data store, change authentication or authorization logic, or integrate a new third-party service, and at minimum quarterly for any system handling sensitive data.

Scoring what you find: DREAD and risk prioritization

DREAD scores identified threats across five dimensions, Damage, Reproducibility, Exploitability, Affected users, and Discoverability, each rated 1 to 3, with a combined score of 13 to 15 flagged critical and 5 to 8 flagged medium.

Here’s the honest gap most content skips: DREAD has genuinely fallen out of favor across mature security teams, because its scores are subjective and inconsistent between different assessors, creating false precision that looks quantitative but isn’t reliable. Most teams now prioritize STRIDE findings using CVSS or a simple risk matrix tied to real business impact instead, treating DREAD as a useful teaching tool for a first workshop rather than a permanent scoring system. If your team is choosing a prioritization method today, start with a straightforward impact-and-likelihood matrix rather than importing DREAD’s five-dimension complexity, since the added precision it promises rarely survives contact with two different assessors scoring the same threat.

Cross-referencing findings with MITRE ATT&CK

Once STRIDE has identified threat categories, cross-reference specific findings against MITRE ATT&CK‘s documented, real-world techniques to ground your abstract “elevation of privilege” or “tampering” finding in concrete, observed attacker behavior rather than a theoretical category alone.

This step turns a generic STRIDE finding into something a detection engineer can actually build against. “Elevation of privilege at this trust boundary” becomes far more actionable once mapped to a specific, documented ATT&CK technique with known detection guidance attached, connecting your design-phase threat model directly to the same framework your SOC already uses operationally.

Why auditors now request threat model diagrams as evidence

Threat model diagrams, complete with documented trust boundaries and STRIDE findings, have become a standard evidence artifact auditors specifically request, since they demonstrate systematic security thinking rather than after-the-fact compliance documentation assembled just for the audit.

This applies directly across two current, high-stakes contexts: SOC 2 audits increasingly expect a documented threat model as evidence of the design-phase controls the audit is verifying, and EU AI Act conformity assessments for high-risk AI systems require comparable documented risk analysis. A business that’s already doing cyber security risk assessment work has most of the raw material for this evidence already, threat modeling simply structures it into the specific artifact an auditor recognizes and expects.

Managing threats as code: keeping the model current, not a one-time exercise

Threat modeling as code means writing the model in a machine-readable format, typically YAML, that lives in version control alongside application code and re-runs automatically in CI whenever the architecture changes, closing the gap where a model gets built once and never revisited.

Threagile, an open-source, MIT-licensed toolkit, is the clearest example: teams describe assets, data flows, and trust boundaries in a threagile.yaml file, wire a GitHub Action to trigger specifically on changes to that file, and the tool auto-generates an updated diagram and threat report as a CI artifact. The path-filtering matters practically: triggering only on genuine model changes, not every commit, keeps the generated report a meaningful review signal instead of noise nobody reads. This is the single highest-leverage fix for the most common threat modeling failure: a model built once during design, then quietly abandoned as the system evolves around it.

Conclusion

Where does your last threat model sit right now, in a shared drive nobody’s opened since the design review, or wired into your pipeline so it actually keeps up with your system? Cyber Security Solutions Ltd can help you build the version that stays current at cybersecuritysolutionsltd.com.