Medical device manufacturers and open source security vulnerabilities
On December 28, 2016, the US Food and Drug Administration (FDA) finalized its guidance on the “Postmarket Management of Cybersecurity in Medical Devices.” The release of the guidance was accompanied by an official blog post, which points out that as medical devices become increasingly sophisticated and connected, they become more prone to attack. Successful attacks can result in physical harm or even death to real people.
Mitigating this risk is the purpose of the finalized guidance for medical device manufacturers. The author of the blog, Dr. Suzanne Schwartz, says it well:
“The best way to combat these threats is for manufacturers to consider cybersecurity throughout the total product lifecycle of a device. In other words, manufacturers should build in cybersecurity controls when they design and develop the device to assure proper device performance in the face of cyber threats, and then they should continuously monitor and address cybersecurity concerns once the device is on the market and being used by patients.”
(emphasis mine.)
The facts: Cybersecurity is a broad term
The conundrum facing medical device manufacturers is that “cybersecurity” is a very broad term and it is difficult to (a) identify all areas of risk and (b) prioritize risk for remediation.
Fortunately, Section (V.)(B.), or page 13 if you are reading the guidance, spells this out succinctly. Specifically, it says that critical components of a cybersecurity risk management program should include:
- Monitoring cybersecurity information sources for identification and detection of cybersecurity vulnerabilities and risk;
- Maintaining robust software lifecycle processes that include mechanisms for:
- monitoring third party software components for new vulnerabilities throughout the device’s total product lifecycle;
- design verification and validation for software updates and patches that are used to remediate vulnerabilities, including those related to Off-the-shelf software;
- Understanding, assessing and detecting presence and impact of a vulnerability;
- Establishing and communicating processes for vulnerability intake and handling
Operationalizing the FDA guidance
I speak with many organizations that already have deployed anti-malware and intelligent firewalls for protecting their infrastructure in real-time, but few of them have anything automated to monitor cybersecurity information sources for vulnerabilities that may affect their devices, and more specifically the software code for the applications and firmware that power their devices. Often the team responsible for infrastructure security is not responsible for product security, and the net effect is that no one has a full-time responsibility to make sure products are as secure as can be.
They also tell me that they have no way of knowing what and where all the third party components and libraries in their applications are because (a) development is outsourced, or (b) software comes through their supply chain, or (c) they don’t have a way to make sure developers are documenting all code that they bring in.
This lack of visibility into third party components means that they are unable to comply with the FDA guidance to “monitoring third party software components for new vulnerabilities.” Without an accurate inventory of open source components used to build their applications, they have no way of knowing whether their applications are impacted when new vulnerabilities are discussed in forums and blogs.
They tell me that what’s needed is a solution with the following characteristics:
- Create an accurate inventory of open source components automatically
- Notify the security team whenever a vulnerability is disclosed, as close to zero-day as possible, not after days or weeks like the National Vulnerability Database that many security tools rely on
- Provide critical triage and remediation information such as: whether a public exploit is available, what the attack vector is, and whether an update or patch is available
- Seamless integration into existing development processes and DevOps tools to minimize training costs and maximize value from the investment
Final thoughts on medical device manufacturers and open source
The medical device industry is not the only one that faces increasingly specific regulations regarding the secure use of open source. In a previous blog post, I cited HIPAA and HITECH regulations affecting the healthtech industry, from large established enterprises to hundreds of companies that have sprung up to move the healthcare industry into the digital age.
By pointing out the specific need to manage third party libraries, including open source, the FDA is doing a public service highlighting a real and often overlooked source of security vulnerabilities that can be easily exploited. Regardless of how you feel about the FDA, that is a good thing for our health and safety.
Learn 5 ways to inoculate yourself against medical device hacks now.
