Incidents de sécurité des SI de santé : que faut-il déclarer ?

Ce décret laisse donc place à l’interprétation dans de nombreux cas et on me pose souvent la question, « Charles, à ma place tu déclarerais cela ? »
Je vais essayer de vous éclairer avec quelques exemples concrets. 

1. Une panne électrique : si l’infrastructure physique n’est subitement plus alimentée électriquement, le redémarrage total du système d’information prendra forcément plusieurs heures, même s’il n’y a aucune casse (au sens large) à déplorer. À minima, il y aura donc une atteinte à la disponibilité des données, par conséquent une atteinte au fonctionnement normal et potentiellement à la continuité ou la sécurité des soins. Soit trois bonnes raisons de déclarer l’incident.

2. Une panne téléphonique : un établissement de santé qui ne peut plus être contacté par téléphone représente un risque important pour la prise en charge des patients et une atteinte au fonctionnement normal, là aussi, aucun doute à avoir, il faut déclarer.

3. Une perte d’accès Internet : si votre établissement utilise uniquement l’accès Internet pour le surf, vous allez me dire, rien de bien grave, mais les accès Internet ne se limitent bien souvent pas qu’à cela. Que votre messagerie soit hébergée en interne ou non, dans tous les cas, vous perdez ce moyen de communication. Les applications hébergées ne seront plus accessibles, les solutions de télémédecine ou de télémaintenance non plus, les interconnexions avec des sites distants… Bref, les exemples ne manquent pas, la vraie question est de savoir combien de temps votre établissement peut vivre en autarcie totale avant qu’il y ait des conséquences sur la sécurité des soins ou que l’on puisse considérer qu’il y ait une véritable atteinte au fonctionnement normal ? Pour ma part, au-delà de deux heures, je déclare. 

4. Une panne de climatisation dans une salle serveur : si cette panne nécessite l’arrêt total de l’infrastructure physique de la salle et que la deuxième salle n’est pas en capacité de faire fonctionner la totalité des applicatifs au cœur du processus de soins, il y a donc une atteinte à la disponibilité des données, et potentiellement à la sécurité des soins. Dans ce cas encore, il faut  déclarer.

5. La réception d’un message malveillant de type : à moins d’embaucher au minimum une personne à temps plein pour un établissement de taille moyenne, il va être très compliqué de tout déclarer. De plus la petite équipe de la cellule ACSS risque fortement de vous détester si vous devenez leur expéditeur de SPAM N°1. Dans ces cas-là, j’essaye de faire appel au bon sens. Si une personne s’est fait piéger et qu’il y a eu une atteinte à la confidentialité, l’intégrité ou la disponibilité des données suite à cela, sans aucun doute, je vais déclarer l’incident. Je n’ai d’ailleurs pas honte de dire que je l’ai déjà fait. Si le message malveillant provient d’une messagerie hébergée dans mon établissement, euhhh, là il y a de sérieuses questions à se poser. Il va falloir déclarer, mais aussi investiguer. La cellule ACSS peut d’ailleurs vous apporter son aide dans les investigations, et pourquoi pas faire appel à l’ANSSI si nécessaire. Si vous constatez un message suspect en provenance d’une messagerie légitime (serveur expéditeur légitime) d’un autre établissement , un coup de fil ou mail au RSSI ou au DSI de l’établissement concerné sera toujours le bienvenu. Si mon anti-spam détecte 300 messages par heure contenant un cheval de Troie ou un rançongiciel, même s’il a fait son boulot et qu’il a protégé mon établissement, déclarer l’incident pour faire remonter l’information à la cellule ACSS et le service du HFDS afin de déterminer s’il est nécessaire de lancer une alerte nationale est à mon sens un acte citoyen. Cette déclaration permettra d’être solidaire avec la communauté, et en allant un peu plus loin, pourquoi pas de sauver des vies en évitant à un établissement moins bien protégé que le mien de voir son SIH totalement mis à plat, faisant encourir des risques à ses patients.

6. Un logiciel malveillant détecté par mon antivirus : une alerte de l’antivirus doit attirer notre attention, dans la majorité des cas, si l’antivirus détecte un comportement malveillant, il va interagir dans le processus et stopper la menace, sinon il indiquera la procédure à suivre. Dans ce cas-là, il n’est pas nécessaire de déclarer un incident, sinon là encore, il risque de falloir embaucher pour remplir les formulaires de déclaration… En revanche, si j’ai 50 postes qui me remontent la même alarme dans la matinée, même s’il n’y a pas d’impact sur mon SIH, ou si mon antivirus détecte une nouvelle souche virale (et Dieu sait que cela est malheureusement légion avec les cryptovirus), là encore, il me parait nécessaire de remonter l’information afin d’évaluer si l’émission d’une alerte est pertinente.

7. Un bug dans une application au cœur du processus de soins : si ce bug peut avoir un impact sur la sécurité des soins, sur la confidentialité, l’intégrité ou la disponibilité des données. Pas d’hésitation à avoir, déclarer un incident ne fera qu’accélérer l’éditeur dans la résolution du problème. La cellule ACSS pourra faire remonter l’incident à l’ANSM, qui aura beaucoup plus de poids qu’une petite structure dans la demande de résolution du problème.

8. Une panne chez mon hébergeur HDS : agréé ou certifié, si mon hébergeur HDS n’est plus en capacité de me fournir l’accès aux données de santé qu’il héberge pour le compte de mon établissement, il y a donc atteinte à la disponibilité des données, au fonctionnement normal de mon établissement et potentiellement un risque pour ses patients. La déclaration s’avère encore une fois nécessaire. De plus, d’autres établissements seront confrontés aux mêmes risques.

Pour reprendre les mots de Philippe Loudenot, « dans le doute, mieux vaut déclarer ». En la matière, il convient de toujours se poser la question : est-ce que l’incident impacte les « métiers » (professionnels de santé, administratifs…) la seule vision de technicien n’étant pas suffisante.

En France, nous avons la chance, contrairement aux États-Unis, de pouvoir déclarer des incidents de sécurité sans qu’ils ne donnent lieu à une révélation publique, afin d’éviter de conduire à l’échafaud l’établissement déjà « victime » de l’incident. Le ministère a fermement rappelé qu’il serait aberrant d’ajouter du trouble au trouble. Il n’y a donc aucun intérêt de continuer à cacher la poussière sous le tapis. La déclaration vous permettra d’obtenir de l’aide si nécessaire, soit d’apporter une aide à la communauté, ce qui sera tout à votre honneur.

Au prochain incident, vous savez ce qu’il vous reste à faire, déclarez [4] ! 

[1] https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000036515017&cidTexte=LEGITEXT000006072665&dateTexte=20180119

[2] https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000033117678

[3] https://esante.gouv.fr/securite/accompagnement-cybersecurite-des-structures-de-sante

[4] https://signalement.social-sante.gouv.fr/