By Rick Brooks and Josh Branch, Battelle
If your medical device has software, someday that software will need to be updated. Do you have a plan in place to ensure that updates can be made safely and securely?
Software updates are a fact of modern life. On the consumer side, we're all used to our phones, computers, and smart gadgets nagging us to download the latest patch and, occasionally, deciding to shut down of their own accord — usually at an inconvenient moment — to perform a critical update.
In the medical device world, the stakes can be much higher. A device that doesn't get a critical update when it is needed may be left with a security vulnerability that puts patient safety or data at risk. At the same time, the update process itself can introduce new security vulnerabilities.
While no medical device containing code is ever 100-percent secure, the industry has made significant improvements in device security over the last decade. However, once devices are released into the market, they are part of an evolving software and security ecosystem in which new vulnerabilities are discovered or introduced all the time. The FDA's postmarket guidance for medical device manufacturers recommends that the latter have a plan for patching software and firmware to address new vulnerabilities as they emerge; the 2018 Medical Device Safety Action Plan outlines the FDA’s intent to make this a requirement for device developers moving forward.
Medical device developers may want to send software or firmware updates for other reasons, as well. These include:
Considerations For Secure Medical Devices Updates
Regardless of the reason for the updates, device manufacturers must ensure that the update process itself is secure and does not introduce new vulnerabilities to the device. The best way to do this is proactively, by building into the device, from the very beginning stages of design, a secure update process. Manufacturers should look at several critical questions:
Building a Software Bill of Materials
The FDA's Medical Device Safety Action Plan outlines evolving expectations for the medical device industry, including expectations for secure updates. Specifically, the FDA plans to:
Consider potential new premarket authorities to require firms, on the front end, to: (i) build capability to update and patch device security into a product’s design and to provide appropriate data regarding this capability to FDA as part of the device’s premarket submission; and, (ii) develop a “Software Bill of Materials” that must be provided to FDA as part of a premarket submission and made available to medical device customers and users.
What does this mean for device developers? First and foremost, it means that developers need to consider the update process on the front end, long before the device is released. Second, it will require developers to pay a lot more attention to the bits of code in their devices.
Creating a "Software Bill of Materials" (BOM) for each medical device (and each version of the device) is a good first step to proactive update management. The software BOM details all the pieces of code contained in the device, including the operating system; custom, in-house developed firmware and software; and code contained in third-party components, such as a Bluetooth processor stack, embedded microcontroller FW, or even fuse bit settings.
Keeping an accurate and up-to-date software BOM for every medical device in circulation — including the specific release version of each piece of code — will enable manufacturers to quickly identify which devices are impacted by an identified security vulnerability, and to develop effective response plans.
Proactive Steps Toward Secure Medical Device Software Updates
A secure medical device update plan encompasses several elements, including these steps medical device manufacturers should be taking already:
Make sure your device has enough memory and processing power to handle a secure update that includes modern cryptographic functions. This includes memory for secure key storage and processing power to handle cryptographic functions, such as digital signature creation/verification and data encryption.
A proactive approach to secure software updates will help medical device manufacturers avoid substantial headaches after the device is released. Incorporating secure design elements will ensure that medical devices can receive the updates they need to improve functionality, protect patient safety and data security, and maintain compatibility with other devices and systems.
About The Authors
Rick Brooks is the Director of Systems, Software, and Electrical Engineering, and DeviceSecure Services for Battelle’s Medical Device and Health Analytics Business. Rick leads an organization at Battelle that develops technology-enabled medical devices and software solutions. Over his career, Rick has served in a variety of roles for product development projects for the commercial, government, and medical products industries. He holds a degree in Electrical Engineering and received his Project Management Professional (PMP) certification in 2009. He is a voting member of the Association for the Advancement of Medical Instrumentation (AAMI) working group on cybersecurity for medical devices.
Josh Branch is a software engineer at Battelle with experience covering a diverse range of applications, including both embedded and non-embedded software. His core skills include extensive development in C, C++, C#, and Java to target platforms including Windows Desktop, Microsoft Azure/AWS, Mobile Applications, Embedded Linux, and various microcontroller cores including ARM Cortex-M, AVR, and PIC. Josh leads software teams that develop technology-enabled medical devices, with a focus on transitioning cybersecurity improvements into production use.