The need for open source security in medical devices

Wireless and wearable technologies have brought about dramatic improvements in healthcare, allowing patients mobility while providing healthcare professionals with easier access to patient data. Many medical devices that were once tethered to patients, positioned next to hospital beds, or at a fixed location, are now transportable. Evolving from the traditional “finger-prick” method of glucose monitoring, wearable devices equipped with sensors and wireless connectivity now assist with monitoring blood sugar levels, connect with health-care providers, and even deliver medication. Critical life-sustaining devices, such as pacemakers, can be checked by doctors using wireless technology and reduce the time a patient needs to spend at the hospital while allowing the doctor to react more rapidly to patient problems.

Built on a core of open source

A major driver of the technological revolution in medical devices is software, and that software is built on a core of open source. Black Duck’s 2017 Open Source Security and Risk Analysis (OSSRA) research found that the average commercial application included almost 150 discrete open source components, and that 67 per cent of the over 1000 commercial applications scanned included vulnerable open source components. The analysis made evident that the use of open source components in commercial applications is pervasive across every industry vertical, including the healthcare industry.

The arguments for using open source are straightforward – open source lowers development costs, speeds time to market, and accelerates innovation. When it comes to software, every manufacturer wants to spend less time on what are becoming commodities — such as the core operating system and connectivity — and focus on features that will differentiate their brand. The open source model supports that objective by expediting every aspect of agile product development.

But visibility and control over open source are essential to maintain the security and code quality of medical device software and platforms.  

Open source in medical devices

Over two million patients in the United States have implanted devices, including pacemakers and implantable cardioverter-defibrillators. More than seven million patients now benefit from remote monitoring and the use of connected medical devices as an integral part of their care routines.

While the software used in the vast majority of medical devices is closed and proprietary to prevent commercial rivals from copying each other's code, that software usually contains a wealth of open source components. The OSSRA study I cited earlier found open source in 46 per cent of the commercial applications associated with the healthcare, health tech, and life sciences sector.

Researchers Billy Rios and Jonathan Butts recently acquired hardware and supporting software for four different brands of pacemakers and looked for weaknesses in architecture and execution. One of the biggest issues noted in the paper they published was one Black Duck sees time and again — unpatched software libraries. 

All four pacemakers examined contained open source components with vulnerabilities, and roughly 50 per cent of all components included vulnerabilities. Most shockingly, the pacemakers had an average of 50 vulnerabilities per vulnerable component and over 2,000 vulnerabilities per vendor. 

Open source safety and security issues

When patient safety is a function of software, the issue of software security becomes paramount — particularly when it comes to medical devices. But, secure software is an ephemeral concept. What we think of as secure today can change overnight as new vulnerabilities are discovered and disclosed. As code ages, the probability is high that more vulnerabilities are likely to be disclosed. An average 3,600 new open source vulnerabilities are discovered every year (though still far less than that reported in commercial code).

Open source is neither more nor less secure than custom code. However, there are certain characteristics of open source that make vulnerabilities in popular components very attractive targets for hackers. The return on investment for an open source vulnerability is high.  A single exploit can be used to compromise hundreds or thousands of applications using that vulnerable component. 

Whether open source or proprietary code, most known vulnerabilities like Heartbleed, and the SMB vulnerability exploited in the WannaCry ransomware attacks, have patches available on the date of their public disclosure. But, despite the availability of patches, an alarming number of both companies and individuals simply do not apply them. Months after Microsoft issued its security patch, thousands of computers remain vulnerable to the WannaCry exploit for a variety of reasons, ranging from the use of bootleg software to simple neglect.

Patches often aren’t applied because of concerns that the patch might break a currently-working system. Each time a patch is introduced, changing a system can impact its reliability and functionality. Healthcare organisations, for example, often will put functionality and uptime as a higher priority than security, and in doing so expose themselves to attack on unpatched — and vulnerable — applications.

In other cases, it’s a lack of insight — organisations are simply unaware of a critical vulnerability or its patch until they’re under attack. While software vendors like Microsoft can “push” updates and fixes out to users, open source has a “pull” support model. Unlike most proprietary software, users of open source are responsible for keeping track of vulnerabilities as well as fixes and updates for the open source they use rather than having those fixes “pushed” out to them. Unless a vendor is aware that a vulnerable open source component is included in its application(s), it’s highly probable that that component will remain unpatched.

Rios and Butts’ paper didn’t state if the researchers checked for software/firmware updates from the vendors prior to analysis. My assumption is that they did not, but whether this would have made a real-world difference is arguable, Black Duck’s own research indicates that vendors are typically unaware of all of the open source they use, since it can enter the code base in so many ways. On average, prior to having a Black Duck code scan, our customers were aware of less than half of the third-party libraries they use.

Best practices for managing open source risk 

To be clear, the problem isn’t the use of open source. It’s the fact that open source is often invisible to those using it. Vulnerabilities in open source may open up users to targeted or non-targeted attacks. Depending on the software (home monitoring, physician, programmer, etc.) the attack could affect a single patient or an entire practice. When the WannaCry ransomware spread across the world, multiple U.K. hospitals reported that their radiology departments were completely knocked out by the outbreak.

If the attack is on implantable medical devices, this could become a life or death decision.

Unless the medical device software supply chain carefully tracks the open source they use, and maps that open source to the thousands of vulnerabilities disclosed every year, they will be unable to protect their applications—and their customers—from those vulnerabilities.

To make progress in defending against open source security threats and compliance risks, both medical device manufacturers and their suppliers must adopt open source management practices that:

Fully inventories open source software: Organisations cannot defend against threats that they do not know exist.   A full and accurate inventory (bill of materials) of the open source used in their applications is essential.

Map open source to known security vulnerabilities: Public sources, such as the National Vulnerability Database provide information on publicly disclosed vulnerabilities in open source software. Organisations need to reference these sources to identify which of the open source components they use are vulnerable.

Identify license and code quality risks: Failure to comply with open source licenses can put organisations at significant risk of litigation and compromise of IP. Likewise, use of out-of-date or poor quality components degrades the quality of applications that use them. These risks also need to be tracked and managed.

Enforce open source risk policies: Many organisations lack even basic documentation and enforcement of open source policies that would help them mitigate risks. Manual policy reviews are a minimum requirement, but as software development becomes more automated so too must management of open source policies.

Alert on new security threats: With more than 3,600 new open source vulnerabilities discovered every year, the job of tracking and monitoring vulnerabilities does not end when applications leave development. Organisations need to continuously monitor for new threats as long as their applications remain in service.

As open source use continues to increase, effective management of open source security and license compliance risk is becoming increasingly important. By integrating risk management processes and automated solutions into their product lifecycle, medical device manufacturers can maximise the benefits of open source use while effectively managing its risks.

Mike Pittenger, Vice President of Security Strategy, Black Duck Software
Image Credit: Photo_Concepts  / iStock