Medical Device Security and CIO Insomnia


During a conversation over drinks with a number of CIOs at a recent healthcare conference, I discovered that the number one concern that keeps most healthcare executives up at night is the security of their medical devices. That was somewhat unexpected, especially following press-grabbing headlines last year about ‘WannaCry’ and other ransomware attacks rendering a large part of the British NHS and other health systems useless for several weeks or months.

Reason 1: Management

Part of their concern is that medical devices are not typically managed by hospital IT (overseen in most cases by the CIO) but by clinical / biomedical engineering staff who power on and attach devices to hospital networks but have little understanding of the cybersecurity risks that are created by connecting an unprotected medical device to the hospital business clinical network. Connected medical devices can by-and-large be compromised easily, used as a foothold on hospital networks, or re-programed to execute patients or hold them to ransom.

This is not fiction! It has been demonstrated numerous times at security conferences most recently by McAfee at BlackHat and Defcon in Las Vegas last month. New Zealand ethical hacker Barnaby Jack started the trend of exposing medical devices vulnerabilities, when in 2011 at the MacAfee Focus Conference he demonstrated a hack of a wireless insulin pump causing the pump to deliver its entire reservoir of insulin into a mock patient. In 2012 he followed this performance up with a hack of a Pacemaker causing the device to administer an 815volt shock directly to the heart of the mock patient. Both demonstrations would have been fatal to a real patient and that might explain why in 2007 Vice President Dick Cheney had the wireless interface disabled to his own pacemaker at the insistence of Doctors and the US Secret Service. Jack demonstrated the ease at which a patient could be harmed or executed once their Implantable Medical Device or IMD had been hacked. Others followed at subsequent security conferences with hacks of network-attached infusion pumps, reprogramming the device to give a continuous maximum dose of Morphine till the reservoir was empty and the patient likely dead.

Reason 2: Lack of Security

The CIOs second concern is that medical devices have almost no built-in security found on a typical workstation or laptop and cannot readily be patched or upgraded. Nor can security tools and supplicants like anti-malware or a host firewall be installed as the limited capacity of devices will not support the additional memory or processing requirements needed.

To compound these issues, medical device manufacturers are notoriously reluctant and slow to release patches for their devices even when known security vulnerabilities have been discovered. This has resulted in some high profile shaming of manufactures as in the case of Muddy Waters Capital, an Options Trader, against St Jude Medical and the first ever FDA recall of a medical device as a result of the public disclosure. Would the Food and Drug Administration (FDA) have acted if it weren’t for the very public disclosure? It’s hard to tell. Would St Jude Medical have spent any time fixing known security vulnerabilities in some of its pumps? Based upon past performance, it’s highly unlikely. In fact, that was the reason for Muddy Waters penetration test in the first place, thus driving down the share price of St Jude Medical stock, allowing Muddy Waters to profit from its options trades.

The fact of the matter is that most medical devices unless afforded extra layers of protection and defense-in-depth security, are extremely vulnerable to cyberattack. Especially if connected to the main hospital network, let alone allowed to talk to the Internet.

Why are Medical Devices so Vulnerable to Attack and Compromise?

Medical devices take 5 to 6 years to go through testing and clinical trials before they receive FDA approval. The same is true in most other countries. That means that brand new devices arriving in hospitals today were designed at least 5 or 6 years ago using technology that was available at the time. Anyone connecting their 2012 era Windows computer to the Internet tomorrow without any security software or updates would more than likely be compromised inside 10 minutes, yet that’s what we do with medical devices. Only with medical devices, we use them not to surf the web or check email, but to monitor and treat patients - and in some cases keep them alive. That’s where unmitigated risks surface that results in CIO insomnia.

The HIPAA Security Rule (45 CFR (§164.308(a)(1)(ii)(A)&(B) requires a Risk Analysis and ongoing Risk Management be conducted of any and all devices that create, maintain, transmit, or receive ePHI or other sensitive data. Yet most hospitals don’t even have an accurate inventory of their medical device assets so how can they possibly assess their risks? The identification and profiling of medical devices has not been easy for hospitals, most of which have had to rely upon labor-intensive ad-hoc manual discovery processes. New tools and services from IoMT / HIoT vendors in the space that can identify and profile medical devices is beginning to change this however. A full asset inventory and medical device profile can now be exported from these tools and entered into enterprise risk analysis tools to perform compressive risk analysis to meet the very strict requirements of OCR and HIPAA.

The concern however is a lot deeper than mere HIPAA Compliance and the protection of PHI. Patient safety has become a major worry for healthcare providers where changes to the integrity and programming of medical devices can have far reaching effects. Hackers have already demonstrated the removal of safety limits and have over-written calibration data and dosages and changed drug libraries. Not only is the integrity of medical devices a growing concern but also their resiliency. Most devices will crash or blue screen when a simple virus or multi-cast traffic appears on the subnet. In particular, device availability for patient telemetry systems is critical to alert care staff to patient Codes or other conditions where speedy action on their behalf is required to save a life. Integrity and availability attacks are far more concerning than confidentiality attacks against PHI, and is where the real damage can be done.

To date, the OCR has only issued written guidance on the risk analysis of medical devices containing PHI, although audits show that OCR is beginning to take a broader look at all medical devices regardless of whether they create, receive, store or transmit PHI. The FDA continues to issue guidance, NCCoE and NIST have written a guide to secure medical infusion pumps resulting in NIST Special Publication 1800-8, and the Cloud Security Alliance (CSA) and Open Web Application Security Project (OWASP) recently joined forces to publish a revised Medical Device Deployment Guide. The fact remains however, that numerous medical devices are extremely vulnerable and are not being adequately managed from a risk perspective.

The average cost of a data breach according to Ponemon is $3.8 million. The damage and impact to a hospital’s reputation following a medical device attack resulting in patient death is pretty much unlimited. This may sound a little far-fetched but a recent study by the University of California Cyber Team found that several hospitals had self-reported adverse events from compromised healthcare infrastructure cybersecurity events, like ransomware, malware, or compromised EHRs. The study found that adverse events impacted between 100 and 1,000 patients. Furthermore, the 80 percent of survey respondents that reported risks in medical devices, is way higher than what the FDA reports.

Risk Management

Once identified, risks to critical systems should be addressed immediately. When remediation or retirement of a medical device is not possible, effective compensating security controls should be implemented to isolate and protect the device from attack and compromise. Many of the larger hospital systems are turning to micro-segmentation of their medical device network assets using Cisco TrustSec or other tools to essentially white-list network communications to and from each medical device and drop all other traffic. GE Health and Unisys do this by routing all medical device traffic through proxy servers. Others have segmented their medical device VLANs by use of internal firewalls. These solutions all increase the complexity of networks and leave many smaller hospital systems with tight budgets and limited capabilities out in the cold.

What’s being done to harden medical devices and prevent them from being hacked?

Guidance (and its only guidance to date) has been published by the FDA, NIST, NCCoE, CSA/OWASP and others to improve the deployment and security of medical devices. The onus however is squarely being placed upon healthcare providers to secure the medical devices they procure and utilize. At the same time manufacturers are being pressured to improve the security design of their devices and now have to perform a risk analysis of medical devices before FDA approval. But with a 5 to 6-year development cycle, the results of ‘improved security by design’ may take many years to reach hospitals and patients. With a 15 to 20-year lifespan for many medical devices, the security problem is not about to go away any time soon. That means hospitals need to implement compensating security controls immediately and keep them there for the foreseeable future.

Somewhat alarmingly however, a recent Ponemon Report on Medical Device Security showed that despite known vulnerabilities “roughly one third of device makers and healthcare delivery organizations (HDOs) are aware of potential adverse effects to patients due to an insecure medical device, but despite the risk only 17 percent of device makers and 15 percent of HDOs are taking significant steps to prevent such attacks.”

Healthcare IoT and the Internet of Medical Things currently presents perhaps the single biggest open back door to securing healthcare the world over. 

Subscribe to our periodic posts via email to periodic new posts so you don't miss them.

Original stories and articles may be republished without charge provided that attribution is provided to the source and author. Articles written for, and published first elsewhere, are subject to the republishing terms and conditions of the host site.