Can't sign in? Forgot your username?
Enter your email address below and we will send you your username
This article in the CyberInsights series uses examples of medical device cyber(in)security that are due to failure to apply security patches and provides a starting point for improving the security of information technology (IT) networks at healthcare delivery organizations (HDOs). As reported on MedTech Dive, “Hospitals are not taking basic security actions and have low levels of accountability regarding cyberattacks, ransomware and data theft stemming from breached medical devices.”
We hear so often that the cybersecurity sky is falling that we may be calloused or perhaps unsure of how to move forward. In its top health technology hazard for 2022, ECRI named cybersecurity attacks as the foremost hazard. On September 12, 2022, the Federal Bureau of Investigation (FBI) published Private Industry Notification (PIN) 20220912-001 with an alarming headline: “Unpatched and Outdated Medical Devices Provide Cyber Attack Opportunities.” The report starts with the following: “The FBI has identified an increasing number of vulnerabilities posed by unpatched medical devices that run on outdated software and devices that lack adequate security features.” The release is coded Traffic Light Protocol (TLP) White, which means the information carries minimal or no foreseeable risk of misuse.
To those of us who work in the field, this is hardly new information, but the TLP White seems to imply that medical devices carry minimal or no foreseeable risk of misuse. Perhaps the choice of TLP White is because the information in the PIN is already well known? Arguably, the first serious mention of medical device cybersecurity was in 2012 by the Information Security and Privacy Advisory Board, about the time that Barnaby Jack showed that implantable defibrillators could be remotely triggered. By 2014, cybersecurity, including that of legacy equipment, was a growing topic of discussion, and the first edition of the AAMI’s Medical Connectivity FAQs (updated in 2020) delved into the topic of security.
In a personal communication, the chief security officer (CSO) from a major university hospital system made a comment that seems to embody the concept that medical devices have minimal or no foreseeable risk of misuse. “I don’t really care about medical devices; they’re such low risk as long as they don’t become attack vectors into my IT system. Then I care a lot. Don’t let that happen,” he said. As Steven Rubino, a retired biomedical engineer, stated, “It will be too late if the CSO waits until medical devices are attack vectors on the IT network to begin to care.”
Typically, a CSO’s primary concern is for the business side of healthcare; however, let’s be clear: It is a mistake to only consider risk to the IT network and neglect the risk to patients. Even so, following the CSO’s concern for the business, it is important to note the following example. The third-party Wi-Fi radio in a medical device running is running LINUX on an ARM-7 core with 1 GB of RAM and 2 Gb of Flash memory. This radio has access to the IT network, including the electronic health record servers and is a powerful platform from which to launch a ransomware attack, which will require an enormous expenditure to remedy.
Hospitals should ensure that medical equipment includes solutions to monitor and patch third-party software, such as in the Wi-Fi module. For those who did, there was a fast response to the KRACK (key replay attack) vulnerability.
The FBI PIN mentions that “53% of connected medical devices and other Internet-of-Things (IoT) devices in hospitals had critical vulnerabilities.” That’s interesting, but without knowing the breakdown of medical devices versus IoT devices used in HDOs and how the devices are connected, the statistic is terribly unhelpful.
In Rubino’s experience, most HDOs do not know the number of biomedical and engineering assets (e.g., HVAC SCADA system) running on the IT network. Knowing all of the devices on the IT network and what software they run is a fundamental step to keeping the IT network secure and patients safe. To properly assess and mitigate risks, both the severity and probability of occurrence must be considered for each attack surface before the vulnerability has been exploited. Medical device security platforms such as Medigate, Ōrdr, and CyberMDX can provide a passive discovery of virtually all devices on the network.
A perennial cybersecurity weak spot, infusion pumps, warrant their own guidance from the National Institute of Standards and Technology (NIST SP 1800-8). According to a report from Palo Alto Networks, 75% of infusion pumps have vulnerabilities, and of infusion pumps studied in 2022, 52% still had a critical and a severe vulnerability in the operating system (OS) that had been discovered in 2019 and for which patches are available.
Greater than three-fourths of attacks used in 2021 exploited vulnerabilities that were more than two years old. For how many of the medical devices mentioned in the FBI PIN are there existing patches that have not been applied? Are the failures to apply patches due to medical device manufacturers (MDMs), HDOs, or something else? How many medical device vulnerabilities are not specific to medical devices for which the patch is provided to the MDM.
For example, if a vulnerability is discovered in the OS, the MDM typically receives a patch from the OS vendor in short order. This patch then needs to be integrated and tested in the medical equipment. Once provided to the HDO, the updated system needs to be tested on the hospital network before deployment. During all this time, the HDO must choose whether to stop using the vulnerable equipment to treat patients or to keep using it, leaving the equipment and network exposed to a known vulnerability. Time is of the essence.
A quick search for an infusion pump vulnerability found a midlevel vulnerability where the Wi-Fi preshared key (the password) is stored in clear text in the battery’s nonvolatile memory, even after resetting the system to factory defaults. An attacker need only exchange the battery from an infusion pump, add a debugger, and read out the Wi-Fi password.
Although exploiting this vulnerability requires physical access to an infusion pump at an HDO, even our above-quoted CSO might care about this medical device that provides a fairly easy way to infiltrate the IT network. Every MDM should ask itself, “Would our review processes catch such a flagrant violation of cybersecurity practices?”
These infusion pumps examples were chosen to highlight a need for reducing the number of vulnerabilities in HDOs. A simple process can be used to do this: inventory all devices on the network, triage by risk, and focus on mitigating or replacing easy-to-fix and high-impact items. Each year, repeat this activity. These vulnerabilities can be broken into two groups:
For the first class: Assuming patches exist for vulnerabilities that are older than two years, applying existing patches should reduce the number attack vectors used by approximately 75%. Consider this example of an easy-to-apply, high-impact cybersecurity improvement: Intravenous pumps represent 38% of connected devices in HDOs, and as mentioned above, 52% of these had critical OS vulnerabilities three years after the patch was available for the infusion pump. This is the ironic part: Even when the patch was provided three years ago, some HDOs continue to neglect applying a cybersecurity fix to help secure their network and protect patients. Every year, an HDO should review the highest-risk devices and fund their replacement.
To be fair, cases exist where the software vendor might have a patch that the MDM fails to qualify, and in this case, the burden rests on the MDM to provide a timely update. What seems clear is that in the current regulatory environment, accountability is low and the incentive is insufficient for HDOs to address cybersecurity issues in medical devices. HDOs, whose very reason for existence is to care for patients, are failing to implement available cybersecurity patches and leaving those patients at increased risk. Perhaps the Food and Drug Administration (FDA) and Joint Commission should provide incentives to MDMs and HDOs, respectively, to improve the response time for responding to known vulnerabilities?
For the second class: The driver for a sensor, such as that for SPO2, can only be easily attacked if a hacker has first exploited an external-facing vulnerability. MDMs typically use third-party OSs, communication stacks, sensors, and drivers for external communication, and these are covered in the first class. The most important things that MDMs can do are (1) not add more vulnerabilities (e.g., store passwords in the clear) and (2) ensure software patches can be quickly and easily applied.
Based on personal experience and discussions with others, it seems clear that many MDMs have performed cybersecurity risk analyses using underqualified personnel. The result is a medical device where the MDM has added vulnerabilities and for which applying security patches is difficult. To address this, the FDA should require that medical device companies not only perform cybersecurity analyses but also that these analyses be conducted by qualified personnel.
To those who make decisions on what medical devices to purchase: The trend is toward more vulnerabilities. As Q1 2022 had 25% more vulnerabilities than Q1 2021, it makes sense to avoid buying medical devices from MDMs with poor cybersecurity hygiene and exposing your IT network and patients to more risk. Meanwhile, HDOs should be sure to clean house, apply any patches that MDMs have provided (which is much easier for HDOs that maintain an accurate medical device software inventory), and begin or improve their medical device security program (as described in the security section of AAMI’s Medical Connectivity FAQs, the Center for Internet Security’s (CIS’s) Critical Security Controls, and NIST SP 1800-8).