Parution de l'arrêté LPM pour les SIIV de santé

Gouvernance Risques et Conformité
Parution de l'arrêté LPM pour les SIIV de santé

Ca y est, l'ANSSI a officiellement publié les premiers arrêtés sectoriels associés à la Loi de Programmation Militaire. (lien décret, lien site ANSSI)

Ce sont donc l'alimentation, la gestion de l'eau et les produits de santé qui ouvrent le bal. Les autres secteurs devraient suivre.

Parlons donc un peu de celui sur la santé, publié au JORF n°0145 du 23 juin 2016, et sobrement appelé " Arrêté du 10 juin 2016 fixant les règles de sécurité et les modalités de déclaration des systèmes d'information d'importance vitale et des incidents de sécurité relatives au sous-secteur d'activités d'importance vitale « Produits de santé » et pris en application des articles R. 1332-41-1, R. 1332-41-2 et R. 1332-41-10 du code de la défense"

Analyse des principaux articles

  • Article 2 : vous avez 3 mois pour adresser à l'ANSSI la liste des vos SIIV (Système d’Information d’Importance Vitale). Pas trop dur normalement, le travail a été commencé dans le cadre d’ateliers avec l’ANSSI en 2015, néanmoins, il est encore temps de revoir sa liste et de justifier l'absence de certains SI, c'est permis (l'ANSSI décidera si oui ou non vous pouvez avoir raison)
  • Article 3 : il faudra revoir la liste tous les ans. C'est normal. Et déclarer tout nouvel SIIV avant sa mise en service.
  • Article 4 : en cas d'incident de sécurité, il faudra adresser le formulaire idoine à l'ANSSI via le moyen adapté à la sensibilité des informations. Donc maintenant, vous êtes fixés, un incident de sécurité, ca se déclare au Ministère de tutelle, à la CNIL s'il concerne des données personnelles (Règlement Européen) et à l'ANSSI. Vivement un portail centralisé !
  • Article 5 : il faut avoir un correspondant pour l'ANSSI, et il doit être habilité défense au bon niveau.

Intéressons-nous maintenant à l'annexe I qui selon l'article 1 stipule les règles de sécurité à appliquer.

La nécessité de maîtriser la connaissance et le niveau de risques des SIIV

Des exigences finalement classiques qui reprennent la notion d'homologation du RGS pour une meilleure maîtrise des risques.

  • Exigence 1  :  Il faut une PSSI (Politique de Sécurité des SI) qui s'applique précisément aux SIIV, approuvée (comme il se doit) par la direction de l'opérateur et un suivi annuel de la conformité à cette PSSI (du boulot pour le RSSI)
  • Exigence 2  :  Il faut homologuer ses SIIV, au minimum tous les 3 ans. L'homologation est une décision formelle prise par l'opérateur (en interne donc, comme pour le RGS) que les risques sont identifiés, les mesures nécessaires mises en œuvre et les risques résiduels acceptés.
    Lors de l'homologation, il faudra mener un audit (Analyse de risques, audit d'architecture, audit de configuration et audit organisationnel et physique).  Il sera mené selon le référentiel Prestataire d'Audit de Sécurité des SI (PASSI), soit en interne soit via un prestataire qualifié par l'ANSSI.
  • Exigence 3  :  Il faut maintenir une cartographie des SIIV.  On parle ici de cartographie physique, logique et fonctionnelle avec, et c'est une particularité, la liste des accès privilégiés sur les systèmes composants le SIIV. Ce n'est pas trivial à faire et nécessitera des procédures strictes et des contrôles réguliers pour le maintien dans le temps.
  • Exigence 20  :  Il faut mettre en place des indicateurs sur une liste bien précise. Plutôt des indicateurs de conformité avec les mesures essentielles (accès, durcissement). 
    Il n'est pas imposé de fréquence de mise à jour, et il faut communiquer les indicateurs une fois par an.
    Ah oui, à propos de communication, l'ANSSI doit pouvoir demander l'accès à peu près tous les documentations dont on a parlé (PSSI, suivi, homologation, etc.).

Construire et maintenir des SIIV sécurisés

La complexité ici sera de s'adapter aux  spécificités des SIIV qui peuvent être parfois très contraints (biomédical dans la santé, mais pensons dans d'autres secteurs aux SI industriels ou temps réel...). Par ailleurs, la gestion du changement ne sera pas triviale car certains mécanismes ne sont simplement pas prévus par les SI d'origines.

A noter quand même qu'il est prévu les cas où ces exigences ne seront pas possibles, avec des arbitrages alors possibles avec la gestion des risques liée à l'homologation.

  • Exigence 4  : L'opérateur doit maintenir en condition de sécurité son SI :veille (vive le CERT-Fr), versions à jour et supportées, corrections des vulnérabilités, etc.
  • Exigence 15 :  Il faut faire attention aux fonctions d'administration et en maîtriser la diffusion à tout instant. Un gros travail peut être à faire pour séparer les postes et logiciels d'administration mais aussi créer un vrai réseau d'administration séparé (jusqu'aux interfaces physiques... sauf encore quand ce n'est pas possible). Il faut utiliser des protocoles sécurisés quand on peut (adieu telnet).
  • Exigence 16  :  Il faut cloisonner les SIIV physiquement ou logiquement en périphérie et en interne.
  • Exigence 17 :  Il faut mettre en place du filtrage, c'est normal, ca va avec le point précédent (cloisonner sans filtrage, ça n'a pas beaucoup de sens).
  • Exigence 18  :  Les accès à distance, notamment de maintenance, sont authentifiés et chiffrés, mais les mémoires de masse des équipements de maintenance le sont aussi. Le premier point semble raisonnable, le 2ème va être plus compliqué pour les mainteneurs.
  • Exigence 19  :  Il faut durcir les systèmes quand on peut et mettre en place des mesures pour passer les supports amovibles, forcément dédiés au SIIV dans un système de détection antimalware. Ici encore, c'est évidemment une bonne mesure quand on voit le nombre d'infections provenant d'une clé USB par un opérateur de maintenance sur des systèmes critiques, mais c'est aussi une mesure contraignante.

Gérer les accès aux SIIV

Ici encore, une complexité sera due à la gestion des changements. Ici encore, quand tout n'est pas possible, il est souvent envisageable de mettre en place des mesures compensatoires.

  • Exigence 11  : Tous les accès au SIIV doivent être identifiés, sauf quand ce n'est pas possible (pour les salles de supervision notamment)
  • Exigence 12  : Tous les accès au SIIV doivent être authentifiés et on doit pouvoir supprimer les authentifiants par défaut des machines (ça peut être difficile avec certains composants matériels ou logiciels souvent rencontrés dans la santé),  séparer compte privilégié et utilisateur,  et se référer aux guide de l'ANSSI sur les moyens d'authentification acceptable.
  • Exigence 13 :  Il faut gérer les droits d'accès
  • Exigence 14  :  Il faut gérer les comptes privilégiés avec beaucoup de soin

Détecter et réagir face aux attaques sur les SIIV

Possiblement un des plus gros morceaux du décret, car ce besoin rend nécessaire une approche globale associant processus, outils et ressources.

  • Exigence 5  :  Il faut journaliser proprement (horodatage fiable, etc.) et garder pendant 6 mois minimum (mais pas forcément plus d'un an en rajoutant les exigences habituelles de la CNIL) les événements. Quels événements : tout ce qui concerne les accès et les modifications de règles de sécurité sur un ensemble les composants classiques du SI (serveurs, postes...).
    Il faudra aussi pouvoir rechercher facilement dans les logs, donc pas question de conserver les logs en local. Une solution de centralisation des logs (ex  SIM ou service d'archivage des logs) semble nécessaire.
  • Exigence 6  :  Il faut analyser et corréler les journaux d'événements pour détecter les événements susceptibles d'affecter la sécurité des SI.
    C'est un gros challenge. Il faut un "SOC", interne ou externe. Si le SOC est externe, il doit être qualifié selon le référentiel Prestataire de Détection des Incidents de Sécurité (PDIS) par l'ANSSI, ce qui entraîne de nombreuses contraintes à respecter mais garantir une véritable professionnalisation du SOC. A ce jour, il n'y a pas d'acteur qualifié mais ça va arriver.
  • Exigence 7  :  Il faut installer une sonde "d'analyse de fichiers et de protocoles", qualifiée par l'ANSSI, au niveau des points d'interconnexion des SIIV avec des SI tiers à l'opérateur (donc pas entre SIIV semble-t-il).
    A ce jour, il n'y a pas non plus de sondes qualifiées, mais ça va également arriver. Ces sondes doivent être exploitées par un SOC interne ou externe, comme au point précédent.
  • Exigence 8  :  Il faut gérer les incidents de sécurité, selon les principes du référentiel Prestataire de Réponse aux Incidents de Sécurité (PRIS) par l'ANSSI, ici aussi gage de professionnalisme. En cas d'incident, il faut conserver les relevés techniques associés pendant 6 mois (prévoir un espace sécurisé pour cela).
  • Exigence 9  :  Il faut savoir recevoir les alertes de l'ANSSI et une procédure pour les traiter le cas échéant.
  • Exigence 10  : Il faut une procédure de gestion de crise en cas d'attaque informatique majeure. L'ANSSI indique une liste d'actions à savoir mener comme isoler ou segmenter le SIIV, stopper un flux, restreinte des communications, installer un correctif, bloquer des fichiers... et pourra fournir des consignes voire exiger des actions en cas d'alerte.

Et donc ?

Au final, pas de grande surprise, beaucoup de bon sens, mais pour autant, la mise en place ne va pas être triviale. La maturité sécurité des acteurs de santé reste souvent assez faible, même si des différences importantes existent entre structures. Bien sûr ces règles ne concernent que les quelques structures de santé OIV en France.

Il n'en reste pas moins que la cible est ambitieuse et ne pourra pas être réalisée immédiatement pour  les structures concernées. L'ANSSI précise des délais d'application différenciés selon les exigences dans l'annexe II de l'arrêté (annexe non diffusée publiquement actuellement).

Il faudra sans doute commencer par faire une analyse d'écart et déterminer une feuille de route précise. Mettre en place une détection d'attaques par exemple reste un projet complexe qu'il faut mettre en place graduellement ; il ne faut attendre d'être au bout du délai proposé pour réfléchir au sujet.

Il est évident aussi que les OIV ne pourront pas se mettre en conformité seuls. Il leur faudra des opérateurs de confiance pour opérer les contrôles et les détections (qui vont devoir également passer à la qualification). Ils auront également besoin que leurs éditeurs/mainteneurs (qui n'ont pas de besoin de qualification bien qu'ils puissent toujours faire qualifier leurs produits) évoluent dans leur prise en compte des exigences de sécurité.

La question qui se pose est : sur un marché des logiciels métiers de santé souvent de niche, comment vont faire ces éditeurs/constructeurs/mainteneurs ? Combien de temps mettront-ils à proposer de solutions sécurisées et s'ils ne le font pas, les structures de santé pourront-elles vraiment les challenger (car changer de partenaire peut être tout simplement très complexe).

Tristan Savalle, Consultant sénior, Advens