Threat Modeling Workshop

Threat modeling is a structured conversation about what can go wrong with a system and what you will do about it. It works best early, when changes are cheap, and when developers, testers and a security partner join the same session. This guide describes a ninety minute workshop built on a data flow diagram and the STRIDE categories.

Learning goals

Build a data flow diagram that shows trust boundaries
Apply STRIDE to find threats systematically
Rank threats by impact and likelihood
Turn the top threats into tracked work items

Step-by-step procedure

Frame the scope in one sentence, for example the new file upload feature and the services it touches.
Draw the data flow diagram: external actors, processes, data stores and the flows between them. Keep it to one page.
Draw dashed lines for trust boundaries, such as the internet to your edge, or your service to a third party.
Walk each flow that crosses a boundary and ask the six STRIDE questions: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
Write each threat as a sentence: an attacker can do X by exploiting Y, causing Z.
Score every threat as high, medium or low for impact and likelihood. Do not argue over precision.
Pick a response for each high item: mitigate, accept, transfer or avoid. Name the owner.
Capture decisions in the repository next to the design document so they survive staff changes.

Worked example

Consider a profile photo upload. The browser sends an image to an API, which stores it in object storage and queues a thumbnail job. At the internet boundary the group asks about spoofing and finds that upload tokens are long lived and reusable. At the storage boundary they ask about tampering and find that the thumbnail worker trusts file names supplied by the client, which allows path manipulation. For information disclosure they notice that storage URLs are guessable. For denial of service they note that no size limit exists. Ranking puts the file name issue and guessable URLs at high. The mitigations are to generate server side names, issue short lived signed URLs, enforce size limits at the gateway and scan content types. Each becomes a ticket with an owner and a due date.

Exercises and templates

Model an existing feature in your product and list at least eight threats.
Pick one threat and write a test that would detect a regression.
Compare your list with a colleague and note the categories each of you missed.

Template:

Threat: An attacker can guess object URLs and read other users photos
Category: Information disclosure
Impact: High  Likelihood: Medium
Response: Mitigate with signed URLs, expiry 5 minutes
Owner: Platform team

Common pitfalls

Drawing diagrams so detailed that the session ends before any threats are found.
Listing threats without owners, which turns the output into a report nobody acts on.
Running the session once and never revisiting it when the design changes.
Excluding developers, who know the real behaviour of the code and often spot issues the diagram hides.

Follow-up and continuous improvement

Keep the model in version control next to the design. When a pull request changes a trust boundary, such as adding a new third party or a public endpoint, update the diagram and ask whether new threats appear. Track the number of high threats closed each quarter. Over time you will notice that the team starts raising threats during design, which is the real goal of the practice.

Adapting this to your team

Treat everything above as a starting point rather than a rulebook. Smaller teams can compress the sessions and merge roles, while larger organizations may need written templates, a shared calendar and a named owner for the practice. Begin with one pilot on a real project, collect honest feedback from participants, and adjust the format before you roll it out more widely. Consistency matters more than perfection, so favour a simple routine you will actually repeat.

Key takeaways

Diagrams drive the conversation, so keep them simple and visible
Trust boundaries are where most threats live
A threat sentence names the attacker action and the consequence
Unowned mitigations are not mitigations