Part 9 · 2 chapters · ~12 min

Threat Modelling

Four questions (what are we building, what can go wrong, what will we do about it, did we do a good job), data flow diagrams and trust boundaries, STRIDE applied to a transfer API, attack trees, prioritising by risk, and making threat modelling a lightweight habit in design reviews.

17

Four questions

Adam Shostack's four questions
  1. What are we working on? Draw the data flow: actors, processes, data stores, and trust boundaries (where data crosses from less trusted to more trusted).
  2. What can go wrong? Walk each element and boundary with STRIDE.
  3. What are we going to do about it? Mitigate, accept, transfer or avoid each threat, with an owner.
  4. Did we do a good job? Review after building; update when the design changes.
STRIDE, APPLIED TO A TRANSFER API
six threat categories, one question each
Spoofingpretend to be someoneTamperingchange dataRepudiationdeny an actionInformation disclosuresee what you should notDenial of servicestop it workingElevation of privilegedo more than allowed
swipe the figure sideways, or tap expand for full screen
1/6
spoofing
Could someone act as another user or service? Controls: strong authentication, mTLS between services, signed webhooks (Auth course).
identity: authenticationpasskeys, mTLS, signatures
18

A lightweight habit

threat (transfer API)STRIDEmitigationowner
replayed transfer requestTidempotency keys; signed requests with timestampspayments team
user reads another user's transfersIscoped queries, object-level authz testsAPI team
forged processor webhookSHMAC verification, IP allowlist as defence in depthpayments team
staff edits a balance directlyE, Rno direct DB writes; maker-checker adjustments; audit logplatform + finance
credential stuffing on loginS, Drate limits, breached-password checks, passkeysidentity team

Twenty minutes with a diagram in every design review that touches money, identity or personal data catches most of what a formal process would.