Threat modeling

In one line

Threat modelling is a structured argument about what could go wrong, held before you build rather than after you're breached. Four questions: what are we building, what can go wrong, what do we do about it, did we do a good job?

STRIDE

The mnemonic that gives the exercise structure:

	Threat	Health example
S	Spoofing	Someone claims to be a clinician they aren't
T	Tampering	A lab result altered in transit
R	Repudiation	"I never opened that chart" — and you can't prove otherwise
I	Information disclosure	The breach everyone pictures
D	Denial of service	The EHR down during a ward round
E	Elevation of privilege	A clerk gains clinical access

Repudiation is the one that's disproportionately important in health and routinely skipped. It's the whole reason audit logging is a legal instrument here: your defence against "I didn't look at that record" is a log that says otherwise, credibly, months later.

Denial of service is also mis-scored. Teams rate it low — "we'd lose some revenue." In a hospital, downtime is a clinical event: a nurse reconstructing a drug chart from memory. Rate it accordingly.

Trust boundaries — where you draw the line

The useful artefact isn't the threat list; it's the data flow diagram with trust boundaries drawn on it. A boundary is anywhere data crosses from something you control to something you don't:

• Browser → your API.
• Your API → the interface engine.
• The interface engine → the third-party lab system.
• Your app → the cloud vendor's managed service.
• Your database → the analytics warehouse.

Every crossing needs a decision: authenticate, validate, log. The bugs live at the boundaries, and the boundaries you forgot to draw are the ones that get you.

That warehouse arrow deserves particular attention: identifiable health data lands there under weaker controls than the EHR it came from, and almost nobody threat-models the export.

The health threat actor nobody diagrams

Security teams model the external attacker: ransomware, nation states, credential stuffing. All real, and hospitals are heavily targeted.

But the most common actual privacy breach in healthcare is an employee looking at a record they had no business looking at. A neighbour. A colleague. An ex-partner. A celebrity admitted overnight.

That person is not an attacker in any conventional sense. They have a valid login, a legitimate role, and no technical sophistication. Every control in your diagram — TLS, encryption at rest, MFA, firewalls — is irrelevant to them, because they walked in through the front door you built for them.

So a health threat model that only contains an external adversary has modelled the wrong threat. The mitigations for the curious colleague are entirely different: relationship-based access, audit review that someone actually runs, and the visible knowledge that access is logged. Deterrence, not prevention.

Doing it without ceremony

It does not need a tool or a week. Around a whiteboard, for an hour, with the people who know:

1. Draw the data flow. Boxes and arrows. Mark the boundaries.
2. Walk each element through STRIDE. "What if this were spoofed? Tampered with?"
3. Write down what you'll do, and — importantly — what you're accepting. A documented accepted risk with an owner is a decision; an undocumented one is an accident waiting.
4. Revisit when the design changes. A model from two years ago describes a system you no longer have.

When to do it

Before you build. The whole value is being cheap at design time and expensive later — retrofitting a trust boundary into a shipped system costs orders of magnitude more.

And do it again when you add an integration. Every new partner, every new export, every new app is a new boundary — and ISO 27001 will ask you to prove you thought about it, which is the one time the certificate and the reality point the same way.