Threat Modeling Methodologies

Threat modeling is a structured examination of a system's design to identify how it could be attacked and what should be done to reduce that risk. It is fundamentally a design-time activity, which is what distinguishes it from testing.

Design flaws versus implementation bugs

Security defects fall into two broad classes. Implementation bugs — a missing bounds check, an unescaped query — are found by scanners, fuzzers, and code review. Design flaws — a trust boundary in the wrong place, a missing authorization check in the architecture, a secret that transits an untrusted channel — are invisible to those tools because the code may be flawless while the design is wrong. Threat modeling targets the second class.

The four questions

Adam Shostack's widely adopted framing reduces the practice to 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. Every methodology in this paper is a different way of answering the second question rigorously.

Why early matters

The cost of remediating a flaw rises sharply the later it is found. A trust boundary corrected on a whiteboard costs an afternoon; the same flaw discovered in production after a breach costs incident response, customer notification, and rework. Threat modeling shifts security decisions left, to the moment they are cheapest to change.

Nearly every methodology begins with a model of the system. The most common is the data flow diagram (DFD) — a map of how information moves between components.

The core elements

• External entities — users, third-party services, and other actors outside your control.
• Processes — code that transforms data, such as an API service or a worker.
• Data stores — databases, queues, caches, and file systems.
• Data flows — the arrows showing how data moves between the above.

Trust boundaries are where the action is

A trust boundary is any point where data or requests cross from one level of trust to another — the edge between the internet and your API, between a web tier and a database, between your code and a third-party SDK. Threats concentrate at these boundaries because that is where assumptions about the caller can be violated.

If you draw only one thing, draw your trust boundaries. Most exploitable flaws live where trust changes hands without validation.

Keep the model small

A DFD that tries to capture an entire platform becomes unreadable and is never updated. The most useful models scope to a single feature, service, or change. GuardsArm's assessment engagements deliberately decompose large systems into per-feature models so each can be reasoned about completely.

STRIDE, developed at Microsoft, is the most widely used methodology because it maps cleanly to how developers think. It is a mnemonic for six threat categories, each the inverse of a security property.

The six categories

• Spoofing — pretending to be someone or something else. Counter with authentication.
• Tampering — unauthorized modification of data or code. Counter with integrity controls and signing.
• Repudiation — denying an action without the system being able to prove otherwise. Counter with logging and non-repudiation.
• Information disclosure — exposing data to those not authorized. Counter with encryption and access control.
• Denial of service — degrading or denying availability. Counter with rate limiting, quotas, and resilience.
• Elevation of privilege — gaining capabilities beyond what was granted. Counter with authorization and least privilege.

Applying it per element

STRIDE is applied by walking each element of the DFD and asking which of the six threats apply. A data flow crossing a trust boundary is examined for tampering and disclosure; a process is examined for spoofing and elevation. This element-by-element discipline is what makes STRIDE thorough rather than ad hoc.

Strengths and limits

STRIDE excels at completeness and is easy to teach. Its weakness is that it can generate long lists of low-value threats if applied mechanically, which is why prioritization — covered later — matters.

Where STRIDE is technology-centric, the Process for Attack Simulation and Threat Analysis (PASTA) is risk-centric and business-driven. It is a seven-stage methodology designed to align technical threats with business impact, making it well suited to executive and regulated contexts.

The seven stages

• Define business objectives and security requirements.
• Define the technical scope of the assets in play.
• Decompose the application to understand its components and data flows.
• Analyze threats using intelligence about real adversaries.
• Analyze vulnerabilities that those threats could exploit.
• Model attacks, often via attack trees, to simulate exploitation.
• Analyze risk and prioritize countermeasures by business impact.

When PASTA fits

PASTA's strength is that it ties every threat to a business consequence and grounds analysis in real-world adversary behavior rather than abstract categories. This makes its output persuasive to leadership and auditors. Its cost is effort: PASTA is heavier than STRIDE and benefits from experienced facilitation.

Use PASTA when the stakes justify simulating how a real, motivated attacker would chain weaknesses toward a business-relevant goal.

Many organizations combine approaches — STRIDE to enumerate threats quickly, PASTA's risk stages to prioritize and justify investment. GuardsArm frequently blends the two so that engineering teams get actionable lists while leadership gets defensible risk decisions.

Security threat modeling asks how a system can be attacked. Privacy threat modeling asks how it can harm the people whose data it holds — even when functioning exactly as designed. LINDDUN is the leading privacy-focused methodology and is increasingly essential under regulations like GDPR and Canada's PIPEDA.

The seven privacy threat categories

• Linking — associating data items or actions to build a fuller profile than intended.
• Identifying — tying data to a specific individual.
• Non-repudiation — the inability of a user to plausibly deny an action, which can be a privacy harm.
• Detecting — inferring that data about someone exists.
• Data disclosure — exposing personal data excessively.
• Unawareness and unintervenability — users not knowing or not being able to control processing.
• Non-compliance — violating privacy policy or law.

Why it is distinct from security

A system can be perfectly secure against attackers yet still violate privacy by over-collecting, over-retaining, or enabling re-identification. LINDDUN forces those questions during design, when data minimization and purpose limitation are still cheap to implement.

Integrating privacy and security

The two disciplines share the DFD as a starting point, so teams can run a security pass (STRIDE) and a privacy pass (LINDDUN) over the same diagram. This dual review is becoming standard practice for products handling regulated personal data.

Some methods start not from the system but from the attacker's goal. Attack trees and MITRE ATT&CK-aligned modeling reason about how a determined adversary would actually operate.

Attack trees

An attack tree places an attacker's objective — say, exfiltrate customer records — at the root, then branches into the sub-goals and techniques required to achieve it. Leaf nodes represent concrete actions. Annotating nodes with difficulty, cost, or required privilege reveals the cheapest attack paths, which are the ones to defend first. Attack trees are excellent for reasoning about a single high-value target in depth.

MITRE ATT&CK as a threat library

MITRE ATT&CK catalogs real adversary tactics and techniques observed in the wild. Used in threat modeling, it grounds the what-can-go-wrong question in documented behavior rather than imagination. Teams map their defenses against relevant techniques and identify coverage gaps.

Adversary-centric methods answer a question STRIDE does not: given a real attacker with a real objective, which path would they take through our system?

Combining perspectives

System-centric methods (STRIDE, LINDDUN) ensure completeness; adversary-centric methods (attack trees, ATT&CK) ensure realism and prioritization. Mature programs use both — enumerating threats systematically, then stress-testing the model against how real intrusions unfold. This pairing underpins GuardsArm's threat detection and gap assessment services.

A methodology is worthless if it is practiced once and shelved. The organizations that get value treat threat modeling as a lightweight, recurring habit embedded in engineering.

Make it small and frequent

• Model at the level of a feature or change, not the whole system.
• Trigger a model whenever a design touches a trust boundary, adds a data flow, or changes an authorization decision.
• Timebox sessions; a focused model takes an hour, not a week.

Make it developer-owned

Threat modeling fails when it is a gate imposed by a separate security team. It succeeds when developers run it themselves during design review, with security acting as coach and reviewer. This scales far better and builds durable security intuition in the engineering organization.

Prioritize and track

Enumerated threats must be triaged — accepted, mitigated, or transferred — and the mitigations tracked like any other work. A threat model that produces no tracked action items has failed the fourth question: did we do a good enough job.

Measure maturity, not volume

The goal is not the number of documents produced but whether design flaws are being caught before implementation. GuardsArm helps teams stand up a right-sized practice — selecting a primary methodology, training engineers, and integrating modeling into existing design and review workflows so it sticks.