Posted by Chester Liu on February 13, 2017
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.”
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:
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:
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.
Get the latest Software Integrity news, thought leadership, and more.