Threat modeling

Threat modeling is the structured, systematic identification of potential threats against a system, ideally performed while the system is still being designed. The team decomposes the application (commonly with data flow diagrams), identifies where an attacker could strike each component or trust boundary, rates the threats, and feeds the results back into the architecture. Frameworks give the exercise discipline: STRIDE categorises threats by type, PASTA works through seven risk-centric stages, and attack trees map the paths to an attacker’s goal.

The defining characteristic is that threat modeling is proactive, not reactive. It assumes the defender moves first: threats are anticipated and designed out before code ships, which is far cheaper than remediating the same weakness in production. That framing also sets its scope: threat modeling is an analysis and prioritisation exercise, not a test. It produces a ranked list of what could go wrong and the mitigations, such as enforcing least privilege across trust boundaries, that the design must include.

Exam relevance: if a scenario mentions identifying threats “during design” or “before deployment”, the answer is threat modeling. If it names spoofing, tampering, or elevation of privilege as categories, the answer is STRIDE. The nearest confusable is vulnerability assessment: that examines a built system for known weaknesses, while threat modeling reasons about hypothetical attackers against a design that may not exist yet. Proactive design analysis beats reactive scanning whenever a question offers both.