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.

It is most valuable performed proactively rather than reactively. Anticipating threats and designing them out before code ships is far cheaper than remediating the same weakness in production, though a model can also be built for a system that already exists, and should be revisited as one evolves. That framing also sets its scope: threat modeling is an analysis exercise, not a test. It produces identified threats and the mitigations, such as enforcing least privilege across trust boundaries, that the design must include. Teams commonly go on to prioritise those threats, but that is a separate step using a separate method: STRIDE categorises what is there without ordering it, and a scoring model such as DREAD is one way of supplying the ranking afterwards.

Exam relevance: a scenario that mentions identifying threats “during design” or “before deployment” is generally pointing at 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. The two answer different questions rather than being interchangeable choices.