Threat modeling with STRIDE and LINDDUN: model, elicit, respond, verify

Threat modeling is a repeatable risk-analysis activity grounded in the actual system, assets, data flows, trust boundaries, actors, and assumptions. STRIDE elicits security threats; LINDDUN elicits privacy threats. Neither acronym ranks risk or replaces validation.

Security invariants

• TM-C1: Threat modeling starts from the actual system, assets, actors, data flows, stores, trust boundaries, and assumptions.
• TM-C2: STRIDE elicits Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege threats.
• TM-C3: STRIDE categories identify threat classes but do not themselves rank business risk or prove controls.
• TM-C4: LINDDUN is a complementary privacy method covering Linking, Identifying, Non-repudiation, Detecting, Disclosure, Unawareness, and Non-compliance.
• TM-C5: Every concrete threat receives an owner and an explicit response with actionable requirements, validation, and residual-risk treatment.
• TM-C6: Threat models are living artifacts revisited after architecture, data, identity, dependency, trust-boundary, or failure-mode changes.

Trust-boundary map

Component	Responsibility
external-user	External User
browser	Browser Process
gateway	Public Trust Boundary
service	Application Service
database	Sensitive Data Store
third-party	Third-Party Processor
attacker	Threat Actor
threat-register	Threat and Assumption Register
security-controls	Security and Privacy Requirements
verification-tests	Abuse, Failure, and Control Tests
privacy-review	LINDDUN Privacy Review

Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.

Executable scenarios

model-the-system — Model assets, flows, stores, actors, and trust boundaries

The team first agrees on what exists and which assumptions apply; an acronym applied to an inaccurate diagram produces false confidence.

▶Walkthrough: model-the-system (not found)

stride-spoofing — STRIDE: spoofing

Ask how an actor, service, device, or message source can be impersonated at every trust boundary and bind mitigations to verifier behavior.

▶Walkthrough: stride-spoofing (not found)

stride-tampering-repudiation — STRIDE: tampering and repudiation

Integrity and accountability are separate: prevent or detect unauthorized modification and retain trustworthy evidence for disputed security-relevant actions.

▶Walkthrough: stride-tampering-repudiation (not found)

stride-disclosure — STRIDE: information disclosure

Trace sensitive data through process memory, logs, stores, backups, networks, errors, and third parties rather than checking only the primary database.

▶Walkthrough: stride-disclosure (not found)

stride-dos-elevation — STRIDE: denial of service and elevation of privilege

Availability budgets and privilege boundaries are explicit; a valid account or internal network path does not justify unlimited resources or higher authority.

▶Walkthrough: stride-dos-elevation (not found)

linddun-privacy — LINDDUN privacy threat elicitation

Privacy analysis examines Linking, Identifying, Non-repudiation, Detecting, Disclosure, Unawareness, and Non-compliance across data interactions.

▶Walkthrough: linddun-privacy (not found)

risk-response — Prioritize and respond to concrete threats

STRIDE and LINDDUN elicit threats; likelihood, impact, exposure, business context, and evidence rank them. Each threat is mitigated, eliminated, transferred, or explicitly accepted.

▶Walkthrough: risk-response (not found)

architecture-change — Revisit the model when the system changes

New data, dependencies, trust boundaries, identity flows, or failure modes invalidate prior assumptions and trigger focused re-analysis.

▶Walkthrough: architecture-change (not found)

Operational and failure rules

• Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
• Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
• Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
• Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.

Related concepts

[CONCEPT]owasp-top-10 [CONCEPT]zero-trust [CONCEPT]supply-chain-security [CONCEPT]data-encryption

Authoritative sources

1. Microsoft Threat Modeling Tool: STRIDE threats
2. OWASP Threat Modeling Cheat Sheet
3. LINDDUN Privacy Threat Categories
4. LINDDUN PRO method instructions