The United States Food and Drug Administration (US FDA) is looking for ways to compel medical device manufacturers to prioritize cybersecurity. Given the rash of ransomware attacks in healthcare, and across other industries, and the recently released Executive Order 14028, which we summarized in an earlier post, the timing seems to be right. According to an interview with Suzanne Schwartz, director of Strategic Partnerships and Technology Innovation at the FDA’s Center for Devices and Radiological Health Office, FDA is seeking “legislative authorities” to enable the office to require medical device manufacturers to adhere to strict cybersecurity policies, including the development of a Software Bill of Materials (SBOM).
Healthcare Attacks Continue
Healthcare has long been a favorite target for bad actors, and the most recent rash of ransomware attacks underscores the need for decisive action that would strengthen the security posture of this critical industry. Hospitals are frantically searching for ways to “stay off the front page” and to tighten security, in the hope of defending against cyberattacks. But hospitals need more information about the medical devices being deployed on their networks. They need basic information such as which software components are running inside those deployed devices, and which of those components might have exploitable vulnerabilities. This is where the Software Bill of Materials (SBOM) comes into the picture.
Software Bill of Materials as a Requirement
FDA is emphasizing the requirement of SBOM for medical device manufacturers because the SBOM provides the much-needed transparency for end users that enables awareness of potential vulnerabilities. These potential vulnerabilities are hidden today and could represent exploitable opportunities for bad actors. FDA refers to the SBOM as a “list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.” By providing SBOMs to their end users, medical device manufacturers are effectively removing the black boxes surrounding their devices.
MDMs Need to Start Preparing Now
Given FDA’s plans to require SBOMs from medical device manufacturers, it makes sense to start planning for this inevitability. For most manufacturers, developing and integrating an SBOM process/procedure into a secure software development lifecycle will take some time. In most cases, MDMs have not been generating SBOMS to date, at least not consistently. So, this exercise will require resource planning, process development, and multi-stakeholder involvement. Generating one SBOM is quite different from developing a scalable process that can handle generation and continuous maintenance of one or more SBOMs to satisfy regulatory requirements, prospects, and customers.
Vulnerabilities and SBOM
SBOM is an evergreen document, in the sense that the vulnerabilities associated with the components utilized are dynamic. As you are reading this document, a vulnerability is being discovered, and hopefully reported, in one of the commercial off-the-shelf or open-source components utilized somewhere in some manufacturers’ product or device. Exploiting these vulnerabilities is a full-time job for some trying to cause harm, so the bad actors are also actively seeking vulnerabilities, however, they are leveraging them in a much more nefarious way.
The Real Problem is Timing
While vulnerabilities are being discovered and communicated, the current practices are just not fast enough. And for device manufacturers with lots of components in several versions of several devices, trying to continuously monitor associated vulnerabilities, is more than just time-consuming, it is nearly impossible. This is where SBOM automation comes into the picture.
MDMS Need a Plan to Automate SBOM
President Biden and FDA both say SBOM is a critical requirement. In other words, SBOM is here to stay. But generating an SBOM manually requires effort, and that doesn’t even begin to address the problem of how to maintain the generated SBOM. The vulnerabilities for the SBOM components must be discovered, which requires matching component information with various sources, some with millions of records. After that initial match, the only way to be sure that the SBOM is accurate is to continuously monitor those sources of vulnerabilities. Attempting to do all of this manually, even for a single SBOM, is a costly undertaking. Clearly, automation will be necessary, so it is advised to plan accordingly.
Summary
Medical device manufacturers will be required to provide SBOMs with their new product submissions to get FDA approval. In addition, hospitals will begin (actually, have begun) requiring SBOMs for new purchases and for deployed devices. The MDS2 revision, introduced in 2019, has a section for SBOM details. Taking a wait-and-see approach to SBOM is a recipe for disaster. There are forward-thinking medical device manufacturers that have already started down the SBOM path, but for most, this will be a new undertaking. Start now.
