Home / Knowledge hub / Threat model
Knowledge hub
Threat model
Asking what is worth taking, who wants it, and how they would try.
What it means
A threat model is a short exercise built on three questions. What do we hold that is worth taking? Who would want it? How would they try?
You do not need a diagram tool or a spare week. A whiteboard, the people who know how the system really works, and an hour of honest answers deliver most of the value. OWASP frames the same idea as four questions, the last one asking whether you did a good enough job.
Why it matters
An hour of this early changes what you build, not only what you find later. It surfaces the feature nobody thought of as sensitive. It exposes the assumption every person in the room made differently.
It also gives you grounds to say no. When every control looks worth having, a model tells you which ones guard the thing you actually care about. And it costs nothing but attention. No licence, no tooling, and the people you need already work for you.
How it shows up
Run one when the system changes shape. A new integration, a first enterprise customer, a payments flow, a public API. Those are the moments when old assumptions quietly stop holding.
Keep the output small. One page naming what matters most, who would come for it, the two or three ways in, and what you are doing about each. Invite somebody who did not build the system, because the best questions here are the ones the authors stopped asking years ago. Cyberlop does not run these sessions for you. What it does is check the model against the running software, which is where a penetration test takes over.
Questions people ask
Threat model, answered
Is threat modelling worth it if we have no security team?
Yes, and small teams often get more out of it than large ones. Most published advice assumes a dedicated security function, which makes it read like a list of reasons not to start.
Take one feature, not the whole system. An engineer, a product owner and whoever knows the data best can do useful work in a single session.
How long does a threat modelling session take?
An hour on one service or one feature produces something real. Teams learning the method often split it across a few shorter sessions instead, which gives the ideas time to land.
If a session runs past two hours, the scope was too wide. Narrow it and run a second one.
Who needs to be in the room?
Somebody who knows how the system works. Somebody who knows what the business loses if it breaks. And somebody who did not write the code.
That third person matters more than people expect. They ask the questions the authors stopped asking because the answer once felt obvious.
Do we have to use STRIDE?
No, but a structure helps. STRIDE walks you through spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
It catches categories that free-form discussion tends to skip, particularly repudiation and privilege elevation. Any checklist that keeps the conversation moving beats no checklist.
Does a threat model replace testing?
No. A model tells you where to look and what would hurt. It cannot tell you whether the check you believe exists actually runs.
The two work together. Model first so testing has a target, then test so the model stops being a guess.
Sources
Where this comes from
Related
Terms that sit next to this one
Threat actor
Whoever might attack you, described by capability and motive.
Attack surface
Everything about your application an outsider can touch.
Least privilege
Giving every person and service the minimum access the job requires.
Risk acceptance
Deciding, on the record, to live with a known issue rather than fix it.
Modelled it, now want it checked?
A threat model says where to look. Cyberlop goes and looks, across ten vulnerability classes on one application, and brings back the request that proves each finding. A pilot is $199.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.