With very little fanfare and nary a whiff of warning, earlier this month the Food and Drug Administration (FDA) has released the much-anticipated 2022 update to their Guidance for Cybersecurity in Medical Devices. While many were anticipating a final version of the 2018 draft guidance, the 2022 guidance appears to be a substantial re-envisioning of the FDA’s guidance. Gone are the device “tiers” that attempted to classify devices based on their “Cybersecurity Risk”, as is the hard focus on use of the NIST Cybersecurity Framework as a foundation for how device manufacturers should design their devices.

Instead, the FDA has reworked the guidance in several important ways:

Secure Product Development Framework

In 2018, FDA focused their guidance on use of the NIST Cybersecurity Framework (or CSF) as a tool on which to base the design, development, maintenance, and end-of-life activities for medical device manufacturers. The NIST CSF was published in 2014 following finalization of the first FDA guidance for cybersecurity in medical devices in 2012 and was the hot new way to manage cybersecurity concerns for organizations, particularly those looking for federal government guidance on the topic. The CSF was intended to be a toolbox for security professionals and not necessarily a security-program-in-a-box. Much in the same way that not every tool in a toolbox is used for every project, applying the CSF uniformly to every security challenge was not always an effective approach.

In the 2022 guidance, FDA proposed the idea of a Secure Product Development Framework (or SPDF), with the goal of requiring manufacturers to adopt a broader view of product security from cradle-to-grave. On the one hand, this change should better address the unique needs of developing trustworthy medical devices. On the other hand, this likely will not simplify compliance considerations during new product development.

Organizations which have already crafted their own product security framework should evaluate their controls against the eight categories called out by the FDA in the new guidance to ensure adequate coverage. Any gaps should be closed based on industry frameworks, especially the Medical Device and Health IT Joint Security Plan (JSP) once the updated plan (JSP2) is released.

Threat Modeling

Threat modeling isn’t a new concept, nor was it when introduced in the 2018 guidance. But in 2018 very little guidance was provided on the subject, with much left open to interpretation of what a threat model must look like, what the threat-modeling process should be, and what form the documentation must take for FDA to accept the device’s threat model.

The 2022 guidance looks to treat Threat Modeling as a holistic activity, which includes many of the artifacts that are required by a 510k submission. It takes a bit of a wandering path to get there. Let’s start at the end (of the document) with the definition:

Threat modeling – a methodology for optimizing system, product, network, application, and connection security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system.

This is good – it defines threat modeling as a methodology. What the 2022 guidance doesn’t do, is provide a clear definition for what a threat model is. And when speaking with new MDMs or existing MDMs without a matured cybersecurity program, “what is a threat model” is, almost without exception, the first question asked. Put a pin in that question because we’ll come back to it in a moment.

Section V.A.1 Threat Modeling goes into further detail on what needs to be included during threat modeling activities:

Threat modeling includes a process for identifying security objectives, risks, and vulnerabilities across the system, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system throughout its lifecycle [emphasis added].

With this statement, they’ve clarified that threat modeling activities should occur throughout the product lifecycle; as they should. Manufacturers should always be aware of new vulnerabilities in software components, emerging threats based on new technologies that may impact their devices, or reports from 3rd parties and their customer base.

What this statement also does, however, is pull risk analysis into the picture for threat modeling – which is traditionally where the line was drawn between where a Threat Model ends, and Risk Analysis begins; Threat Modeling ended where threats were identified. Risk analysis picked up where those threats were analyzed for exploitability, risk to patient or business resources, mitigations for those risks (or threats), residual risk, and risk acceptance or transfer.

The guidance continues with this same line of thought in subsequent statements:

With respect to security risk management, and in order to identify appropriate security risks and controls for the system, FDA recommends that threat modeling be performed to inform and support the risk analysis activities [emphasis added].

The threat model should identify system risks and mitigations as well as inform the pre- and post-mitigation risks considered as part of the security risk assessment [emphasis added].

With these statements, FDA has drawn a broad boundary around Threat Modeling activities to include, effectively, all Cybersecurity-related design activities – design and requirements, threat modeling, risk analysis, mitigations, and risk acceptance – occurring during both pre- and post-market stages.

So, in answer to the question of “what is a threat model”? Unfortunately, the answer seems to be everything.

Software Bill of Materials

FDA has returned to requiring Software Bill of Materials (SBOM), replacing the Cybersecurity Bill of Materials (CBOM) from the 2018 guidance. The CBOM guidance from 2018 was foundational in that it pushed manufacturers towards using the bill of materials as a tool for vulnerability management. This goal has been carried forward into the new 2022 guidance, but with considerable improvement. The following quote from the new guidance summarizes this well:

An SBOM helps facilitate risk management processes by providing a mechanism to identify devices that might be affected by vulnerabilities in the software components, both during development (when software is being chosen as a component) and after it has been placed into the market throughout all other phases of a product’s life.

Putting this another way, manufacturers should be aware of the technical debt they are about to incur when selecting software components – even with the latest release of a software package. This is the reality of software, and it should be embraced with tools and processes to manage that technical debt and risks associated with it.

If used correctly, an accurate and well maintained SBOM is a tool that can assist with managing risks related to that technical debt and drive appropriate action. When coupled with a well-maintained Threat Model, a manufacturer should be able to quickly identify if a vulnerability found in a software component of their device may impact that device, and how that impact may be felt throughout the system.

Bonus Content – Legislative Backing of Guidance

Much has been written about the FDA’s efforts to transition some aspects of their guidance to true requirements for medical device cybersecurity. Suffice it to say, we will be watching closely to see if the FDA is able to codify cybersecurity requirements into law. We wouldn’t expect the guidance to be adopted as requirements whole cloth and will be interested to see what would remain as guidance-only.

It will also be interesting to see how the industry responds to requirements to “design, develop, and maintain updates and patches throughout the lifecycle of their devices” particularly for devices with lifecycles that often outlive the underlying third-party software (see SBOM discussion above).

MDMs may be incentivized to shorten their device lifecycles to comply with regulations and avoid prolonged support of increasingly insecure devices in the future as the cybersecurity landscape continues to evolve. Providers have historically prioritized spending more on patient care, and not the cyber health of their organizations. Both providers and MDMs will need to balance their priorities as the focus on cybersecurity posture in healthcare increases in the coming years.

Closing Thoughts

Overall, the new guidance feels like a step in the right direction over the 2018 draft guidance. The focus on vulnerability management via the SBOM is an excellent example of a practical solution to help solve the nth-party software vulnerability problem that has, does, and continues to plague software-based systems everywhere. It also provides some interesting methods for documenting the system and threat-modeling activities, albeit odd that they would focus on the concept of a call-flow diagram instead of relying on more systems-engineering-familiar terms such as UML-sequence diagrams.

We look forward to working with existing MDM partners and readers in integrating these changes into their development lifecycles and quality systems. We also look forward to continued refinements in the guidance as FDA considers input from the community and (hopefully) provides a revised draft of the guidance before finalizing in the coming months.