Threat Modeling Workflows

STRIDE gave you a checklist, and attack surface mapping gave you a map. On their own they are one-off exercises. A threat modelling workflow turns them into a habit the Tiffin team runs for every significant feature, early enough that the answer can still change the design.

The rule

What are we building, what can go wrong, what will we do, did it work?

These four questions are the heart of almost every threat modelling method:

1. What are we building? Draw a simple data flow diagram: users, processes, data stores and the arrows between them. Mark the trust boundaries, the lines where data moves between zones of different trust, such as internet to API or pipeline to production.
2. What can go wrong? Walk each element and boundary with STRIDE.
3. What will we do about it? For each threat: mitigate, remove the feature, transfer the risk, or consciously accept it. Write the decision down.
4. Did we do a good job? Check that the mitigations were built and tested, and that the model still matches reality.

When: in design, before most code exists, and again when the design changes in a way that matters: new data, new integration, new trust boundary. Who: the people building the feature, plus someone with security experience as a guide, not a gatekeeper.

PASTA (Process for Attack Simulation and Threat Analysis) is a heavier, seven-stage method that starts from business objectives and ends with risk analysis. It suits high-stakes systems; most feature work does well with the lighter four-question loop.

In DevSecOps, the model lives with the code and flows into the pipeline:

The shortcut

Every threat must end as a ticket, a test, or a written acceptance. Anything else is a conversation that will be forgotten.

Drills

Answer fast — trust the rule.

Remember

• What are we building, what can go wrong, what will we do, did it work?
• Every threat ends as a ticket, a test, or a written acceptance.
• Model in design, revisit on change, and keep the model next to the code.