Hacking the (Medical) Matrix: Risk Managing IoMT in Hospitals

Cybersecurity in Operational Technology (OT) is often overlooked, until it’s too late. When it comes to hospitals, the stakes couldn’t be higher. Imagine a ransomware attack locking critical medical devices or a hacker altering patient data mid-surgery, scenarios that might sound like a thriller but are disturbingly realistic in today’s interconnected healthcare environment. When it comes to healthcare delivery organisations (HDOs), the stakes transcend financial or reputational damage—they directly impact patient safety and human life.

During my MSc in Cyber Security Engineering, the module Information Risk, Management, and Governance was particularly enlightening, compelling me to apply theoretical risk frameworks to the practical security challenges hospitals face today. It wasn’t just an academic exercise, it was real-world OT security in action. By bridging the gap between abstract risk management standards and the concrete, complex ecosystem of the Internet of Medical Things (IoMT), this article provides a comprehensive, highly technical analysis of threat modelling and risk managing IoMT devices inside modern hospital networks.

1. The Clinical OT Conflict: Safety-First (AIC vs. CIA)

Traditional IT security operates under the classical CIA Triad (Confidentiality, Integrity, Availability), usually prioritising confidentiality to prevent data breaches. In contrast, Clinical Operational Technology (OT) and IoMT operate under a Safety-First or AIC Triad (Availability, Integrity, Confidentiality).

In a clinical environment, the sudden loss of availability or unauthorised modification of a device’s integrity (e.g., stopping a ventilator or altering defibrillator settings) presents an immediate threat to a patient’s life. Consequently, traditional IT security controls—such as aggressive automated vulnerability scanning or immediate service termination upon detecting anomaly—cannot be applied blindly. A scan that crashes a legacy syringe pump during an active infusion is more dangerous than the vulnerability itself. Security engineering in HDOs requires a nuanced, risk-based approach that balances clinical safety with technical controls.

2. Comparative Analysis of Risk Management Frameworks

To navigate this landscape, HDOs must leverage a combination of generic information security standards and healthcare-specific frameworks. Below is a critical comparison of the primary standards applied to IoMT risk governance:

Rather than adopting a single standard, a mature HDO must implement a hybrid approach: using ISO 27001 to govern the overarching ISMS, ISO 81001-1 to manage the safety-critical software lifecycle of medical devices, and the NHS DSPT to maintain compliance with regional healthcare mandates.

The 10 NHS DSPT Data Security Standards

For HDOs operating in or interfacing with the UK NHS, the DSPT mandates adherence to ten core standards:

1. Personal Confidential Data: Staff must handle, store, and transmit patient data securely in compliance with the UK GDPR.
2. Staff Responsibilities: All personnel must understand their responsibilities under the National Data Guardian’s data security standards.
3. Staff Training: Annual information governance and cybersecurity training are mandatory for all staff.
4. Managing Data Access: Implement the Principle of Least Privilege; remove access immediately upon role changes or termination.
5. Process Reviews: Establish a feedback loop where security incidents and near-misses inform periodic process improvement workshops.
6. Responding to Incidents: Active monitoring to resist cyber-attacks, combined with prompt response to CareCERT security advisories.
7. Continuity Planning: Maintain tested business continuity plans to recover clinical services during significant cyber disruptions.
8. Unsupported Systems: Zero tolerance for unsupported operating systems, browsers, or software on the clinical network.
9. IT Protection: Implement technical defences (firewalls, endpoint protection, intrusion prevention) to secure the IT and OT estate.
10. Accountable Suppliers: Enforce contractual clauses ensuring that third-party IT/OT suppliers adhere to the same high security standards.

3. Threat Modelling via MITRE’s 4-Question Framework

The FDA and MITRE’s Playbook for Threat Modelling Medical Devices advocate for a proactive, design-stage security analysis built around the Four Questions Framework developed by Adam Shostack:

+-----------------------------------------------------------------------------------+
| TRUST BOUNDARY: PATIENT HOME / WARD                                               |
|                                                                                   |
|  [ IoMT Ankle Sensor ] <========( BLE / RF Communications )========> [ Mobile App ]|
+--------------------------------------------------------------------------||-------+
                                                                           ||
                                                                   ( HTTPS / TLS )
                                                                           ||
+--------------------------------------------------------------------------||-------+
| TRUST BOUNDARY: CLOUD SERVICES (AMPSCS)                                  ||       |
|                                                                          v       |
|                                                                  [ API Gateway ]  |
|                                                                    /     |     \  |
|                                 (Validate Credentials)            /      |      \ |
|                                          v                       /       |       \|
|                                  [ Auth Server ] <--------------+        |        |
|                                                                          |        |
|                                                                (Internal Routing) |
|                                                                          |        |
|                                                                          v        |
|                                                                   [ Analysis ]    |
|                                                                   [  Engine  ]    |
|                                                                          |        |
|                                                                 (Read / Write SQL)|
|                                                                          |        |
|                                                                          v        |
|                                                                   [(Database)]    |
+--------------------------------------------------------------------------||-------+
                                                                           ||
                                                                     ( HTTPS Session)
                                                                           ||
+--------------------------------------------------------------------------||-------+
| TRUST BOUNDARY: CLINICAL / HDO NETWORK                                   ||       |
|                                                                          v       |
|                                                            [ Clinician Web Portal ]|
+-----------------------------------------------------------------------------------+

Q1: What are we working on?

HDOs must map out their system architectures using data flow diagrams (DFDs), sequence diagrams, and state machines:

• Data Flow Diagrams (DFDs): Define the core entities, processes, data stores, data flows, and trust boundaries (as shown in the data flow diagram above). Crucially, trust boundaries must encircle elements under different administrative controls (e.g., patient-owned smartphones vs. HDO cloud services).
• Sequence/Swim Lane Diagrams: Model the dynamic, temporal aspect of communications, such as the cryptographic handshake between an insulin pump and its remote controller, highlighting potential windows of interception or replay.
• State Machines: Model the operational states of the medical device (e.g., Clinical/Infusion Mode, Maintenance/Calibration Mode, Firmware Update Mode). Attacking a device often involves forcing it into an administrative or debug state while it is clinically active.

Q2: What can go wrong?

To identify threats systematically, we apply the STRIDE methodology specifically to the clinical context:

• Spoofing: Spoofing server identities to push malicious firmware updates to patient monitors, or spoofing Bluetooth MAC addresses to inject false vital sign telemetry.
• Tampering: Altering therapeutic parameters (e.g., changing syringe pump infusion rates via unauthenticated commands) or modifying configuration files.
• Repudiation: A rogue action or unauthorised configuration change occurring without audit log evidence, leaving the clinician unable to trace who altered a dose limit.
• Information Disclosure: Intercepting unencrypted Protected Health Information (PHI) over wireless protocols (e.g., Bluetooth, Wi-Fi) or accessing unsecured local databases containing patient logs.
• Denial of Service (DoS): Exhausting device battery via continuous RF pinging (battery drain attacks), jamming RF bands, or sending malformed packets to crash critical telemetry modules.
• Elevation of Privilege: Exploiting buffer overflows or debug interfaces (like JTAG or serial consoles) to bypass clinical user interfaces and execute commands with root/system privileges.

Q3: What are we going to do about it?

HDOs must categorise their response to identified threats into four strategic options:

1. Eliminate: Remove the risky feature entirely (e.g., disable wireless capabilities if they are not clinically necessary).
2. Mitigate: Implement technical or administrative controls to reduce the risk to an acceptable level (e.g., require cryptographic mutual authentication and enforce encrypted TLS/DTLS tunnels).
3. Accept: Retain the risk if it falls within the HDO’s risk appetite and is outweighed by clinical benefits (e.g., maintaining a legacy, unpatchable MRI machine because replacement is financially unviable, but isolating it entirely).
4. Transfer: Move the risk to another party, typically via cyber insurance or service-level agreements (SLAs) with device manufacturers.

Q4: Did we do a good job?

Validate the threat model through security verification and validation (V&V):

• Automated Testing: Implement static application security testing (SAST) and dynamic application security testing (DAST) on companion mobile applications and cloud APIs.
• Penetration Testing: Perform targeted Red Team exercises attempting to exploit the identified threat vectors under simulated clinical constraints.
• Continuous Reviews: Re-evaluate threat models annually, or whenever a major software update, configuration shift, or new vulnerability advisory is released.

4. The Corrected IoMT Risk Register

In compiling an HDO-wide risk register, we must catalog specific medical devices, their vulnerabilities, STRIDE impacts, CVSS severity, and potential mitigations.

Note: The table below represents a corrected and technically aligned version of the risk register, resolving vertical row misalignments commonly found in raw coursework audits (such as swapping the vendors and vulnerabilities of Innokas vital sign monitors and Medtronic insulin pumps):

5. Technical Deconstruction of Critical Exploit Vectors

Understanding the specific mechanics of IoMT exploits is vital to engineering effective countermeasures. Let’s analyse three common vulnerability classes in clinical OT:

A. RF Command Injection (Medtronic MiniMed Pumps)

The Medtronic MiniMed 508 and Paradigm series pumps communicate with peripheral devices (like continuous glucose monitors and remote programmers) over a proprietary RF protocol in the 400 MHz band (typically 433 MHz).

• The Exploit Mechanics: The protocol does not implement cryptographic handshakes, packet signing, or replay protection. An attacker equipped with a Software Defined Radio (SDR) transceiver (such as a HackRF One or a Yard Stick One) can sniff local RF traffic to capture the 6-character device serial number (which acts as the destination address). Once the serial number is known, the attacker can craft malicious RF packets containing instructions to deliver an immediate maximum bolus dose of insulin. This command is processed by the pump as legitimate, potentially causing severe, life-threatening hypoglycaemia.
• Mitigation: Physical replacement is the only reliable option. Modern pumps utilise Bluetooth Low Energy (BLE) with authenticated bonding (using Out-of-Band pairing) and payload-level encryption (AES-128).

B. Bypassing Segmented Architectures (Smiths Medfusion 4000)

The Smiths Medical Medfusion 4000 pump employs a dual-processor architecture designed to segment the wireless communications module (which interfaces with the hospital network to retrieve drug libraries) from the therapeutic module (which drives the mechanical syringe pump motor).

• The Exploit Mechanics: The communications module runs a web server and network stack, exposing it to the network. An attacker on the local network can exploit a stack-based buffer overflow vulnerability (CVE-2017-12718) by sending a crafted HTTP request to the communication module. This payload overflows the stack, overwriting the instruction pointer to execute arbitrary code (RCE) with root privileges. Once the comms module is compromised, the attacker can leverage the internal UART/serial interface connecting the two modules to transmit malformed configuration files and command packets to the therapeutic board. This bypasses the physical segmentation intent, allowing the attacker to alter the active infusion rate.
• Mitigation: Upgrading to v1.6.1 is required, which enforces input sanitisation on the network interface and implements cryptographic verification for firmware and internal commands.

C. Directory Traversal and Serial Debug Consoles (BD Alaris Plus)

The BD Alaris Plus syringe pump uses a serial communication port (RS-232) for maintenance and communication when docked in a gateway workstation.

• The Exploit Mechanics: If the serial port is connected to an unauthorised terminal server (often used in hospitals to convert RS-232 to Ethernet for remote log aggregation), it exposes the device’s raw debug console to the local network. An attacker can connect to this TCP port and exploit a directory traversal vulnerability (CVE-2018-14781) on the device’s internal filesystem. By sending escape sequences (e.g., ../../), the attacker can read sensitive system configurations, leak proprietary algorithms, and overwrite critical calibration parameters used to calculate infusion dose-error reduction limits.
• Mitigation: Restricting physical access to the RS-232 serial interfaces, disabling remote terminal server access, and ensuring the device is docked in a secured Alaris Gateway Workstation.

6. Defence-in-Depth and Operational Clinical Mitigation

Securing an HDO network requires a multi-layered defence-in-depth architecture that addresses network design, device lifecycle, and clinical operational workflows.

       +-------------------------------------------------------------+
       |                  Enterprise Network / WAN                   |
       +-------------------------------------------------------------+
                                      |
                                      v [Firewall / IPS]
       +-------------------------------------------------------------+
       |               Clinical VLAN (Micro-segmented)               |
       |  +------------------+  +------------------+  +-----------+  |
       |  |  Workstations    |  |  Internal APIs   |  |   DICOM   |  |
       |  +------------------+  +------------------+  +-----------+  |
       +-------------------------------------------------------------+
                                      |
                                      v [Access Control Lists / Zero Trust]
       +-------------------------------------------------------------+
       |                  IoMT Dedicated VLAN / SSID                 |
       |  +------------------+  +------------------+  +-----------+  |
       |  |  Syringe Pumps   |  |  Patient Monitors|  | Ventilators |  |
       |  +------------------+  +------------------+  +-----------+  |
       +-------------------------------------------------------------+

Network Architecture: Zero Trust Micro-segmentation

HDOs must transition away from flat network topologies.

• Dedicated IoMT VLANs: Segment all IoMT devices onto dedicated, non-routable VLANs separate from the general hospital administrative network and the public patient Wi-Fi.
• Micro-segmentation: Implement firewall Access Control Lists (ACLs) to ensure that medical devices can only communicate with their designated central stations or gateways. For example, a syringe pump has no operational need to communicate with a workstation in HR or another syringe pump in a different ward.
• Protocol Filtering: Configure Intrusion Prevention Systems (IPS) to actively inspect clinical protocols (such as HL7, DICOM, and CoAP) and block malformed packets that match known vulnerability signatures.

Lifecycle & Procurement Governance

Security must be integrated into the purchasing process.

• Software Bill of Materials (SBOM): Mandate that device manufacturers supply a comprehensive SBOM. If a new device uses a vulnerable subcomponent (such as the Thales cellular module), the HDO can track and remediate it proactively.
• Manufacturer SLAs: Require vendors to commit to a Service Level Agreement (SLA) for security patches, defining maximum timelines for releasing fixes after a CVE disclosure.
• Physical Hardening: Physically disable or cover unused ports (USB, RJ45, serial) on clinical devices using physical locks to prevent local tampering.

Incident Response under Clinical Constraints

Standard incident response (IR) procedures must be modified to account for patient safety.

• Collaborative IR Playbooks: Incident response teams must not unilaterally isolate a device or segment a network without confirming the clinical status of the impacted equipment. Isolating a critical server might shut down a telemetry screen displaying vitals for an entire ICU department.
• Immutable Backups: Maintain offline, cryptographically signed, and air-gapped backups of all device configurations and central databases. Backups must be retained for at least 30 days to align with typical intrusion detection latency.
• Alternative Care Pathways: Establish manual clinical procedures (e.g., manual drip-rate calculations for syringe pumps or manual bagging for ventilators) that staff can execute immediately if a cyber incident forces the shutdown of IoMT infrastructure.

Conclusion

Ultimately, what this IRMG module taught me is that managing risk in the Internet of Medical Things requires bridging the gap between rigorous cybersecurity standards and the uncompromising safety requirements of clinical operations. Through implementing structured threat modelling, maintaining accurate and aligned risk registers, and enforcing strict network micro-segmentation, I learned how healthcare delivery organisations can safely navigate the complex digital pulse of modern medicine. Protecting the medical matrix is not just about securing data—it is about safeguarding the patients who depend on it.