Threat Modelling — Deep Dive

#What Is Threat Modelling?

What is this?Threat modelling is a structured conversation about a system before (or while) it is built: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job? Those four questions come from Adam Shostack's book Threat Modeling: Designing for Security (2014) and are the simplest way to remember the whole method.

Why it mattersDesign flaws are the expensive ones. A missing authorization check in a design becomes a missing check in every endpoint built from it. OWASP lists "Insecure Design" as A06 in its 2025 Top 10. Interviewers use "threat model this system" because it shows in 30 minutes whether you can reason about a system you have never seen, rather than recite vulnerability names.

How it works

#Step 1 — Draw the System

What is this?A data-flow diagram (DFD) shows how data moves, not how code is organised. It has only five shapes, which keeps it fast:

In practiceA file-sharing feature drawn in two minutes:

                 ┆ trust boundary: internet → company
  [User browser] ┆──HTTPS upload──▶ (API service) ──signed PUT──▶ [[S3 bucket: uploads]]
                 ┆                        │                              │
                 ┆                        │ writes row                   │ S3 event
                 ┆                        ▼                              ▼
                 ┆                 [[Postgres: files]]   ┆   (Thumbnail worker) ──▶ [[S3: thumbnails]]
                 ┆                                       ┆ ← boundary: worker parses untrusted files
  [Recipient] ◀──┆──── share link (GET /f/{id}) ─────────┆

The arrows crossing a dashed line are where nearly every serious threat lives. Here: the upload, the share link, and the worker that parses files a stranger chose.

Memory hook

threats live on the arrowsBoxes are what you built; arrows are where something you don't control talks to something you do. If you only have five minutes, list the arrows that cross a trust boundary and ask STRIDE questions about each one.

#Step 2 — Find the Threats with STRIDE

What is this?STRIDE is a checklist of six ways things go wrong, each the opposite of a security property. Its value is that it forces you past the threats you already thought of.

STRIDE per elementNot every letter applies to every shape. Shortcut:

Other lenses worth one sentence each in an interview:

📰

Real incident — Capital One (2019). A web application firewall on EC2 could be tricked into fetching an attacker-supplied URL (SSRF). It fetched the instance metadata service, which returned temporary credentials for the instance's IAM role, and that role could list and read S3 buckets holding about 106 million customer records. On a data-flow diagram this is one arrow, "WAF → metadata service", crossing a boundary nobody drew. Threat modelling asks what each process can reach, not only what it is meant to reach.

#Step 3 — Rank and Decide

What is this?A threat model with 60 equal threats is useless. Rank them, fix the top ones, and write down who accepted the rest.

How it works

Each threat ends in one of four decisions:

In practiceWhat the output looks like in a ticket tracker. This is what interviewers mean by "actionable":

TM-FILESHARE-03  Thumbnail worker parses untrusted images with full S3 access     Risk: HIGH
  Threat (E):  parser RCE → worker IAM role → read/write every bucket
  Control:     worker runs in a sandbox with no network; role limited to
               s3:GetObject on uploads/* and s3:PutObject on thumbnails/*     ← least privilege removes the blast radius
  Test:        integration test asserts AccessDenied on s3://uploads-other-tenant/
  Owner:       platform-team   Due: before GA

🎯

On the job. Threat modelling happens in design reviews, usually from a one-page design doc. The useful questions are almost always the same:

• Where are the trust boundaries?
• Who can call this without logging in?
• What can this process reach if it is fully compromised?
• Where are secrets stored, and who can read them?
• What do we log, and would we notice abuse?
• What happens when a dependency is down: does it fail open or closed?

The best outcome is a design change before code exists, not a list of findings after launch.

#Worked Example — A Cloud Data Pipeline

Partners upload CSV files over SFTP; a Lambda function validates them and loads them into a data warehouse; analysts query it from a BI tool.

[Partner] ──SFTP──▶ (AWS Transfer) ──▶ [[S3 landing]] ──event──▶ (Lambda: validate+load) ──▶ [[Warehouse]] ◀── (BI tool) ◀── [Analyst]
          ┆ boundary 1: internet                     ┆ boundary 2: untrusted file content      ┆ boundary 3: humans querying data

For an AI agent example (prompt injection, tool permissions, MCP servers), see Agentic AI and MCP security.

📰

Real incident — Storm-0558 (2023). Attackers used a Microsoft consumer-account signing key to forge tokens that Exchange Online accepted for enterprise mailboxes, reading email at US government agencies. Two trust domains, consumer and enterprise, were supposed to be separate, but token validation didn't check which domain a key belonged to. The US Cyber Safety Review Board described it as a cascade of avoidable errors. A threat model asking "what stops a consumer key from signing an enterprise token?" is exactly the boundary question that catches this.

#Answering "Threat Model This" in an Interview

What is this?A 30–45 minute exercise: the interviewer names a system ("a URL shortener", "our CI pipeline", "a chatbot with access to customer orders") and watches how you think.

What interviewers listen for

• You ask clarifying questions instead of assuming.
• You name trust boundaries, not just components.
• You rank, and say why the top threat is the top threat.
• You include detection and response, not only prevention.
• You use concrete controls ("scope the role to s3:GetObject on one prefix"), not slogans ("use least privilege").