In the first part of our series covering cybersecurity in medical devices, we presented the threat modeling process which regroup activities to identify the potential threats for a medical system. It allows to prevent or mitigate the effects of threats and is used as input into the risk management assessment of the medical solution. In this second part, we are going to introduce another well-known method in cybersecurity, the Common Vulnerabilities and Exposures (CVE) analysis.

Medical Device Are Becoming Increasingly Complex

Projects tend to be more and more complex, and medical devices are following this trend. Modern projects may include hundreds of components (hardware tools, compilers, libraries, frameworks which can be open source or not), which may all contain vulnerabilities.

As pointed out by the Open Web Application Security Project ®  (OWASP) top ten, one of the most critical risk is using and/or including components with known vulnerabilities in a product (source).

To emphasize this observation, UL 2900-1 states that “The binary code and bytecode under test including those provided by third parties shall contain no known vulnerabilities […]” (UL 2900-1 13.1).

SBOM for The Search of CVEs

It means that known vulnerabilities (i.e., CVE) in the code used in the project must be checked on a regular basis AND during the entire lifetime of the project (even long after release to market). To achieve that goal, the tools/libraries included in a project must be identified by generating a Software Bill Of Material (SBOM). The SBOM is a list of all software components along with metadata like their version or their license which will be part of the Cybersecurity BOM (CBOM) requested by the FDA in its latest cybersecurity guidance.

Depending on the size of the code base or technology used, this task may be either done manually or using automated tools. Major build systems (e.g., Buildroot, Yocto) are able to generate SBOMs which must preferably be in standard format like CycloneDX or SPDX. Alternatively, tools that will automatically scan the projects dependencies can be used (e.g., using makefiles for C/C++ projects or pip requirements for python).

Figure 1: CycloneDX is a lightweight SBOM standard that allow to describe all SW components in XML or JSON format

With this dependencies analysis, it’s easy to check if there are existing known vulnerabilities affecting the project. This can be done by searching for each library in the CVE or NVD database.

Figure 2: Example of CVE search using NVD database

Composition Analysis, A Method for Complex Systems

For large projects, this task could be very time-consuming and error prone. That’s why we recommend using a Software Composition Analysis (SCA) tool which will automate the process of generating SBOM and searching for CVEs (not to be confused with Source Code Analysis tool, which shares the same acronym and will be described in a future article).

A lot of SCA tools exist on the market. The choice should be based on which one best meets the needs and requirements of the project (e.g., integration into the workflow, performance, price). Some of the well-known tools are Sonatype Nexus, WhiteSource or Black Duck.

Figure 3: Sample output of Black Duck SCA tool

 

Once CVEs are identified, an assessment must be performed to determine if the product is affected. If it is the case, either fix it by applying a patch, find a workaround which doesn’t involve the affected component or implement a mitigation that will make it acceptable according to the risk management process.

Penetration Testing, a Method for Verifying Potential Vulnerabilities

The best way to verify that all vulnerabilities are correctly fixed is to request a penetration testing lab to confirm that none of them can be exploited.

Structured penetration testing is required by UL 2900-1, section 16. Penetration testing should be run by an independent lab. Such test should be first performed as “Black-box testing”, which means that testers will try to find and exploit vulnerabilities with no (or very little) knowledge of the device. Then, “White-box” testing should be run, where all valuable information (even source code or schematics if necessary) is provided. Also, providing the list of identified CVEs will help the lab confirm that the device doesn’t contain weaknesses.

Preview of Part 3

After having covered Threat Modeling and CVE Analysis in the previous articles, the third part on cybersecurity in medical devices will give insights on static code analysis, a good method to find bug and usually part of a continuous integration process (i.e., run every time a change is applied to the code).