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 exam­ple, 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 med­ical 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 con­nected 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 de­velopment teams in balancing a systematic approach with a sys­temic 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 de­vice often has value (eg, personal data). The hacker might be in­terested 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 vulnera­bilities of such off-the-shelf software, the medical device inherits the same software vulnerabilities. A famous example is the ran­somware 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 Win­dows operating system, and were able to finalize the attack be­cause 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 indi­viduals to large companies. Recent attacks disrupt operational technology (OT) of those companies, and here are just few ex­amples 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 at­tack on various servers across the Internet.

SAFETY, SECURITY & C-I-A

The C-I-A triad stands for Confiden­tiality, Integrity, and Availability, and is the basis of information security. Confidential­ity indicates the protection of data and in­formation at rest or exchanged between a sender and one or more recipients; In­tegrity 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 avail­ability of data and services for users who are authorized to use them.

Since 2014, regulators’ attention to cybersecurity has been increasing. Manu­facturers are required to take care of se­curity risks and mitigations during the development of the medical device, and are required to monitor for new vulnera­bilities when their devices are on the mar­ket. Figure 1 shows a subset of resources available to medical device manufacturers from national and international regulatory or working groups.

Key regulatory documents released after the NIST cybersecurity framework.

Click image to enlarge

In order to assess and control the risks that may impact the basic safety and es­sential performance of medical devices, manufacturers apply the ISO standard 14971:2019 (Application of risk manage­ment 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 med­ical 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 con­trol measure added to the system) shall be checked and verified against the other risk analysis. For example, adding an encryp­tion algorithm that is too demanding for the medical device might impact its per­formance and so might impact its safety.

Relationship between safety and security.

FRAMEWORKS FOR MANAGING CYBERSECURITY

A widely used framework for manag­ing 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 cyberse­curity 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 is­sued in 2014 by the Food and Drug Ad­ministration, in the US, suggests guidelines for managing cybersecurity in medical de­vices during the design phase.10 Manufac­turers can take their cues from some of the mitigations proposed for the Identify and Protect functions, such as user authentica­tion, role and privilege identification, session timeouts, and software/firmware up­dates 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 es­sential performance capabilities for which they were designed. An updated draft of the guidance was released in 2018; it fo­cuses on the security testing that manufac­turer should perform and document to en­sure that security measures are imple­mented, 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 documen­tation that manufacturer should provide as evidence that they have designed and im­plemented security features correctly. Fur­thermore, it is required that each single design decision is derived from a rigorous risk analysis activity as described in the fol­lowing 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 con­ducted throughout the entire develop­ment 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 se­curity features and risks of the medical device
  • manufacturers shall monitor their de­vices on the market for new vulnerabil­ities that might be found and might cause risks for the patients

SECURITY RISK MANAGEMENT

Figure 3 shows a simplified frame­work 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 consid­ered valid throughout the life of the device, with regard to cybersecurity, it is necessary to re-evaluate the analysis periodically be­cause new vulnerabilities are constantly being discovered. A device classified as se­cure the day it is approved for commer­cialization may no longer be so in the following months.

Simplified product development process and key security activities.

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 def­inition of harm, expanding the one intro­duced by ISO 14971 (physical injury or damage) by adding the concepts of reduc­tion 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 chan­nels of the device with the external net­works. When the system is fully described, the next step is the threat modeling, ie, the evaluation the possible threats and vulner­abilities that could affect the assets. Exam­ples of assets (also suggested by TIR57) are the software itself that guarantees the functionality of the medical device, the en­cryption 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 an­alyze the internal interfaces. The example shown in Figure 4 highlights that the “Sub­system 3” of that hypothetical medical de­vice 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.

External and internal interfaces of a system and their links to the assets.

An output of the Security Risk Assess­ment activity is the definition of the Security Requirements that implement the risk con­trol 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 protec­tion can be added to the device, limiting access to communication ports. Specific electronic components, such as secure el­ements, can be integrated in the design in order to protect keys and sensitive data, and to implement cryptographic function­alities. Usability is also important because the security mechanisms should be trans­parent for the end user, or at least should not compromise the overall user experi­ence.

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 classi­fied as proactive costs. But if something goes wrong, manufacturers might face re­active costs for a recall campaign, compli­cated forensic analysis or, even worse, penalties.

Managing the cost of cybersecurity.

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 proac­tive costs. Reactive costs may also have a negative effect on the brand reputation.

SUMMARY

Cybersecurity should be managed during the entire life cycle of a project, from the initial idea, through the market­ing 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 archi­tecture that includes security control meas­ures, 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 Require­ments 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 life­cycle.

Note: This article is based on an article published in Viewpoints Newsletter of AISE, the Italian chapter of INCOSE, Issue 6, 2018.

REFERENCES

  1. Kaspersky.com – What is WannaCry ran­somware?, https://www.kaspersky.com/resource-center/threats/ransomware-wannacry
  2. us-cert.cisa.gov – Alert (AA20-302A) Ransomware Activity Targeting the Healthcare and Public Health Sector,https://uscert.cisa.gov/ ncas/alerts/aa20-302a
  3. BBC.com – US fuel pipeline hackers ‘didn’t mean to create problems’, https://www.bbc.com/ news/business-57050690
  4. 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
  5. threatpost.com – Bose Admits Ransomware Hit: Employee Data Accessed, https://threatpost.com/bose-ransomware-employee-data/166443/
  6. 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
  7. ISO 14971 – Application of risk management to medical devices, https://www.iso.org/standard/72704.html
  8. AAMI TIR57 – Principles for medical device security – Risk management, https://store.aami.org/s/store#/store/browse/detail/a152E000006j60WQAQ
  9. NIST framework, https://www.nist.gov/cyberframework
  10. FDA – premarket guidance 2014, https://www.fda.gov/media/86174/down­load
  11. FDA – premarket guidance draft 2018, https://www.fda.gov/ media/119933/download
  12. UL2900-1, https://standardscatalog.ul.com/ ProductDetail.aspx?productId=UL2900-1
  13. UL2900-2-1, https://standardscatalog.ul.com/ProductDetail.aspx?produc­tId=UL2900-2-1
  14. UL2900-1 as recognized consensus standard, https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=36149
  15. UL2900-2-1 as recognized consensus standard, https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=37046
  16. The Joint Security Plan (JSP), https://healthsectorcouncil.org/wp-content/up­loads/2019/01/HSCC-MEDTECH-JSP-v1.pdf

FURTHER SUGGESTED READINGS

  1. FDA – post market guidance, https://www.fda.gov/media/95862/download
  2. AAMI TIR97 – Post market riskmanagement, https://store.aami.org/s/ store#/store/browse/detail/a152E000006j60oQAA
  3. mitre.org – Common Vulnerabilities and Exposures (CVE®), https://cve.mitre.org/
  4. nist.gov – National Vulnerability Database (NVD), https://nvd.nist.gov/
  5. mitre.org – Common Weakness Enumeration (CWE™), https://cwe.mitre.org/
  6. IMDRF – Principles and Practices for Medical Device Cybersecurity, http:// www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-200318-pp-mdc-n60.pdf
  7. MDCG 2019-16 rev.1 – Guidance on cybersecurity for medicaldevices, https:// ec.europa.eu/health/sites/health/files/md_sector/docs/md_cyberse­curity_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.