Threat Modeling at Interview Depth

Four-question frame (Shostack)

1. What are we building?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good job?

Enough for system design — no 50-page threat model required.

STRIDE (lite)

Threat	Meaning	Example
Spoofing	Fake identity	Stolen JWT
Tampering	Alter data	Modified request body
Repudiation	Deny action	No audit log
Info disclosure	Leak data	Verbose error with stack trace
DoS	Deny availability	Expensive regex on hot path
Elevation	Gain more privilege	IDOR on admin endpoint

Map one mitigation per category in design reviews.

Trust boundaries

Draw boxes:

• Internet → API gateway (authenticate)
• Gateway → service mesh (mTLS, service identity)
• Service → database (authZ, parameterized queries)
• Service → S3 (IAM role, presigned scope)

Attacker crosses boundary → controls at that edge.

Attacker personas (interview)

• Anonymous external — public API abuse
• Authenticated user — IDOR, horizontal privilege escalation
• Compromised service account — lateral movement
• Malicious insider — audit, least privilege

Don't threat-model nation-states unless role is security-focused.

System design security thread

When moderator asks "secure this?":

1. AuthN — how users/services prove identity
2. AuthZ — who can do what on which resource
3. Data — encryption in transit (TLS — Networking) and at rest
4. Audit — who did what, tamper-evident logs
5. Abuse — rate limits, input size caps

2–3 minutes each; defer mesh/KMS details to "platform provides X."

Common mistakes

• "HTTPS so we're secure" — transport only
• "We use OAuth" — without scopes and token validation detail
• Ignoring internal threats — east-west auth matters at scale

Cross-reference: Microservices → API Gateway for edge auth; Communication → REST for Problem Details without leaking internals.