Medical device security and updates
Last year, when visiting a hospital, I was astonished to find a medical device managed by a PC running on an obsolete operating system. Unfortunately this situation is common. Why? It’s simple: certain medical devices are built to last longer than the operating systems (OS) used to control them! This overlap carries major risks when it comes to security patches and the vulnerability of PCs running on OS that are no longer supported by the developer. The end of Windows XP support provides one case in point that will take on critical importance in the very near future.
OS updates and vulnerability
Without generalizing too much, let’s consider a device preloaded with software designed for a specific OS. In this case, the manufacturer will only support the medical device if it’s not modified in any way, which is understandable. But the same also holds true for the OS – which is a lot harder to guarantee! So whenever there’s a major update to the OS (or it gets replaced), hospitals or operators using the device will find themselves faced with the following dilemma:
- update the OS powering their device and lose manufacturer support,
- keep manufacturer support and don’t update the OS, which leaves the PC managing the device vulnerable to known and easily avoidable threats
A clear catch-22 by any measure!
In a perfect world, OS updates would have no impact on the medical functions performed by a device. This seems obvious, but how do things work in the real world?
perform risk analysis
To update a medical device, the user will have to identify the components of the OS that will actually impact the medical program necessary for the device to operate properly. Next comes an analysis of any relevant risk by asking “Is there more risk with or without the patch?” But are the typical users of these devices (doctors, operators, etc) capable of answering this question? Doubtful.
In this video Jay Radcliffe proposes a common sense classification into three types of libraries for risk analysis:
- Libraries provided by the OS supplier but not used during the normal operation of the medical device
- Libraries used only to operate or control the medical portion of the device and under the sole responsibility of the vendor
- Libraries provided by the OS supplier and used directly at one point or another during the normal operation of the medical device
The first libraries are part of normal OS updates and they shouldn’t pose any problems since they have no impact on the operation of the medical portion of the device. Risk analysis is easy in this case.
Same for the second set of libraries. It should cause no problem if the manufacturer provides a software update and the hospital installs it. All you have to do here is make sure the OS is compatible.
where things get tricky
Problems arise with the last library classification. Whenever there is an update for the OS libraries used by the medical device, the user should be able to contact the manufacturer to make sure the update poses no risk for the medical portion of the device. Not easy, but definitely doable. Unfortunately, this isn’t possible yet! As far as I know, every manufacturer has its own update policy and best practices.
And I have no idea if these updates are overseen by anyone and, if so, who they might be: medical staff, IT managers, others… It’s a mystery!
what questions should you ask before investing?
This should certainly give you something to think about if you’re considering investing in a medical device that will undoubtedly outlive its OS. Here are a few of the common sense questions I would ask myself before buying:
- is there an update process for the medical software? If so, how is it updated?
- how dependent is the medical software on the OS?
- did the manufacturer plan for and approve a process for upgrading the OS?
- is there a process for changing the OS if it’s no longer supported by the developer?
So I still have a lot of questions and not enough answers. And to the extent of my knowledge, there aren’t many best practice guides in this area either. However, I think the U.S. Food and Drug Administration (the American agency that approves medical devices) is starting to integrate cybersecurity into its evaluation criteria.
Even if it’s just a draft for now, I’m sure this is only the beginning and that this topic will become more and more important in years to come.
photo: © sudok1 - Fotolia.com
October 15, 2014Medical security servicesHello,
Medical security is a critical topic and everyone should be aware of it. With the medical device security there must be rules to secure patients data and test reports from an unauthorized use.
May 22, 2014
Thank's for your comment.
I didn't know this document. I read the abstract with attention!
May 16, 2014Mark ThristanHi Philippe, Strictly speaking all OTS (i.e. COTS and SOUP) software, including OS should be part of a managed approach to Medical Devices. This is outlined in IEC62304 items for design, risk and configuration, in the FDA Guidance for Off-the-Shelf Software Use in Medical Devices, and in terms of general verification and validation required for Medical Devices.The FDA points to the need for patching for security/cybersecurity in guidance and draft guidance for Networked Medical Devices Containing Off-the-Shelf (OTS) Software and Management of Cybersecurity in Medical Devices. However, this just sets out what you need to do, with not much detail on how to do it, and obviously is more likley to be seen in new device submissions than in older legacy platforms... Happy reading, Mark