.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
SBOM Requirements for Medical Devices
Learn about the 2023 FDA rule for medical devices, including requirements for SBOMs, a mitigation plan, and secure software development practices.
Learn about the 2023 FDA rule for medical devices, including requirements for SBOMs, a mitigation plan, and secure software development practices.
Learn about the 2023 FDA rule for medical devices, including requirements for SBOMs, a mitigation plan, and secure software development practices.
Learn about the 2023 FDA rule for medical devices, including requirements for SBOMs, a mitigation plan, and secure software development practices.
Learn about the 2023 FDA rule for medical devices, including requirements for SBOMs, a mitigation plan, and secure software development practices.
IoT devices have revolutionized healthcare, enabling individuals to take greater ownership of their own health and access medical care even in underserved regions. But the industry experiences high attack volumes, and according to the 2022 report The Insecurity of Connected Devices in Healthcare, more than half of respondents experienced a cyberattack involving an IoT / IoMT device. Over the last decade, the U.S. Food and Drug Administration (FDA) led regulatory action, most recently with Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act). Known as “Ensuring Cybersecurity in Medical Devices,” this rule sets forth requirements for legally-marketed medical devices.
In this blog I’ll outline the FDA requirements and share some best practices organizations can take to be compliant, especially when leveraging open source software (OSS).
What is a Cyber Medical Device?
Section 524B defines a “cyber medical device” as one that:
- Includes software validated, installed, or authorized by the sponsor as a device or in a device;
- Has the ability to connect to the internet; and
- Contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.
In other words, it’s a device that has software, can connect to the internet, and is potentially vulnerable to cyber attacks. It’s an incredibly broad definition (rightly so) that includes both personal and healthcare provider devices such as monitoring devices, blood glucose meters, smartwatches, and more.
FDA Requirements for Cyber Medical Devices: An SBOM with “Teeth”
There are three core requirements that manufacturers must meet to achieve FDA approval:
- A Risk Mitigation Plan
- Use of Secure Development Processes
- A Software Bill of Materials (SBOM)
Requirement #1: A Risk Mitigation Plan
Manufacturers must submit their plan “to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated
vulnerability disclosure and related procedures.” This includes patches and updates on a regular cycle and as-soon-as-possible patches for serious vulnerabilities found outside of the normal patch cycle.
OSS Considerations for a Mitigation Plan
- Software Composition Analysis (SCA)— The first area to consider is an SCA tool to identify potential risks. But don’t pick just any SCA! Traditional SCAs generate high rates of false positives or false negatives (depending on whether they’re static or dynamic). This means your development team spends all their time chasing vulnerabilities that don’t matter or you have a false sense of security. You need an SCA tool that reduces noise through reachability and saves time by generating an SBOM.
- Vulnerability Disclosure and Patch Development— While these seem like obvious best practices even if you’re not beholden to the FDA, the reality is they’re uncommon. I recently spoke with a Gartner analyst who said “undermangement is the biggest risk” to organizations being compliant and secure. And unfortunately she said many organizations aren’t applying fixes or doing it inconsistently, or they’re not updating working code with new patches, because they don’t have a management program in place to make sure it’s happening.
Requirement #2: Use of Secure Development Processes
In addition to the mitigation plan, manufacturers seeking FDA approval must “design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure…” This includes patches and updates on a regular cycle and as-soon-as-possible patches for serious vulnerabilities found outside of the normal patch cycle.
OSS Considerations for Secure Development Practices
To be effective in this area, you’ll need to make sure three groups of people are engaged:
- Your development team which will be tasked with putting these processes and procedures into action
- Platform ops or engineering, which will be responsible for any necessary tooling and platform architecture
- And of course IT security, which will need to be able to be able to articulate how these processes and procedures make the device more secure
These three groups should work together to outline which practices and philosophies they’ll use. Fortunately the last few years have seen the creation/growth of some useful tools and frameworks. Start by investigating Software Lifecycle Security Assurance Processes (SLSA) and the Secure Software Development Framework (SSDF), which go hand-in-hand as tools to integrate security into the software development lifecycle. Also, if you haven’t already starting adopting a Zero Trust (ZT) philosophy, now’s the time! Although ZT has become incredibly hyped, integrating the principle of “never trust, always verify” will help set you up for a security-first mentality.
If you’re interested to see what secure development can look like for an open source project, read Kubernetes Secure Development Best Practices in Action.
Requirement #3: A Software Bill of Materials (SBOM)
Finally, an SBOM is required that includes “commercial, open-source, and off-the-shelf software components.” Making a really good SBOM requires collaboration and involvement from various stakeholders throughout the software supply chain. To start this includes development, platform, and security teams but can also include compliance, procurement, legal, and vendors. Bringing together a broad group of stakeholders can ensure your SBOMs capture the necessary information about software components, enhance supply chain security, and facilitate risk management and compliance efforts.
OSS Considerations for SBOMs
SBOMs have something of a bad reputation because they’re often seen as an “ingredients list” and compliance checkbox. There are three steps you can take to make your SBOMs truly useful.
- High-quality data— Garbage in, garbage out! Again this seems obvious, but consider this: Most SBOM tools only pull data from the manifest, but many open source projects have dependencies that aren’t declared in the manifest. Consequently, these “phantom dependencies” won’t appear in most SBOMs, leaving you with an incomplete picture of your software supply chain.
- Vulnerability annotations— Another reason SBOMs can be unpopular is because the second a customer gets one, they’re going to compare it to a national vulnerability database that will inevitably prompt a round of investigating potential vulnerabilities. This is a painful investigation process that can be avoided by using a tool that annotates vulnerabilities, informing the viewer which ones actually matter. Vulnerability Exploitability eXchange (VEX), developed by the U.S. government, is an emerging format that communicates the vulnerability details, exploitability, and detailed analysis. Generating a VEX along with your SBOM can make life much easier.
- SBOM governance— Too often when an SBOM is created, it ends up getting stored in a random SharePoint library and forgotten about. As you may have experienced, this chaos makes it harder to research which apps contain the next Log4j! Invest in a structured way to track and version control 1st and 3rd party SBOMs. Ideally the governance platform should ingest, parse, and analyze the information.
Building Security into the SLDC
Although this regulation is unique to the healthcare industry, the requirements are essential to any device or software vendor. If you’re new to building security into the software development lifecycle, check out our latest LeanAppSec course, Implementing Open Source Security & Dependency Management. This free on-demand training helps security and dev teams learn about:
- Planning— Creating organizational standards for dependency management
- Requirements— Gathering requirements from stakeholders and reconciling them with the plan
- Design— Understanding how the desired plan and ongoing requirements will be implemented
- Development— Constructing coding guidelines to make our lives easier
- Testing— Implementing guardrails to ensure quality and security
- Monitoring— Detecting and responding to ongoing issues and maintenance