Threat modeling is the structured process of identifying potential threats to a system, evaluating their likelihood and impact, and determining countermeasures. It is a proactive exercise: you think about how things could go wrong before they actually do.
The goal is to answer four questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job?
The best time is during the design phase, before writing code. Changing a design is far cheaper than changing an implementation. But threat modeling at any stage provides value. Even modeling an existing production system reveals risks you can address.
Trigger threat modeling for: new systems or services, significant changes to existing systems, addition of new data types or integrations, preparation for security assessments, and after incidents that reveal gaps.
STRIDE per element. Draw a data flow diagram of your system showing processes, data stores, data flows, and trust boundaries. For each element, consider six threat categories: Spoofing (can an attacker pretend to be someone else?), Tampering (can data be modified?), Repudiation (can actions be denied?), Information Disclosure (can data leak?), Denial of Service (can the system be disrupted?), and Elevation of Privilege (can an attacker gain higher access?).
Attack trees. Start with the attacker's goal (e.g., "steal customer data") as the root. Branch into the ways that goal could be achieved. Branch further into the prerequisites for each approach. This produces a visual map of attack paths that you can evaluate and prioritize.
What if analysis. Simply asking "what if" questions: What if the database credentials are leaked? What if the CDN is compromised? What if an insider exfiltrates data? This informal approach is better than no threat modeling at all.
Gather the right people: developers who built the system, architects who designed it, and someone with a security perspective. Time-box to 60 to 90 minutes per session.
Start by whiteboarding the system architecture. Identify trust boundaries (where data crosses between different trust levels). Walk through data flows and apply your chosen methodology at each boundary and component.
Document findings as: threat description, affected component, likelihood (low/medium/high), impact (low/medium/high), and proposed mitigation. Prioritize mitigations and add them to the development backlog.
Trying to model everything at once leads to exhaustion. Focus on the highest-risk components first. Ignoring the human element (social engineering, insider threats) leaves significant gaps. Not following up on findings defeats the purpose. Treat threat model outputs like any other requirement: track them, prioritize them, and verify they are addressed.
The most effective threat modeling programs are lightweight and frequent rather than heavy and rare. A 60-minute session for each significant design change produces better results than an annual comprehensive review that tries to cover everything.