The Importance of SBOM and CVE in Medical
What does cybersecurity mean for a medical device? This is an interesting and complex topic to find out.
One of the most important documents about the subject is indeed “Principles and Practices for Medical Device Cybersecurity” from IMDRF and available here: Principles and Practices for Medical Device Cybersecurity (imdrf.org). IMDRF stands for International Medical Device Regulators Forum and is a group of medical devices regulators whose aim is to harmonize and converge medical device regulations.
The purpose of this document is to provide general principles and best practices to facilitate international regulatory convergence on medical devices cybersecurity.
For medical devices, security is undoubtedly a key concern. Indeed, the effect of a compromised device can be catastrophic such as diagnostic errors, wrong therapies up to impossibility to access treatment.
The increasing threat of Cybersecurity has pushed companies to quickly react and, in many cases, perform security checks at the end of the development phase. However, the reality is that security must be applied to the total product life cycle (TPLC). TPLC is a concept widely used by the US Food and Drug Administration (FDA) and other regulatory bodies and should be followed by medical device companies to shepherd a product from concept to disposal. For a review of cybersecurity requirements for medical devices sold in the US, watch the webinars from my colleagues Ryan Zheng and Robert Krantz, which are available here. According to the IMDRF, in the Pre-market phase the manufacturer should consider how to securely update the device when it is affected by a vulnerability, but of course this is not enough because it is crucial to identify which devices are really affected and need an update. Such traceability can be achieved only by making use of the database of software components (SBOM) of the device.
SBOM (Software Bill of Materials) is key, not only to enable the backward traceability but it is also important for the healthcare providers as they can manage their assets, assess the risks, and finally deploy the needed countermeasures to maintain the safety integrity of the device.
SBOM also influences healthcare purchasing decisions: buyers having visibility of the content of a device will be able to assess the potential security risks (e.g., the presence of a component close to its end of life) and therefore better quantify the associated value.
The reasons above drove the IMDRF to clearly state in their document that, in addition to the usual user instructions and technical information, the manufacturer should always include the SBOM of the device.
Healthcare providers, who are typically the end customers of medical devices, usually use them for much longer than the original planned and communicated lifetime. In such scenarios, SBOM is extremely important because it allows risk assessments based on the lifetime of software components: devices including components near to or in end of life may be a source of vulnerability due to lack of maintenance.
This is the reason why, to ensure robust reliability and sustainable commercialization, manufacturers should consider adopting long life components and/or managed services which extend the support of open-source components.
We must also consider that according to the FDA (Postmarket Management of Cybersecurity in Medical Devices – Guidance for Industry and Food and Drug Administration Staff (fda.gov), manufacturers must report vulnerabilities to the FDA itself no later than 30 days after learning of the vulnerability; in addition they must, no later than 60 days after learning of the vulnerability, fix it, validate the change, and distribute the deployable fix to their customers.
This means that all the CVEs which may affect a device should be notified within a month and fixed in two.
CVEs have drastically increased since 2017, and moreover the trend looks exponential. In 2022 there were 25059 CVEs (c.f. Metrics | CVE), around 2100 per month. This means that a device manufacturer must check each month if one or more of 2100 CVEs is/are affecting its devices. The CVSS (Common Vulnerability Scoring System) provides a way to capture the principal characteristics of a vulnerability and produces a numerical score reflecting its severity, which is not always a correct index for assessing a vulnerability. CVSS and its associated rubric were developed for enterprise information technology systems and do not adequately reflect the clinical environment and potential patient safety impacts. The MITRE Corporation and FDA, developed a rubric that provides guidance for how an analyst can utilize CVSS as part of a risk assessment for a medical device [Rubric for Applying CVSS to Medical Devices | MITRE]. There are many cases in which a manufacturer needs to create its own rubric and policies because of the requirements of their end customers.
Filtering and checking CVEs is, therefore, a tedious and error prone task that cannot be done manually, and since it is not the core business of the medical manufacturers it should be better outsourced to avoid any impact on the R&D delaying the deliveries and/or neglecting innovation.
Wind River offers highly automated managed services for Linux and VxWorks which can relieve medical manufacturers from the heavy duty of keeping pace with all the newly published CVEs. It relies on automated SBOM generation and can filter out all the non-relevant CVEs. A team of highly skilled experts can then fix or mitigate the affected vulnerability collaborating closely with manufacturer R&D engineering and security experts.
To learn more about how Wind River can help, feel free to contact us.
