How do you run a threat modeling exercise?
Short answer
Threat modeling answers four questions: what are we building, what can go wrong, what do we do about it, and did we do a good job. You diagram the system (often a data flow diagram with trust boundaries), enumerate threats with a framework like STRIDE, prioritize by risk, and assign mitigations. PASTA adds a risk- and attacker-centric flavor; attack trees decompose a single goal. Doing it at design time is far cheaper than patching production.
Threat modeling is the practice of finding design flaws before they are built. Interviewers ask about it to see whether you can reason about a system structurally rather than only react to scan output, and whether you know that the cheapest place to fix a security flaw is the whiteboard.
The four questions
A good model answers Adam Shostack's four framing questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job? Everything below is machinery to answer them.
The flow
- Model the system. Draw a data flow diagram — processes, data stores, external entities, data flows — and mark trust boundaries where data crosses from less-trusted to more-trusted zones. Threats cluster on those boundaries.
- Enumerate threats. Apply a framework. STRIDE is the workhorse: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — each mapping to a violated property (authentication, integrity, non-repudiation, confidentiality, availability, authorization).
- Prioritize. Rate threats by likelihood and impact so you spend effort where risk is highest, not on every theoretical issue.
- Mitigate and verify. Assign each accepted threat a control, then confirm it was actually implemented and tested.
Choosing a method
STRIDE is great per-component and per-data-flow. Attack trees decompose a single attacker goal (e.g., "exfiltrate the database") into branches and are excellent for deep analysis of one risk. PASTA is a heavier, seven-stage, risk- and attacker-centric process that ties technical threats to business impact — useful when you need executive buy-in.
What interviewers look for
They want to hear that you start from the design and trust boundaries, that you map STRIDE letters to concrete security properties, and that you keep the model living as the system evolves rather than treating it as a one-time document.
Likely follow-ups
- What does each letter of STRIDE map to, and to which security property?
- When would you choose PASTA or attack trees over STRIDE?
- How do you keep a threat model alive as the architecture changes?