threat-modeling

Topics in the source

• Threat modeling
• 1. Draw the system and mark the trust boundaries
• 2. Name the attackers and what they want
• 3. Walk each element with a prompt list
• 4. Prioritise by reachability and impact
• 5. Prefer structural mitigations
• 6. Write it down briefly, and revisit it
• Report

Threat modeling asks what could go wrong here while the answer is still cheap to act on. Code review finds the bug you wrote; threat modeling finds the defence you never designed. Four questions structure the whole exercise: 1. What are we building? 2. What can go wrong? 3. What are we going to do about it? 4. Did we do a good enough job? The output is a short list of decisions, not a risk register nobody reads. You cannot reason about attacks without knowing where untrusted things meet trusted things. Sketch: the components, the data flows between them, the datastores, and — most importantly — the trust boundaries those flows cross. A boundary is anywhere the level of trust changes: internet to your edge, your service to a third party, one tenant's data to another's, user to admin. Keep it to one diagram someone can hold in their head. See diagramming. Done when: every trust boundary in the design is marked. Generic "hackers" produces generic mitigations. Be specific about who and why: An anonymous internet user: the largest population, lowest capability A legitimate user acting maliciously: has valid credentials. Most under-modelled, and the source of most real access-control fai

This is an excerpt. Refer to the complete source and its current requirements.