In previous posts, we discussed several elements of a Secure Product Development Framework (SPDF) which aims to help Medical Device Manufacturers (MDM) develop secure, connected medical devices. For SPDF, placing a secure device on the market is of utmost importance, but how do MDMs maintain a secure device? Most connected devices will be used for many years. Certainly new threats will emerge regularly. To maintain device security, two additional activities are crucial:
SBOM management
Continuous vulnerability monitoring and assessment
In this final blog post for our series on medical devices, let's dive deeper into post-development cybersecurity activities.
Threats during use
During the use of a device, new cybersecurity threats constantly emerge which may significantly impact patient safety and data integrity. Many devices are designed for years of service, during this time, they may become vulnerable to cyberattacks, such as unauthorized access through weak network interfaces. Malicious actors may exploit unpatched known vulnerabilities, or insecure communication channels, potentially leading to device malfunction, data breaches, and ultimately even serious patient harm. Since medical devices are increasingly interconnected with hospital/clinical networks, security risks extend to compromising larger healthcare infrastructures, impacting not only individual patients but possibly the overall delivery of care. Effective cybersecurity measures during device use, such as vulnerability identification and assessment, along with regular software updates, are essential to maintaining a secure device and mitigating these security risks.
SBOM management, what is it?
To keep device software up to date and secure, we start with a basic question: ‘What software components are in my device?’. This question may seem straightforward, however can be very complex when the usage of third-party components is included.
SBOM stands for ‘Software Bill of Materials’. A common definition used by NTIA is:
‘A Software Bill of Materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build (i.e. compile and link) a given piece of software and the supply chain relationships between them.‘
The SBOM is not new, however, it seems to be gaining recognition from organizations such as U.S. FDA with their Pre-market guidance for medical devices (2023). This may have been the first time the SBOM became an enforced requirement for medical devices in the United States. MDMs stood, and still stand, in front of a great challenge managing the entire SBOM lifecycle: creating, maintaining, operating, and distributing SBOMs.
To learn more, read our blog on SBOM Management: https://www.securitypattern.com/post/all-you-need-to-know-about-sbom-management
Ongoing Vulnerability Management to keep devices secure
Most vulnerabilities are found in third-party components. With the help of a well-maintained SBOM, MDMs may search forknown vulnerabilities within global databases, such as the NVD database or CISA’s Known Exploited Vulnerabilities Catalog (KEV).
Identification of vulnerabilities, is the first step in the Vulnerability Management Process (VMP). Once identified, the vulnerabilities must be triaged, addressed, and disclosed. VMP must be a continuous process. Identified vulnerabilities are continuously (re)prioritized and vulnerabilities previously accepted (low risk) or even mitigated should be re-assessed regularly.
Figure 1 – Vulnerability Management Process
Organizations that implement a robust VMP are much more effective in finding, prioritizing, and fixing vulnerabilities, leading to more secure devices with increased supply chain transparency. There are thousands of known vulnerabilities, and to asses this mass of information requires some kind of automation. Each day over 100 vulnerabilities are reported within the various databases, which makes manual identification time-consuming, costly, and frankly, nearly impossible. Automated vulnerability management solutions have entered the market to reduce time and/or cost for MDMs.
Assessing the Risk of a Vulnerability
From our blog post on Cybersecurity Risk Management, we discussed how vulnerabilities are evaluated. The ideal way is to develop a matrix which combines "Exploitability" and "Severity of patient harm". This matrix is then used to assess the security risks for each vulnerability. We used the following image:
To be concise, security risk is estimated using:
Severity of HARM (e.g., Clinical description – a broken bone, death, laceration – if the vulnerability were to be exploited) PLUS EXPLOITABILITY of a Cybersecurity VULNERABILITY (i.e., How likely is the VULNERABILITY – unauthorized access to cloud – occur?).
From here, we may say a security risk is either ‘Controlled’ or ‘Uncontrolled’. When there is an unacceptable residual risk of patient harm due to insufficient risk mitigations and compensating controls, we speak of Uncontrolled risk.
From our Threat Model blog post, we said that for a security risk analysis to be thorough, use known tools such as Threat Model to develop a complete understanding of all possible risks from the intended use environment.
What does the FDA require?
MDMs must create and maintain SBOMs for all connected devices within the U.S. market. From FDA guidance (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, Sept 2023), MDMs must:
“...provide machine-readable SBOMs consistent with the minimum elements….identified in the October 2021 National Telecommunications and Information Administration (NTIA) Multistakeholder Process on Software Component Transparency document.”
Minimum SBOM elements are:
Supplier name: The name of an entity that creates, defines, and identifies components.
Component name: Designation assigned to a unit of software defined by the original supplier.
Version of the component: Identifier used by the supplier to specify a change in software from a previously identified version.
Other unique identifiers: Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases.
Dependency relationship: Characterising the relationship that an upstream component X is included in software Y.
Author of SBOM data: The name of the entity that creates the SBOM data for this component.
Timestamp: Record of the date and time of the SBOM data assembly.
See NTIA’s Minimum Elements for SBOM for more information and optional elements. FDA guidance also requires two additional items:
“...for each software component contained within the SBOM, manufacturers should include in the premarket submission:
The software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned); and
The software component’s end-of-support date.”
FDA also requests a lot with respect to Vulnerability Management:
“…manufacturers should also identify all known vulnerabilities associated with the device and the software components, including those identified in CISA’s Known Exploited Vulnerabilities Catalog. For each known vulnerability, manufacturers should describe how the vulnerabilities were discovered to demonstrate whether the assessment methods were sufficiently robust. For components with known vulnerabilities, device manufacturers should provide in premarket submissions:
A safety and security risk assessment of each known vulnerability (including device and system impacts); and
Details of applicable safety and security risk controls to address the vulnerability. If risk controls include compensating controls, those should be described in an appropriate level of detail.”
For vulnerabilities leading to ‘Uncontrolled Risk’, FDA requests MDMs to take various steps and remediate uncontrolled risks as quickly as possible. One major requested action is to fix the vulnerability, validate the change, and distribute the deployable fix to customers within 60 days of learning about the vulnerability.
The agency also requires MDMs to provide traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation. This requirement highlights how the various layers of the SPDF are interconnected as we discussed.
Conclusion
Maintaining the security of connected medical devices throughout their operational lifecycle is crucial to protecting patient safety and ensuring the integrity of healthcare systems. By adopting effective practices such as SBOM management and continuous vulnerability monitoring, MDMs may stay ahead of emerging cybersecurity threats and maintain devices secure into the future.
How Security Pattern can help
We offer various consultancy services and training modules to support your organization with cybersecurity challenges. For the topic covered in this article, we highly recommend:
ARIANNA the product security management platform for connected devices and systems.
About the Author
Dr. John Salvato, President, Design Quality Services LLC
Design Quality Services (DQS) was established to support large and small innovators' product development endeavours, resolve quality system challenges, and provide technical training. The pathway to commercialization is complex, regulatory expectations can be ambiguous, and quality management systems (QMS) may become unstable. DQS brings a pragmatic approach to enable these pathways, fostering business growth and market success. We are here to help you solve your toughest challenges. John has an impressive 30-year career spanning quality assurance, manufacturing, and product development in the medical device and automotive industries. As the president of DQS, he brings exceptional engineering abilities and unparalleled global management experience. His leadership has led to successful development projects globally. John leverages his many years of professional experience with his academic work.
Comments