CYBERSECURITY – Cybersecurity for Connected Medical Devices: A Holistic Approach During the Entire Product Lifecycle
Cybersecurity is a topic that periodically gets headlines when a new category of devices connects to the Internet or creates a local network to provide added value to the end user. For example, due to the increase of personal computers connected to the Internet and the introduction of services that deal with sensitive data, there has been a gradual shift from HTTP (not secure) to HTTPS. For about 10 years, we have become accustomed to being connected to the Internet 24/7 with our smartphones; these devices are therefore a target of hackers who daily attempt to find security flaws. This is also true for automotive, Industry 4.0, IoT, and medical devices: a new era of connected devices.
The following focuses on cybersecurity issues relating to medical devices that are rapidly becoming more connected. Larger medical devices are connected to the hospital network, and they exchange patients’ personal data and the results of analyses and therapies with other devices inside the same network. Smaller medical devices directly used by patients can send logs and other personal data to smartphones (or directly to a server in a cloud), in order to monitor the therapy, and to share the information with family members and doctors. We are in the midst of the Digital Health transition, but not all medical devices were designed with security at the beginning of their development lifecycle.
The following explains why cybersecurity is important for connected medical devices and how to integrate ad hoc activities to tackle cybersecurity in the early phases of product development. The risk management drives the design choices, guiding the development teams in balancing a systematic approach with a systemic and holistic viewpoint of the entire system.
WHY ATTACK A MEDICAL DEVICE?
An attacker might have several reasons and opportunities to target a medical device. The data stored or transferred by the device often has value (eg, personal data). The hacker might be interested in modifying data or in altering functionalities of the medical device. The effect of such attack could be a safety harm for the patient, or economic damage to the healthcare facility that is prevented from using the medical device.
An opportunity to target a medical device originates from the growing complexity of the modern devices and, in particular, of the firmware and software they embed. Operating systems and communication protocol libraries are commonly integrated into medical devices as third-party software but, due to the vulnerabilities of such off-the-shelf software, the medical device inherits the same software vulnerabilities. A famous example is the ransomware WannaCry, which spread across thousands of personal computers including hospital facilities and their medical devices.1 The attackers took advantage of a weakness in the Microsoft Windows operating system, and were able to finalize the attack because those devices remained unpatched for a long time. During the pandemic, the number of ransomware attacks has increased, and cyber-criminals have shifted their target from random individuals to large companies. Recent attacks disrupt operational technology (OT) of those companies, and here are just few examples from recent news: Healthcare and Public Health Sector, Colonial Pipeline, JBS, Bose.2-5
Finally, considering that cybersecurity is a relatively new topic for connected medical devices, it follows that insecure devices could be selected by hackers as easy targets. Hackers could use medical devices as a starting point for more complex attacks, similar to what happened with Mirai malware.6 It infected home routers and IP cameras, using them to launch a DDoS attack on various servers across the Internet.
SAFETY, SECURITY & C-I-A
The C-I-A triad stands for Confidentiality, Integrity, and Availability, and is the basis of information security. Confidentiality indicates the protection of data and information at rest or exchanged between a sender and one or more recipients; Integrity is the guarantee that the data has not been altered at rest or during transmission from the sender to the recipient; Availability indicates precisely the availability of data and services for users who are authorized to use them.
Since 2014, regulators’ attention to cybersecurity has been increasing. Manufacturers are required to take care of security risks and mitigations during the development of the medical device, and are required to monitor for new vulnerabilities when their devices are on the market. Figure 1 shows a subset of resources available to medical device manufacturers from national and international regulatory or working groups.
In order to assess and control the risks that may impact the basic safety and essential performance of medical devices, manufacturers apply the ISO standard 14971:2019 (Application of risk management to medical devices).7 Figure 2 shows the link between cybersecurity and safety: confidentiality can be associated with the concept of privacy, while a lack of integrity and/or availability can compromise the safety of the medical device.
For this reason, the AAMI TIR57:2016/(R)2019 (Principles for medical device security – Risk management) suggests executing the security risk analysis in parallel to the safety risk analysis.8 Each output of one analysis (eg, a new risk control measure added to the system) shall be checked and verified against the other risk analysis. For example, adding an encryption algorithm that is too demanding for the medical device might impact its performance and so might impact its safety.
FRAMEWORKS FOR MANAGING CYBERSECURITY
A widely used framework for managing cybersecurity risks is the one proposed by NIST in 2014.9 The NIST framework is not specific to the medical industry but helps organizations to integrate cybersecurity into their processes. The framework defines the activities to be implemented to manage cybersecurity (core functions and categories) and defines criteria to assess the maturity level (tiers) of organizations. The five basic functions defined as ”core”- Identify, Protect, Detect, Respond, Recover – have inspired many of the subsequent standards or guidelines indicated in Figure 2.
Premarket submission guidance issued in 2014 by the Food and Drug Administration, in the US, suggests guidelines for managing cybersecurity in medical devices during the design phase.10 Manufacturers can take their cues from some of the mitigations proposed for the Identify and Protect functions, such as user authentication, role and privilege identification, session timeouts, and software/firmware updates with digital signature mechanisms. For the Detect, Respond, and Recover functions, the guidance suggests that the devices be able to detect attacks, track them in logs, and, most importantly, still be able to provide the basic safety and essential performance capabilities for which they were designed. An updated draft of the guidance was released in 2018; it focuses on the security testing that manufacturer should perform and document to ensure that security measures are implemented, are effective, and do not introduce safety risks.11 The emphasis on testing is also evident when reading the table of contents of UL 2900-1 and UL 2900-2-1 (which the FDA has recognized as applicable standards:)12-15
- Known vulnerability testing
- Malware testing
- Malformed input testing
- Structured penetration testing
- Software weakness analysis
- Static source code analysis
- Static binary and bytecode analysis
Other updates in the draft premarket guidance are about the level of documentation that manufacturer should provide as evidence that they have designed and implemented security features correctly. Furthermore, it is required that each single design decision is derived from a rigorous risk analysis activity as described in the following section.
It is worth mentioning that most of the guidelines have the following common points to tackle the cybersecurity issues of a medical device:
- the risk analysis is a key activity to conducted throughout the entire development process
- a secure design development shall be established
- security testing shall be executed
- all the activities shall be documented properly
- the end user shall be notified about security features and risks of the medical device
- manufacturers shall monitor their devices on the market for new vulnerabilities that might be found and might cause risks for the patients
SECURITY RISK MANAGEMENT
Figure 3 shows a simplified framework inspired to the one proposed by the Joint Security Plan in January 2019.16 The JSP highlights the need to manage risk management activities during all phases of development and, very importantly, even during device commercialization. If the device’s safety analysis can be considered valid throughout the life of the device, with regard to cybersecurity, it is necessary to re-evaluate the analysis periodically because new vulnerabilities are constantly being discovered. A device classified as secure the day it is approved for commercialization may no longer be so in the following months.
AAMI TIR57 (Principles for medical device security – Risk management) defines guidelines for:
- identifying assets, vulnerabilities, and threats
- assessing risks
- evaluating countermeasures
- monitoring effectiveness
Note that TIR57 proposes a new definition of harm, expanding the one introduced by ISO 14971 (physical injury or damage) by adding the concepts of reduction of effectiveness, breach of data, and system security.
In the initial phases of a project, it is useful to identify the assets to be protected, and to evaluate the communication channels of the device with the external networks. When the system is fully described, the next step is the threat modeling, ie, the evaluation the possible threats and vulnerabilities that could affect the assets. Examples of assets (also suggested by TIR57) are the software itself that guarantees the functionality of the medical device, the encryption keys, the digital certificates, the user data, the logs, the configuration data, the communication interfaces, etc.
When a complete description of the system is available, it is useful to also analyze the internal interfaces. The example shown in Figure 4 highlights that the “Subsystem 3” of that hypothetical medical device does not have a direct link to any asset, but its relationship with “Subsystem 4” might allow an attacker to access the three assets of the device. For this reason, the internal interfaces between “Subsystem 4”, “Subsystem 3”, and “Subsystem 2” shall be carefully analyzed and, if they are really necessary, they shall be secured properly.
An output of the Security Risk Assessment activity is the definition of the Security Requirements that implement the risk control measures identified during the risk assessment. These requirements impact the system architecture and, subsequently, the product development, its verification, and validation.
Cybersecurity is not synonymous with cryptography, which represents only one of the possible Cybersecurity tools. It is not an exclusively software matter. In fact, many disciplines contribute to design a device that is inherently secure. Physical protection can be added to the device, limiting access to communication ports. Specific electronic components, such as secure elements, can be integrated in the design in order to protect keys and sensitive data, and to implement cryptographic functionalities. Usability is also important because the security mechanisms should be transparent for the end user, or at least should not compromise the overall user experience.
MANAGING THE COST OF CYBERSECURITY
The security-related activities added to a design lifecycle do not come for free. They require additional costs to design and protect the medical device during the development phase. They also require a structured maintenance plan to monitor new vulnerabilities and apply security patches as necessary. These can be classified as proactive costs. But if something goes wrong, manufacturers might face reactive costs for a recall campaign, complicated forensic analysis or, even worse, penalties.
The right approach is to invest in proactive costs, designing a secure device from the beginning. In addition, reactive costs are generally higher than the proactive costs. Reactive costs may also have a negative effect on the brand reputation.
Cybersecurity should be managed during the entire life cycle of a project, from the initial idea, through the marketing of the product, and post-sales support. This is the suggested approach to design and maintain a safe and secure device.
The design team shall include product security experts to conduct security risk analysis properly, to help define an architecture that includes security control measures, to perform design review, to execute security testing, and to plan maintenance activities. The system engineer leading the project shall contribute by approaching the cybersecurity with a holistic mindset. Safety and security risk management activities shall be conducted in parallel, identifying the security risk control measures that should be translated into System Requirements or Software Requirements.
Several guidelines specific for the medical industry are available upon which device manufacturers can rely to define their own secure product development lifecycle.
Note: This article is based on an article published in Viewpoints Newsletter of AISE, the Italian chapter of INCOSE, Issue 6, 2018.
- Kaspersky.com – What is WannaCry ransomware?, https://www.kaspersky.com/resource-center/threats/ransomware-wannacry
- us-cert.cisa.gov – Alert (AA20-302A) Ransomware Activity Targeting the Healthcare and Public Health Sector,https://uscert.cisa.gov/ ncas/alerts/aa20-302a
- BBC.com – US fuel pipeline hackers ‘didn’t mean to create problems’, https://www.bbc.com/ news/business-57050690
- bloomberg.com – All of JBS’s U.S. Beef Plants Were Forced Shut by Cyberattack, https://www. bloomberg.com/news/articles/2021-05-31/meat-is-latest-cyber-victim-as-hackers-hit-top-supplier-jbs
- threatpost.com – Bose Admits Ransomware Hit: Employee Data Accessed, https://threatpost.com/bose-ransomware-employee-data/166443/
- CSOonline.com – The Mirai botnet explained, https://www.csoonline.com/ article/3258748/the-mirai-botnet-explained-how-teen-scammers-and-cctv-cameras-almost-brought-down-the-internet.html
- ISO 14971 – Application of risk management to medical devices, https://www.iso.org/standard/72704.html
- AAMI TIR57 – Principles for medical device security – Risk management, https://store.aami.org/s/store#/store/browse/detail/a152E000006j60WQAQ
- NIST framework, https://www.nist.gov/cyberframework
- FDA – premarket guidance 2014, https://www.fda.gov/media/86174/download
- FDA – premarket guidance draft 2018, https://www.fda.gov/ media/119933/download
- UL2900-1, https://standardscatalog.ul.com/ ProductDetail.aspx?productId=UL2900-1
- UL2900-2-1, https://standardscatalog.ul.com/ProductDetail.aspx?productId=UL2900-2-1
- UL2900-1 as recognized consensus standard, https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=36149
- UL2900-2-1 as recognized consensus standard, https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=37046
- The Joint Security Plan (JSP), https://healthsectorcouncil.org/wp-content/uploads/2019/01/HSCC-MEDTECH-JSP-v1.pdf
FURTHER SUGGESTED READINGS
- FDA – post market guidance, https://www.fda.gov/media/95862/download
- AAMI TIR97 – Post market riskmanagement, https://store.aami.org/s/ store#/store/browse/detail/a152E000006j60oQAA
- mitre.org – Common Vulnerabilities and Exposures (CVE®), https://cve.mitre.org/
- nist.gov – National Vulnerability Database (NVD), https://nvd.nist.gov/
- mitre.org – Common Weakness Enumeration (CWE™), https://cwe.mitre.org/
- IMDRF – Principles and Practices for Medical Device Cybersecurity, http:// www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-200318-pp-mdc-n60.pdf
- MDCG 2019-16 rev.1 – Guidance on cybersecurity for medicaldevices, https:// ec.europa.eu/health/sites/health/files/md_sector/docs/md_cybersecurity_en.pdf
Nicola Alagia is a Senior Systems Engineer who has been working for Flex in the medical industry for more than 13 years, focusing on software development and cybersecurity. He currently leads a multidisciplinary team in Flex’s Milan Design Center to integrate cybersecurity and regulatory requirements into product development. He graduated with a degree in Telecommunications Engineering from Polytechnic University of Milan. He also attended a 1-year post-graduate master in Information and Communication Technology studying solutions to secure the forthcoming mobile ad hoc networks (similar to the modern Zigbee and BLE mesh networks). Prior to Flex, he worked as firmware engineer for Pirelli Broadband Solutions, an Italian telecommunications company.
Total Page Views: 1390