Cybersecurity Bill Of Materials For Medical Devices: What's Next?

By Sagar Patel, Battelle

The U.S. Food and Drug Administration (FDA) published an updated draft of Premarket Cybersecurity Guidance on October 2018. As part of the updates, the FDA introduced the concept of cybersecurity bill of materials (CBOM) for medical devices.

The proposed bill of materials to be submitted by the medical device manufacturers (MDMs) before devices are marketed would be “a list of commercial, open source, and off-the-shelf software and hardware components to enable device users — including patients, care providers, and healthcare delivery organizations (HDOs) — to effectively manage their assets, understand the potential impact of identified vulnerabilities to the device – and the connected system – and to deploy countermeasures to maintain the device’s essential performance,” states the guidance. While software and hardware bills of materials have been in use by the MDMs to varying extent, the aim here is to bring both under the same umbrella.

The rest of the updated draft focuses on several ways a CBOM can be leveraged by MDMs to improve processes and products — and have significantly better adherence to the FDA’s post-market cybersecurity guidance. At a very high level, a CBOM would contain the list of software components (proprietary and open source) and hardware components, along with their respective version numbers (if available).

Supply Chain Management for Hardware

Managing a healthy supply chain of hardware has been a focus of the technology industry at large, fueled primarily by concerns of foreign hardware manufacturers manipulating electronic chips to add backdoors in the system. In the absence of tracking information for the supply chain of hardware components, an MDM might end up using chips with backdoors, which could allow malware/ransomware unfettered access to the device and its resources.

Such backdoors can be leveraged later for wide-scale data theft, spreading ransomware, or as a part of botnets. Furthermore, the U.S. Department of Homeland Security has categorized Healthcare and Public Health Sector as one of sixteen critical infrastructure sectors whose assets, systems, and networks are considered vital to the United States.

This is where a CBOM containing a hardware bill of materials can assist regulators, users, and MDMs to verify and/or effectively manage the supply chain of critical components in a medical device. This also will enable MDMs in their device anti-counterfeiting efforts to holistically ensure that no counterfeit components are making their way in the supply chain.

Dependency Management for Software

Growing complexity in software can quickly spiral out of control, especially when developers are unaware about the dependency graph of the third-party commercial or open-source software they are including in the system. A CBOM containing a comprehensive software bill of materials can be leveraged to identify and manage software dependencies. Think of the Heartbleed vulnerability discovered in the OpenSSL library in 2014; as a manufacturer, knowing your product contained the specific version (1.0.1) of OpenSSL vulnerable to Heartbleed allowed you to effectively apply countermeasures.

Additionally, a CBOM can be integrated in the device development lifecycle to alert developers whenever they include third-party software that has a vulnerability or contains a vulnerable dependency. This can go a long way toward bootstrapping security into device development from the get-go. Another benefit of maintaining a CBOM is effective management of software licenses. Collaborative efforts are underway to standardize how information related to the components, licenses, and copyright associated with software packages is communicated.

Automated Vulnerability Search

An electronically digestible CBOM can be periodically cross-referenced against the National Vulnerability Database (NVD), or similar open vulnerability databases, to automate vulnerability monitoring and alerting. If a vulnerability is discovered in a specific software dependency or hardware chip being used in the device, the manufacturer can be alerted and can take necessary steps in timely manner.

Here’s an example scenario: a vulnerability that allows an attacker in proximity to change configuration of the device is discovered in a widely used Bluetooth communication protocol stack. If users are alerted in time, they can disable the functionality until an official recommendation or patch is issued by the MDM to fix the vulnerability.

Inventory/Asset Management

For HDOs, small and large, a typical pain point is managing the thousands of medical devices connected to their network. Traditional remote scanners can sometimes interrupt a device in use, raising patient safety concerns. It becomes vital to have a CBOM associated with each of the devices procured by the HDO. If a vulnerability is discovered in a specific device using a specific software/hardware, then it can be isolated from rest of the network, taken off the network in timely manner, or have its software updated, if a patch has been released by the manufacturer.

Software Updates

Many legacy medical devices do not employ any software update mechanisms. Delivering patches or bug fixes to the devices is practically impossible without issuing recalls or sending service personnel on-site to manually deliver updates. Increasing connectivity adoption in medical devices helps device manufacturers deliver software updates/patches remotely, but if developers don’t know what software is running the device, it is nearly impossible to release a timely security advisory or produce a patch for a vulnerability. This is where a CBOM can assist the device manufacturers in keeping track of all the software, its version information, source (commercial vs. open-source) and dependencies, so that they can produce a patch or contact the third-party for a patch when a vulnerability is discovered.

Concerns

Several medical device manufacturers have raised concerns regarding mandating CBOMs in the 510(k) or premarket approval packet. Some of these concerns include:

• Loss of confidentiality regarding software libraries and hardware components in use
• Potential loss of intellectual property due to having to disclose proprietary software details and dependency
• Anybody with lists of CBOMs would know which devices are vulnerable, reducing the effort a potential hacker may have to put into reverse engineering software
• Lack of guidance regarding how much depth would be required in the bill of materials. For example, do trivial hardware components like resistors or capacitors need to be reported?

The FDA is proactively working with the industry on several of these areas to bolster the cybersecurity guidance through industry feedback and discussions. Additionally, other stakeholders like the National Telecommunications and Information Administration (NTIA) are working with industry, nonprofits and vendors to explore a proof-of-concept format for a software bill of materials. Finally, NTIA has established a Software Component Transparency Initiative, which involves a healthcare-specific industry group working towards generating a standardized proof of concept format of software bill of materials.

Through combined efforts of various stakeholders, there is hope to alleviate some of these concerns.

About the Author:

Sagar Patel is Cybersecurity lead for Battelle’s DeviceSecure Services. Apart from working with device manufacturers, Sagar is responsible for development of new testing toolsets, conducting research into novel penetration testing techniques, and collaborating with product development teams for security aspects of internal product development. Sagar is a voting member of the AAMI Device Security working group, contributing to security guidance and standards for medical devices.