On April 17, 2018, the United States Food and Drug Administration (FDA), announced plans to ask Congress for more funding and regulatory powers to improve its approach towards medical device safety, including cybersecurity. As we all know, medical devices play a crucial role in the treatment and diagnosis of illness and disease. From common medical supplies (bandages, hospital gowns) to complex instruments (MRI machines, heart valves, etc.), the FDA regulates over 190,000 different devices manufactured by more than 18,000 firms in more than 21,000 medical device facilities worldwide.
The FDA’s plan (1) intends to require medical device makers to create a document called “Software Bill of Materials” for each medical device. This document would include software-related details for each product. It also wants device makers to include mandatory software update delivery systems to deliver critical security patches. The idea is to help device owners “better manage their networked assets and be aware of which devices in their inventory (or use) may be subject to vulnerabilities.”
The FDA, the only federal government agency responsible for the cybersecurity of medical devices, now considers the medical device manufacturer responsible for the validation of all software design changes, including computer software changes to address cybersecurity vulnerabilities. As this plan declares, the FDA will not conduct pre-market security testing for medical products, as it considers cybersecurity testing to be the responsibility of the medical product manufacturer. It also clarifies that the medical device manufacturer will choose what software to use, thus bearing responsibility for the security as well as the safe and effective performance of the medical device.
While the FDA already has a set of cybersecurity guidelines (2), malicious attacks will likely grow as more medical equipment becomes connected and, therefore, vulnerable. The FDA cybersecurity guidelines look to mitigate serious threats to connected medical devices, especially attacks that could disrupt the operation of critical monitors and drug delivery equipment.
Historically, Linux has been the operating system of choice for a wide range of medical devices where IEC 62304 safety certification has not been required. Since the first edition of the IEC 62304 standard was created about 12 years ago, safety certification requirements have become more prevalent and BlackBerry QNX has seen significant interest in our IEC 62304 compliant operating system (QNX OS for Medical).
By supporting the needs of medical device manufacturers, BlackBerry QNX reduces program cost and risk, and shortens the time-to-market (revenue) for medical device developers. The product is shipped with the independent third-party assessed declaration of compliance to IEC 62304 Class C, the highest class for applications where death or serious injury is possible.
There are many reasons why using Linux in connected medical devices is not a great idea, some of which are highlighted in the following whitepapers:
Total Cost of Ownership Linux vs. QNX – Part 1
Total Cost of Ownership Linux vs. QNX – Part 2
Total Cost of Ownership Linux vs. QNX – Part 3
These whitepapers demonstrate the many limitations of using Linux in medical devices. Examples include the higher Total Cost of Ownership driven by product-specific testing, added time to market, and the cost of maintaining in-house OS experts. In addition, the challenges associated with IEC 62304 safety certification as well as security vulnerabilities make Linux sub-optimal. In 2017, BlackBerry QNX released SDP 7.0 which incorporates several security features at the OS level. Complementing SDP 7.0, BlackBerry’s Over-The-Air (OTA) software update platform has been optimized for embedded systems and battery-operated devices. BlackBerry was the first company in the world that developed a secure OTA system and, from 2013 to 2017, executed over 50 million OTA updates successfully. Both are perfect examples of what the FDA is asking for in a secure, safety-certified, RTOS with an eye on managing life-cycle software upgrades and device security.
Now, let’s move from the FDA to another government agency, the National Institute of Standards and Technology (NIST), and its National Vulnerability Database (NVD). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, misconfigurations, product names, impact metrics, and, most important to our discussions, security-related software flaws. To access this database and see interesting snap shots of QNX vs. Linux from a security vulnerability perspective, please go to https://nvd.nist.gov/vuln/search, enter the word QNX, then choose the statistics button. Then do the same for Linux. Here you will see the number of Common Vulnerabilities and Exposure (CVEs) per year for each OS.
For QNX
For Linux
In the above charts, please consider the Y-axis representing the number of vulnerabilities, historic as well as current. These charts tell a story. Usually when you talk to the open source proponents, they all tout that with open source, there is an army of developers fixing bugs and security issues. However, to those of us in the cybersecurity business, it is obvious that there is an even larger army that is creating bugs and finding security vulnerabilities. In one estimate, over 30% of hacks related to electronic products we read about in the press are the result of “a back door being left open” during the design and integration phase. It is not hard to imagine that there are a lot of backdoors in open source, masquerading as “good, easy to use software components”. BlackBerry QNX only comes from one source, BlackBerry QNX.
How can you mitigate the risk of cyberattacks if, as a medical equipment manufacturer, you are getting ready to release a product using Linux or any other unsecure operating system? Consider BlackBerry Jarvis, a powerful Static Binary Application Security Testing (SAST) tool that will help you analyze your binary files without source-code, and quantify and prioritize areas of risk to mitigate. BlackBerry Jarvis also provides security posture management, so that the effectiveness of a software security strategy can be measured over time.
Learn more about Jarvis and how BlackBerry can help automakers secure their software supply chain.
Finally, I would highly recommend that you read our white paper, “BlackBerry’s 7-Pillar Recommendation for Cybersecurity”, which provides a framework to secure a medical (or any other type of) device over its life-cycle in the age of connected everything.
References
