In a world now seemingly filled with mad probability robots you might think this makes the world simpler, I’m not so sure…. More code, faster, more tools, faster, more technical debt, faster… and then what of the erosion of the human importance? Well human 2.0 is probably augmented not redundant… and who doesn’t love a bit of Deus Ex! Now full disclosure this blog is guided by me but written by Claude (mostly), why? Why not? I’m still here, guiding things, writing this intro by hand, but the concepts of cyber security, the foundations and underpinning logic, well they are probably older than me! I’m not talking about castles and moats, but even they play a part in our understanding of attack and defence. There’s even a bit of a public wifi link here if you read between the lines. Not every threat actors is all knowing and all powerful (in fact no one is!). So let’s see what Claude Opus 4.8 has to say about the topic:

You Can’t Defend Everything: Threat Modelling as an Economics Problem

Most security advice starts from the wrong end. It starts with the control — the EDR, the firewall, the awareness training, the shiny new platform with the threat-feed-of-the-week — and then works backwards to invent a justification for it. This is how organisations end up with seven overlapping tools, a SIEM that nobody reads, and a board that still can’t answer a simple question: if something goes badly wrong tomorrow, what is it, and how much will it cost us?

Threat modelling is the discipline of refusing to start from the control. It starts from what matters and reasons outward. And the uncomfortable truth at its centre is this: you cannot defend everything, you were never going to be able to, and pretending otherwise is the most expensive mistake in security.

Threat modelling exists because of constraints. If you had infinite money, infinite time, and infinite competent people, you wouldn’t need to model anything — you’d simply buy every control and apply it everywhere. Nobody has that. So the entire exercise is really about allocating finite defensive effort against an effectively infinite attack surface, and being honest about where you’re choosing not to spend. That’s not a regrettable limitation of the process. That is the process.

Here are the five questions that get you there. Treat them as a loop, not a checklist — each answer reshapes the others.

1. What are you defending?

Assets and services.

This is where most threat models quietly die, because most organisations genuinely cannot answer it. Ask a leadership team what their crown jewels are and you’ll get a confident answer that’s wrong, vague, or both. “Our data.” Which data? Where does it live? Who touches it? What breaks the business if it’s gone, leaked, or altered?

Asset and service mapping is unglamorous, nobody gets promoted for it, and it is the single highest-leverage thing you can do. You’re not just listing servers. You’re identifying the handful of services and data flows whose compromise actually hurts — the payroll run, the design IP, the customer database, the one legacy box that quietly underpins everything and that nobody is allowed to patch. If you don’t know what you’re protecting, every subsequent decision is guesswork dressed up as strategy.

2. From whom, and from what?

Threat actors.

Now name your opponents — but resist the industry’s favourite cosplay. Not everyone is being targeted by a nation state, and modelling a 30-person manufacturer against the TTPs of an APT with a national budget is a good way to burn money defending against the wrong thing while the actual threat — a commodity ransomware crew walking in through an exposed RDP port — strolls past.

Threat actors vary along two axes that matter: capability and intent. Opportunistic commodity crime will take whatever’s cheap and exposed; it doesn’t care who you are. Organised crime is industrialised, motivated by money, and increasingly patient. Hacktivists want noise and embarrassment. Nation states want access, persistence, and silence. Insiders — malicious or just careless — already have a key to the building. The actor set that’s realistic for you is a function of what you do, what you hold, and who you annoy. Model against the adversaries you’ll actually meet, not the ones that make for an exciting slide.

3. Against what threat vectors?

Threats.

How does the bad day actually start? This is the connective tissue between the actor and your assets — the routes in. Phishing and credential theft. Exposed and unpatched edge services. Supply chain — your software vendors, your managed providers, the npm package three dependencies deep. Misconfigured cloud. The trusted laptop that went to a conference and came back compromised.

The point of enumerating vectors is to stop thinking about threats as abstractions (“ransomware!”) and start thinking about mechanisms (“an unmanaged contractor device with a cached domain credential connecting over a flat network”). Abstractions can’t be defended. Mechanisms can.

4. Who will exploit which weaknesses?

Vulnerabilities.

Here’s where people reach for the CVE list and stop. Don’t. A vulnerability is any weakness an actor can use to turn a vector into a foothold — and most of the ones that get organisations breached aren’t in the NVD. They’re architectural (a flat network with no segmentation), procedural (a joiners-movers-leavers process that never actually disables anyone), human (a finance team trained to act fast on urgent requests), and configurational (the default that nobody changed, the MFA exception that became permanent).

The right question isn’t “which CVEs do we have?” It’s “given that actor, using that vector, against that asset — what’s the weakness they’ll lean on?” Patching matters, but a clean vulnerability scanner and a wide-open identity model is a fast car with no brakes.

5. To achieve what outcome — and how likely is it?

Impact, then risk.

This is the one worth getting precise about, because two ideas get jammed together here and the conflation does real damage.

The outcome is the impact: confidentiality lost, integrity corrupted, availability denied — and downstream of that, financial loss, regulatory penalty, operational disruption, safety consequences, reputational harm. The risk is that impact multiplied by the likelihood of it happening. They are not the same thing, and risk registers fall apart precisely when teams rate everything by impact alone. You end up with a wall of “critical” items, half of which will never occur, while a genuinely probable, moderately damaging event sits unaddressed because it didn’t sound dramatic enough.

Impact tells you what’s at stake. Likelihood tells you whether to care yet. You need both, or you’re not prioritising — you’re just panicking in a structured format.

The part everyone skips: appetite, tolerance, and constraint

Here’s where the five questions earn their keep, and where most threat models stop one step too early.

Once you can see your assets, your realistic adversaries, the vectors and weaknesses, and the risk-weighted outcomes — you still haven’t decided anything. Because the output of threat modelling isn’t a control. It’s a prioritised list of risks, against which someone has to make a decision: treat it, transfer it, tolerate it, or terminate the activity that creates it.

And that decision is governed by three things people love to leave undefined:

• Risk appetite — how much risk the organisation is willing to take in pursuit of its goals. This is a business decision, not a security one. Security informs it; security does not own it. One of the most common failure modes in the field is a security function setting the appetite by default, because the board never articulated one — and then getting blamed either for being a blocker or for missing the thing they were never resourced to cover.
• Risk tolerance — how much deviation from that appetite is acceptable in specific cases before someone has to escalate. Appetite is the strategy; tolerance is the operating band around it.
• Constraints — money, time, headcount, skills, legacy you can’t rip out, regulation you can’t ignore, the contract that says you must keep that ancient system running for another three years. These aren’t excuses. They’re the boundary conditions of the whole problem.

Good security design isn’t the design that eliminates risk. That design doesn’t exist, and chasing it bankrupts you while annoying everyone. Good security design is the one that achieves the right effectiveness to meet the organisation’s risk appetite, within its real constraints, in service of its actual goals.

That’s the whole game. Not maximum security — appropriate security. A defensible, articulated, deliberately-chosen posture, where the risks you’re accepting were accepted on purpose, by someone with the authority to accept them, with their eyes open — rather than absorbed by accident because nobody did the modelling.

A closing caveat

Threat models decay. They’re snapshots of a moving target — your assets change, your adversaries adapt, your constraints shift, and yesterday’s accepted risk becomes today’s incident. The map is not the territory, and a threat model you wrote eighteen months ago and never revisited is closer to a comfort blanket than a control.

So treat it as a living conversation, not a document you produce once to satisfy an auditor and then entomb in SharePoint. Re-baseline. Ask the five questions again. The value was never in the artefact — it was always in the thinking.

Defend what matters. Accept what you must. Be honest about the difference.

Human Summary

I’m kind of laughing, we have gone from using LLMs to summarise things to me now using a human to summarise LLM output.. how odd a world we live in! but always changing, always something new to learn and experience, so it’s anything but dull.

I think Claude did pretty ok with this, you can’t defend against everything, you only have finite resources but also the threats often do as well. Some risks can be accepted without question for most scenarios, having a firewall on the internet without brute force protections, without monitoring, with it’s management interfaces exposed… well that’s probably in the unforgivable bracket when it comes to ‘vulnerabilities’

There’s a good NCSC article on that subject: https://www.ncsc.gov.uk/report/a-method-to-assess-forgivable-vs-unforgivable-vulnerabilities

The key thing is always is, it depends. Thinking about risk is kind of important though, so thinking good, blindly doing computer stuff… normally bad!