Cybersecurity Perspective – Physical OTS Components in Medical Devices

Medical devices are now considered a subtype of Internet of Things (IoT) devices [(2) https://owasp.org/www-pdf-archive/SecureMedicalDeviceDeployment.pdf]. There is a growing need to properly document the physical off-the-shelf (OTS) subsystem components that a medical device contains. Medical devices are often no longer stand-alone devices which contain only proprietary components. Inattention to additional components may lead to a gap in effectively assessing potential hazards a device may contain. In cybersecurity submissions, analysis of OTS components in a medical device should be complete and easily accessible in documentation.

Often highlighted is the concern of vulnerabilities arising when OTS software is not properly patched and maintained, such as when a new vulnerability has been discovered [(7) https://www.fda.gov/regulatory-information/search-fda-guidance-documents/information-healthcare-organizations-about-fdas-guidance-industry-cybersecurity-networked-medical]. However, if a physical component is omitted from OTS documentation, traceability may be absent to cybersecurity vulnerabilities that need to be considered in the software of a device. In addition to considering traditional safety, risks and hazards for device assets must also be considered from a cybersecurity perspective.

Why Physical OTS Components in Medical Devices?

To illustrate why subcomponents must be included in OTS documentation in development, consider secure communication. When considering wired or wireless network components, both internal and external components should be incorporated clearly within system architecture documentation. This includes components such as hard-wired ethernet connections, Bluetooth, BLE, Wi-Fi, and USB connections. Rather than focusing solely on complex communications and their encryption methods, it is necessary to document all forms of communication a device is capable of. The intended environment(s) for the device and its possible connection configurations should also be documented and assessed for security [(8) http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-200318-pp-mdc-n60.pdf]. If a new form of communication may be added in future iterations of a design, it is highly recommended this be noted whenever feasible, so that future cybersecurity risk assessments can take them into account accordingly. These secure communications considerations should be clearly documented to lower the chance of discontinuity across documentation.

Secure communication is only one aspect of design consideration where documenting components within a device is necessary. In practice, it is necessary to consider all components, regardless of their function. To illustrate the inherent relation between tracing components back to vulnerabilities, AMD’s Radeon graphics cards can be used as an example. Four vulnerabilities, currently all listed as a 9.9 in criticality level, were discovered by MITRE on July 20th, 2020. According to the National Vulnerability Database, these cards were compromised by certain compatible drivers that were found to have exploitable code execution and memory corruption vulnerabilities [(9) MITRE. CVE-2020-6100,6101,6102,6103]. Had these cards not been considered as components of a computer system, the corresponding drivers would not have been identified in a timely fashion. This gives an example of how a cybersecurity breach could arise as result of omitting all internal components.

High profile vulnerabilities

In August 2020, a more severe vulnerability was reported in insulin pumps. Miniature circuit boards used in insulin pumps distributed by IBM and other medical companies were found to have a vulnerability that allows an attacker to overdose a patient. Further abilities of the attacker include altering readings from the device and hiding vital signs of a patient [(6) https://www.medtechdive.com/news/insulin-pumps-among-millions-of-iot-devices-vulnerable-to-hacker-attacks/584043/]. This miniature circuit board, produced by the French company Thales, is an example of an Industrial Control System (ICS). ICS is a term used for several types of control systems, which range from programmable logic controllers to SCADA systems. These types of issues are not projected to cease any time soon. Attacks against ICS systems have increased 2000% since 2018 [(5) https://newsroom.ibm.com/2020-02-11-IBM-X-Force-Stolen-Credentials-and-Vulnerabilities-Weaponized-Against-Businesses-in-2019].

Including complete analysis of OTS components in documentation lowers the risk from another inherent, yet unintentional, threat agent – benign insiders. Documenting all subcomponents in a device lowers probability of occurrence for harms related to human error. As interconnectivity becomes more ubiquitous in medical technology, proper documentation is of particular importance to networked devices. When incorporating components into a networked medical device additional precautions should be taken. Here, networked refers to software or components with the ability to connect to a private intranet or public Internet [7]. In a networked medical device, OWASP Top Ten vulnerabilities must be considered when assessing security [(2) ]. Two examples of how this assessment may be negatively impacted if components are not documented from the current OWASP Top Ten are security misconfiguration and using components with known vulnerabilities. If it is not known that a subsystem component is in a device, the device cannot be assessed for proper security configuration or known vulnerabilities. The likelihood of occurrence for these types of inherent backdoors that stem from human error can be lowered by properly defining all assets in a physical system architecture.

Note: According to OWASP, medical device companies can determine what type of questions to expect in a cybersecurity submission using their OWASP Secure Medical Device Deployment Standard: Purchasing Assessment Criteria. This list provides relevant questions to be considered in a medical device for three groups of assessment criteria:

When OTS components are mentioned in cybersecurity documentation there has traditionally been an emphasis on addressing these as either the software within a medical device (SwMD) or software as a medical device (SaMD). As medical technology becomes more complex and IoT expands, the need to address individual physical components contained in a medical device will continue to grow accordingly. This includes subsystem components within a device that have a disabled functionality, either intentionally during the development process or unintentionally within a component. These subsystem components present inherent backdoor risk if they are to be discovered by an attacker and enabled. Attackers can execute code that discloses the IP, MAC address, Operating System, services, and open ports on a device. This can be used to extract further information, such as underlying system structure. Internal and design for each physical component must be documented from a cybersecurity standpoint. Defining the current known physical properties of a device clearly and concisely allows for a more rigorous cybersecurity analysis and lowers the risk for undiscovered vulnerabilities.

References:

[1] Christopher Frenz. List of OWASP Medical Device Purchasing Assessment Criteria Medical Device Purchasing. OWASP. September 12th, 2017.
[2] Christopher Frenz et al. OWASP Secure Medical Devices Deployment Standard Version 2.0. OWASP. July 18th, 2018.
[3] Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. U.S. Department of Health and Human Services. October 2nd, 2014. fda.gov
[4] Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. Draft. U.S. Department of Health and Human Services. October 18th, 2018. fda.gov
[5] IBM Security. IBM X-Force: Stolen Credentials and Vulnerabilities Weaponized Against Businesses in 2019. Newsroom.IBM.com
[6] Greg Slabodkin. Insulin pumps among millions of devices facing risk from newly disclosed cyber vulnerability, IBM says. MedTechDive. August 25th, 2020.
[7] John F. Murray Jr. Center for Devices and Radiological Health. Docket Number: FDA-2020-D-0957. Cybersecurity Networked Medical Devices Containing Shelf OTS Software. Issued FDA Guidance. fda.gov.
[8] Medical Device Security Working Group. Principles and Practices for Medical Device Cybersecurity. International Medical Device Regulators Forum (IMDRF). IMDRF/CYBER WG/N60FINAL:2020. March 18th, 2020.
[9] MITRE. CVE-2020-6100,6101,6102,6103. National Vulnerability Database. July 20th, 2020.
[10] OWASP Top Ten. OWASP. owasp.org.
[11] Sagar Patel, Battelle. Cybersecurity Bill of Materials For Medical Devices: What’s Next?. Med Device Online. April 1st, 2019.

Upcoming Training

Agile Methods for Medical Device and Health IT Software

One day course that expands on the software risk management topics covered in our IEC 62304 and other Emerging Standards for Medical Device and HealthIT Software course. Essentially the same topics are covered but in greater depth with more attention to hands-on analysis of examples.

Email training@softwarecpr.com for more info.

Corporate Office

15148 Springview St
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN) and Italy.