DFR Lab / Applied Framework

Patient-Side Threat Modeling

Almost every published IoMT threat model is written from the network’s point of view. Mine is written from the patient’s side of the device.

Network-side threat modeling asks what an attacker can reach. Patient-side threat modeling asks what happens to the human when it’s reached. Five lenses, built from 28+ years of frontline emergency medicine, applied to every scenario in this lab.

5
Lenses
12
Scenarios run through them
1
Live intelligence tracker
5
Frameworks mapped

01 — The inversion

Same device. Different question.

In enterprise IT, the triad runs Confidentiality → Integrity → Availability. At the bedside, that order inverts. A ventilator that stops is a code. A ventilator whose data leaks is a HIPAA letter. Standard risk scoring cannot see the difference between those two events. PSTM is built to see it.

Network-side asks: what can an attacker reach?
Patient-side asks: what happens to the human when it’s reached?

Network-side vs. patient-side threat modeling
Network-sidePatient-side
Core questionWhat can an attacker reach?What happens to the human when it’s reached?
Priority orderC → I → AA → I → C on life-sustaining tiers
Unit of riskAsset / nodePatient / procedure
Prioritization driverCVSSLatency to harm
Detection endpointThe SOCThe bedside
Blind spotThe clinical workaroundNone — the workaround is a primary lens

02 — The five lenses

The method.

Each lens is a question the network-side model cannot answer. Run all five against a device, a finding, or a whole environment, and the risk register reorders itself. The order it lands in is the order a patient would choose.

01

Physiological Dependency

Is the patient’s physiology dependent on this device functioning correctly right now?

Why network-side models miss it

An asset inventory sees two nodes running the same OS with the same CVE. It cannot see that one of them is keeping a chest rising and the other is archiving vitals for the morning report. Same score. Not remotely the same risk.

PSTM tiers every device before anything gets scored:

Life-sustainingventilator · pump running vasopressors · pacing Life-supportingdialysis · BiPAP · anesthesia delivery Monitoring / diagnostictelemetry · CGM · imaging Conveniencebed scales · asset tags · smart TVs

From the floor

The same vulnerability disclosure lands on a networked ventilator and on the server that stores its historical trend data. The register scores them identically. On the ventilator, exploitation is a code blue. On the archive, it’s a breach-notification workflow. Any model that can’t separate those two outcomes isn’t modeling healthcare — it’s modeling a data center that happens to contain patients.

What changesOn life-sustaining tiers, availability and integrity outrank confidentiality by orders of magnitude. Most risk registers have it exactly backwards.

02

Latency to Harm

How long from compromise to physiological harm?

Why network-side models miss it

CVSS measures exploitability and impact to the system. It has no axis for how fast a human deteriorates. Two findings with the same score can sit on opposite ends of the only clock that matters at the bedside.

MinutesInfusion pump dose manipulation. Ventilator settings. Pacing parameters.
HoursTelemetry suppression. Alarm rerouting. Lab interface tampering.
DaysEHR record tampering. Imaging integrity. Allergy fields quietly edited.

From the floor

A suppressed telemetry alarm hurts no one at minute one. It hurts someone at hour three, when the rhythm changes and nothing sounds. A deleted allergy field hurts no one for days — until the next admission, the next order, the next push of the wrong drug. Latency isn’t a technicality. It is the response window, and it tells you which findings you fix tonight and which can wait for the change window.

What changesLatency to harm, not CVSS score, drives patch and response prioritization in clinical environments.

03

Bedside Detectability

Would a clinician actually notice?

Why network-side models miss it

Detection engineering ends at the SOC. But a “detected” event in the SOC is not a detected event on the floor. Most IoMT compromise is silent at the point of care: the device keeps displaying what the clinician expects to see, and the clinician has four other patients.

Alarm fatigue makes it worse — it is an attacker’s ally. Clinical staff silence hundreds of alarms per shift because most of them mean nothing. An attacker doesn’t have to hide the alarm. The environment hides it for them.

From the floor

A compromised pump can display the ordered rate while delivering a different one. There is no visual difference at the bedside between a pump that is working and a pump that is lying. The nurse checks the screen — that’s the verification step the workflow allows — and the screen confirms the order. Every control downstream of that glance assumes the glance means something.

What changesDetection engineering for clinical environments must account for the human at the bedside, not just the sensor on the wire.

04

Workaround Pressure

What do clinicians do when the control gets in the way of care?

Why network-side models miss it

Shared logins. Propped doors. A badge taped over the reader. Screens left unlocked because the timeout fires mid-code. Every one of them was invented by a rational person trying to keep a patient alive.

The workaround is the vulnerability. No scanner finds it, no register scores it, and no network-side model can produce this lens — because producing it requires having been the clinician who invented the workaround.

From the floor

I have been the clinician the screen timeout fired on — mid-resuscitation, gloves on, seconds mattering. The next shift, that workstation stays logged in as whoever touched it first. Security calls that an audit finding. The floor calls it Tuesday. Design the control for the code, not the demo, or the floor will redesign it for you.

What changesA control that clinicians route around is a control that does not exist. Controls must survive the bedside, or they aren’t controls.

05

Downtime Survivability

When the system fails, does the manual fallback actually work — and has anyone on shift ever run it?

Why network-side models miss it

The register ends where the outage begins. Paper downtime procedures exist on paper. Most staff hired after 2015 have never executed one — never charted a med pass by hand, never run orders on carbon-copy forms, never worked a floor where the EHR simply is not coming back this shift.

From the floor

Downtime survivability is a set of testable questions. Are the downtime forms in the box current? Does the charge nurse know where the box is? Is the read-only EHR snapshot fresher than 24 hours? Has anyone on nights — the shift ransomware actually hits — run a paper med pass end to end? Every one of those has a yes/no answer. Almost nobody asks.

What changesRansomware resilience in healthcare is a training and process problem at least as much as a technical one. The fallback is testable — so test it.

03 — Worked example · Scenario 03

One scenario. Two priority lists.

Scenario 03 in this lab is an infusion pump compromise on an oncology floor: a networked pump receives unauthorized parameter updates during active chemotherapy delivery, while the nurse covers four other patients. Below are six findings a standard assessment of that environment produces — scored the way a network-side register scores them, then run through the five lenses.

F1Unauthenticated remote code execution in the pump’s legacy remote-management service.CVSS 9.8
F2Drug-library updates accepted unsigned from any host on the clinical VLAN — dose limits and concentrations can be rewritten in transit.CVSS 8.8
F3PHI transmitted in cleartext between the pump gateway and the integration engine.CVSS 7.5
F4Flat clinical VLAN — the pump fleet shares a network segment with non-clinical systems.CVSS 6.5
F5Shared login on the med-room workstation; screen lock disabled by staff.No CVE · unscored
F6Paper downtime medication procedure last exercised 2019; night shift never drilled.No CVE · unscored

Network-side register

Ordered by CVSS

1F19.8 — critical. Remote code execution tops every list it appears on.
2F28.8 — high. Unsigned update channel.
3F37.5 — high. Cleartext PHI in transit.
4F46.5 — medium. Segmentation gap.
F5Not on the register. No CVE to score.
F6Not on the register. Not a technical finding.

Patient-side re-prioritization

Ordered by the five lenses

1F2The finding that reaches the patient.Critical
Life-sustaining tier · latency in minutes · bedside detectability near zero — the pump displays the ordered dose while delivering a different one. Lenses 01 · 02 · 03
2F1Same fleet, louder failure. Exploitation most plausibly crashes the pump: the infusion stops, the alarm sounds, the nurse sees it. Serious — and visible. Lenses 01 · 03
3F6The response to rank 1 or 2 is “pull the fleet.” That plan is only as real as a paper fallback nobody has run since 2019. Lens 05
4F5The audit trail you’d need to investigate F1 or F2 is already gone — when everyone charts as everyone, attribution dies first. Lens 04
5F4The enabler. It widens the path to F1 and F2; on its own it touches no one.
6F3The register’s #3. Real, reportable, worth fixing — and the only finding here where nobody’s physiology changes.

Two of the top four patient-side risks never appeared on the network-side register at all. The register’s number three landed last. Same environment, same findings — a different question. That reordering is the method.

04 — Framework mapping

PSTM does not replace your frameworks. It reorders them by patient consequence.

Every lens lands inside controls that assessors already recognize. That is deliberate: PSTM output drops into an existing GRC program — it re-ranks the register, it doesn’t invent a new one.

Where each lens lands in the standards you already run
PSTM lensNIST CSF 2.0HIPAA Security RuleFDA Pre/PostmarketIEC 62443HHS 405(d) HICP
01 Physiological DependencyID.AM — assets prioritized by criticality§164.308(a)(7)(ii)(E) criticality analysisPremarket: security risk assessment tied to safety risk (ISO 14971)Zone criticality & security-level targets (62443‑3‑2)IT asset management
02 Latency to HarmID.RA — risk analysis; response prioritization§164.308(a)(1)(ii)(A) risk analysisPostmarket: exploitability plus severity of patient harmConsequence-driven risk assessment (62443‑3‑2)Vulnerability management
03 Bedside DetectabilityDE.CM / DE.AE — monitoring & event analysis§164.312(b) audit controlsPremarket: design for detection of security eventsTimely event response & monitoring (SR 6.x)Security operations & incident detection
04 Workaround PressurePR.AA access control; PR.AT training§164.308(a)(5) workforce security & trainingHuman factors & usability engineering guidanceIdentification & authentication (SR 1.x), fit for clinical workflowIdentity & access management
05 Downtime SurvivabilityRS / RC — response & recovery§164.308(a)(7) contingency plan; (ii)(D) testing & revisionPostmarket: response, resilience & recovery expectationsBackup & system recovery (SR 7.3 / 7.4)Data protection & incident response planning

05 — Scenario index

These are not hypotheticals. Each is a Patient-Side Threat Model.

Every scenario in this lab exercises specific lenses. The tags below say which — use them to jump straight to the failure mode you’re accountable for.

DFR Lab scenarios, tagged by PSTM lens
#ScenarioSeverityLenses exercised
S01Silent Battery Failure — portable O₂ concentratorCritical01 Physiological Dependency02 Latency to Harm05 Downtime SurvivabilityOpen →
S02AI Triage Override — emergency departmentCritical03 Bedside Detectability04 Workaround PressureOpen →
S03Infusion Pump Network Compromise — the worked example aboveHigh01 Physiological Dependency02 Latency to Harm03 Bedside DetectabilityOpen →
S04OSINT Recon on Hospital InfrastructureHigh01 Physiological Dependency03 Bedside DetectabilityOpen →
S05Wearable Data Spoofing — athlete & patient, same failureHigh02 Latency to Harm03 Bedside DetectabilityOpen →
S06Ransomware in the ER — the 2am decisionCritical02 Latency to Harm04 Workaround Pressure05 Downtime SurvivabilityOpen →
S07CPAP Firmware Vulnerability — connected home therapyCritical01 Physiological Dependency02 Latency to Harm03 Bedside DetectabilityOpen →
S08Dementia Home Health Failure Chain — a patient who cannot self-advocateCritical01 Physiological Dependency03 Bedside Detectability05 Downtime SurvivabilityOpen →
S09CGM Signal Compromise — dosing on manipulated dataCritical01 Physiological Dependency02 Latency to Harm03 Bedside DetectabilityOpen →
S10AI Symptom Checker, Steered — indirect prompt injection downgrades an emergencyCritical02 Latency to Harm03 Bedside DetectabilityOpen →
S11System Prompt Leakage — a clinical assistant gives up its guardrailsCritical02 Latency to Harm03 Bedside DetectabilityOpen →
S12Over-Permissioned Scheduling Agent — harm at machine speedCritical02 Latency to Harm05 Downtime SurvivabilityOpen →
Healthcare Ransomware Intelligence Tracker — PSTM applied at population scaleLive02 Latency to Harm05 Downtime SurvivabilityOpen →

06 — Put it to work

Bring Patient-Side Threat Modeling to your team.

Four ways in: a Patient-Side Threat Assessment of your connected-device environment, a Clinical Ransomware Tabletop with scenarios that survive contact with clinicians in the room, Healthcare GRC & Audit Readiness mapped to clinical workflow, or standing Advisory & Expert Engagement. No rate card on a webpage. Book the call.

Speaking, media, or expert-network inquiries: connect@chaundacdallas.com