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.
“This feels insecure” is a weak argument in an architecture review: you can neither verify it nor close it. Threat modeling exists precisely to turn vague worries about security and data privacy into concrete threats, each with an owner, a control, and a deadline.
The chapter runs from assets and data-flow diagrams to trust boundaries, STRIDE and LINDDUN categories, a threat register, risk prioritization, and a backlog of controls. Without a diagram and trust boundaries, threat analysis quickly slides into listing scary words with no tie to the actual system.
When to use STRIDE, LINDDUN, or both
STRIDE: security threats
Reach for it when integrity, availability, and access control are at stake: spoofing, tampering, privilege escalation, denial of service, and forged operations. It is a strong attacker lens, but it says almost nothing about what the system does with data legally.
LINDDUN: data privacy risks
This lens looks where STRIDE does not: linkability, deanonymization, personal-data disclosure, user awareness, and policy non-compliance. Here the problem is not a breach but that the system simply knows too much about the user.
STRIDE + LINDDUN: digital products with PII
In a product that both stores sensitive data and moves money, one lens leaves a blind spot. Pairing the two methods covers security threats and personal-data privacy risks together — at the cost of a longer analysis session.
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 and filing the report — by the time an incident hits, the architecture has already changed.
Stopping at STRIDE and never touching data privacy risks — in a product with PII, the leak arrives from exactly that blind spot.
Listing threats but leaving them without owners or deadlines: a list like that gets read, nodded at, and never closed.
Adding new integrations and data flows while the threat model stays the same — so it describes a system that no longer exists.
Recommendations
Put threat modeling into the Definition of Ready for major architecture changes — then the analysis happens before the code, not after the incident.
Make the first session a simple data-flow diagram and a couple of threats on the key flow; trying to cover the whole system at once usually ends in nothing.
Every high-risk threat needs a concrete control and a CI/CD check — otherwise there is nothing to prove the threat was closed.
Where both security and data privacy matter, run STRIDE and LINDDUN together — a single lens is guaranteed to leave a gap.
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) - removes a large share of STRIDE risks: without clean identity flows and permission checks, spoofing and privilege escalation stay open.
- 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.