Threat modelling sounds heavyweight, but a useful session fits into an afternoon. It is structured around four questions:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
Step 1: Draw what you are building
Sketch a simple data-flow diagram: the people and external systems (actors), your processes, your data stores, and the flows between them. Then draw the trust boundaries: the lines where data crosses between different levels of trust, such as internet to application, application to database, or your system to a third-party API. Most problems cluster on those lines.
Step 2: Ask what can go wrong, using STRIDE
STRIDE is a checklist of six threat types. Walk each element and boundary of your diagram through it.
| Threat | Question | Typical mitigation |
|---|---|---|
| Spoofing | Can someone pretend to be a user or service? | Strong authentication, mutual TLS |
| Tampering | Can data be altered in transit or at rest? | Integrity checks, signing, access control |
| Repudiation | Could someone deny an action, with no proof either way? | Audit logging, tamper-evident logs |
| Information disclosure | Can data leak to someone who should not see it? | Encryption, authorisation, minimisation |
| Denial of service | Can it be made unavailable? | Rate limiting, quotas, redundancy |
| Elevation of privilege | Can someone gain rights they should not have? | Least privilege, input validation |
Step 3: Decide and record
For each credible threat, choose to mitigate, accept, transfer or avoid it. Write the mitigations as backlog items with owners, so they are built and tested like any other work. Rank by likelihood and impact, and do not try to fix everything at once.
Step 4: Keep it alive
Store the diagram and decisions alongside the code. Revisit them whenever the architecture changes, for example when you add a new integration, data store or user role. Later, check that mitigations were actually built and that tests cover them.