Medical devices are particularly notable as targets for cybercriminals. A few root causes for medical device security vulnerabilities stand out:
- Use of deprecated and unpatched commercial, off-the-shelf software and operating systems.
- Slow security patching cycles and security misconfigurations.
- Reliance on unsecured medical protocols.
These practices (or malpractices) together endanger a majority of medical devices. Across 30+ participating hospital facilities, healthcare cybersecurity firm CyberMDX noted more than 60 percent of medical devices were exposed to some degree of cyber risk, around 8 percent were vulnerable to remote code execution and a full 1 percent of devices were found to be at high risk, requiring immediate remediation.
The danger is very clear and very present. Allow me to explain.
Some medical devices use deprecated software and operating systems that are no longer supported, such as Windows XP. It should go without saying that unsupported 20-year-old software will lose in a fight against modern hackers. Every. Single. Time.
The infamous Wannacry and NotPetya attacks exploited the SMBv1 vulnerability (based on the EternalBlue attack path) affecting all Windows machines. These attacks proved particularly effective against machines running Windows XP, since XP reached the end of its product life and has long-since stopped receiving patches.
Similarly, in every hospital I visited, I witnessed growing concern around Windows 7, which is also approaching its end of product life (slated for January 2020). The concern is that machines will keep running the OS after its product life cycle is deemed officially complete. Just because the operating system no longer receives support and updates will not prevent it from working—and as long as it works, it will continue to be used, exposing any and all medical devices still running Windows 7 to increasing risk over time.
To put the threat into context, a great many imaging machines, patient monitors and dedicated medical integration servers run Windows 7. In fact, our fields statistics show that the number of medical devices running Windows 7 is 5X the number running Windows XP, representing a huge near-term risk factor!
Many medical devices use newer operating systems, but are still subject to lags in patching as vendors slog through the onerous validation processes required for medical devices. These lags are so widespread and formidable that it’s not at all uncommon for vendors to push patches for vulnerabilities disclosed as far back as two years. Obviously, this opens the door to serious security gaps.
A more recent example can be found in the CPU vulnerabilities Spectre and Meltdown, discovered by the Google’s Project Zero and published Jan. 26, 2018. Spectre and Meltdown affect a huge range of computers and devices running Intel, AMD and ARM CPUs—including many medical devices. These vulnerabilities originate in the firmware, so patching the software to mitigate exposure is a cumbersome (and somewhat limited) process that inhibits computing power and efficiency. Microsoft pushed initial patches a few weeks before the vulnerabilities were formally disclosed and then again a few weeks after.
For their part, most medical device vendors were been quick to acknowledge concern about the potential impact of Spectre and Meltdown on their products. Yet even a year later, almost none of the major players have offered a path to remediation.
As of the time of this article’s writing, a vast majority of medical devices still lack proper patching and remain ostensibly vulnerable to Spectre and Meltdown. This is despite the fact that some of those same vendors have issued patches for their non-medical products.
Evidently, there is something about developing and distributing security patches for medical technologies that is uniquely difficult; a disturbing thought, if you consider the extent of devastation that could be unleashed with a Spectre/Meltdown exploit targeted at health care.
Making matters worse, there tends to be a blindness to vulnerabilities in medical contexts. In many cases, hospital teams neglect to consider the exposure of their medical devices to known vulnerabilities that they’re defensively conscientious about in different IT ecosystems. Part of this is exacerbated by the lack of an efficient HIT tools for delivering up-to-date vulnerability assessments, collated according to affected devices and device types.
At CyberMDX, we often come across networked medical devices that are left unpatched for years, even though software and firmware updates are, in fact, available.
Permissive Configurations and Misconfigurations
Hospitals around the world are rife with medical devices configured with default passwords, sometimes even hard-coded ones. The threat here is clear: Any attacker with access to the network can assume control of the device and manipulate its behavior or change its availability.
Per CyberMDX field statistics, almost half of the connected devices monitored are left with their standard management ports (such as ssh, telnet, ftp) wide open, exposing the machines to internal and external threats. In many cases, although access is supposed to be authorized by the vendor support team, the device’s network configuration makes it accessible to any other connected endpoint and sometimes to the internet.
Unsecured Communication Protocols
Many medical communication protocols lack proper authentication or authorization mechanisms. In cases where these devices are capable of being remotely controlled—as in the case of an infusion pump or CT machines—this opens a hole for attackers to manipulate the protocols and, therefore, can change the device behavior, potentially putting the patient’s life at risk.
Nightmarish scenarios wherein a bad actor might remotely change the drug delivery rate of a connected pump or the radiation discharge level of a connected X-ray machine are not at all unrealistic. The means are there; all that’s needed is the motive. In fact, the viability of these attacks have been demonstrated by CyberMDX’s own research team as well as by academic researchers.
A Step in the Right Direction
Unfortunately, even if teams are promptly made aware of a vulnerability and implement the patch as soon as it’s made available by the vendor, it might be too late. Patching, as important as it is, is far from being sufficient for winning the race against attackers. For that, organizations will need a more comprehensive bottom-up healthcare cybersecurity architecture.
Healthcare facilities need to be able to map their digital landscape and track network endpoints; automatically classify devices into like groups; build risk profiles around each device and group; issue tailored recommendations to improve their endpoint security posture; scalably define context-aware, microsegmentation-enabled security group policies; push these policies to network policy enforcers; and continuously monitor traffic patterns for emerging threat signals.
The task is tall to be sure, and many healthcare organizations will be hard-pressed to accomplish it without the support of a strong team, thoughtful planning, keen attention-to-detail and smart automation tools. With the future of health care in the balance, those are investments that organizations simply can’t afford not to make!