A shield in with a lock on it in the foreground, 0 and 1 in the background, symbolizing cybersecurity principles in software

Cyber Security Threats in Healthcare

Cyber security threats in healthcare can result in severe consequences as unauthorized disclosure, modification of data or loss of function of medical devices.

Thus, the protection objectives in healthcare cyber security are confidentiality, integrity, and availability for all functions, data, and physical parts. In this respect there is no difference to other products or industrial branches.

Here, we give you an overview of the regulatory requirements for cyber security in healthcare in Europe and the US with a special focus on medical devices. Furthermore, we explain the standards that may be applied by the manufacturer of medical devices to ensure their cyber security.

Are Cyber Security Threats Only a Theoretical Problem?

The U.S. Food and Drug Administration (FDA) issued from 2015 to 2018 six product-specific safety communications. They have addressed cyber security threats in three different types of medical devices: implantable cardiac device programmers, implantable cardiac devices, and infusion pumps.

Anyhow, the FDA states that they are not aware of “any patient injuries or deaths associated with cyber security incidents, nor […] that any specific devices or systems in clinical use have been purposely targeted.”

Basically, cyber security threats in healthcare are not only caused by vulnerabilities of networked medical devices. Another risk is the poorly protected IT network of health care facilities, typically hospitals.

The “WannaCry” ransomeware attack is one example. There, medical devices were infected and deactivated by malware and cyber security threats. This had fatal consequences for the affected health care facilities and for the patients.

Although medical technology is often not the primary target of ransomware networked medical devices are often indirectly affected. Moreover, DoS attacks disrupt services of a health IT network and, thus, make a machine or network resource unavailable to its user.

Therefore, some operators like the U.S. Veterans Affairs Department and the Mayo Clinic have taken serious actions in promoting cyber security of medical devices. As a reaction to upcoming cyber security threats regulatory requirements are currently changing in different markets.

Understanding the Regulatory Framework in Europe

The existing regulatory framework for medical devices in Europe requests that the manufacturer establishes a risk management. This does not only include risks originating from safety issues but also risks resulting from cyber security threats.

The legal basis for medical devices and thus also for medical software in Europe is the EU medical device regulation 2017/745 (EU MDR), which came into force on 25 May 2017. Even though the “old” directives on medical devices and active implants will continue to apply in a transitional period until 26 May 2020, you should always deal intensively with the new regulation.

Appendix 1 of the EU MDR describes which requirements manufacturers must meet in terms of cyber security (the EU MDR calls cyber security information security):

  • 14.2.(d): “Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible: […] (d) the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts; […]”
  • 17.2.: “For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.”
  • 17.4.: “Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.”

As a result, manufacturers must not only look after the cyber security of their devices, but also after that of the IT environment.

Recently, the German Federal Office for Information Security (BSI) has published a recommendation on “Cyber Security Requirements for Network-Connected Medical Devices”. The recommendation is intended to help manufacturers become aware of the risks associated with networked medical devices. It also explains how manufacturers can meet the legal requirements.

Healthcare as Critical Infrastructure

The EU has addressed the cyber security of critical infrastructures and adopted the EU directive “Network and Information Security” (NIS). The EU member states must adopt this directive into national law. As a result, Germany introduced the “Act to Implement the European Directive to Ensure a High Level of Network and Information Security”, the so-called “NIS Directive” in 2017.

The NIS directive is aimed both at providers of certain digital services and at operators of critical infrastructures such as “health care settings”. This includes hospitals and private clinics. Under certain circumstances, hospitals must prove to the BSI that they have taken the necessary “technical and organizational measures”. According to the German Hospital Society, manufacturers may consider “audits, certifications, etc.” for this purpose.

European Cyber Security Agency and Certification

Furthermore, the EU Commission agreed 2018 the text for a “Regulation on ENISA, the EU Cyber Security Agency and on Information and Communication Technology Cyber Security Certification”. This so-called “Cyber Security Act” is going to be negotiated with the European Parliament. The aim is to set uniform requirements for cyber security within the EU by introducing a certification scheme for specific ICT processes, products, and services.

ENISA is the “EU Agency for Network and Information Security” and the EU wants to transform it into a permanent agency for cyber security. Interestingly, the new EU regulation explicitly mentions medical devices. Thus, the question remains if this regulation will overlap with the EU MDR in terms of medical device certification.

What is the Difference Between the Regulatory Approach in the EU and in the US?

The FDA sees cyber security of medical devices as a challenge for the entire life-cycle. The agency has published three guidances and one draft guidance on this issue:

Furthermore, the U.S. Department of Health and Human Services has established a Health Care Industry Cyber Security Task Force. The 2017 report on “Improving Cyber Security in the Health Care Industry” summarized the current state, identified associated risks und gave recommendations for the future.

In addition, the National Cyber Security and Communications Integration Center (NCCIC), which belongs to the U.S. Department of Homeland Security, is notified about reported or occurred incidents. In parallel, the FDA interacts with the manufacturer to assess the vulnerability and develop mitigating or corrective action. In case of any criminal background the Federal Bureau of Investigation (FBI) takes part as well.

Develop a Holistic Cyber Security Concept

Successful measures against cyber security threats do not require isolated activities but a holistic approach. This encompasses the fields of processes, technology and people. Hence, a corresponding concept is not only limited to the processes and the technologies being applied, but also includes the knowledge and skills of the persons that use the products. There are five equivalent entry points to such a concept available:

  • enhance awareness,
  • provide secure IT infrastructure,
  • handle incidents,
  • improve processes, and
  • use security features.

A further important aspect is the definition of roles. The roles represent the major stakeholders in healthcare. The following figure shows the different responsibilities of the roles.

Roles* in the Healthcare Cyber Security Concept, * Sometimes up to five roles are defined; Asset Owner - hospital operator - operates and maintains - Secure operation, policies, and requirements; System Integrator - hospital IT or external IT service provider - designs and deploys - Design and hand over / maintain a secure solution; Product Supplier – manufacturer - develops and supports - Secure product development process; Technical requirements for product / component security

  • The asset owner is responsible for the secure operation as well as the provision of guidelines and requirements.
  • The product supplier has established a secure development process (process level) and defined the technical requirements for the security of the products or components (product level). Moreover, the product supplier is responsible for determining the level of security required to protect the product.
  • The system integrator takes over certain activities from the asset owner. This includes the establishment of IT networks, maintenance work or the selection of network components.

Which Cyber Security Standards are Available for Healthcare?

The respective role of the healthcare cyber security concept implies which security standards are suitable. There are various standards available and not all of them are “typical” medical device standards.

The following table gives you an overview of standards and standard series that play a role in healthcare cyber security. Note, that this is only a selection and that other standards may occasionally be applied. If the respective standard (series) is currently either harmonized in the EU or recognized by the FDA in the US for medical devices it is marked by an asterisk.

StandardScopeMarketRoleKeyword
AAMI TIR 57medical devicesUS*product supplierrisk management
ISO/IEC 15408IT products and systemsEU, USproduct supplierIT, security techniques
ISO 27799healthcare IT  networksEU, USasset ownerinformation security, management
IEC 60601-1medical devicesEU*, US*product suppliersafety requirements
IEC 62304health softwareEU*, US*product suppliersoftware, life cycle, processess
IEC 62443industrial automation and control systemsEU, US*asset owner, system integrator, product supplierprocesses, functional requirements, security
IEC 80001healthcare IT networksEU, US*asset ownerrisk management, IT networks
IEC 82304-1health softwareEU, US*product suppliersoftware, product requirements, validation, documents, post-market activities
UL 2900-1network-connectable productsUS*product supplierverification and validation testing
UL 2900-2-1network-connected components of healthcare systemsUS*product supplierverification and validation testing

In the following paragraphs we will elucidate the standards compiled in the table in more detail.

Security Medical Device Standards

Malfunctions of components can cause cyber security threats. The manufacturer (or product supplier) should avoid this by focusing the development process on “security by design”.

The IEC 62304 standard describes software life-cycle processes and is equally applicable to both, embedded and stand-alone software. It requires the definition of security requirements, but does not provide any further details.

Appendix H.7 of the IEC 60601-1 standard describes possible causes of hazardous situations of medical devices in IT networks.

Unfortunately, so far, a comprehensive standard or standard family that addresses cyber security threats of medical devices does not exist as hamonized European standard. Therefore, let’s have look at FDA recognized consensus standards for software that are also often applied by manufacturers.

AAMI Standards for Medical Device Security

The Association for the Advancement of Medical Instrumentation (AAMI) published TIR 57 standard in 2016. It addresses the risk management for medical device security as a best practice approach and complies with the requirements proposed by the FDA. It includes several methodologies and tools:

  • preparation and execution of the cyber security risk management process,
  • scope and content of the related documentation, and
  • support through examples and referenced templates.

The following figure shows the “traditional” ISO 14971 security risk management process on the left. AAMI TIR 57 complements this by taking cyber security threats into account (right part of figure). 

Relationship between Safety and Security Risk Management Processes: ISO 14971: Security Risk Analysis - Safety Risk Evaluation - Safety Risk Control - Safety Residual Risk - Safety Risk Management - Safety Production and Postproduction information; AAMI TIR 57: Safety Risk Analysis – Security Risk Evaluation - Security Risk Control - Security Residual Risk - Security Risk Management - Security Production and Postproduction information; Safety control affecting security; Security risk with potential safety impact; Safety control affecting safety

Note, that security risks may impact the safety of a medical device. For example, if an attacker gains unauthorized access to a hospital network, it is a security problem. If the attacker then influences a networked insulin pump and changes the release of the drug, the security problem becomes a safety problem.

Furthermore, safety risk control may impact security risk analysis and vice versa (yellow and blue arrows in the figure above). Here are two examples:

  • First, a networked infusion pump receives regular software updates as a safety measure. The internal drug library delivers default dosage information to the pump. However, an attacker could gain access to the drug library and change the dosage information. Here, a safety risk control impacts the security risk analysis.
  • Second, an intensive care unit uses ventilators. For security reasons, a doctor or a nurse can use a ventilator only if they enter a user name and a password. But what happens in an emergency situation when user name and password are lost? Here, a security risk control obviously affects the safety risk analysis.

AAMI TIR 57 supports security risk management and refers to well known procedures of ISO 14971. Moreover, it refers to the NIST SP 800-30r1 standard for security risk analysis.

Nevertheless, it is also possible to use other approaches of security risk analysis that match the criteria of the FDA. The FDA post-market management guidance describes these criteria. For instance, you can use the ISO/IEC 15408 standards. We will explain how this works in the following section.

How to Apply ISO/IEC 15408 in 5 Steps

The ISO/IEC 15408 security standard is accepted and used worldwide. We show you in 5 steps how to use it. As an example we take self-care medical devices. The following figure compiles the basics.

5 Steps for Compliance With ISO/IEC 15408: 1. Description of Assets, 2. Identification of Threats (Assumptions and Security Policies), 3. Analysis and Rating of Threats (Safety Risk Analysis), 4. Determination of Security Objectives (System and Environment Objectives), 5. Selection of Security Functional Requirements, --> 1.

1. Assets

Describe the assets that represent all specific product aspects. The alarm function is an example of a core asset. A device gives an alarm if e.g. a certain value exceeds a limit. Divide this core asset further into informational, functional, and physical assets.

2. Threats

Identify possible threats. The ISO/IEC 15408 standard gives you threat categories to help you with their identification. Alternatively, you can use the ones defined by Microsoft Stride:

  • spoofing of identity,
  • tampering,
  • repudiation,
  • information disclosure,
  • denial of service, and
  • elevation of privilege.

3. Analysis and Rating

Analyze and rate possible threats. Detail the assets and their threats further and consider particular vulnerabilities and impacts for your medical device.

Note, that one asset or threat can have multiple vulnerabilities or impacts. At this stage you can identify threats that may have an impact on patient safety. Introduce these threats in your safety risk analysis.

Also, you have to rate security risks. Depending on the risk rating system you must define a certain risk threshold. Use this threshold to divide risks that need countermeasures from risks that are acceptable.

4. Security Objectives

Define security objectives for all threats that exceed the risk threshold. Examples for security objectives are “confidential wireless communication” or “signed firmware only”. Re-rate threats that require countermeasures with the goal of not exceeding the threshold.

5. Security Functional Requirements

Part 2 of ISO/IEC 15408 gives you templates for security functional requirements. You can use it to to define the requirements for the security objectives.

Note that the ISO/IEC 15408 standard series further defines a security certification process with different levels. This does not play a role here.

AAMI is currently developing the TIR 97 standard, which focuses on post-market security management for equipment manufacturers.

Testing Standards of UL

UL has published two Standards UL 2900‐1 and UL 2900‐2‐1 that are recognized by the FDA. They allow the manufacturer to verify and validate the security risk control measures against design specifications or design requirements. These standards include detailed descriptions of tests addressing vulnerabilities, exploits and software weakness.

Product Specific Standards

The Diabetes Technology Society (DTS) defined DTSec standard. It  specifies security requirements for wireless diabetes devices. Moreover, DTS has published the “Guidance for Use of Mobile Devices in Diabetes Control Contexts”.

This guidance supports the safe use of consumer mobile devices (CMDs), which are under control of diabetes-related medical devices. A typical example for a CMD is a smart phone with a mobile app for controlling an implanted insulin pump.

The IEC 62443 Standard Series for all Roles

The IEC 62443 series originates from the field of industrial automation. Basically, one can apply it to any industrial environment, including critical infrastructures. The standard follows the proposed holistic approach. Thus, the different parts from IEC 62443-1-1 to IEC 62443-4-2 cover all three roles in cyber security by specifying capabilities of technical security and process security.

There are activities to adapt the standards of the IEC 62443 series to medical applications. They focus on:

  • textual revision of the IEC 62443 series for a cross-sector use,
  • development of profiles for specific situations or roles that determine the validity of specific aspects of standards,
  • adaption of the IEC 62443-2-4 for cyber security in healthcare by the Medical Device Innovation, Safety, and Security Consortium (MDISS), and
  • development of a technical report in the IEC 60601 series with recommendations based on fundamental requirements described in the IEC 62443-1-1.

Four IEC 62443 standards are part of the Conformity Assessment Schemes for Electrotechnical Equipment and Components (IECEE). Thus, manufacturers may obtain a certificate of conformity based on these standards.

Various Parts of IEC 62443 are Suitable for Medical Devices

IEC 62443-2-1 describes the requirements for setting-up and operating an information security management system by the asset owner. It includes guidelines, procedures, implementation in practice and personnel.

IEC 62443-2-4 contains approximately 120 requirements from different subareas for system integrators. These concern e.g. certain areas of knowledge, qualification schemes, security training measures or handling of sensitive data. The subarea “assurance” describes the documentation of threat analyses and the demonstration of system hardening measures.

IEC 62443-4-1 defines the requirements for a secure product development life cycle. This includes:

  • management of cyber security at the manufacturer’s site,
  • specification of cyber security requirements, including environment, threat model and demonstration of compliance with respective standards,
  • definition of a defense-in-depth strategy (staggered defense),
  • effective implementation of the defense-in-depth strategy,
  • verification and validation measures to verify compliance with the requirements,
  • dealing with deficiencies in cyber security during product use
  • patch management for the product, and
  • instructions for configuration and operation of the product

IEC 62443-3-3-3 specifies detailed system requirements (SR) based on the functional requirements (FR) of IEC 62443-1-1-1.

For instance, the standard lists a total of twelve SRs related to the FR “Use Control”. The SR “Authorization Enforcement” describes that devices may only be used with authorization. The subsequent SR “Permission Mapping to Roles” requires that the operative authorizations are assigned according to the roles a user has.

Overall, both system integrators and product suppliers may use IEC 62443-3-3-3.

Security Standards for Asset Owners of Healthcare IT Networks

IEC 80001-1 aims to reduce risks for patients, users and third parties arising from networked medical devices in hospitals.

Section 3.5 of IEC 80001-1 lists the documentation requirements and IEC/TR 80001-2-2-2 specifies them. The reference HIMSS/NEMA HN1-2013 “Manufacturer Disclosure Statement on Medical Device Security” (MDS2) supplements both standards. Many manufacturers use this reference for networked medical devices to comply with their obligation under Section 3.5 of EN 80001-1.

Another family of standards, ISO/IEC 27000, aims to protect IT systems through describing best practices in the implementation, maintenance and continuous improvement of controls. ISO/IEC 27002 describes aspects of cyber security in IT risk management processes and how these risks can be controlled.

ISO 27799 complements ISO/IEC 27000 with reflections on cyber security risks and their impact on healthcare. Appendix A systematically lists cyber security threats in healthcare. Manufacturers can use information from these standards to derive appropriate requirements for their medical devices.

In addition, the U.S. NIST Cyber Security Framework defines standards, guidelines and best practices for managing cyber security risks.

Our Recommendations

  • Consider a holistic approach to handle cyber security threats involving all essential stake holders (roles).
  • Select your appropriate role and identify related standards considering the target market.
  • Address cyber security threats already early in product development.
  • Always carry out the risk management for security and safety of your products and pay attention to the interactions.

This article is based on presentations of Daniel Jacobi (Zühlke Engineering GmbH) and Bernhard Petri (Siemens AG) during a VDE Workshop in 2018.

Write a comment or suggest a term!