Security by Design · Part 2 — Threat Modelling as a Design Ritual: The 30-Minute Version That Sticks

This is Part 2 of the Security by Design program — the central technique the whole program is built around. Part 1 prepared the ground: an enabling security team, champions in every delivery team, a security-aware definition of done that already asks for threat modelling, and non-blocking gates so security informs rather than obstructs. Now we fill those rituals with the practice itself. Threat modelling has a deserved reputation for being heavyweight — the multi-day workshop, the specialist facilitator, the enormous diagram nobody updates — and that reputation is exactly why it so often fails to take hold. This part is about the opposite: threat modelling small enough to run in thirty minutes, simple enough for a delivery team to lead without a security PhD, and frequent enough to keep pace with a design that changes every sprint. Done this way, it is the highest-leverage security activity a team can perform, because it catches the expensive class of flaw — the design flaw — at the one moment it is cheap to fix, before a line of code is written.

The reason threat modelling is the spine of this program bears repeating: it is what makes everything downstream specific. A pipeline scanner (Part 3) checks for generic problems; a threat model tells you which problems this system actually has. Cloud guardrails (Part 4) enforce a baseline; a threat model tells you which service holds the data worth protecting. The ranked list of "what can go wrong here" that a threat model produces is the input that turns a generic security program into a proportionate one — effort spent where your real risk is. Master this ritual and the rest of the program has something to aim at.

Scope of this phase

Every part of this program is scope-bounded so you know exactly when you are done.

• In scope: the threat-modelling method itself — the four-question framework, data-flow diagrams right-sized for a whiteboard, STRIDE as a lightweight prompt, and how to rank and record what you find; when to trigger a threat model in the SDLC; and how to keep the practice continuous and developer-owned rather than a one-time specialist event.
• Explicitly out of scope (later parts): turning the threats you find into automated pipeline controls and tests (Part 3); the specifics of threat-modelling cloud architectures and mapping to cloud-native controls (Part 4); and measuring coverage and risk burndown across the organization (Part 5). This part produces ranked threats and mitigation decisions; the later parts operationalize and measure them.
• Definition of done: the exit checklist at the end of this part. When every box is ticked, your teams can run a threat model themselves, at the right moments, and produce a ranked, recorded, actionable set of threats — the raw material Part 3 turns into controls.

The method rests on four questions and a small amount of supporting technique. The questions are the ritual; the technique (diagrams, STRIDE, ranking) just makes answering them faster and more complete. Keep the questions in front and the technique in service of them, and threat modelling stays light.

The four questions

Every useful threat model, however lightweight, answers four questions in order — Adam Shostack's framing, and the most durable thing in the field. Everything else is in service of answering them well.

1. 1What are we building? You cannot find threats in a system you have not described. This is the data-flow diagram: the components, the data stores, the flows between them, and — critically — the trust boundaries where data crosses from less-trusted to more-trusted territory. It does not need to be elaborate; a whiteboard sketch that the team agrees is accurate beats a beautiful diagram that is out of date.
2. 2What can go wrong? With the system described, you enumerate the threats — the ways an adversary (or an accident) could violate a security property. This is where STRIDE earns its place as a prompt, walking you through categories of "wrong" so you do not just imagine the attacks you happen to think of.
3. 3What are we going to do about it? For each threat that matters, a decision: mitigate it (add a control), eliminate it (change the design so the threat cannot exist), transfer it (push the risk elsewhere, e.g. to a managed service), or accept it (consciously, with an owner). Most threats get mitigated; the most valuable ones get eliminated by design, which is the whole payoff of doing this at design time.
4. 4Did we do a good job? A short retrospective: is the diagram accurate, did we cover the important flows, are the mitigations real and are they going to be verified? This is the question that keeps the practice honest and improving, and it is the one teams skip most.

The discipline that keeps this a thirty-minute ritual rather than a two-day workshop is scoping: you threat-model a change or a feature, not the entire system every time. The first model of a new service might take an hour; a model of a new endpoint added to an existing service takes ten minutes because most of the diagram already exists. This is what makes threat modelling continuous — you are always modelling the delta.

Technique 1 — Data-flow diagrams, right-sized

The diagram is the foundation, and the most common failure is making it too detailed. You are not documenting the system; you are creating a shared picture just accurate enough to reason about threats. Four element types are enough: external entities (users, third-party services — things outside your control), processes (your services, functions, the things that act on data), data stores (databases, buckets, queues, caches), and data flows (the arrows between them, labelled with what data moves and how). Over the top you draw trust boundaries — the lines data crosses when it moves between different levels of trust, such as the internet-to-service boundary, the service-to-database boundary, or the boundary between two teams' services. Trust boundaries are where threats concentrate, because they are where an assumption ("this input is safe") meets a reality ("this input came from outside") — so drawing them well is most of the value.

Keep it at the level where the team can hold the whole thing in their heads. A diagram with two hundred boxes is not a threat model; it is a distraction. If a system is genuinely that large, model it in pieces along its trust boundaries — each bounded context or service is its own small model, and the flows between them are modelled at the boundary. A whiteboard photo or a few lines of diagram-as-code checked in next to the service is the right fidelity; the goal is a picture the team will actually keep current, because a threat model of last quarter's architecture protects last quarter's system.

Technique 2 — STRIDE as a lightweight prompt

"What can go wrong?" is hard to answer from a blank page, so you use a prompt. STRIDE is the most useful one: for each element and flow in your diagram, you ask whether it is vulnerable to each of six categories of threat. The value is not the taxonomy for its own sake; it is that walking the six categories forces you past the attacks you would have thought of anyway and into the ones you would have missed.

You do not apply all six to every element mechanically — that way lies tedium and disengagement. The champion (Part 1) leads the team through the diagram element by element, focusing STRIDE where it is likely to bite: spoofing and elevation of privilege at authentication points and trust boundaries, tampering and information disclosure on data flows and stores, denial of service on anything internet-facing, repudiation on actions that matter legally or financially. The skill — which teams build quickly with practice and champion support — is knowing where to spend the attention. A team's third threat model is far faster and sharper than its first, which is why building the habit (Part 1's definition of done) matters more than perfecting any single session.

Technique 3 — Ranking and recording what you find

A threat model that produces forty undifferentiated threats is nearly as useless as none, because the team cannot act on forty things and will act on none. So you rank, using two axes that any team can estimate without a risk-quant background: impact (how bad if it happens — trivial to catastrophic) and likelihood (how plausible given the system and its exposure). The product gives you a rough priority, and the point is not precision but triage — separating the handful of threats that deserve a mitigation now from the many that are low-impact, implausible, or already covered by an existing control. Product should be in or near this conversation (Part 1's buy-in), because ranking a threat's impact is partly a business question and prioritizing its mitigation against features is entirely one.

Then you record — lightly. Each threat that survives triage becomes a short, durable note: what the threat is, the decision (mitigate / eliminate / transfer / accept), the specific mitigation, and an owner. This is the artifact that flows into Part 3, where mitigations become pipeline controls and tests. Recording it as structured data next to the code keeps it alive and reviewable, and lets the definition of done ask "did we re-model the changed flows?" meaningfully:

- id: TM-014
  threat: "Attacker forges JWT to impersonate another tenant (Spoofing / Elevation)"
  boundary: internet -> api
  impact: high
  likelihood: medium
  decision: mitigate
  mitigation: "Verify signature with rotated asymmetric key; validate tenant claim server-side"
  owner: team-payments
  verified_by: "test: auth/test_jwt_tenant_isolation"

The verified_by field is the bridge to Part 3: a threat is not truly mitigated until something checks that the mitigation is present and stays present. Recording the intended verification here is what lets the pipeline enforce it later.

When to threat-model: keeping it continuous

The final and most important discipline is timing. A threat model done once, at the start of a project, describes a system that no longer exists six months later. The practice only delivers if it is continuous, triggered by the events that change the risk picture:

• New feature or service with meaningfully new data flows or a new trust boundary — model it at design time, before implementation, when eliminating a threat by design is still free.
• Material change to an existing design — a new integration, a new data store, a change to an authentication or authorization boundary. Model the delta, which is fast because the base diagram exists.
• A trigger in the definition of done (Part 1): "new/changed data flows re-modelled" makes this a normal part of finishing significant work rather than a special event someone has to remember to schedule.
• Periodically for critical systems — a lightweight re-review of the crown-jewel services once or twice a year catches drift the per-change models missed.

The anti-pattern to avoid is the "threat modelling phase" — a gate before a big release where a specialist parachutes in. That is expensive, late, and adversarial, and it is exactly what Part 1's culture work exists to prevent. Continuous, small, developer-owned, triggered by design change: that is the shape that survives. The champion leads, the team participates, security consults on the hard ones, and Product sees the output — and because each session is small and produces a better design, the ritual earns its own place rather than being imposed.

Definition of done — Threat modelling exit checklist

You are ready for Part 3 when every one of these is true:

• Method adopted: teams can run the four-question method themselves, led by their champion, without a central specialist present for routine cases.
• Diagrams: teams produce right-sized data-flow diagrams with trust boundaries marked, at a fidelity they will keep current, stored next to the code.
• STRIDE in use: teams use STRIDE (or an equivalent prompt) to enumerate threats, focused where it bites rather than applied mechanically.
• Ranking: threats are triaged by impact × likelihood, with Product involved in impact and prioritization, so a small set of real threats is separated from the noise.
• Recording: surviving threats are recorded as durable, structured notes with a decision, a specific mitigation, an owner, and an intended verification — the input Part 3 consumes.
• Continuous: threat modelling is triggered by design change (via the definition of done and design reviews), not run as a one-off phase; critical systems get periodic re-review.

Tick every box and your organization has the single most valuable security practice there is, running under its own power inside delivery teams. The threats you are now producing — ranked, recorded, owned — are the raw material for everything downstream. Skip the continuity box in particular and you will have a drawer full of accurate threat models of systems that have since changed beyond recognition.

What's next

Part 3 — Wiring threat models into DevSecOps is where the design activity grows teeth. A ranked, recorded threat with an intended verification is a promise; Part 3 turns it into a running check — a pipeline test that fails the build if the mitigation for TM-014 regresses, a policy that enforces the control the model called for, a scanner rule targeted at the specific weakness you identified. This is the seam with the DevSecOps Program: threat modelling gives the pipeline its priorities (so it checks what matters to your system, not just generic issues), and the pipeline gives threat modelling its enforcement (so a mitigation, once decided, cannot silently disappear). It ships next month.

If you would like experienced hands to launch the threat-modelling ritual — train your champions to facilitate, right-size the method to your teams, and embed it in your design reviews and definition of done — that is exactly what Axelia's consultants do, and ISMShed records your threat models and their mitigations as continuous, framework-mapped evidence across ISO 27001, ENS, NIS2, DORA, SOC 2 and GDPR. Make threat modelling a habit now, and Part 3 has something concrete to enforce.