Threat modeling is not about producing a neat spreadsheet. It is about seeing where the system is weak before someone exploits it.
The chapter shows how data-flow diagrams, STRIDE, and LINDDUN turn security and data privacy into a review of concrete flows, entry points, trust boundaries, and controls.
In interviews, it is especially useful because it gives you a clear answer path: asset, flow, threat, control, residual risk instead of a vague discussion about security in general.
Practical value of this chapter
Design in practice
Capture assets, data flows, trust boundaries, and threat categories before architecture decisions become expensive to change.
Decision quality
Validate controls against concrete STRIDE and LINDDUN threats instead of relying on a generic security wish list.
Interview articulation
Frame answers as asset, data flow, threat, control, residual risk. That shows mature architectural reasoning.
Trade-off framing
Make control costs explicit: implementation complexity, latency, operating cost, data privacy, and regulatory constraints.
Context
OWASP Top 10 in the context of System Design
OWASP explains what to protect; STRIDE and LINDDUN help you find threats systematically.
Threat modeling turns security and data privacy from broad concerns into testable architecture decisions.
This chapter moves from assets and data-flow diagrams to trust boundaries, STRIDE and LINDDUN categories, a threat register, risk prioritization, and a backlog of controls.
When to use STRIDE, LINDDUN, or both
STRIDE: security threats
Use it for integrity, availability, and access-control risks: spoofing, tampering, privilege escalation, denial of service, and forged operations.
LINDDUN: data privacy risks
Use it to reason about linkability, deanonymization, personal-data disclosure, user awareness, and policy non-compliance.
STRIDE + LINDDUN: digital products with PII
Combine both methods when business security risks and personal-data privacy risks matter at the same time.
STRIDE: threat categories and architecture controls
SSpoofing
Key question: Who can impersonate a trusted principal?
Threat example: A service account is impersonated to call an internal API.
Controls: MFA, mTLS, signed tokens, device or workload identity.
TTampering
Key question: Where can data be modified without authorization?
Threat example: The request payload is changed between the BFF and the backend service.
Controls: Message signatures, checksums, immutable logs, and strict authorization.
RRepudiation
Key question: Who can deny a performed action?
Threat example: A user disputes a payment, but the system has no provable audit trail.
Controls: Correlated audit logs, timestamps, request IDs, and defensible action history.
IInformation Disclosure
Key question: Which data can leak?
Threat example: PII appears in logs and traces with overly broad access.
Controls: Data classification, masking, encryption, and policy-based access.
DDenial of Service
Key question: What can exhaust or disrupt the service?
Threat example: A public API is overwhelmed by bot traffic without rate limits.
Controls: Rate limits, queues, autoscaling bounds, circuit breakers, and WAF.
EElevation of Privilege
Key question: How can an attacker gain broader permissions?
Threat example: An IDOR path lets a user role reach administrator capabilities.
Controls: Least privilege, hop-by-hop policy checks, permission boundaries, and regular reviews.
LINDDUN: data privacy risks and mitigations
LLinkability
Key question: Can separate user actions be linked together?
Risk example: A single device identifier links user behavior across contexts.
Controls: Pseudonymization, rotating identifiers, and dataset separation.
IIdentifiability
Key question: Can identity be reconstructed from available data?
Risk example: ZIP code, birth date, and gender together re-identify users.
Controls: Data minimization, aggregation, k-anonymity, and differential privacy where useful.
NNon-repudiation
Key question: Does strict proofability conflict with privacy expectations?
Risk example: Detailed operation logs reveal a complete user behavior history.
Controls: Policy-driven retention, scoped audit access, and purpose limitation.
DDetectability
Key question: Can an observer detect user presence or sensitive state?
Risk example: Response timing reveals whether an account exists.
Controls: Constant-time responses, generic error behavior, and traffic padding for sensitive flows.
DDisclosure of Information
Key question: Where can personal data be exposed?
Risk example: A data-export endpoint includes sensitive attributes by default.
Controls: Encryption, redaction, DLP controls, and least-privilege data access.
UUnawareness
Key question: Do users understand what data is collected and why?
Risk example: Telemetry is collected without a clear consent experience.
Controls: Consent UX, contextual notices, and transparent data-use communication.
NNon-compliance
Key question: Do the processes satisfy legal and internal policy requirements?
Risk example: Data is retained beyond the allowed retention period.
Controls: Retention policies, legal-basis tracking, and automated compliance checks.
Threat modeling workflow
1. Define boundaries and architecture context
Mark system boundaries, user types, trusted and untrusted zones, and business assets with the highest risk.
Output: Asset list and trust boundaries.
2. Build a data-flow diagram
Map data flows between the client, API gateway, services, queues, and stores. Mark external dependencies explicitly.
Output: Data-flow diagram with explicit trust boundaries.
3. Run STRIDE on each diagram element
For each process, data store, data flow, and external entity, ask the STRIDE questions and record concrete security threats.
Output: Draft security threat register.
4. Run LINDDUN on PII flows
Evaluate privacy risks and transparency requirements for identifiers, profiles, analytics, and user-level events.
Output: Privacy threat register and compliance gaps.
5. Prioritize threats and assign owners
Score likelihood and impact, choose mitigation or residual-risk acceptance, and assign an owner to each entry.
Output: Prioritized control backlog.
6. Embed controls into the change lifecycle
Connect controls to ADRs, CI/CD checks, observability signals, and incident-response plans.
Output: Implementation plan and acceptance criteria.
Practical example: checkout and user profile
Checkout API
STRIDE: Spoofing: forged customer token; Tampering: modified order amount; Denial of Service: public API flooding.
LINDDUN: Detectability: account existence leaks through different errors; Disclosure: payment PII appears in logs.
Controls: mTLS, signed JWT, idempotency keys, rate limits, masked logs, and consistent error responses.
User Profile Service
STRIDE: Elevation of Privilege: cross-user profile read; Repudiation: no defensible audit trail for updates.
LINDDUN: Linkability: behavioral event correlation; Non-compliance: profile data retained longer than allowed.
Controls: ABAC/ReBAC checks, immutable audit trail, pseudonymous analytics IDs, and retention automation.
Session outputs
- Data-flow diagram with explicit trust boundaries and an external dependency list.
- STRIDE + LINDDUN threat register with severity, owner, and remediation deadline.
- Mandatory control list for architecture and CI/CD integration.
- Security and privacy tests linked to concrete threats.
- Scheduled threat-model review plan for architecture changes.
Typical antipatterns and recommendations
Typical antipatterns
Running threat modeling once before release as a reporting ritual.
Using STRIDE only and ignoring privacy risks in products with PII.
Leaving threats without owners or deadlines, which makes the list non-executable.
Failing to update the threat model after new integrations and data flows appear.
Recommendations
Include threat modeling in Definition of Ready for major architecture changes.
Start with a simple data-flow diagram and short sessions instead of trying to model everything at once.
Map each high-risk threat to a concrete control and a CI/CD check.
Combine STRIDE and LINDDUN when both security and data privacy matter.
Related materials
Related chapters
- OWASP Top 10 in the context of System Design - links identified threats to architecture controls and practical security-backlog prioritization.
- Identification, Authentication and Authorization (AuthN/AuthZ) - addresses key STRIDE risks through robust identity flows and permission checks.
- API Security Patterns - translates the threat model into concrete API controls: validation, abuse prevention, and token or key management.
- Zero Trust: a modern approach to architectural security - extends threat modeling with continuous trust verification and trust-boundary segmentation.
- Data Governance & Compliance - adds governance and regulatory perspective for LINDDUN risks in personal-data handling.