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 the device level, the interface level, the software system level or the operational level. In Part 3 of this white paper, we review current FDA guidance around cybersecurity, discuss common attack vectors 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 focus for the FDA in recent years. Empowered by new statutory authority, regulators may ask more cybersecurity-related questions of developers when reviewing software.

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 structure, 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 as well as information that speaks to actions developers took based on test results. Cybersecurity vulnerabilities identified in testing should be prioritized based on impact to overall safety and potential risk to patients.

Furthermore, the 2023 Omnibus Bill gave the FDA, among other things, additional statutory authority to demand more content around cybersecurity from the submitter than before. The FDA now has the ability to issue a “refuse to accept” to a device submission that 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”. The guidance also acts as a supplement to the following guidance documents: “Postmarket Management of Cybersecurity in Medical Devices”; “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software”; and “Content of Premarket Submissions for Device Software Functions.”

Though not specific to the subject, the “Multiple Function Device Products” policy is considered a “workhorse” in cybersecurity by FDA regulators. The policy defines clear boundaries between device functions and non-device functions. It also explicitly states that cybersecurity testing involves the entire system – the device parts, the non-device parts and all other dependencies that could add risk 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, the FDA expects a submission to have the following items:

Bluetooth captured in the device’s threat model and risk assessment.
Requirements around Bluetooth to ensure the most secure configuration possible.
A plan for Over the Air (OTA) firmware updates.
If the device uses the cloud, a plan for dealing with interruptions of 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 in compliance with the FCC, manufacturers need to perform specialized testing, typically in FCC-approved laboratories, to ensure 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 – which Bluetooth falls under – do not affect aircraft systems.

Developers should be aware of OSHA’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 on top of the existing cybersecurity risks of a software-enabled medical device.

Bluetooth connectivity between smartphone and device

The Bluetooth connection between a smartphone and medical device hardware is kept secure by 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 could allow bad actors to eavesdrop on the device and gain access to its data, or to command the device to provide inappropriate treatment that could lead to patient harm. It could also cause the app to pair with the wrong device and unintentionally expose medical data to a person or system that shouldn’t have access to it.

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 access to the medical device app.

Connectivity between other apps on the phone

Just as an unrelated device hardware can communicate with an app, an unrelated app installed on the user’s smartphone could theoretically communicate with the connected medical device hardware.

Connectivity to the cloud

When you have app connectivity to the cloud, you have to consider the cybersecurity vulnerabilities of that interaction. 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 operating system (OS) updates. An OS update could break some part of the device, potentially creating a new and unforeseen vulnerability.

Bluetooth for medical devices white paper CTA

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, a 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.

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 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, which were vulnerabilities within the code of Bluetooth Low Energy, soon after they were identified.

Cybersecurity for Bluetooth Medical Devices Best Practices

Cybersecurity 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 are 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.” The security measures in Bluetooth alone are not enough. Manufacturers need to add encryption and investigate interactions between the medical device app, smartphone and other apps on the phone. Some of Orthogonal’s recommended best practices are to:

Implement security controls underneath the Bluetooth layer, including encryption at rest and in transit.
Detect jailbroken phones and decide which parts of the app should be allowed to run, if at all.
Identify security holes in third party apps that live on users’ phones.
Establish trusted communication with Software Development Kits 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 legal aspects for interoperability.

Risk management process

Orthogonal recommends having a cybersecurity risk management process that integrates with the patient 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 manager role on a development team. This team member is responsible for overseeing cybersecurity risk management and testing.

Following NIST’s framework

The National Institute of Standards and Technology (NIST) provides an accessible 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 with 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 wireless security.

Monitoring

Device monitoring can help developers detect issues as they occur in devices both while in development and in production. By architecting the system to detect and report specific scenarios, and by deploying monitoring solutions, developers can spot issues as they happen and start working on mitigations immediately.

For example, devices can be designed to monitor for if the companion app is loaded onto a jailbroken phone. It is also possible to detect for hacks or phishing attempts.

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

Bluetooth chipset
Firmware OS
Bluetooth protocol
Smartphone OS
Contents of SBOM

Pairing

As detailed in Part 1: Introduction to Bluetooth for Medical Devices, some forms of pairing are less secure than others, making them easier for hackers to exploit. Options such as Out-of-Band pairing and using an encrypted pass key help not only to reduce attack vectors but also to satisfy the FDA’s requirement that developers implement the most secure configuration possible for their devices.

Application level security

Orthogonal recommends implementing application layer security for medical device systems, including on firmware, mobile app and cloud. These can include code obfuscation and encryption with dynamic keys, as well as data encryption in flight and at rest. This 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 the vulnerabilities in a Bluetooth-enabled medical device system and addressing them during development, it is possible to reduce the amount of system risk as well as risk 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: