Threat modeling workshops for teams — Ops Runbook — Practical Guide (Oct 10, 2025)

Threat modeling workshops for teams — Ops Runbook

body { font-family: Arial, sans-serif; line-height: 1.5; max-width: 900px; margin: auto; padding: 1rem; }
h2, h3 { colour: #0B3D91; }
pre { background: #f5f5f5; padding: 1em; overflow-x: auto; border-left: 4px solid #0B3D91; }
.audience { font-weight: 600; font-style: italic; color: #555; }
.social { margin-top: 2em; font-style: italic; }

Threat modeling workshops for teams — Ops Runbook

Level: Intermediate

Date: October 10, 2025

Introduction

Threat modelling is a critical activity in contemporary software engineering that helps teams anticipate, identify, and mitigate security risks early in the development lifecycle. Running effective threat modelling workshops can boost a team’s security awareness, foster cross-functional collaboration, and improve design decisions. This Ops Runbook covers a practical, hands-on approach to conducting threat modelling workshops with engineering and operations teams as of late 2025. While many threat modelling frameworks and tools exist, this guide emphasises a process that suits modern cloud-native architectures and scalable systems, with references to relevant tools and methods.

Prerequisites

Before running a threat modelling workshop, ensure the following prerequisites are met:

Team composition: Include representatives from development, security, operations, QA, and architecture teams.
Architecture overview: Up-to-date system diagrams (preferably both data flow and component views). The diagrams should capture services, trust boundaries, data flows, and external dependencies.
Familiarity with basic security concepts: Participants should know standard attack surfaces like injection, authentication, authorisation, sensitive data exposure, and denial of service.
Workshop tools: A digital whiteboard (such as Miro, MURAL, or Microsoft Whiteboard), threat modelling tools (like Microsoft Threat Modelling Tool, OWASP Threat Dragon, or Alpine Security), and collaboration platforms (Slack, Teams).
Framework selection: Decide which threat modelling approach to apply. Common frameworks include STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) or PASTA (Process for Attack Simulation and Threat Analysis). STRIDE is popular for beginners and intermediate teams; PASTA suits complex threat profiles.

Hands-on Steps

Step 1: Define the scope

Clarify exactly what system, service, or feature to model. Avoid overbroad scopes—for example, “the user authentication service” or “payment microservice.” Limit scope to manageable boundaries, ideally aligning with a single logical trust area or service.

Step 2: Prepare architecture diagrams

Use or create diagrams describing components, data stores, trust boundaries, user roles, and external actors. Annotate data flows clearly. If your team’s documentation is outdated, update these diagrams collaboratively before the session.

Step 3: Identify assets and entry points

Brainstorm with the team to identify what valuable assets exist (data, APIs, reputation, operational state) and points where an attacker could enter the system.

Step 4: Apply threat categories

Use STRIDE or your selected framework to systematically identify threats for each component and data flow. The goal is to enumerate how an attacker might exploit, compromise, or disrupt the system.

Example: STRIDE applied to a login flow

Component: Login API

- Spoofing: Could an attacker impersonate a user or system?
- Tampering: Can parameters be modified to bypass controls?
- Repudiation: Is logging sufficient to prove actions?
- Information Disclosure: Is sensitive data (password, tokens) exposed in transit?
- Denial of Service: Could the login endpoint be flooded?
- Elevation of Privilege: Are there bugs allowing privilege escalation?

Step 5: Prioritise threats

Use risk assessment criteria such as impact, likelihood, exploitability, and existing mitigations. Collaborate to prioritise threats for mitigation in upcoming sprints or security initiatives.

Step 6: Define mitigation actions

For each high-priority threat, determine specific mitigations. For example, enforce multi-factor authentication to prevent spoofing, implement rate limits to combat DoS, or use strong cryptographic measures to reduce data disclosure risk.

Step 7: Document and track

Record the sessions’ outcomes in a shared document or ticketing system. It’s essential that these risk items become part of the team’s backlog or risk register for visibility and accountability.

Common Pitfalls

Too broad or vague scope: Workshops become inefficient if trying to cover an entire system at once. Focus on meaningful slices.
Insufficient preparation: Outdated or missing diagrams limit understanding and reduce participation quality.
Overemphasising theory: Avoid overly academic discussions—focus on actionable, realistic threats relevant to your system and team context.
Ignoring operational input: Ops teams’ insights on incident patterns, capacity limits, or external dependencies are often overlooked.
Failing to prioritise: Without clear prioritisation, teams may feel overwhelmed and deprioritise remediation.
No follow-up: Threat modelling must feed back into planning and development workflows to be meaningful.

Validation

To validate the effectiveness of your threat modelling workshop:

Review outputs: Ensure threat lists are comprehensive and actionable by peer or security champions.
Integrate with security testing: Correlate identified threats with dynamic/static analysis findings or penetration test results.
Follow up on mitigations: Track whether mitigation actions are implemented as planned within the team’s development cycle.
Conduct retrospectives: After the session, gather feedback on the process, tools, and cross-team collaboration to improve next workshops.

Checklist / TL;DR

Assemble a cross-functional team including dev, security, ops, QA.
Prepare current, clear architecture diagrams with data flows and trust boundaries.
Define a narrow, manageable scope per workshop.
Choose a framework (e.g., STRIDE for most scenarios) aligned with team expertise.
Identify assets, entry points, and apply threat categories systematically.
Prioritise threats using agreed risk criteria.
Define specific mitigations and map ownership.
Document findings; integrate into risk registers or sprint backlogs.
Validate by linking to security tests and tracking mitigation progress.
Iterate workshop format based on team feedback and evolving architectures.

References

Microsoft Threat Modelling Tool documentation – Official guidance on tool and STRIDE methodology.
OWASP Threat Dragon – Open source threat modelling tool for collaborative workshops.
OWASP Top Ten – Common web application risks referenced in threat assessments.
NIST SP 800-154 – Guide to Threat Modelling – Comprehensive official US government guide on threat modelling approaches.
PASTA Methodology – Detailed process framework for advanced threat modelling.
Google Cloud Threat Modelling – Guidance tailored for modern cloud-native applications.