Imagine a new malware attack has emerged, targeting hospital networks and the medical devices that operate on them. Think fast—are your medical devices vulnerable? If you don’t have complete transparency into all of the software components that make up your device, it’s a surprisingly difficult question to answer quickly.
This scenario is not theoretical. In 2017, the WannaCry ransomware attack shut down hospitals across the UK and resulted in billions of dollars of damages globally. Hospital buyers and regulators are increasingly concerned about the potential for medical devices to become a vector for spreading malware attacks onto hospital networks.
That’s why the FDA and other regulators have begun requesting a complete Software Bill of Materials (SBOM)as part of the regulatory submission for medical devices. But simply listing the basic software components in your device isn’t enough. To create an SBOM that will meet the needs of all stakeholders, you need to know what to include, how to document it so that it is useful and usable, and how to share it with the people who need it. A usable SBOM must be: 1) complete; 2) formatted according to consistent industry standards (and, ideally, machine-readable/searchable); and 3) easily shareable with all stakeholders.
Creating Your Ingredient List: What Belongs in the SBOM?
Let’s start with “complete.” The SBOM is the “ingredient list” for the software in your medical device. It includes all of the operating systems, libraries, browsers, buffers, compression engines and other pieces of code within your device. That includes not just the top-line components, but the sub-components within each piece of software you use. And that’s where things get difficult.
For example, imagine you are creating a new infusion pump. You may use five to ten main software elements, including an off-the-shelf operating system, a browser, some libraries, and some custom applications for the device. You may know exactly what is in your custom applications, but do you know what subcomponents are in the third-party operating systems, libraries and browsers that you are using? Each of these third-party components may have dozens of subcomponents—and, ideally, your SBOM will include all of them.
To understand what we’re talking about, think about how recipes are written. Your grandma’s green bean casserole recipe may call for fresh green beans, a can of mushroom soup, parmesan cheese, French-fried onions and a few other prepared and simple ingredients. That’s enough for most purposes, but if you are worried about allergies, you also want a complete list of ingredients in that can of soup and other multi-ingredient, off-the-shelf components. Your SBOM is the complete ingredient list, not just the top-line recipe.
A complete SBOM is a nested inventory that includes the component name, supplier name, version, author name and relationship information for each known subcomponent within the software ecosystem for the device. It should also note where information about the components of a third-party piece of software is unknown. Here’s a simplified example of what we’re talking about:
Writing an SBOM That Others Can Read
Once you’ve figured out what is in your device, you then have to determine how to write and format the SBOM so that it is useful and usable for your internal development and compliance teams, the FDA and other regulators, and hospital buyers and IT managers.
Formatting may seem like a small issue compared to identifying the software components, but it’s a big deal when it comes to usability and searchability for your SBOM. For example, if some SBOM authors write out Windows 7 and others use abbreviations like Win 7, Win.7, Win-7, W-07, etc., it makes it difficult to quickly find all of the devices that use a specific operating system and version.
This becomes a major problem for hospital networks that may have hundreds of different types and models of devices in use and tens of thousands of individual devices spread across multiple locations. When a new malware attack is identified, hospital IT teams must work quickly to identify all of the devices that contain the software vulnerability so they can deploy the right patch or take them off the network until a patch is available. In this scenario, it is vital that the SBOMs for all of the devices on their networks are easily comparable, searchable and, preferably, machine-readable.
Common industry standards for SBOM formatting will make them easier to share and use for all stakeholders in the medical device industry. In addition to helping end users, common standards, such as SPDX or SWID, will make it easier for medical device manufacturers to ingest SBOMs for all of their sub-components into their software inventories. Common industry standards will also help regulatory bodies understand SBOM submissions.
Establishing a Common SBOM for the Medical Device Industry
If you’re not sure how to create an SBOM for your medical device that meets emerging regulatory standards and stakeholder needs, you’re not alone. Fortunately, you have help. The National Telecommunications and Information Administration (NTIA) Software Transparency Project is working on common formats and standards for medical device SBOMs.
I co-lead the SBOM Framing Group for the NTIA Software Transparency Group with Art Manion from CERT. Along with my colleague Garrett Sipple and other industry leaders, we are working towards the establishment of a voluntary “Common SBOM” framework for the medical device industry. This defines the minimum set of information that should be captured in an SBOM. It also includes guidance on how to create, use, exchange and manage SBOMs. You can read about our work and find answers to SBOM FAQs on the NTIA website.
Preparing for Emerging SBOM Regulatory Requirements
Some regulatory bodies, such as Health Canada, already require an SBOM, and others strongly recommend them. The FDA does not yet require an SBOM for regulatory submission, but they are currently working on updates to the medical device cybersecurity guidance documents that will include an SBOM requirement. Their requirements are expected to draw heavily from the Common SBOM framework established by the NTIA SBOM Framing Group.
Medical device manufacturers should start developing a process for SBOM creation and management now to ensure that they will be ready for emerging regulatory requirements and the expectations of hospital buyers. Creating an SBOM that is complete, usable and sharable demonstrates to regulators and buyers that your organization is able to control security vulnerabilities for your devices. It will also help device manufacturers reduce their own risks and provide better, faster support for affected customers when a new vulnerability is discovered.
Author: Michelle Jump
About Michelle
Michelle Jump is widely recognized as one of the leading experts on Global Regulations, Standards and Guidance on medical device cybersecurity and software, having led or been a major contributor to the creation of many of the industry-respected documents. Michelle routinely consults in the healthcare industry to help customers incorporate cybersecurity into their product development processes and quality systems.
For more information, please contact info@medsec.com