Medical Devices MUST Be Secure
I recently had the opportunity to present in a Webinar focusing on security needs of medical devices along with Patrick Carrier of Infineon and Bob Blumenscheid of Digi. I thought there were some interesting points covered in the discussion that warranted discussing here.
While both Patrick and Bob’s presentations were interesting, I took special interest in Patrick’s focus on modern security issues and their impact on medical device manufacturers. I generally focus on software aspects of security, so I thought his perspective on hardware aspects of device security was especially helpful. The main takeaway I had from his presentation was that counterfeits and fakes are becoming an increasingly serious security threat to hospitals, medical providers and consumers of home medical devices, putting themselves, their health, personal information and networks at risk. While this has been an issue in the industrial market for some time, this was the first time I had considered it to be more than a theoretical threat in the medical market.
The other point along these lines in his presentation was that there are capabilities built into modern microcontrollers and boards which can help to ensure the validity of the medical devices that these providers and consumers might want to use.
This leads to one of my major beliefs about security in all devices from a software standpoint, and it doubly applies to medical devices. Before thinking about your security policies, consider the security capabilities that your hardware platform provides, and make certain that these capabilities are enabled by the software you use to build your application. I liken this principle to that of your front door. Your front door has a lock, but if you don’t lock it, then it does nothing to keep the bad guys from walking right in. The same logic applies here; if your hardware platform provides facilities to help you secure your device and you don’t use them, then you are allowing the bad guys to walk right in for whatever purposes they desire, whether that’s stealing personal data, installing ransomware, compromising the provider’s network, or all the other attacks you’ve heard about in the news.
Beyond that, I discussed the needs of the medical device provider to focus on security aspects during every step of their design and development process if they are going to be successful gaining regulatory approval for their device. The FDA and other national authorities are expecting the device provider to provide evidence of this activity as part of their 510k submission considering HIPAA, device security when the device is first marketed, and how the device will maintain its security through its lifetime once deployed, along with concepts to consider in the software design, development and testing for the device that will help ensure these goals.
The design, development and testing concepts described are not sufficient to manage the security of your device throughout its lifetime; beyond this, being able to manage security attacks that were not considered during development is also needed for your device to remain secure. Not considering these attacks is not a shortfall of your process; new vulnerabilities and attacks are discovered at a blistering pace; what is important is that you acknowledge this during the design and development of your device, which likely means that you build an ability to update the software in your device safely and securely. These considerations must be taken into account regardless of how your software is built; whether you write “bare-metal” software (i.e. software without an operating system), using a real-time operating system (RTOS), or using Linux.
More and more, medical device manufacturers are looking for Linux to solve a host of issues they have during development. Linux combines high-end flexible UI capabilities with connectivity, ease of development, and state-of-the-art security facilities. At the same time since Linux and associated open-source software is ubiquitous as well as being the most heavily studied software in the world, security issues are discovered and fixed all the time. This is actually a feature, since the community has determined that it’s important to continually strengthen the security of the Linux ecosystem and has built up policies that allow open-source projects to learn about their issues and fix them before they become known to the world. This is achieved through a mechanism called Common Vulnerabilities and Exposures (CVEs), and if your medical device uses Linux, your regulator will want to make certain you have a plan for monitoring these throughout the lifetime of your device, and have procedures in place to resolve high impact issues when they’re discovered.
Siemens Embedded has the products, knowledge and ability to help you through the tangled web of requirements I’ve discussed, regardless of the foundational software you decide to use. The Nucleus® RTOS, and the Flex OS and Omni OS Linux distributions, along with Siemens Embedded’s world-class support and professional services provide you the advice and capabilities you need to manage security both up-front and during your device’s lifetime.
If you’re interested in looking at the webinar, you can find it here: https://opensysmedia.com/solutions/webcasts/event/1026
Robert Bates, Chief Safety Officer
Siemens Embedded
