In lesson 4.8.1 you wrote down for every connection of the Kladde how it is checked. That answers the question "What do we do?". A threat model asks the question before it: What can go wrong? It goes through every element of the system, asks about every kind of attack, estimates how bad it would be, and records what has been done about it or still has to be done.
At the end of this lesson docs/threat-model.md is in the Kladde, with at least fifteen threats, a tool that checks its form, issues for
the open countermeasures, and three countermeasures that are already in the code and tested.
Four questions
A threat model answers four questions, in this order:
- What are we working on? A picture of the system, precise enough to talk about: the data flow diagram.
- What can go wrong? The threats, found systematically with STRIDE.
- What are we going to do about it? For each threat a countermeasure or a reasoned decision to accept it.
- Did we do a good job? A review of the model and tests that prove the countermeasures work.
Microsoft makes threat modeling a fixed part of its Security Development Lifecycle (SDL), and does so in the design phase: A flaw in the design is cheap to fix there and expensive after shipping. For you as an architect that means: The threat model is not written once at the end, it grows with every design.