Applied · Module 1
Threat modelling as design
Security improves fastest when I can answer one question clearly.
Previously
Start with Applied Cybersecurity
Think like attackers and defenders with threat modelling, web auth flows, common vulns, logs, and risk trade-offs.
This module
Threat modelling as design
Security improves fastest when I can answer one question clearly.
Next
Identity and access control
Authentication answers who you are.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
A threat model is a simple story about risk.
What you will be able to do
- 1 Explain what a threat model is and what it is for
- 2 Identify assets, entry points, and trust boundaries in a small system
- 3 Write one abuse case and map one preventive and one detective control
Before you begin
- Foundations-level vocabulary and concepts
- Confidence with basic diagrams and section terminology
Common ways people get this wrong
- Threat list without controls. A model that ends at threats is unfinished work. The output is control choices and evidence.
- Generic threats. If everything is a threat, nothing is. Tie threats to assets and entry points.
Main idea at a glance
Diagram
Threat Model Architecture - Trust Boundaries and Attack Surfaces
`flowchart LR
subgraph Internet["Internet"]
User["User"]
Attacker["Attacker"]
end
subgraph Edge["Edge / DMZ"]
WAF["WAF"]
LB["Load balancer"]
end
subgraph App["Application"]
Web["Web app"]
API["API"]
end
subgraph Data["Data"]
DB[(Database)]
Cache["Cache"]
end
User -->|"HTTPS"| WAF
Attacker -->|"Probes / malicious input"| WAF
WAF -->|"Filtered"| LB
LB --> Web
Web -->|"Session / token"| API
API -->|"Queries"| DB
API --> Cache
classDef node fill:#ffffff,stroke:#94a3b8,color:#0f172a;
class User,Attacker,WAF,LB,Web,API,DB,Cache node;
style Internet fill:#fff7ed,stroke:#fed7aa;
style Edge fill:#eef2ff,stroke:#c7d2fe;
style App fill:#f5f3ff,stroke:#ddd6fe;
style Data fill:#ecfdf5,stroke:#a7f3d0;
`Threat Model Architecture - Trust Boundaries and Attack Surfaces
A threat model is a simple story about risk. I list each asset. I name the threat. I map attack surface and the trust boundary. This keeps me focused on reality instead of memorising exotic exploits.
In simple terms, threat modelling is how I decide what to worry about first. It is not a perfect prediction. It is a structured way to turn "security feels scary" into "these three controls will reduce harm most for this system."
In the real world, a cyber person does not sit around naming movie villains. We sit with engineers, product, and sometimes ops, and we ask annoying questions. Where does data enter, where does it leave, who can change it, and what happens if it is wrong. We then write down the assumptions and test them.
How it fails. Teams either go too broad (a huge diagram nobody reads) or too narrow (only listing SQL injection because it is familiar). Another failure is skipping the human actors. Support staff, vendors, and internal admins are where many realistic attack paths live.
How to do it well. Keep scope small, tie each threat to an entry point, and tie each entry point to a control you can actually implement or measure. Accept trade offs. If a control adds friction, decide where that friction is worth it and where it will be bypassed.
Diagram
STRIDE Threat Categories
`flowchart TB
direction LR
subgraph STRIDE["STRIDE categories"]
S["Spoofing\\nPretending to be someone else"]
T["Tampering\\nUnauthorised modification"]
R["Repudiation\\nDisputing actions taken"]
I["Information disclosure\\nExposing sensitive data"]
D["Denial of service\\nMaking service unavailable"]
E["Elevation of privilege\\nGaining higher access"]
end
subgraph Controls["Example controls"]
C1["Authentication"]
C2["Integrity checks"]
C3["Audit logging"]
C4["Encryption"]
C5["Rate limiting"]
C6["Authorisation"]
end
S --> C1
T --> C2
R --> C3
I --> C4
D --> C5
E --> C6
classDef node fill:#ffffff,stroke:#94a3b8,color:#0f172a;
class S,T,R,I,D,E,C1,C2,C3,C4,C5,C6 node;
style STRIDE fill:#f8fafc,stroke:#cbd5e1;
style Controls fill:#f8fafc,stroke:#cbd5e1;
`STRIDE Threat Categories
Before you use the tool, the goal is not to produce a pretty canvas. The goal is to spot one or two high leverage failures. When you fill it in, focus on what would actually hurt and what someone could realistically do with the access they have.
After you use the tool, sanity check your output. Do your threats connect to real entry points, or did you drift into generic fear. Also check whether your controls are specific. "Be secure" is not a control. "Require MFA for staff logins and alert on new device sign in" is closer to a control.
Mental model
Threat modelling is design
Threat modelling is how you choose where to spend effort before the incident chooses for you.
-
1
Assets
-
2
Actors
-
3
Entry points
-
4
Abuse paths
-
5
Controls
Assumptions to keep in mind
- Scope is explicit. If scope is fuzzy, the model becomes a list of fears. Define the system and the boundary first.
- We can name abuse paths. Write abuse as verbs: steal, tamper, disrupt. It keeps the model concrete.
Failure modes to notice
- Threat list without controls. A model that ends at threats is unfinished work. The output is control choices and evidence.
- Generic threats. If everything is a threat, nothing is. Tie threats to assets and entry points.
Key terms
- asset
- something that hurts if stolen, changed, or stopped
- threat
- who or what could cause harm
- attack surface
- every way they can interact with the system
- trust boundary
- places where assumptions change
Check yourself
Quick check. Threat modelling
0 of 6 opened
Why start with assets before attacks
Assets tell you what actually matters, so you focus controls on protecting real value rather than chasing scary stories.
Scenario. A support agent can reset customer passwords after answering two questions. What is the asset and what is the attack surface
The asset is customer accounts and the ability to authenticate. The attack surface includes the support reset process, knowledge questions, agent tooling, and social engineering paths into that process.
What is a trust boundary
A place where assumptions change. Data and actions crossing it must be validated and authorised.
Scenario. You have a mobile app, an API, and an admin console. Which boundary usually deserves the most paranoia first, and why
The admin console and privileged paths, because a small mistake there often has high blast radius. Also the boundary between the public internet and your API entry points.
How do entry points relate to controls
Each entry point should have specific controls. Validation, authentication, authorisation, rate limiting, and logging that supports decisions.
What makes a threat model useful
It changes a decision. It drives a test, a control, or a monitoring requirement. If it only produces a diagram, it is decoration.
Artefact and reflection
Artefact
A simple threat model note that could support a design review
Reflection
Where in your work would explain what a threat model is and what it is for change a decision, and what evidence would make you trust that change?
Optional practice
Pick a small system, list assets, actors and trust boundaries, then note where someone might realistically attack it.