FDA's New Cybersecurity Requirements: Are You Prepared as a Medical Device Manufacturer?

Where To Begin?

Companies submitting products for FDA approval must do the following:

1. Provide details of their process to monitor, identify, and remediate vulnerabilities
2. Develop and maintain processes to ensure new patches are released and communicated regularly and immediately address critical vulnerabilities 
3. Provide a Software Bill of Materials (SBOM) that includes details of the commercial, open-source, and off-the-shelf software components in your tech stack
4. Comply with any other regulations or requirements the government may introduce to demonstrate the security of devices and their related systems 

What Are The Risks of Not Following Cybersecurity Standards?

Medical devices increasingly face scrutiny from security researchers as they become more interconnected. Many high-profile news stories have outlined how researchers have exploited vulnerabilities in insulin pumps, pacemakers, and other connected medical devices. A 2022 report by the FBI cited research finding that 53% of digital medical devices and other internet-connected products in hospitals had known critical vulnerabilities. "Malign actors who compromise these devices can direct them to give inaccurate readings, administer drug overdoses, or otherwise endanger patient health," according to the FBI report.

With cybercriminals increasingly targeting hospitals with ransomware campaigns, it's not a great stretch to a future where they target individuals, threatening or ransoming a user's health for a pay-off. There's also the seemingly more mundane, but no less important, risk of data exposure and access into wider networks from exploiting a vulnerability in a device as an entry point. 

Finally, aside from the potential risk to patients, companies that cannot provide the FDA with the above will find their products receiving a "refuse to accept" decision when submitted for approval after October 1, 2023, meaning you could be unable to bring your products to market. 

How to Comply?

The FDA has previously advised organizations to reference relevant ISO documentation (like ISO/IEC 29147 and ISO/IEC 30111) to determine how to implement cybersecurity requirements. Some of the requirements can be relatively straightforward. For example:

1. Provide details of their process to monitor, identify, and remediate vulnerabilities

One critical component of any mature vulnerability management process is a Vulnerability Disclosure Program or VDP. Setting up a VDP is the best way to ensure you're prepared to accept vulnerability reports from the global ethical hacking community. Establishing this open channel to report vulnerabilities will be an important part of providing details about identifying vulnerabilities. Many government organizations are already doing this, like the U.S. Department of Defense and the State of Ohio. 

VDPs can be as simple as a few statements and are generally just a few pages long. What's important is to include these five elements:

1. Promise: You state a clear, good-faith commitment to customers and other stakeholders potentially impacted by security vulnerabilities.
2. Scope: You indicate the covered properties, products, and vulnerability types.  
3. "Safe Harbor": You assure that the hacker reporting in good faith will not be penalized.
4. Process: You outline the process finders use to report vulnerabilities.
5. Preferences: You provide a living document that sets expectations for preferences and priorities regarding report evaluation.

Many VDP templates and guides exist; we recommend referencing the Coordinated Vulnerability Disclosure Template published by a working group of the U.S. National Telecommunications and Information Administration.

Get started with a VDP today.

2. Develop and maintain processes to ensure new patches are released and communicated regularly and critical vulnerabilities are addressed immediately

Identifying and receiving vulnerability reports is one (critical) component of the vulnerability management lifecycle. But identifying vulnerabilities doesn't do anyone any good without a plan to triage and remediate them, along with a communication strategy to inform consumers of the issue, the remediation, and how to implement it. 

If you're looking for a mechanism to communicate patches and updates to external audiences, quite a few standards are in place today. Firstly, direct distribution lists are built from current product users; this process ensures organizations can notify those most immediately impacted by a vulnerability of the issue and the fix first. Creating a CVE (Common Vulnerabilities and Exposures) through MITRE is another recognized best practice for a more public approach. Often a combination of the two is implemented, with organizations notifying direct users first and creating a CVE in parallel for reference. Finally, some organizations use their own public channels to publish security advisories for public consumption. These aim to announce the vulnerability and remediation in a public or semi-public manner. 

When it comes to the fix, it's all about time to remediation. For "critical vulnerabilities to be addressed immediately," as a part of a vulnerability management program, you must have a well-established process in place to handle critical vulnerabilities. Below are some important steps to getting this process to work effectively: 

1. Monitor the mechanism to receive a report or identify vulnerabilities for new critical vulnerabilities. There is a lot of noise in the world of vulnerability identification, so having the proper filters in place to amplify critical issues is a must.
2. Triage the vulnerability to assess its validity and relevance within your tech stack. Not every vulnerability is exploitable in your environment. A security team member or the Product Security Incident Response Team (PSIRT) typically tests for this. 
3. If the vulnerability is assessed to be valid and critical, you now need to implement a fix. This step often happens across silos in a technology organization, so communication is key. You need a communication channel between the security teams and the product development and engineering teams to ensure all the data points are in place for proper remediation work.
4. Finally, once a fix is in place, this must be communicated to the relevant end-user via internal or external methods, so consider the audience as a part of the communication strategy.

The timeline to remediate a critical vulnerability will vary based on the circumstances; however, for reference, the standard given by CISA to remediate critical vulnerabilities on external facing systems is 15 calendar days of initial detection. Establish a process to fast-track the out-of-band work needed to address critical vulnerabilities and ensure all teams understand the importance of collaborating to remediate a critical bug and that they can prioritize it. 

3. Provide a Software Bill of Materials (SBOM) that includes details of the commercial, open-source, and off-the-shelf software components in your tech stack

The SBOM is the most challenging goal for a multitude of reasons. One-third of large enterprises say they observe less than 75% of their attack surface, and 20% say over half of their attack surface is unknown or not observable. How are you supposed to even start understanding the software in your tech stack?

When building a comprehensive inventory and SBOM, approach the problem through a risk-based lens. Ask yourself: what are the most critical components in your environment? Is it a database of stored PHI or a server that receives and sends commands to medical devices? Where does that data live, and what systems does it flow through? Start your inventory based on criticality and issues that track that back to real systems.

When it comes to building the inventory process, it will be easier and more accurate if you compile it at each step of the software build process. Gathering each step is particularly essential in the initial stages of the build pipeline. Emphasize documentation at the farthest left point of the development lifecycle and make it a part of your development team's goals. 

Finally, when you build the SBOM itself, choose the SBOM tooling that fits your environment best. The tools and standards in this space are always evolving. Still, there are a few options that organizations are making headway on, including CycloneDX Maven Plugin, Kubernetes Bom, Microsoft's SBOM Tool, SPDX SBOM Generator, and Syft. Once you've experimented and identified the right one for your organization, create a standard to ensure all teams use the same tool. Once you've got your tool in place, conduct regular scans and internal audits of what's in your environment to catch changes (new software introduced, version updates, etc.). 

Although the October deadline is getting closer every day, you can take these relatively simple steps to begin complying and retaining your competitive edge. Click here for more advice on getting started with VDP.