Cybersecurity for Bluetooth Medical Devices

Bernhard Kappe

Published on: November 17th, 2023

This blog contains Part 3 of the Orthogonal White Paper titled “Bluetooth for Medical Devices.” The following are links to each part of the white paper:

For more in-depth discussions on Bluetooth from medical device experts, visit our page on our Bluetooth Low Energy for Medical Devices Webinar Series, co-presented by MedSec.

– – –

Table of Contents show

Part 3: Cybersecurity

Wireless connectivity introduces increased security risks to a connected medical device system, and Bluetooth is no exception. Vulnerabilities can occur at different levels: the device itself, the interface, the software system or the operational level. In Part 3 of this white paper, we review current FDA guidance on cybersecurity, discuss vulnerabilities that Bluetooth adds to medical devices and share best practices for addressing risk, both pre- and post-release.

The FDA on Cybersecurity

Cybersecurity has become a much bigger priority for the FDA in recent years. Empowered by new statutory authority, regulators will likely ask more cybersecurity-related questions of developers when reviewing software developed for medical devices.

What is the current FDA guidance on cybersecurity for medical devices?

The FDA published their final guidance on cybersecurity in September 2023, titled “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.” In it, the FDA outlines the “general principles” that they expect medical device manufacturers to conform to in order to ensure both software and patient safety. These principles include:

Integrating cybersecurity activities into quality system regulations.
Implementing security objectives like authorization, authenticity and confidentiality into software architecture.
Creating clear cybersecurity labeling for the device to ensure transparency.
Having detailed documentation of cybersecurity risks and mitigations performed for device submission.
Using a structured approach, such as a Software Product Development Framework, to guide development throughout the product’s lifecycle.
Producing a Software Bill of Materials (SBOM) to aid in managing cybersecurity risks across a software stack.

The document also details the cybersecurity testing the FDA expects to see in documentation, as well as the evidence manufacturers need to support that testing. Submissions should include full test reports and information describing the actions taken by developers based on the test results. Cybersecurity vulnerabilities identified during testing should be prioritized based on their impact on overall safety and potential risks to patients.

Furthermore, through the 2023 Omnibus Bill, the FDA gained additional statutory authority to demand for more information about cybersecurity from those submitting devices than they could before. The FDA now has the ability to issue a “refuse to accept” a device submission if it does not meet their standards for cybersecurity.

Other FDA guidance on cybersecurity

The September 2023 final guidance document supersedes “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices – Final Guidance, October 2, 2014”. Other past guidance documents act as supplements, including: “Postmarket Management of Cybersecurity in Medical Devices” from 2016; “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” from 2005; and “Content of Premarket Submissions for Device Software Functions” from 2023.

Though not specific to cybersecurity, the “Multiple Function Device Products” policy document is considered a “workhorse” in cybersecurity by FDA regulators. The policy defines clear boundaries between device functions and non-device functions, emphasizing that cybersecurity testing covers the entire system, including device and non-device components and other dependencies that could add risks through adverse interactions.

Has the FDA published Bluetooth-specific guidance on cybersecurity?

Currently, no formal Bluetooth-specific guidance on cybersecurity exists, but from Orthogonal’s experience and ongoing conversations with industry peers, the FDA expects submissions to have the following items:

Inclusion of Bluetooth in the device’s threat model and risk assessment.
Requirements related to Bluetooth to ensure the most secure configuration possible.
A plan for OTA firmware updates.
If the device uses cloud services, a plan for dealing with interruptions in connectivity to the cloud.

What other U.S. regulatory standards do Bluetooth-enabled medical devices need to meet?

All wireless medical devices are expected to meet the FDA’s and Federal Communication Commission’s (FCC) wireless device standards. To be compliant with the FCC, manufacturers are required to perform specific tests, typically in FCC-approved laboratories, ensuring wireless devices function correctly in their intended use environments.

The Federal Aviation Administration offers guidelines for portable electronic devices’ (PED) radiofrequency emissions in RTCA DO-160G. In 2017, they stated in an advisory circular that PEDs may use Bluetooth during flight without complying with DO-160G, as low powered emissions do not interfere with aircraft systems.

Developers should also be aware of the Occupational Safety and Health Administration’s nonionizing radiofrequency standards, as it may apply to a medical device used in a work environment.

Connectivity Areas of Concern for Bluetooth Medical Devices

Bluetooth connectivity adds additional areas of cybersecurity concern for a software-enabled medical device.

Bluetooth connectivity between smartphone and device

The security of the Bluetooth connection between a smartphone and medical device hardware relies on the pairing method chosen by the device architect. If that pairing method is not encrypted enough, or if it fails due to an unforeseen occurrence, it leaves the system open to exploitation.

Poor encryption may enable unauthorized access to device data, eavesdropping or manipulation of the device for inappropriate treatment, risking harm to patients. It could also cause the app to pair with the wrong device and unintentionally expose medical data to unauthorized individuals or systems.

Connectivity between other linked devices

Medical devices are just one of the many devices connected to apps on a user’s smartphone via Bluetooth. Unrelated devices, like smartwatches or wireless headphones, could potentially gain inappropriate access to the medical device app.

Connectivity between other apps on the phone

Similar to unrelated device hardware communicating with an app, an unrelated app installed on the user’s smartphone could theoretically communicate with the connected medical device hardware, posing potential security risks.

Connectivity to the cloud

When an app is connected to the cloud, it’s critical to consider the cybersecurity vulnerabilities involved in that connection. Establishing app connectivity to the cloud over Bluetooth Low Energy (BLE) without implementing the proper security measures on top of BLE security may add additional remote attack vectors to a connected device.

bluetooth white paper part 3 graphic edit — *Illustration of the connectivity between devices, smartphone apps and the cloud*

OS updates

As discussed in Part 1: Introduction to Bluetooth for Medical Devices, medical device developers are not in control of the content or frequency of smartphone OS updates. An OS update could break some part of the device, potentially creating a new and unforeseen vulnerability.

Potential Cyberattacks for Bluetooth Medical Devices

Manufacturers of Bluetooth-enabled medical device systems need to be on the lookout for these Bluetooth-specific cyberattacks on smartphones.

Bluesmacking

In Bluesmacking, the attacker sends an oversized data packet over the L2CAP layer of Bluetooth’s networking stack to trigger a Denial of Service (DoS). DoS attacks can pose problems for devices that rely on Bluetooth connectivity for their functioning, or implanted devices where an external reboot is not possible, and can mask other, more dangerous attacks.

Bluejacking

In Bluejacking, one Bluetooth device hijacks another by spamming its advertising signal, with the intent to send the victim spam messages or other junk data.

Bluesnarfing

In Bluesnarfing, an attacker exploits the Bluetooth connection and gains access to the victim’s device to steal data from it. Devices set to “discoverable” can be easy targets for Bluesnarfing.

Bluebugging

In Bluebugging, an attacker uses Bluetooth to create a backdoor into the victim’s device, allowing attackers to listen in on calls and other conversations without the victim’s knowledge.

Bluetooth exploits

At times, vulnerabilities are discovered in the Bluetooth code itself. If device manufacturers are not aware of these vulnerabilities, they can be easily exploited by bad actors. Fortunately, when such exploits are discovered, agencies such as CISA, ISAOs such as MedISAO, hardware and software developers like Apple and Microsoft and open source projects like Linux publish advisories and alerts.

For example, the FDA published a notice about the SweynTooth exploits soon after they were identified in 2020, which were vulnerabilities within the code of Bluetooth Low Energy.

Bluetooth for medical devices white paper CTA

Cybersecurity for Bluetooth Medical Devices Best Practices

Ensuring cybersecurity in Bluetooth medical devices should be an ongoing process woven into the product development life cycle. Doing so helps manufacturers avoid costly issues that can extend development time and add to the budget. The following describes some of Orthogonal’s best practices for managing cybersecurity for Bluetooth-enabled medical devices.

Meeting FDA requirements

Key to meeting FDA requirements for Bluetooth-enabled medical device cybersecurity is adopting a mantra of “trust, but verify.” Relying solely on Bluetooth’s built-in security measures isn’t enough. Manufacturers should enhance security by using additional encryption and investigating interactions between the medical device app, smartphone and other apps on the phone. Some of Orthogonal’s recommended best practices are to:

Implement additional security controls underneath the Bluetooth layer, including encryption data while it’s stored and when it’s being sent.
Detect jailbroken phones and decide in that scenario which parts of the app should be allowed to run, if at all.
Identify security holes in third party apps that users have installed on their phones.
Establish trusted communication with Software Development Kits (SDKs) used within the app and with other apps. Determine who is responsible for security, whether it is unidirectional or bidirectional, and work out shared security certificates and address the legal aspects of interoperability.

Risk management process

Orthogonal recommends integrating cybersecurity risk management into the overall device risk management process. Just as patient risk is considered at the start of development, cybersecurity risk management should begin early in the process as it has implications for device architecture and mitigation requirements that come out of the analysis process.

On the personnel side, it’s recommended to have a cybersecurity lead role within the development team to oversee cybersecurity risk management and testing.

Following NIST’s framework

The National Institute of Standards and Technology (NIST) provides a Risk Management Framework, as well as specific guidance on cybersecurity for Internet of Things (IoT) devices.

Best practices from OWASP

Open Worldwide Application Security Project (OWASP) is a software security nonprofit providing free resources for anyone looking to improve the security of their development projects. They host a number of prescriptive recommendations for security for mobile apps and web apps, including measures for wireless security.

Monitoring

Device monitoring can help developers detect issues as they occur in devices during development and production. By architecting the system to detect and report specific scenarios, and by deploying monitoring solutions, developers can quickly spot issues and mitigate issues as they arise.

For example, devices can be designed to check if the companion app is installed on a jailbroken phone. It is also possible to detect hacking or phishing attempts.

It’s also recommended to monitor any part of the medical device system that may have vulnerabilities, including:

Bluetooth chipset
OS Firmware
Bluetooth protocol
Smartphone OS
Contents of SBOM

Pairing

As detailed in Part 1: Introduction to Bluetooth for Medical Devices, some techniques for pairing devices are less secure than others, making them more vulnerable to hackers. Using secure options such as Out-of-Band pairing and using an encrypted pass key not only reduces the chance of an attack but also meets the FDA’s requirement for developers to implement the most secure configuration possible for their devices.

Application level security

Orthogonal recommends implementing application-level security measures for medical device systems, covering firmware, mobile apps and cloud. These measures may include code obfuscation (making code hard to decompile or disassemble) and encryption with dynamic keys, as well as data encryption in flight and at rest. These steps can prevent attackers from reverse-engineering the application, as well as prevent hacking and manipulation of data.

Conclusion

Cybersecurity risk is constantly evolving, and methods for addressing that risk are evolving as well. By understanding and addressing the vulnerabilities in a Bluetooth-enabled medical device system during development, we can reduce the overall risk to the system and, most importantly, minimize the risks to patients’ health.

– – –

This blog contains Part 3 of the Orthogonal White Paper titled “Bluetooth for Medical Devices.” The following are links to each part of the white paper: