At the IBM Security Summit in 2018, X-Force Red Global Head Charles Henderson told a memorable story. A colleague frantically reached out one Friday afternoon asking him to test five medical internet of things (IoT) devices. One of the devices was to be implanted in the colleague’s body, and he wanted to make sure he chose the most secure model. Charles immediately called his hacker friends, who happily agreed to help him with the research. Within a couple days, Charles recommended a specific model to his colleague, confident the model was the least hackable.

Unlike Charles’ colleague, most patients do not have someone on hand to test their medical IoT devices prior to implantation, which is why it’s critical for device manufacturers to build security into the devices from the earliest stages of development. Patients should be able to trust that the devices in their bodies have no critical vulnerabilities that criminals could potentially exploit.

A Q and A With ‘Q’: Reviewing the FDA’s Guidance on Medical IoT Devices

On Jan. 29–30, 2019, the Food and Drug Administration (FDA) will host a public workshop to discuss medical IoT security. The discussion will focus on the recently drafted guidance titled “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” which aims to help strengthen cybersecurity across medical IoT devices.

Catherine Norcom, X-Force Red’s resident hardware hacker, specializes in building and testing IoT devices in the medical field. Catherine, also known as “Q,” recently joined the team after serving 10 years in the U.S. Air Force.

I chatted with Catherine about the FDA’s guidance, the top risks related to medical IoT devices and how to minimize those risks.

Question: Thank you for taking the time to chat today, Catherine. Which parts of the FDA’s guidance do you think may be most effective?

Catherine: I like the objective of the guidance. Manufacturers of medical IoT devices should be prioritizing security, especially considering the potential detrimental consequences of a breach. Specifically, I like the clause about logging people out after a period of inactivity. I also like the clause that discusses the need for rapid deployment of patches and updates.

However, that clause actually contradicts another clause in the guidance that recommends users approve any product updates before they are installed. That being said, in November 2018, the FDA provided more details on this topic, saying critical patches can and should be applied without user approval. I also think that’s an important update. After all, patient safety should not vary from user to user, simply based on whether they have the resources to process and deploy critical patches in a timely fashion. The FDA should include those details in the guidance.

I also like that the guidance promotes encrypting any information stored on devices and requires authentication of some kind before the user accesses medical information coming from the device. That way, if a user left a device on a bus, for example, someone else could not access the user’s private medical information.

Where do you think the guidance could be improved?

There are some parts that seemed like they could vary in meaning. For example, the guidance recommends assessing risk and mitigation throughout a product’s life cycle. However, manufacturers and end users can have different interpretations of what constitutes the life cycle of a product. Obviously, manufacturers will release newer versions of products, whether it’s because of their own innovations or due to external factors such as a pending update to a third-party operating system or plug-in that makes the existing product design a challenge to maintain.

When a manufacturer releases a new version of a product, they cannot continue to support all older versions of that product in the same manner they did before. But even after the manufacturer needs to end its support, the product may still work fine for some period. And even if it doesn’t work as well as it once did without manufacturer support, the user may choose to continue using and servicing it themselves. Although this is a difficult subject to address, it could be valuable if the guidance is able to spell out in more detail what the expectations are for manufacturers and users at different stages of a normal product life cycle. There are other FDA documents that include more details about this matter, but it should be spelled out in this guidance as well.

The guidance also uses buzzwords like “holistic.” Many manufacturers — and, frankly, people in general — do not know what that term means or else they could interpret it differently. Also, a part of the guidance recommends manufacturers identify vulnerabilities up front. This is both exceedingly nuanced and complex. For example, even if a manufacturer identified a vulnerability in the Wi-Fi connection, they may not know the USB port is also vulnerable. In this case, you need penetration testers to assess risk throughout the process – whether that’s hiring outside specialists or someone in-house. Penetration testers, who are hackers, understand the many different ways criminals may exploit individual vulnerabilities or chain them together to compromise a device. As such, testers can identify how criminals may exploit vulnerabilities – whether it’s one or many chained together – exposing a device and connected ecosystem.

Since X-Force Red specializes in cybersecurity, let’s pivot the conversation and discuss security risks that come with medical IoT devices.

Medical IoT devices are a top target of cybercriminals, so even if a manufacturer thinks it has developed a device with reasonable security, criminals may still find vulnerabilities. I recently read a Ponemon Institute study that said 67 percent of medical device makers believe an attack on one or more medical devices they have built is likely.

One of the most obvious points of vulnerability is if the user loses the device or the device is stolen. If criminals get physical access to the hardware, they may be able to access all of the medical data in that device. They could also potentially reverse engineer the device and in this way gain access to even more information that is stored on underlying servers. That information could aid in planning a larger attack against the device manufacturer or help criminals use patient identity in insurance fraud or other schemes.

Yes, physically stealing a device would provide the easiest pathway to compromising it. What about the risks related to the Wi-Fi connection used by most IoT devices?

Obviously, anything connected to Wi-Fi can potentially be compromised. A brute force attack is one of the more popular attack methods. The service set identifier (SSID) is the Wi-Fi network name you see when you try to connect. If a device broadcasts its SSID, for example, a criminal would see the device on the Wi-Fi network and may try every password under the sun until one grants him access. These attacks are typically automated by computers and it can take mere seconds to brute force a weak password.

Also, if the Wi-Fi connection from the device is not secured and the data stored on the device is not encrypted, a criminal could intercept the packets and access medical data as it moves from the device to the router. Essentially, a criminal could grab the device’s stored medical data as it moves through the air.

What about USB ports? Many medical IoT devices contain USB ports similar to those we use to charge our cellphones.

Yes, USB ports on medical IoT devices can be used to transfer data. If someone plugs into the device’s USB port and the stored data is unencrypted, the person could potentially access the data. It’s similar to your cellphone: If you plug a USB cable into your phone and connect it to a laptop, you can see the data on your phone and move it to your laptop.

As a rule, people should avoid connecting to any USB port they do not control. That means avoiding those in airports, airplanes, public places, etc. Behind every USB port, there can be a device reading data without explicit permission.

So, what can IoT medical device manufacturers do to strengthen the security of their products as they’re being developed?

First, developers should make sure the device’s SSID is hidden so it doesn’t show up on Wi-Fi networks. Also, IoT manufacturers will oftentimes give all their devices the same SSID. For example, devices that are meant for the kitchen will have the SSID “kitchen.” If devices have the same SSID, then a criminal can connect to them even if they are hidden. It’s crucial that devices have unique SSIDs and preferably let their owners name them to create random names that attackers won’t be able to readily look up.

Good security practices for an application programming interface (API)-enabled device include making sure a criminal doesn’t have access to the API key — which is like a password — so that he or she can’t read the private medical data that the medical device is logging.

An easy and obvious recommendation is to use encryption. Any data on the device and the connection to the wireless hotspot or cell phone should be encrypted. Encryption will disable criminals’ ability to read private data whether they steal packets or plug into a USB port. Manufacturers can also make proprietary software that only talks to the specific IoT device and enables it to securely decrypt the data on it.

It’s also critical to have a secure connection between the device and Wi-Fi access point you are using. The device should not connect to anything that doesn’t require authentication.

Finally, manufacturers must test their hardware and software as the device is being developed. Manual penetration testing can uncover unknown vulnerabilities that automated tools may not find. For example, testers can determine whether the software was programmed in a way that makes files difficult to read. As they are writing and developing the device and its software, manufacturers should consult a security expert at every step, from selecting products to testing during development, and test after the device is built.

Any last words or recommendations for the FDA as it works to finalize the guidance?

Unfortunately, hacking an IoT device, medical and nonmedical, is oftentimes not that difficult. At the DEF CON hacker conference, people with little experience were hacking IoT coffee pots and voting booths in minutes. When you allow an IoT device on your network, if the device has a vulnerability, a criminal can easily compromise your entire network. That’s why it’s critical for all IoT manufacturers to prioritize security when developing their products.

This guidance is a step in the right direction to achieving that goal. It gives some really strong recommendations and places a focus on the subject of IoT security. The FDA is inviting comments from medical device and component manufacturers, independent researchers and security firms, which will be extremely beneficial in shaping the final draft. It’s always encouraging to see the security world’s perspective being brought into the development of this kind of guidance.

Listen to the X-Force Red in Action Podcast Series