Threat modelling a feature
Most security flaws are cheapest to fix before the first line of code. This lesson shows you how to threat-model one feature in about 45 minutes: draw how its data moves, mark where trust changes, walk STRIDE over every piece, and leave the room with ranked tickets that each have an owner and a test.
By the end you can
- Use the four questions of the Threat Modeling Manifesto to structure a session
- Draw a data-flow diagram for a feature and mark its trust boundaries
- Walk STRIDE over each element and flow, and write threats specific enough to fix
- Rate and rank threats with a simple scale, and turn the top ones into tickets with an owner and a test
- Run a 45-minute session with engineers, product and a security champion, and keep the model up to date
The everyday picture
Picture a shop owner who takes the day's cash to the bank. Before she trusts a new courier with the job, she sketches the route on paper: till, back office, courier's bag, van, bank counter. Then she marks every point where the cash leaves one person's hands and enters another's, because that is where things go wrong.
At each handover she asks the same six questions. Could someone pretend to be the courier? Could the bag be swapped on the way? If money goes missing, is there a signed receipt to prove who had it? Could someone on the street see how much is in the bag? What if the road is blocked and the bank closes? Could the courier end up with the key to her safe? She does not need to be a security expert. She needs a drawing, the handovers marked, and a fixed list of questions. Threat modelling a software feature is the same habit.
Four questions, one feature
Threat modelling sounds heavy, but the Threat Modeling Manifesto (written in 2020 by a group of practitioners) boils it down to four questions:
- What are we working on? A diagram of the feature and its data.
- What can go wrong? A list of threats, found with a method such as STRIDE.
- What are we going to do about it? A decision for each threat: fix, reduce, accept or transfer, with tickets for the fixes.
- Did we do a good enough job? A quick review: did we cover every element, are the tickets real, and when do we look again?
Threat-modelling "the whole Partner app" takes weeks and nobody finishes. Threat-modelling one feature, while it is still a design, takes under an hour and changes the design. Our feature is a real request from partner shops: download all invoices as one PDF zip, so that a shop owner like Ravi can send a year of invoices to his accountant in one file.
The proposed design looks normal. The Partner app calls the API. The API puts a job on the job queue, because rendering hundreds of PDFs takes too long for one request (you met this pattern in Queues, background jobs and pub/sub). A PDF worker picks up the job, reads the shop's invoices from Postgres, renders them, zips them, and writes the zip to object storage. The API then hands the app a signed URL, and the phone downloads the zip straight from storage.