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.
Chester’s 25-year career has spanned diverse disciplines including polymer science, software engineering, user experience design, product marketing, and most recently, sales enablement. His broad experience has made him an effective bridge between the worlds of R&D, marketing, and sales, which often operate independently. During his 4-year stint at RSA Security, Chester was a frequent public speaker and advocated for an integrated view of security, spanning infrastructure, data, and application security, with the right tools and processes in place for proper governance, risk and compliance management. At Black Duck Software, Chester’s role as Director of Sales Enablement is critical in building a world-class team of sales professionals who not only understand the product, but also the challenges customers face regarding the security and legal risks of using open source software in application development. Chester enjoys taking on complex topics such as the software development lifecycle and operating system virtualization, and making them easy to understand for those without a technical background. In his free time, he is often found enabling his kids on the ski slopes or the tennis courts.