How do you run a threat modeling session?

Direct answer

What a strong answer covers

How it works

A threat modelling session answers four questions: what are we building, what can go wrong, what will we do about it, and did we do a good enough job. It starts with scope and the assets worth protecting, then a data-flow diagram that shows components, data stores, external entities, and the trust boundaries between them, because attacks happen at boundaries. For each boundary and flow, the group enumerates threats using a framework such as STRIDE and concrete abuse cases from the attacker’s point of view, ranks them by likelihood and impact, chooses preventive and detective controls, and records each threat with an owner and a way to verify the control exists. The model is revisited when the architecture changes.

Example

Modelling a new file-sharing feature, the diagram showed uploads crossing from the browser to an API to object storage and a virus scanner. Threats included malicious file execution, path traversal in filenames, unauthorised access to another tenant’s files through guessable IDs, and denial of service through huge uploads. Controls: content-type validation and sandboxed scanning, generated object keys, per-tenant authorisation on every download, and a size limit at the load balancer, each with a test in CI and an owner.

Common mistakes

• Running the session without a diagram and enumerating threats from memory.
• Producing a list of threats with no controls, owners, or verification.
• Modelling once at launch and never revisiting after major changes.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.