A threat model is a data-flow diagram and a list of things that could go wrong at each flow. Here the diagram is data (entities, processes, stores, flows, one trust boundary), drawn in the kit's ink, and the list is played: Vex walks to each flow and asks a STRIDE question; the answer the author wrote appears, red when it is open, green when something stands in the way, and the mitigation is named. Ines watches from the reader's side. A review you can step through instead of a table you read once.
The model is data
nodes: entity, process, store (each with x, y in 0..1); a boundary: { label, x, y, w, h }; flows: { from, to, label, threats: [{ stride: S|T|R|I|D|E, asks, answer, open, mitigation }] }
What this taught us
- The attacker is the best narrator. A threat is a question somebody asks at a flow; drawing the person asking it turns a table row into a scene with a point of view, and the mitigation into the answer they get.
- Open and mitigated are the only two moods a finding needs. Red or green on the card, worried or calm on Ines's face. A severity scale would have been a verdict; the kit's moods carry the status without one.
- The DFD wants its own drawing vocabulary. An entity is a box, a process a circle, a store two lines, a boundary a dashed red rectangle: four shapes, all a prop pack away. This page draws them itself.
- A review is a path through the flows, like a flowchart's. The order the author probes them in is part of the argument (start at the boundary crossing). The data should carry it; this page walks the flows in the order written.
- A model this size fits a panel; a real one will not. Twelve flows need the camera and a "chapter" per boundary. The next step is a threat model as a series of these panels, one boundary each.