I recently had reason to spend an overnight visit in the hospital. When friends and family left me late in the evening I was confronted with a subject that I had considered professionally but never had to face personally: the connected medical device.
When software security gets personal
The device that dominated my attention was the infusion pump attached to my IV line. First, it became my constant companion if I left my bed, so we quickly became quite close. Second, it reminded me of specific hacks demonstrated by security researcher Billy Rios. Specifically, the hack where he shows how such a device could be used to endanger the life of the patient. For those of you who have never had the pleasure of being connected to an infusion pump, it is a device that continuously meters and dispenses medicine intravenously into the patient. These pumps are widely deployed and used for a wide range of treatments and medical conditions. They are not terribly complex or exotic, so they represent a fair example of a connected medical device. They also stretch the term “connected” as they are connected to the network and connected to the patient.
A few weeks ago, I had the pleasure of seeing Billy deliver his presentation on medical device security in person, and my experience with the infusion pump came flooding back to me. Hearing him speak again inspired me to explore the subject and use medical device security to build on the points I made in my last column comparing security and quality in the context of software; specifically, their relationship to developing and deploying software.
Now, as I consider medical device security, I want to add safety and privacy into the conversation. I believe these two elements exist side-by-side with quality and security as characteristics of good software.
Injecting privacy and safety into the security-quality conversation
Let’s start with privacy, which I’ll define as the protection of personally identifiable data (my personal data). Connected medical devices collect and store patient information as part of their normal operation. With the advent of connected devices, privacy and security have become tightly linked because theft of private data is often the goal of malicious attacks.
However, it is entirely possible for software to expose private data without the involvement of a malicious outside agent. The mishandling of a device can create the same amount of exposure as an attack. For example, what happens when an infusion pump is sent away for repair? Does the hospital clear the memory of the device before releasing it to the shop? It stands to reason that someone qualified to repair such a device would have the knowledge and privilege to access data on the device.
Safety is also a critical element because the same medicine that provides help and relief to a patient may cause serious problems or even prove fatal if improperly administered. For example, if the device dispensed the medicine too quickly, the safety of the patient would be compromised. The cause could be traced to mechanical problems, software quality issues, or an outside agent compromising the software.
Quality assures that the infusion pump performs the way it’s intended to. In this case, the pump should dispense the proper volume of medicine at the proper flow rate. The software in the device is crucial to controlling the device based on the settings entered for each medicine. Defects in the code could cause the pump to malfunction, resulting in real harm to the patient.
When enhanced functionality poses a life-threatening risk
Software for medical devices existed well before they became connected. However, manufacturers now leverage the connected nature of devices to update the software on a regular basis to enhance their capabilities and extend their useful life. This opens the door for more exposure to quality issues beyond the initial software in the manufacturing process.
Security is pervasive in our scenario—both physical security and protection from external attack as a connected device. The software must authenticate the operator of the device to ensure that it cannot be improperly used by an unauthorized person. Since the device is protected, the software must also be protected against attacks that allow for remote operation of the device or exfiltration of patient data.
This is not just my imagination, as Billy Rios has ably demonstrated in a sobering way. Billy documented an attack on an infusion pump where he infiltrated the device, remotely put the device into a test mode, and initiated a volume test that quickly emptied the medicine in the pump. If the pump was attached to a patient and the medicine in the pump was harmful or fatal at high doses, the safety of the patient would be at obvious risk.
The Equation: Privacy, Safety, Quality and Security
Taking privacy, safety, quality, and security all into the equation, the innocuous-looking box beeping and flashing by my bed suddenly demands a whole new level of consideration. Connecting such a device makes great sense regarding sharing medical data and providing software updates to improve functionality. However, as in all things, there are two edges to the sword.
All too often the theme of patient privacy dominates the conversation around connected medical devices. However, as security researchers like Billy Rios and Dr. Marie Moe so adroitly remind us, there is often much more at stake than the exposure of personal medical data. I can assure you that in the quiet of my hospital room late in the evening, I was far more worried about what medicine was coming out of the pump than what data was coming out of it.
