Do you remember the hacked Hospira infusion pump in 2015, which was a big story in the news and forced an FDA product recall? A laptop with applicable software was connected to the maintenance port, which was an Ethernet Network port, of this pump and the hacker got soon access to the medical library of this pump and also the Wi-Fi credentials of the internal hospital network. But how and why did this happen? There are different underlying reasons why this hack was possible. One is that during the development of this pump, Cyber-/IT-Security was possibly not recognized as important or it was assumed that only the hospital personnel would have access to the maintenance port of this infusion pump. It is also possible that it nobody thought this pump would be one day connected to a network and the internet. A third reason could be that the developer of this device did not have sufficient experience in the area of secure programming. And finally, it could be that for updating the software of the pump a whole revalidation would be required. Let’s take a closer look into this area.
Different Lifecycle of Medical Devices and Software
As you may know, each year new smartphones are launched. Along with these launches, Google and Apple introduce major updates of their smartphone and tablet OS every year and bring their devices up-to-date every quarter to month for bug fixes. In the consumer electronics world this is okay, but for the regulated industries like medical devices with product lifecycles from 10 to 20 years or even longer, this could be a problem. Think about a Bluetooth enabled pacemaker. The time from concept to market for medical devices is approximately 3–7 years. The pacemaker will be around about 13 years on the market and will reside up to 10 years and more inside the patient. This shows, that keeping this pacemaker up-to-date is a tough challenge. You think this is only theory? You are wrong. Unsecure St.Jude pacemakers, which needs a security update were in the news when this blog article was written in January 2017.
Let’s take an example: You or an external party discovers 10 years after market approval a security vulnerability in the Bluetooth connection of your Bluetooth enabled pacemaker, which allows potential attackers to kill the patient via internet. How are you going to fix it? One option would be to apply an update to those affected pacemakers. However, this could lead to a re-validation of all devices and you would have to indicate all affected patients. The FDA or EMA could force you to recall the pacemakers from the market and you would have to provide to any patient a replacement surgery. Also, some questions could come up: Does your pacemaker have enough CPU power to deal with this security update? What happens when this update fails? Is this device not already outdated from a technology point of view? And why do I still need to fix it? These are all valid questions which need to be answered with a risk-based approach.
No awareness of Cyber/IT-Security for connected Medical Devices
Another problem is, that companies enable connection on their medical devices to the outer world with no experience to secure them or they think, Cyber-/IT-Security is a low risk, which does not have to be considered. The first point can be fixed by increasing the cooperation between medical device engineers and Cyber-/IT-Security professionals internally and externally. The second point needs a mindset change. Here the company have to decide if they want a shorter time to market with an unsecured product or a secure product, which may take a year longer to the market. This decision can make the difference between a good image with high net sales and a bad image with low net sales. One important thing is if security researchers find a vulnerability in one of your products, do not force a lawsuit against them. Work together with them to make your products more secure.
The Risk of Firmware
Take a look at some risk factors of firmware, which should be considered during a risk assessment according to GAMP5:
- Highly split development of firmware, only interfaces are mostly documented.
- Chain of Error correction
- Too many features (the more complex a system is, the more exposed to failure it is)
- Mostly no time to check inherited liability
- Less used functions are less tested
- Connect legacy interface without any or un-secure security functions via adaptors to the network/Internet
- Statistically 50 Bugs in 1000 lines of Code
TOP 10 Firmware development failures:
Now here are the Top 10 firmware Development failures, which would need to be avoided to develop secure medical devices:
- Insecure Web Interface
- Insufficient Authorization/Authentication
- Insecure Network Service
- Lack of Transport Encryption
- Privacy Concerns
- Insecure Cloud Interface
- Insecure Mobile Interface
- Insufficient Security Configurability
- Insecure Software/Firmware
- Poor Physical Security
How to deal with it
To mitigate the Cyber-/IT-Security risk of your connected medical device firmware (Internet of things), it is recommended to you these follow following approaches:
- Check cybersecurity of connected firmware with the same amount of attention as the business models behind this
- Think about, what function should be implemented and activated. Does this function offer a value and does not harm the patient or set his/her life on risk?
- Change default passwords and use strong passwords
- Implement auto-update functions to deliver security updates to software based Medical Devices. If the software based Medical Device is not connected every time and everywhere to the Internet, implement a function to inform the patient about security updates
- Have skilled people in your team who know how to fix IT/cybersecurity issues. Your patients will be grateful for this.
For those of you who want to know more, please take a look in the guideline “13 Steps how to develop secure IoT Products” from the cloud security alliance which was published in October 2016.
Please keep in mind, that security through obscurity will not work in a connected world in the long run.
We at KVALITO can provide you with the experts you need to deal with Cyber-/IT-Security topics for your medical devices and digital health apps. We have experts with multiple years of experience in the GxP and Cyber-/IT-Security area, who know how to bring both worlds together. For those of you, who want to know more about how to deal with the topic of this blog post, please see our blog post about the published FDA Guidance on “Postmarket Management of Cybersecurity in Medical Devices”.
Author: KVALITO Consulting
