Threat modelling for software teams: STRIDE in one afternoon

Threat modelling sounds like a heavyweight exercise for security specialists. It doesn't have to be. At its core, it is a structured conversation about four questions from the Threat Modeling Manifesto: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job? A software team can answer those well in one afternoon.

Who should be in the room

• One or two engineers who know how the system really works.
• The product owner, who knows what matters to customers.
• Someone who runs the system in production.
• A facilitator, ideally with security experience, who keeps time and asks awkward questions.

Keep it to five or six people. Book three hours and pick a single feature or service, not the whole platform.

Step 1: draw the system (45 minutes)

Sketch a data flow diagram: external entities such as users and third-party services, processes such as APIs and workers, data stores, and the flows between them. Then draw trust boundaries wherever data crosses from one level of trust to another, for example from the internet to your API, or from your app to a payment provider.

Step 2: walk STRIDE (75 minutes)

STRIDE, developed at Microsoft, is a mnemonic for six categories of threat. Walk each element and boundary on the diagram and ask which categories apply.

• Spoofing: can someone pretend to be another user, service or device? Think session handling, API keys, webhook signatures.
• Tampering: can data be modified in transit or at rest? Think unsigned payloads, client-controlled prices, writable storage.
• Repudiation: could someone deny an action because there's no trustworthy record? Think audit logs.
• Information disclosure: can data leak to the wrong party? Think tenant isolation, verbose errors, public buckets.
• Denial of service: can someone exhaust resources or block legitimate use? Think unbounded queries, expensive endpoints.
• Elevation of privilege: can someone gain rights they shouldn't have? Think role checks done only in the UI.

Write each threat as a short sentence: "An attacker with a valid account in tenant A changes the organisation ID in the request and reads tenant B's invoices." Specific threats lead to specific fixes.

Step 3: decide what to do (45 minutes)

For each threat, agree a rough likelihood and impact, then choose a response: mitigate, accept, transfer or eliminate the feature. Note existing controls so you don't duplicate work.

• Mitigations become tickets with owners, in the normal backlog.
• Accepted risks are written down with who accepted them and when to revisit.
• Questions nobody could answer become investigation tasks.

Step 4: check your work (15 minutes)

Ask whether the diagram matched reality, whether any boundary was skipped, and whether the high-priority threats have owners. Save the diagram and threat list somewhere the team will find them next time the feature changes.

Making it a habit

The best threat models are living documents. Revisit the model when you add a new integration, change authentication, or store a new kind of sensitive data. A short refresh during design review is often enough. Over time the team starts asking STRIDE questions instinctively, which is the real goal.

Common pitfalls

• Trying to model the entire product at once and running out of time.
• Producing a beautiful diagram with no actions attached.
• Writing vague threats like "hackers attack the API".
• Leaving it to the security person while engineers watch.