STRIDE-HC Threat Model: [Device name]
Template: replace bracketed text and italicised guidance with device-specific content. Delete unused subsections.
1. Device profile
| Field |
Value |
| Device name and model |
e.g., ExampleMed Volumetric Infusion Pump v3.2 |
| Manufacturer |
e.g., ExampleMed Inc. |
| Device class (FDA / EU MDR) |
e.g., Class II |
| UMDNS / GMDN code |
e.g., 16495 / 35143 |
| MDS² reference |
attach manufacturer disclosure form |
| Archetype |
Archetype 1 (general-purpose-OS legacy) or Archetype 2 (embedded RTOS legacy) |
| Operating system / firmware |
e.g., VxWorks 6.9 (EOL); proprietary firmware v3.2 |
| Networking |
e.g., 100Mbit Ethernet, HL7 v2 over TCP/2575, no TLS |
| Authentication |
e.g., Hardcoded service-mode credential; no per-user login |
| Patching |
Manufacturer no longer issues patches; FDA clearance limits modification |
| Audit logging |
None on device; only at upstream nursing station |
| Physical interfaces |
RS-232 service port; USB-A (firmware update); Bluetooth (paired display) |
| Deployment count |
e.g., 240 units across the facility |
| Clinical use |
Continuous medication infusion; ICU and oncology |
2. STRIDE-HC threat scenarios
For each category, list network-attacker and physical/insider-attacker scenarios. Some categories may have more scenarios than others. Mark each scenario with the archetype it applies to (A1, A2, or both).
S — Spoofing (CAW = 1.2)
Network-attacker scenarios:
- ARP cache poisoning to redirect device traffic (A1, A2)
- Forged HL7 / DICOM messages from spoofed source (A1, A2)
- Rogue device impersonation on shared VLAN (A1, A2)
Physical / insider-attacker scenarios:
- Substituted device with cloned identifier (A1, A2)
- Vendor-impersonation social engineering at device location (A1, A2)
- Cloned RFID/NFC token used for proximity authentication (A1, A2)
Detection methods (Framework V):
- Passive device fingerprinting (network sensor with longitudinal store)
- Badge-correlation analytics
- Network UEBA peer-set anomaly
Compensating controls (Framework I):
- 802.1X port-based access control with MAB allowlist
- Tamper-evident asset tags with serialised identifier
- Vendor-escort policy with badge correlation
T — Tampering (CAW = 1.1)
Network-attacker scenarios:
- Unauthorised firmware push from compromised vendor channel
- Configuration tampering via management interface
- Malicious software via Archetype 1 OS vulnerability (A1)
Physical / insider-attacker scenarios:
- Firmware injection via USB or service port
- Configuration tamper via local console or service-mode PIN
- Physical replacement of removable storage
Detection methods (Framework V):
- File integrity monitoring (network-adjacent for A2)
- Configuration version comparison via management API
- Tamper-evident seal inspection (monthly cadence)
Compensating controls (Framework I):
- Write-protect switches; immutable boot media
- USB port disablement (logical or physical)
- Inline MFA shim (Pattern C) at service port
- Tamper-evident sealing with serialised seals
R — Repudiation (CAW = 0.9)
Network-attacker scenarios:
- Unattributable configuration changes via shared service account
- Untraceable data access via cleartext protocol
Physical / insider-attacker scenarios:
- Service-mode access by unidentified technician
- Bedside changes to therapy parameters by unidentified clinician
- PHI capture by mobile-phone photography
Detection methods (Framework V):
- Network PCAP with retention
- Syslog proxy capturing device-adjacent events
- Physical badge access logs correlated to device location
- UEBA behavioural baseline
Compensating controls (Framework I):
- Network-layer logging pipeline (compensates for absent device logging)
- PAW with individual auth upstream (Pattern A)
- Session recording at MFA shim (Pattern C)
- Badge-to-device correlation analytics
Network-attacker scenarios:
- PHI interception on shared network segment (cleartext HL7 v2, DICOM)
- Memory scraping via OS vulnerability (A1)
- Unprotected data export via management interface
Physical / insider-attacker scenarios:
- PHI display photographed in shared environment
- Bulk PHI export to USB at service port
- Eavesdropping on proximity wireless (BLE / NFC)
Detection methods (Framework V):
- Protocol-aware IDS flagging cleartext PHI
- Display privacy filter audit
- WIDS for proximity wireless
- DLP at network gateway
Compensating controls (Framework I):
- VLAN isolation
- IPSec tunnel encapsulating cleartext
- Display privacy filters
- PHI minimisation at gateway
- Service-port USB disablement
D — Denial of Service (CAW = 1.5)
Network-attacker scenarios:
- Network flooding disrupts real-time monitoring
- Targeted protocol-parser crash (URGENT/11-class)
- Resource exhaustion via malformed messages
Physical / insider-attacker scenarios:
- Power or network cable disconnection at device location
- Physical destruction or theft
- Service-mode reset rendering device unavailable
Detection methods (Framework V):
- Network rate limiting upstream
- Availability monitoring with alerting
- Device location video surveillance
- Environmental monitoring (Framework V side-channel)
Compensating controls (Framework I):
- Dedicated VLAN with QoS priority
- Rate limiting; redundant network paths
- Uptime SLAs with vendor
- Physical access controls; backup device staging
E — Elevation of Privilege (CAW = 1.1)
Network-attacker scenarios:
- Default credential exploitation via network management interface
- OS CVE exploitation for local root (A1)
- Lateral movement to adjacent clinical systems
Physical / insider-attacker scenarios:
- Service-mode credential abuse via physical port
- Vendor-service-tool privilege abuse
- Unauthorised access to administrative menus via undocumented key sequence
Detection methods (Framework V):
- IDS/IPS with legacy OS exploit signatures
- Privilege escalation monitoring
- Behavioural analytics for anomaly
- Service-port session recording
Compensating controls (Framework I):
- Virtual patching via IPS
- Application allowlisting (Archetype 1)
- Network microsegmentation
- Inline MFA shim (Pattern C)
- PAM upstream (Pattern A)
3. Mapping to MDRS
This threat model informs the device’s MDRS Compensating Control Deficit (CCD) score. The CCD dimension counts STRIDE-HC categories with effective compensating controls:
- CCD = 1–2: Comprehensive controls across all six STRIDE categories, validated annually.
- CCD = 3–4: Comprehensive controls, not formally tested.
- CCD = 5–6: Controls in 3–4 STRIDE categories.
- CCD = 7–8: Partial controls (1–2 STRIDE categories covered).
- CCD = 9–10: No compensating controls.
For this device, the CCD score is [fill in] because:
- Spoofing: [covered / partial / not covered] — because [reason]
- Tampering: [covered / partial / not covered] — because [reason]
- Repudiation: [covered / partial / not covered] — because [reason]
- Information Disclosure: [covered / partial / not covered] — because [reason]
- Denial of Service: [covered / partial / not covered] — because [reason]
- Elevation of Privilege: [covered / partial / not covered] — because [reason]
4. Document control
| Field |
Value |
| Author |
Clinical engineering / information security |
| Reviewer |
CISO and Director of Clinical Engineering |
| Approval |
Joint sign-off |
| Approval date |
YYYY-MM-DD |
| Next review |
YYYY-MM-DD (annual or after material event) |
| Linked CJRs |
List of Control Justification Records |
| MDRS score (current) |
e.g., 8.175 → CRITICAL |