A few months ago, I was at a birthday party with one of my sons when another young man took out a medical device that had a long, thin tube leading back into his pocket. When asked, he identified it as his insulin pump, which he needed to check and set appropriately before having a piece of cake. “It’s capable of connecting to my phone via Bluetooth, but I’ve never set it up and wouldn’t know what to do with it anyway,” he said.

Our short conversation highlighted many of the issues we should be concerned with when the world of medical devices meets the Internet of Things (IoT). This young man was carrying a device that his life literally depends upon, and while he knows the basics of the device, he doesn’t understand the full extent of its capabilities or vulnerabilities. Unluckily, the same can probably be said of the device’s manufacturers.

Securing the Medical Device

Honestly, security has been low on the priority list for most medical device manufacturers. Reliability is a much bigger concern, as it should be. But cybercriminals have been picking away at them since at least 2008, when researchers explained how a pacemaker could be subverted to give life-threatening shocks to its owner. While companies have taken threats like this seriously and in general fixed the problems quickly, preventing this type of vulnerability through increased focus in the software development and testing areas has not become a priority for most organizations.

But this will likely be changing in the near future: The U.S. Food and Drug Administration (FDA) has released a draft of proposed guidelines for medical device manufacturers, the succinctly named “Postmarket Management of Cybersecurity Medical Devices.” This paper laid out basic guidelines for understanding and compensating for the risks that medical IoT devices will likely face, patching and how such vulnerabilities will be reported to the FDA and the device users.

Perhaps the most important part of the paper is that it described potential suggestions for dealing with the people researching medical IoT devices. In other words, it recommended what to do when a white-hat hacker finds a vulnerability in a device and reports it.

I found this paper from the FDA to be filled with good advice — not just for medical IoT manufacturers, but for anyone who’s developing a program for external researchers to report issues. In other words, a bug bounty program.

While the FDA paper doesn’t explicitly talk about paying for vulnerability research, it does discuss about many of the considerations that go into making such a program. There’s significantly more to the paper, most of it fundamental to any good security program, but this is what stood out the most to me.

Additional Guidelines

External to the FDA, but also pushing in the right direction for the security of medical IoT devices, a group of security professionals called I Am The Cavalry published a Hippocratic Oath for Connected Devices. While the oath calls for some of the same controls the FDA’s guidance pointed toward, it goes far beyond, listing five core cybersecurity capabilities, including security by design and resilience. Perhaps we’ll see the FDA adopt several of the points from this Hippocratic Oath to encourage manufacturers to take further steps to secure their devices development through to deployment and beyond.

My one criticism of the FDA’s guidelines is that they leave too much of the decision of what should be reported and how specific risks and vulnerabilities should be graded to manufacturers. The outline does include a few good examples of what controlled and uncontrolled risks are, but leaves it up to the manufacturer to judge where the line is.

We’ve seen multiple examples of manufacturers who refuse to acknowledge reported vulnerabilities in all industries, not just medical devices, which points to the need for concrete, defined reporting regulations rather than general ones. The guidelines are in comment phase, so there’s hope this will change as they approach finalization.

Medical devices with Bluetooth and other wireless technologies are here and constantly evolving. The convenience of being able to control a device from your phone or a website is too alluring for it to do anything but become the standard rule for such devices. Given that people’s lives will quite literally rely on the security of medical IoT devices, manufacturers simply have to secure them.

If Dick Cheney sees enough threat in medical IoT to have the wireless on his pacemaker disabled, perhaps the rest of us should take it seriously, as well. Or at least the FDA and medical device manufacturers need to.

Watch the on-demand webinar with Arxan and Forrester to learn more about securing the IoT

More from Application Security

What’s up India? PixPirate is back and spreading via WhatsApp

8 min read - This blog post is the continuation of a previous blog regarding PixPirate malware. If you haven’t read the initial post, please take a couple of minutes to get caught up before diving into this content. PixPirate malware consists of two components: a downloader application and a droppee application, and both are custom-made and operated by the same fraudster group. Although the traditional role of a downloader is to install the droppee on the victim device, with PixPirate, the downloader also…

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today