pgssi s : politique générale de sécurité des systèmes d...

PGSSI-S : Politique générale de sécurité des systèmes d’information de santé

Best Practices for medical device security

V 1.0

ASIP Santé PGSSI-S – Best Practices for medical device security 06/06/16

Classification : Public 2 / 17

Table of Contents

1 Introduction ...................................................................................................................... 3 1.1 Purpose ...................................................................................................................... 3 1.2 Scope of Application ................................................................................................... 4 1.3 Goals for medical devices ........................................................................................... 5

2 Foundation Documents ................................................................................................... 6

3 How to use this document ............................................................................................... 8

4 Security requirements ..................................................................................................... 9 4.1 Configuration management ......................................................................................... 9 4.2 Physical security ......................................................................................................... 9 4.3 Operation and communications ................................................................................. 10 4.4 Access control ........................................................................................................... 12 4.5 Software development and maintenance .................................................................. 12 4.6 Conformance ............................................................................................................ 13

Appendix 1: Medical device and workstation configuration types ................................. 15

Appendix 2 : Glossary ....................................................................................................... 16

Annexe 3 : Documents de référence ................................................................................ 17



1 Introduction

1.1 Purpose

This document defines the security rules and recommendations for medical devices that are connected to a Health Information System (HIS).

It is part of the PGSSI-S technical reference documentation as illustrated in the document architecture below.

Figure 1 PGSSI-S Reference Architecture

This set of best practices defines the security rules that medical device manufacturers must conform to.

These rules specify the necessary conditions that medical devices must conform to in order to be integrated into a Health Information System with a sufficiently high level of security assurance. These rules are necessary to reduce the security risks associated with the connection of medical devices to a Health Information System to a level that is acceptable by the Director of operations of the organization where the device will be installed. These rules do not cover user training, which is the responsibility of the supplier.

To this end, the audience for this document includes:

manufacturers of medical devices

suppliers of medical devices

implementers that integrate medical devices into Health Information Systems

healthcare organization staff that may participate in the acquisition of medical devices, their IT components, or related support and maintenance contracts (e.g. biomedical engineers, chief security officers, etc…)

For the sake of simplicity, the term “Director” is used to represent any individual that participates in the enforcement of the rules described in this document, including the Director of the



organization or any of their delegates. The role of the Director as specified here is different from the Director of operations as defined in the loi Informatique et Liberté n°78-17 du 6 janvier 1978 modifiée regulations but may be performed by the same individual.

1.2 Scope of Application Definition of medical devices

From the Code de la santé publique (articles L 5211-1 et R 5211-1) regulations: “A medical device includes any instrument, device, equipment, material (with the exception of biological samples) or any other item used alone or with other instruments, including accessories and supporting software designed by the manufacturer to be used on humans for healthcare purposes where the primary method of operation is not pharmaceutical, immunological, or metabolized; however the medical device’s method of operation may be helped by one of these methods.

In the scope of the document, a medical device specifically refers to a medical device connected to a Health Information System either locally or remotely. This device includes components such as servers, peripherals, single-purpose digital devices, software, operating systems, firmware, and data. The medical device may provide the following functions: medical treatment, medical analysis, medical surveillance, or diagnostics.

This medical device is run on a workstation delivered by the medical device provider, or on a general purpose health information system. This workstation uses a standard operating system such as Windows, Linux, iOS, Android and can run software packages and store data or databases for managing the medical device.

The grouping of the medical device and its workstation(s) is called the “medical device system” throughout the rest of this document.

This general configuration can be as simple as just a medical device and a single workstation, or a range of more complex configurations including the use of an external server. Several examples of more complex configurations are provided in Appendix 1.

The following types of medical devices are in scope for this document:

Automated laboratory analysis machines and their workstations

Medical imaging modalities such as scanners, echocardiograms, MRI and their workstations



Image acquisition devices such as microscopes, angiograms, ocular fundus

Picture Archiving and Communication Systems (PACS)

Automated dispensing machines

Anesthetic monitoring stations

Radiation therapy accelerators

Echocardiograms (ECG) machines

Vital signs monitors

Monitoring devices such as respiratory, cardiac and multiparameter monitors

Remote monitoring devices such as remote heart rate monitors, glucose monitors, sleep apnea machines, etc.

The following types of medical devices are out of scope: implantable devices

Medical devices that are physically implanted in the patient’s body are out of scope for this document.

1.3 Goals for medical devices

The medical devices used today were not designed to deal with the risks introduced by new technologies, especially the risk of malicious attacks.

In the healthcare domain more so than in other domains, the exploitation of medical device vulnerabilities can impact the health information systems that they are connected to, and potentially impact patients as well.

For example, the unauthorized modification of radiology equipment can have disastrous effects on a patient’s wellbeing or on the healthcare provider.

As a result, directors need to include the security of medical devices in their overall security planning, especially taking security into account when establishing the criteria for the selection of medical devices or their components, as well as during the implementation and maintenance of medical devices.

In order to respond to Health Information System security requirements, the following rules are adopted in order to enable:

medical device manufacturers or providers, as well as associated implementers to select and specify the security practices and features of their products;

Directors to assess whether the risks presented by existing or future medical devices that will be connected to the Health Information System are acceptable.



2 Foundation Documents The “Maîtriser la SSI pour les systèmes industriels” Guide

The national French information systems security agency, known as “L’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI)” published a guide for security of industrial information systems.

The ANSSI guide emphasizes the importance of security in specific systems used in production activities. It specifies production system vulnerabilities and the threats and attack vectors that production systems may be exposed to. The guide also describes the impact of incidents such as damaged materials, financial losses, environmental impacts, data theft, liability and associates penalties and reputation.

The guide recommends a comprehensive approach to industrial system security and includes best practices for that purpose.

A medical device approximates an industrial system for information security purposes. The use of a medical device focuses on activities that center around the provision of healthcare. The equipment mostly fulfills specific monitoring, control, measurement, actuator operations, or data acquisition functions.

The ANSSI guide is useful for assessing the security considerations of medical devices during their integration into a Health Information System.

The “Exigences de sécurité des Systèmes d’Information pour les équipements biomédicaux des établissements de santé” requirements

A collaboration of Information Systems Security Directors and biomedical engineers from health institutions and hospitals centers1 have defined security criteria for the integration of biomedical equipment into a Hospital Information System in response to a request from the Ministry of Health. The requirements are supported by the FSSI, ANAP and DGOS.

The security requirements were determined based on regulatory requirements, best practices, and lessons learned from security incidents.

The list of requirements enables Directors to define security policies for the biomedical equipment in their organizations and keep them up to date, as well as specify the detailed security requirements for the acquisition of new biomedical equipment.

The “Exigences de sécurité des Systèmes d’Information pour les équipements biomédicaux des établissements de santé” requirements are retained as reference documents for the set of best practices described in this document. Their scope of application is extended to include all medical devices connected to Health Information Systems of all types of legal entities.

1 As described in reference 1 in the appendices.



Main threats introduced when connecting medical devices to a health information system

The requirements in this guide are based on the specific threats and challenges encountered in a hospital environment, including but not limited to:

hacking of medical device equipment, especially by exploiting software vulnerabilities;

introduction or activation of malware;

disruption of the operation of medical devices from the health information system or the network that they are attached to;

disruption of the operation of medical devices by electromagnetic interference;

unauthorized access to or modification of health information in transmission between the medical device and the health information system;

unauthorized access to medical devices and introduction or removal of data stored on them;

misuse of medical devices by authorized personnel;

unauthorized modification of medical device software.



3 How to use this document The requirements identified in this document are applicable regardless of the context in which the device manufacturers or suppliers, or associated service providers implement them.

This document recommends that manufacturers and suppliers document in detail in any RFP response or proposal their product or service’s conformance to the requirements listed in this document. Where a requirement is not met, the manufacturers or suppliers should document why this requirement does not apply to their device.

Manufacturers are required by law to alert government officials of any vulnerabilities in their software, when the vulnerabilities can be exploited either maliciously or by error in a way that may threaten the life of an individual.

This document also enables Directors to evaluate the device or associated service offerings according to their conformance to the security requirements.

Additional rules may be defined in local policies as needed depending on the type of the healthcare organization, whether it is a hospital, independent physician practice, etc.

It is the responsibility of Directors to assess and manage security risks arising from all outstanding requirements related to the medical device or its use.

Security risks may be managed by one or more of the following options:

reducing the risks by implementing protective or preventative safeguards;

accepting the risk;

avoiding the risk;

transferring the risk to a third party via contractual agreement, such as obtaining insurance.



4 Security requirements There are two levels of implementation of security requirements for medical devices: Level 1 which is an intermediate level and is comprised of priority requirements, and a higher Level 2 that includes both the priority requirements as well as additional security requirements for a stronger overall level of security.

4.1 Configuration management

# Requirement Level

Configuration Management [G]

[G1]

The manufacturer and/or supplier must identify in their documentation and make available to the client, the set of hardware and software components that the medical device is composed of, as well as their main features.

Level 1

[G2] The manufacturer and/or supplier must identify in their documentation the complete specifications for the medical device’s workstation, including the hardware features, operating system version, middleware, drivers, activated services, peripherals, etc.

Level 1

[G3]

The “medical device system” (see 1.2) must provide an interface for a health information system’s configuration management database (CMDB) or a remote service, such as one that may be used by a healthcare professional in their private practice to automatically obtain the configuration details for the “medical device system” (see 1.2).

Level 2

4.2 Physical security

# Requirement Level

Physical Security [S]

[S1]

The manufacturer and/or supplier must identify in their documentation all physical security safeguards recommended for the implementation of the “medical device system” (see 1.2) that will be connected to the Health Information System, including but not limited to:

physical security of the premises

keys for the cabinet that protects the medical device

environmental constraints, especially electromagnetic compatibility (WiFi, Mobile devices)

security for cables and wiring

Level 1

[S2] The medical device must implement physical security measures for detecting physical access attempts to any of its sensitive internal components, including but not limited to the hard drive, internal interfaces, hardware jumpers, etc.

Level 2



4.3 Operation and communications

# Requirement Level

Operations and maintenance [E]

Operations check

[E1]

Medical devices must have a function to verify the integrity of the software and sensitive data during device start as well as during operation of the device.

The date when the device’s software and sensitive data were last modified must be shown at user login.

Level 1

Device updates

[E2] Medical device and workstation software must have a function for the secure update of software and firmware to ensure the origin and integrity of updates.

Level 1

[E3] Medical devices must verify the correct installation of a software update, and have the possibility to perform a rollback in case of a detected malfunction.

Level 1

[E4] Medical devices and workstation software must have a secure update function that provides automatic update notifications whenever a software or firmware update is available.

Level 2

Malware protection

[E5]

Medical devices must include security measures to detect and respond to threats from malware, especially when removable media is used.

If the medical device has no antivirus software then use of removable media is prohibited.

Level 1

[E6]

Medical device workstations must have security measures for detecting and responding to malware threats, or must be compatible with external malware detection software.

The device manufacturer must provide a list of tools with which its software and hardware are compatible.

Level 1

Network Security

[E7] The medical device documentation that is made accessible via a client portal, must include a comprehensive map of data flows, including protocol types, origin/destination points of data flows, network addressing plan, etc.

Level 1

[E8] Medical devices must have security mechanisms for filtering data exchanged over networks, including protocol types, origin/destination points of data flows, etc.

Level 2

[E9] Medical device workstations must have security mechanisms for filtering data exchanged over networks, including protocol types, origin/destination points of data flows, etc, or must be compatible with external network security filtering solutions such as personal firewalls.

Level 1

[E10]

If wireless networking is implemented, the medical device must follow best practices for wireless networking.

For more information on WiFi best practices, please refer to reference documentation in the wireless field, such as these guides:

http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-003/index.html

http://www.ssi.gouv.fr/fr/bonnes-pratiques/recommandations-et-guides/securite-des-technologies-sans-contact/guide-securite-des-technologies-sans-contact-pour-le-controle-des-acces.html

http://www.ssi.gouv.fr/fr/bonnes-pratiques/recommandations-et-guides/securite-des-liaisons-sans-fil/recommandations-de-securite-relatives-aux-reseaux-wifi.html

Level 1

Data Security

http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-003/index.html








# Requirement Level

[E11]

In order to ensure the confidentiality of locally stored personal health information, the medical device must have embedded encryption.

The device manufacturer and/or supplier may refer to the Référentiel Général de Sécurité (RGS) appendix for the description and requirements of the “confidentiality” security function. The RGS document can be found on the ANSSI website here: http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/liste-des-documents-constitutifs-du-rgs-v1-0.html

Level 2

[E12] To ensure data integrity, the medical device must implement appropriate transmission protocols for verifying the electronically exchanged data has not been altered.

Level 1

[E13] During image capture and compression, standardized procedures must be implemented in order to ensure the integrity of the data.

Level 1

[E14]

Medical device data exchange must conform to the security requirements identified in the HIS Interoperability Framework published by ASIP Santé, especially any requirements that

relate to authentication and encryption. For more information on the transport encryption module of the HIS Interoperability Framework, see here: http://esante.gouv.fr/sites/default/files/HIS-IF-Transport_Layer-Synchronous_Client_Module_v1.0.2_R.pdf

Level 1

[E15] Data exchanged between the medical device and workstations must be protected for confidentiality and integrity.

Level 2

[E16] Access to the data export functions of the medical device must be limited to authorized users.

Level 1

Management of removable media

[E17] The functionality for a medical device to boot from removable media must be deactivated except for special cases.

Level 1

Surveillance

[E18] The medical device must have a local alert function to monitor the correct operations, and any event that may have a critical impact on the operations of the medical device.

Level 1

[E19]

The medical device must have an alert function based on commonly used alerting mechanisms which allow the Health Information System to monitor the operations, connections, and any critical events that may impact the operations of the medical device such as software updates, critical parameter modifications, etc.

Level 2

Logging

[E20]

The medical device must have a local logging function to keep track of accesses to the medical device, and of any events that may have a critical impact on the operations of the device, especially any alert events raised by rule [E18] above.

The manufacturer must document the configuration methods for the logging function, especially the storage capabilities of the medical device as well as recommendations for how to archive and back-up logs.

Level 1

[E21]

The medical device must have a logging and trace management function based on standard mechanisms that allow the Health Information System to maintain records of any event that may have a critical impact on the operation of the medical device with a guarantee of non-repudiation for all operations on this device.

These logs must be able to be further analysed for the root cause of any malfunctions.

Level 2

Backups

[E22] The medical device must have a backup function that is conformant with industry best practices.

Level 1

Data destruction rules for hardware transfer

[E23] The supplier must implement security functions for data destruction that are conformant with industry best practices.

Level 1

http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/liste-des-documents-constitutifs-du-rgs-v1-0.html

http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/liste-des-documents-constitutifs-du-rgs-v1-0.html

http://esante.gouv.fr/sites/default/files/HIS-IF-Transport_Layer-Synchronous_Client_Module_v1.0.2_R.pdf

http://esante.gouv.fr/sites/default/files/HIS-IF-Transport_Layer-Synchronous_Client_Module_v1.0.2_R.pdf



4.4 Access control

# Requirement Level

Access control [A] Network Access Control

[A1] The medical device must have an industry standard method for network identification and authentication of hardware, such as the use of the 802.1X protocol.

Level 2

User authentication

[A2]

The medical device must have a user authentication function based on individual user accounts and at minimum user-selected passwords.

Default passwords must be changed during installation or upon first user login, and must be unique to each user.

Level 1

[A3] The medical device must have strong authentication for specific user profiles such as administration, maintenance, etc.

Level 2

[A4] The medical device must have the ability to impose a password policy, including elements such as password expiration period, password complexity rules, ability to reuse old passwords, etc.

Level 2

[A5] Authentication is required prior to any access to the “medical device system” (see 1.2). Level 1

[A6] The time of last access to the “medical device system” (see 1.2) must be presented upon each new user login.

Level 1

[A7] The medical device’s software must provide automatic locking functionality for instances of prolonged user inactivity, as well as user account locking for instances of repeated unauthorized access attempts.

Level 1

Access rights

[A8] User access rights must be organized according to user roles. Level 1

[A9]

Access to software update, or sensitive configuration functionality requires strong user authentication.

Any validation action in these contexts requires double confirmation, such as validation of the sensitive configuration modification request opens a dialog window reminding the user of the potential impact of the change and requesting confirmation of the change request.

Level 2

4.5 Software development and maintenance

# Requirement Level

Software development and maintenance [D]

[D1]

The manufacturer and/or supplier must agree to install only the software necessary for the operation of the medical device.

The manufacturer and/or supplier must agree to activate only the services necessary for the activation of the medical device.

Level 1



# Requirement Level

[D2]

The general architecture of the medical device, workstation and the software developed must be as independent as possible of commonly used software in order to facilitate update to the commonly used software. In other words, if the software is built on a particular Operating System platform, the software should rely as little as possible on the underlying O/S so that the O/S can be updated without undue risk to the medical device architecture.

At minimum, the supplier must ensure forward compatibility with underlying software updates.

Level 1

[D3] The development process must include exception handling, including buffer overflows, component internal errors, etc.

Level 1

[D4] The manufacturer and/or supplier must implement a function to check software integrity upon startup or update.

Level 1

[D5] The supplier of the medical device must ensure continuous monitoring of medical device related incidents. The supplier must also make any necessary patches available to customers.

Level 1

[D6] The supplier of the medical device must ensure continuous monitoring of vulnerabilities related to the technologies used in its products, and must make any necessary corrections/mitigations/patches/fixes available to customers.

Level 1

[D7] Remote maintenance functionality of the medical device must comply with the guide PGSSI-S – Règles pour les interventions à distance sur les SIS.

Level 1

[D8] Medical device testing and maintenance modes must be exclusive of the operational mode, so that the device either runs in maintenance and testing mode or is used in operational mode to provide healthcare to patients.

Level 1

[D9]

The medical device must have a secured failure mode that permits the ongoing operations of the medical device when it is disconnected from the Health Information System.

The medical device must upload the information collected while offline upon resumption of the connection to the Health Information system.

Level 1

[D10] The manufacturer must conduct robustness tests on medical devices, such as stress testing, malformed data injection, etc.

Level 1

[D11] The manufacturer and/or supplier must provide data restoration solutions that enable the customer to restore data, in a format that is reuseable by the client, when equipment is changed.

Level 1

[D12] The manufacturer and/or supplier must perform regression testing for each new version of medical device software or hardware.

Level 1

4.6 Conformance

# Requirement Level

Conformance [C]

[C1]

It is the responsibility of the supplier to acquire and provide to the customer all licences required to operate the medical device, except where the customer specifies otherwise.

This includes hardware, software, and any other rights necessary including O/S, algorithms, security software, network software, database software packages, remote control software, etc.

Level 1



# Requirement Level

[C2]

The manufacturer and/or supplier must perform a risk analysis on the “medical device system” (see 1.2) and must adapt the implementation of the security measures to reduce residual risks.

They must inform the customer of the risk analysis method that was used, the risks that were mitigated, and any residual risks that must be managed by the customer. They may also recommend security measures that should be implemented by the customer in order to reduce the residual risks as part of the medical device’s disclaimers.

Level 1



Appendix 1: Medical device and workstation configuration types

In the figure below, the purple portions of each box represent what is delivered by the supplier.

serveur

Poste de pilotage du matériel

Matériel médical

Poste client

Réseau interne au dispositif

Réseau du SI

Matériel médical

Réseau du SI

Poste de pilotage du matérielMatériel médical

Réseau du SI


Réseau du SI


Matériel médical

Réseau du SI

serveur


Sous-réseau du SI

dédié au dispositif

Sous-réseau du

SI

Routage, filtrage

InternetPoste télémaintenance

Exemple 1 : cabinet médical Exemple 2 : scanner, radiologie, automates Exemple 3

Exemple 4 Exemple 5


Matériel médical

Sous-réseau du SI

dédié au dispositif

serveur

Sous-réseau du SI

Routage, filtrage

Exemple 6

serveur

Exemple 7

Serveur(hébergeur)

Matériel médical

Poste client

Internet3G

Réseau du SI

InternetPoste télémaintenance

Exemple 8 : Hospitalisation à domicile

Serveur



Appendix 2 : Glossary

Acronym Meaning

ANAP Agence Nationale d’Appui à la Performance des établissements de santé et médico-sociaux

ANSSI Agence Nationale de la Sécurité des Systèmes d’Information

ASIP Santé Agence des Systèmes d’Information Partagés de Santé

CMDB Configuration Management Data Base

DGOS Direction Générale de l’Offre de Soins

ECG Electrocardiogram

FSSI Fonctionnaire de la Sécurité des Systèmes d’information

O/S Operating System

PACS Picture Archiving and Communication System

PGSSI-S Politique Générale de Sécurité des Systèmes d’Information de Santé

RGS Référentiel Général de Sécurité



Annexe 3 : Documents de référence

Référence n°1 : Exigences de sécurité des Systèmes d’Information pour les équipements biomédicaux des ES (Collectif RSSI et ingénieurs biomédicaux des ES)

Référence n°2 : La cybersécurité des systèmes industriels (ANSSI)

Référence n°3 : Décret n°2006-6 du 4 janvier 2006 - conditions d'agrément des hébergeurs de données de santé à caractère personnel

Référence n°4 : Référentiel de constitution des dossiers de demande d'agrément des hébergeurs de données de santé à caractère personnel (ASIP)

Référence n°5 : Recommandations de sécurité relatives aux ordiphones (ANSSI)

Référence n°6 : Externalisation des systèmes d’information (ANSSI)

Référence n°7 : Référentiel Général de Sécurité (ANSSI)

Référence n°8 : Any other PGSSI-S document (references and best practices)2

2 Any changes to the PGSSI-S family of documents, including document updates and the development of new

documents, will be taken into account in subsequent versions of this document. This includes the referencing of other best practices on specific requirements discussed in Section 4 such as data destruction, backup, etc.

http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000264665&dateTexte=