Implementing medical device security for optimal outcomes

Robert Bates is the chief safety officer for the Embedded Platform Systems group of Mentor, a Siemens business, responsible for the safety, quality and security aspects of the embedded product portfolio targeting the medical, industrial, automotive, and aerospace markets. Robert has over 30 years of experience in the embedded software field, most of which has been spent developing operating system and middleware components for device makers around the world.

The security of medical devices is critical since customers and patients that interact with your devices need assurance that their health and personal information are protected, especially when the device is connected to the internet. Globally, regulators are requiring and verifying that devices are as secure as possible. In the United States, the Food and Drug Administration (FDA) has published guidance outlining requirements for medical devices that mandate a number of facets of device development and maintenance.

Common Vulnerabilities and Exposures (CVEs)

A security vulnerability is a defect that potentially exposes the device to some unintended external or internal application. Security vulnerabilities are in every type of product, including medical devices. Embedded developers can limit exposure and potential damage due to vulnerabilities by recognizing and preparing for potential attacks. The most important part of the mitigation process is known as Common Vulnerabilities and Exposures (CVEs).

Figure 1. Common Vulnerabilities and Exposures are vital security mitigation tools.

Defined in 1999, CVEs are a repository of known exploitable security issues that exist (or existed) in products. CVEs are published and maintained in a joint effort between the MITRE Corporation and the US National Vulnerability Database (NVD), which is maintained by the US Department of Homeland Security. Every significant security vulnerability has been documented as a CVE from Heartbleed (CVE-2014-060) to Shellshock (CVE-2014-6271) to URGENT/11 (11 CVEs discovered in 2019).

Most CVEs are discovered without causing damage, but once an exploit is communicated to the world, it can be exploited by hackers worldwide – so timing is critical. Fortunately, the CVE process gives product or software developers time to fix an exploit and implement appropriate device security before it is announced globally. Once a CVE is discovered, it is assigned a CVE identification ID. If the CVE is identified as an issue, it is assigned a Vulnerability Score by the NVD of between 1 and 10 – the higher the number, the more serious the vulnerability. The NVD also contains any other known information about the issue, plus links to pertinent sites that further describe the issue and the existing fixes available.

The main benefit of the CVE reporting process is knowledge of the issue, potential fixes, and the severity and risk the issue might have with regard to your products. Security vulnerabilities can expose your devices and customers to several adverse consequences, including:

■ Loss or modification of patient critical data that could harm the patient or medical personnel;

■ Exposure of patient data that could lead to identity theft, HIPAA violations, and other serious consequences; and

■ Infiltration of the device by malicious actors who may, for example, inject malware, disable the device, or infest other parts of a hospital or clinician network.

For secure devices development, it is important to consider the different sources of potential security issues: those known to the community at the time the device is developed; those that become known after the device is released; and/or those attributable to software written specifically for the device due to insufficient preventative development techniques.

Protection from known issues

Each CVE that is shown to be an exploit is searchable in both the NVD and CVE databases. You can search by component name, CVE ID or any keyword of interest. For example, if your device uses some Linux distribution, a searching for Linux vulnerabilities will bring up a number of issues, such as CVE-201911683. This is a critical severity issue that should not be in any product, since it is well-known and allows remote denial of service attacks, or “unspecified other impacts”. The defect is resolved from Linux kernel version 5.0.13 onwards, so you should upgrade to that at least version if your kernel is an earlier one.

For open-source components in your product, several tools are available to identify if important CVEs are included in your software. The most important source is called ‘cve-check’ (https://github.com/clearlinux/cve-check-tool). This tool generates reports on which packages contain CVEs that are not resolved in the versions used, with discovery performed by version checking. This information can determine if any pre-emptive action is required before your product images can be considered complete.

Manufacturers do not want to do this kind of checking and updating because they consider their engineers priorities to be the solution of product problems rather than the management and maintenance of a Linux distribution. The device manufacturer must take this task on or use a commercial Linux distribution where they can hold their vendor responsible for doing the work for them.

However, monitoring for known exploits and then ensuring they are addressed are not the only considerations at this point – other device concerns include:

■ Access Control: Have you designed-in the ability to define roles that can access various types of data (user, management and maintenance level)? Is data access difficult with higher levels of access control from the internet versus physical access to the device? Are the device authentication methods difficult to exploit? Are default accounts and passwords managed to prevent exploitation?

■ Encryption: Is the data stored (in memory and in storage) on your device, and then transmitted between your device and others both protected and encrypted so that it can be deciphered by only those meant to see it? Do you have a different mechanism to access keys beyond just encrypted memory?

■ Hardware security assistance: Have you taken advantage of features such as TrustZone, Cryptographic Acceleration, and Trusted Platform Modules (TPMs), on modern microprocessors that accelerate and assist in the development of secure designs.

Applying preventative development techniques

When using Linux and other open source software, there will be vulnerabilities in your device that you will not know about when you release it. So you must not only eliminate as many known and possible vulnerabilities before product release, but also still assume that some bad actor will be able to get unauthorized access to the device at any given time. When that happens, you must make it as difficult as possible for them to profitably exploit that access.

There is no perfect defense from determined hackers armed with the knowledge of exploits in your device. You cannot protect yourself from flaws in the open source modules you used, but you can control potential flaws in your own applications. Consider the techniques mentioned above to design in greater protection, but what about the way your applications are developed?

Again, most exploits in open source and application software are due to developmental flaws that happen repeatedly. Things like NULL pointer de-references, freeing already freed memory, and overflowing a fixed length buffer are the kinds of coding error that can be easily exploited by hackers to compromise a device. However, several strategies can help. They are generally beyond the scope of this article but for reference and to guide your further reading, they include:

■ Static and dynamic analysis. The first static analysis you are likely to see are the warnings that come from your compiler. It is surprising how many organizations ignore this valuable diagnostic tool in a misguided rush to get something released. Beyond that, the open-source community provides several useful static analysis tools such as ‘cppcheck’ and ‘clang’, and there are many commercial solutions available. All will detect issues that are easily missed in code reviews. As long as the reports from these tools are managed, you can prevent several major classes of potential exploits in your applications.

■ Use of a coding standard (MISRA). The MISRA coding standard (https://misra.org.uk/) is the gold medal standard and provides many well thought-through recommendations for securing your applications. While its genesis is from the automotive industry and the world of safety, there is nothing automotive or safety-specific about it. MISRA should be considered by any device manufacturer looking to secure their applications. Note that most static analysis tools also greatly ease the checking of applications against MISRA rules. While there are other coding standards available, MISRA combines common sense with good practice allowing implementation by organizations of all sizes.

■ Use of a coding standard (SEI CERT C). This is a useful coding standard from the Software Engineering Institute at Carnegie Mellon is SEI CERT C (https://wiki.sei.cmu.edu/confluence/display/seccode). It has a significant overlap with MISRA, but the SEI standards extend beyond C and C++ and into Android, Java and Perl.

There are many other useful sources of information to consider when developing secure software, but if you are not already employing the above techniques, start there and consider expanding your thinking once you have a smart coding standard and static analysis paradigm in place. Several resources can also be found here.

Security with confidence

By following the guidance in this article, your product will be protected against known and unknown exploits when released. It will be faster to update to close any newly found exploits, and more secure.

This approach will give your customers confidence that they are protected even if something goes wrong. By approaching security and limiting exposure to exploitation, your devices will be less prone to attack and better prepared to protect patient data. They will then be more likely to smoothly achieve regulatory approval and, most important of all, improve medical outcomes for patients around the world.