Killed by code in your connected medical device
Are we more concerned with politicians with pacemakers or families with large numbers of connected medical devices?
Back in 2011, I thought it would only be a question of time before we have a drive by execution of a politician with an ICD (implanted cardiac device). May 2019, with mushrooming growth in connected medical devices (and after the Israeli 2019 elections), I am rethinking my risk analysis.
Consider this: If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable that this number will double with medical IoT and software as devices for diabetes management, asthma monitoring, fetal monitoring, remote diagnosis of children, home-based urine testing and more.
So far, it seems the politicians are still around, but the cybersecurity vulnerabilities for medical devices are growing in frequency and impacting big medical device vendors like Medtronic as reported by FDA in March 2019 – Cybersecurity Vulnerabilities Affecting Medtronic Implantable Cardiac Devices, Programmers, and Home Monitors
Audience: Patients with a Medtronic cardiac implantable cardioverter defibrillators (ICDs) or cardiac resynchronization therapy defibrillators (CRT-Ds)
-Caregivers of patients with a Medtronic ICD or CRT-D
-Cardiologists, electrophysiologists, cardiac surgeons, and primary care physicians treating or managing patients with heart failure or heart rhythm problems using a Medtronic ICD or CRT-D
-Cardiac Electrophysiology, Cardiology, Cardiothoracic Surgery, Heart Failure
Purpose: The U.S. Food and Drug Administration (FDA) is issuing this safety communication to alert health care providers and patients about cybersecurity vulnerabilities identified in a wireless telemetry technology used for communication between Medtronic’s implantable cardiac devices, clinic programmers, and home monitors. The FDA recommends that health care providers and patients continue to use these devices as intended and follow device labeling.
Although the system’s overall design features help safeguard patients, Medtronic is developing updates to further mitigate these cybersecurity vulnerabilities. To date, the FDA is not aware of any reports of patient harm related to these cybersecurity vulnerabilities.
In Jan 9, 2017 FDA reported in a FDA Safety Communication on “Cybersecurity Vulnerabilities Identified in St. Jude Medical’s Implantable Cardiac Devices and Merlin@home Transmitter.
-Patients with a radio frequency (RF)-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
-Caregivers of patients with an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
-Cardiologists, electrophysiologists, cardiothoracic surgeons, and primary care physicians treating patients with heart failure or heart rhythm problems using an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
Different classes of device. Different threat scenarios. A wellness app does not have the same threat model as implanted devices
I’ve been talking to our medical device customers about mobile security of implanted devices for over 7 years now.
I gave a talk on mobile medical device security at the Logtel Mobile security conference in Herzliya in 2012 and discussed proof of concept attacks on implanted cardiac devices with mobile connectivity.
But – ICD are the edge, the corner case of mobile medical devices.
If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable scenario that this number will double withe devices for fetal monitoring, remote diagnosis of children, home-based urine testing and more.
Mobile medical devices are becoming a pervasive part of the Internet of things; a space of devices that already outnumber workstations on the Internet by about five to one, representing a $900 billion market that’s growing twice as fast as the PC market.
There are 3 dimensions to medical device security – regulatory (FDA), political (Congress) and cyber (vendors implementing the right cyber security countermeasures)
The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that the software as a device mobile apps:
-are intended to be used as an accessory to a regulated medical device, or
-transform a mobile platform into a regulated medical device.
Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review. The FDA guidance document provides examples of how the FDA might regulate certain moderate-risk (Class II) and high-risk (Class III) mobile medical apps. The guidance also provides examples of mobile apps that are not medical devices, mobile apps that the FDA intends to exercise enforcement discretion and mobile medical apps that the FDA will regulate in Appendix A, Appendix B and Appendix C.
Mobile and medical and regulatory is a pretty sexy area and I’m not surprised that politicians are picking up on the issues. After all, there was an episode of CSI New York that used the concept of an EMP to kill a person with an ICD, although I imagine that a radio exploit of an ICD or embedded insulin pump might be hard to identify unless the device itself was logging external commands.
See my presentation ‘Killed by code’
Congress is I believe, more concerned about the regulatory issues than the patient safety and security issues:
Representatives Anna Eshoo (D-CA) and Ed Markey (D-MA), both members of the House Energy and Commerce Committee sent a letter last August asking the GAO to Study Safety, Reliability of Wireless Healthcare Tech and report on the extent to which FCC is:
–Identifying the challenges and risks posed by the proliferation of medical implants and other devices that make use of broadband and wireless technology.
–Taking steps to improve the efficiency of the regulatory processes applicable to broadband and wireless enabled medical devices.
–Ensuring wireless enabled medical devices will not cause harmful interference to other equipment.
–Overseeing such devices to ensure they are safe, reliable, and secure.Coordinating its activities with the Food and Drug Administration.
At Black Hat August 2011, researcher Jay Radcliffe, who is also a diabetic, reported how he used his own equipment to show how attackers could compromise instructions to wireless insulin pumps.
Radcliffe found that his monitor had no verification of the remote signal. Worse, the pump broadcasts its unique ID so he was able to send the device a command that put it into SUSPEND mode (a DoS attack). That meant Radcliffe could overwrite the device configurations to inject more insulin. With insulin, you cannot remove it from the body (unless he drinks a sugary food).
The FDA position that it is sufficient for them to warn medical device makers that they are responsible for updating equipment after it’s sold and the downplaying of the threat by industry groups like The Advanced Medical Technology Association is not constructive.
Following the proof of concept attack on ICDs by Daniel Halperin from the University of Washington, Kevin Fu from U. Mass Amherst et al “Pacemakers and Implantable Cardiac Deﬁbrillators:Software Radio Attacks and Zero-Power Defenses” this is a strident wakeup call to medical device vendors to implement more robust protocols and tighten up software security of their devices.