System Design Cases
Threat Modeling: STRIDE & LINDDUN
Threat modeling concept page (STRIDE methodology). DFD with trust boundaries (Internet -> DMZ -> App tier -> Data tier). Three scenarios: STRIDE walkthrough on login flow (Spoofing/Tampering/Repudiation/Information disclosure/DoS/Elevation), STRIDE on file upload feature, LINDDUN privacy threat model for GDPR PII flow. Includes ADR on lightweight vs formal SDLC threat modeling.
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.
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.
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.
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.
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.
linddun-privacy — LINDDUN privacy threat elicitation
Privacy analysis examines Linking, Identifying, Non-repudiation, Detecting, Disclosure, Unawareness, and Non-compliance across data interactions.
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.
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.
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.