To use Linux in a medical device that has a safety requirement, embedded developers must follow the processes defined by appropriate certification standards. Alongside safety, security is also an important factor in medical device development, but not all aspects of security are tied to safety. Nevertheless, if the device is not secure, it is possible for bad actors (or even simple bad luck) to influence what happens to the detriment of the patient’s safety and well-being. This article covers the use of Linux for embedded development and the security measures required for today’s medical devices.
Linux is the most heavily used operating system (OS) for medical devices. Its global developer base focuses on ensuring that it works as expected in all conditions and is as secure as possible. Linux is thus the most studied OS in the world with that base conscientiously working on improving the OS and other open-source packages. At the same time, there will also always be a small number of hackers seeking ways to break into Linux for their own purposes. The security of applications using open-source technologies is a constant tug-of-war between these opposing forces.
Linux (and other major open-source packages like OpenSSL or SQLite) can have unpredictable interactions with the other software that might be running in a system. This is complicated by the fact that many flaws are hard to find in code reviews, normal testing, or by static analysis — they can lurk undetected unless software is combined with task switching and inter-process communication. Best practices cannot identify every possible flaw or exploit. Moreover, much of the open-source software in use was not even originally developed according to today’s best practices.
The most important pieces of open-source software used today are nevertheless much more stable and secure than they were five years ago. This is mainly due to the efforts and diligence of engineers globally toward identifying those avenues vulnerable to exploitation, fixing them as they are found, and remaining vigilant to avoid similar issues occurring in their own projects. It is becoming harder to find exploitable flaws in important infrastructure software, but the work involved remains – and likely always will be – ongoing.
Security issues in Linux (including software such OpenSSL) are often found either by happenstance (bugs uncovered during development and design) or concerted efforts to find exploits (‘white hat’ hacking). Sometimes, an exploit will be found during the post-mortem after an attack.
However they are discovered, the engineers that find these exploits need to spread the news to the community around any open-source components involved.
This is typically done through the Common Vulnerability and Exposures (CVE) group. CVE is run by MITRE, an organization closely related to the U.S. National Vulnerability Database (NVD) that is itself managed by the National Institute of Standards and Technology.
The engineer that discovers an issue does not generally go to the CVE authority directly. Instead, he or she contacts a middleman organization. There are about 90 of these and they are known as CVE Numbering Authorities (or CNAs). As the name suggests, a CNA assigns a CVE number and gets the ball rolling with the CVE database and the NVD.
So, once a vulnerability has been understood and a fix made available, it will be publicized by the CVE along these lines. Most such vulnerabilities are found by the ‘good guys’, but under this model, the ‘bad guys’ do find out about them at the same time. They may still be able to deploy exploits that take advantage of newly-revealed vulnerability. That said, alerts from the CVE remain very important, so that any organization potentially affected in the worldwide user community can review whether a particular exploit does affect their devices. If so, the owner can then mitigate the issue before it is attacked. Perhaps not every user will update every vulnerable device. Some will be left open to attack, but this openness in communication prevents more breaches than it causes.
Design-for-safety is no longer simply a hardware or software issue, but an integrated systems issue. To take full advantage of the lower board bill-of-materials costs and higher integration of components in an advanced multiprocessor chip for a safety-sensitive design, applications must be kept separate. This is known as mixed-safety criticality.
For example, developers can run the user interface portion of a system on a processor cluster that is optimized for applications with features like multi-level cache, and power islands for conserving consumption by individual processors and memory on battery-operated medical devices. Linux can also enable optimal use of an application processor cluster thanks to built-in features such as symmetric multiprocessing, task parsing, and individual processor threading.
Simultaneously, the safety-critical portion of a system can be run on a separate cluster dedicated to real-time processing with features like tightly-coupled data, and instruction memory with extremely low fetch cycles and highly deterministic performance – or lockstep mode for error detection.
Advanced multiprocessing systems contain hardware-enforced isolation that separates the worlds of the application and the safety-critical. However, to take advantage of these hardware features, the software designer needs to use middleware such as the Mentor Hypervisor or Mentor Multicore Framework. These software packages make it possible to deliver important system-level functions possible such as secure inter-processor communication (IPC) between the processor clusters.
Linux is easy acquired, usually from a board or microprocessor vendor. It is available ‘as-is’ so you can quickly get a system up and running. However, it is up to the device developer to perform Linux maintenance, apply timely updates and manage other issues that arise over the lifetime of the device, once it reaches its first release.
This involves committing engineering resources to monitor and maintain the significant number of CVEs that are reported against open-source components every day. In 2019, there were 170 CVEs issued against the Linux kernel alone and 12,174 CVEs created in total. It is a significant effort to review each of these, determine their importance, round up the fixes, and verify that the OS is still operating as expected. A commercial Linux provider will do this as a core competency and charge for the service. But a medical device manufacturer – indeed any device manufacturer – should consider focusing on maintaining its devices itself over their lifetimes. It will cost less in the long run and result in higher-quality products with fewer integration issues.