Security Concerns in Healthcare IoT Devices (Part 2)

Alice Emma Walker
4 min readJan 30, 2018

--

The security vulnerabilities of healthcare related IoT devices is undeniable. What is unclear is the risk to benefits ratio of patching these vulnerabilities. Surprisingly, there are risks of fixing security vulnerabilities!

To understand why healthcare IoTs are a challenge, lets look at the process of patching other IoTs. If a smart thermostat is found to have a vulnerability that allows an unauthorized person to take control of the device over the internet, the risks are moderately high. A malicious person can set the temperature to be dangerously high or low. The IoT manufacturer will create the update, then inform the user when the update will be pushed. The users can set the device to operate in a ‘manual mode’ for the few minutes the device reboots and applies the update. There is a minute risk of the updated software being buggy. This will result in another update to fix the regression bugs. There are virtually no risks in updating the device vs the benefits of updating.

Let’s compare this to how Abbott’s® implantable cardiac pacemaker was updated in August, 2017. Unlike patching the thermostat immediately, the patients with these pacemakers were asked to stick to the scheduled follow-up, and discuss updating the pacemaker software at the next regular clinic visit! Given that a malicious user can regulate the heart beat of a compromised person, asking the patient to wait will seem like an absurd decision. However, there is sound reasoning to make this recommendation and fortunately, no fatalities were reported as a result of this.

This is how the update process was implemented in practice. Patients came to the regular follow up and were informed of the vulnerability along with the risks of updating the software. If it was decided to update the software, the patient was admitted to a specialist center and the pacemaker was set to work in ‘backup mode’. With facilities for emergency external pacing and resuscitation, the programming device was placed near the pacemaker and the update was installed. There was 0.161% risk of failure to update, 0.023% risk of losing current device configuration, and 0.003% risk of total loss of device functionality.

The risks of not installing the update are not very high either. The pacemakers communicate with the programmer at short distances (2 meters at maximum), using radio frequency(RF). Although anyone can build an RF transmitter to reprogram the pacemaker, it is not easy for a stranger to get a patient to lie in front of his RF transmitter for a couple of minutes to reprogram the pacemaker. An alternative is a malicious user accessing the programmer device at the hospital and using that device to reprogram all the pacemakers that comes to the hospital.

Even if someone could actually do all that, many pacemakers have inbuilt hardware safety features that will limit the maximum and minimum heart rates. Ultimately, the security vulnerability may not be life-threatening.

There is a far easier method to disable a pacemaker. All pacemakers come with an ‘emergency deactivation switch’ This is meant to stop the pacemaker in a medical emergency. Because emergencies can occur globally, these emergency mechanisms have become industry standards. Any hospital anywhere can use any transmitter to stop the pacemaker in an emergency. These communications are not encrypted to allow for the maximum compatibility. Overtime, this practice has not changed significantly in terms of security.

It is surprising to know that the former U.S. vice president Dick Cheney might have stopped the remote possibility of terrorists messing with his pacemaker when he switched to a pacemaker without wireless communication features. But even his pacemaker could be stopped using the simple, insecure and the industry standard emergency stop feature.

Click here to continue to Part 3.

Click here to read Part 1 of this series.

About me: I’m Alice Emma Walker, a User Experience Designer in Canada/Hong Kong/Australia. When I’m not UXing, I’m playing rugby or travelling. Check out my other articles or connect with me on LinkedIn.

--

--