Module 80: Security Assessment
Threat modelling
🏠The everyday picture
Before a big wedding, the organisers sit down and ask: what could go wrong? Rain, a power cut, gatecrashers, a lost ring. For each, they plan something. Thinking ahead costs an hour; surprises cost the day.
📘What it really is
- Threat modelling is a structured way to ask "what could go wrong?" about a design, ideally before building it (Module 78). Four simple questions:
- What are we building? Draw a data-flow diagram: users, browser, Nginx, API, database, storage, outside services, with arrows for data and dotted lines for trust boundaries (Module 73).
- What can go wrong? Use STRIDE at each element and boundary:
- Spoofing (pretending to be someone) → authentication;
- Tampering (changing data) → integrity checks, permissions;
- Repudiation (denying an action) → audit logs;
- Information disclosure (leaks) → access control, encryption;
- Denial of service (making it unavailable) → limits, redundancy;
- Elevation of privilege (gaining more rights) → authorisation, least privilege.
- What are we going to do about it? A control for each real threat, or a recorded decision to accept it (your risk register, Module 73).
-
Did we do a good job? Check the controls exist and work (tests, reviews).
-
Keep it light: a whiteboard or a page per feature is enough. Repeat for significant changes.
- Free tools: OWASP Threat Dragon, Microsoft Threat Modeling Tool, or simply a diagram and a table.
🖱️Try it
Draw your CRM's data-flow diagram with trust boundaries. Go through STRIDE for the login flow, the customer API and the backup process, writing at least two threats for each with the control (or gap). Add new gaps to your risk register.
✅Quick check
What does STRIDE stand for?
Show the answer
Spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
When is threat modelling most useful?
Show the answer
During design, before building, and again for significant changes.