500.000 données de patients en 96 heures : Rapport d’incident anonyme d’un groupe hospitalier de la région DACH

10 min. de lecture

Entre mi mars et début avril 2026, le secteur de la santé a connu une vague de violations de données : CareCloud, Hong Kong Hospital Authority, Signature Healthcare (ANUBIS-Ransomware, 09.04.2026), ACN Healthcare (Groupe Lynx, 10.04.2026) et Covenant Health avec près de 480.000 personnes concernées. Parallèlement, nous suivons dans la rédaction un incident anonyme dans un groupe hospitalier DACH (Allemagne, Autriche, Suisse) avec environ 500.000 dossiers patients. Le rapport suivant retrace les 96 heures du compromis initial jusqu’à l’obligation de déclaration au BSI (Bundesamt für Sicherheit in der Informationstechnik) en vertu du NIS2 et fournit les leçons apprises qui doivent intégrer chaque révision de Security-Operations-Playbook au cours des six prochaines semaines.

Ce qui s’est passé: les 96 heures en détail

Qu’est-ce qu’un rapport d’incident dans le contexte de la santé? Un rapport d’incident est la reconstruction écrite structurée d’un incident de sécurité ou de protection des données, construit le long des phases Initial Compromise (compromis initial), Execution (exécution), Persistence (persistance), Lateral Movement (mouvement latéral), Data Exfiltration (exfiltration de données) et Impact. Dans le secteur de la santé, le rapport a en outre pour tâche de documenter l’obligation de déclaration NIS2 auprès du BSI (Bundesamt für Sicherheit in der Informationstechnik), la notification de la DSGVO (Datenschutz-Grundverordnung) auprès de l’autorité de contrôle et, le cas échéant, l’information aux patients. Un rapport d’incident complet comprend généralement de 40 à 120 pages et constitue la base du suivi interne et de l’examen externe par les instances de protection des données et de conformité.

Dans le cas anonyme, un groupe de cliniques avec environ 500.000 dossiers patients a été la cible d’un groupe de rançongiciel dont la signature présentait plusieurs modèles qui sont également apparus dans les vagues d’avril autour d’ANUBIS et Lynx. Le compromis initial a eu lieu le jour -4 via un passerelle de bureau à distance (Remote Desktop Gateway) non corrigée avec une configuration MFA (Multi-Factor Authentication) faible (basée sur SMS, sans facteur résistant au phishing). Les attaquants ont utilisé un lot d’ Credential Stuffing provenant d’une précédente panne d’un tiers et ont obtenu l’accès à un compte de maintenance avec des droits de lecture étendus sur le SIH (Système d’Information Hospitalier).

Les jours -3 et -2 ont été utilisés pour la reconnaissance et le mouvement latéral. Les attaquants ont établi une chaîne de proxy SOCKS, installé un beacon léger sur trois serveurs d’administration centraux et ont parcouru les partages de fichiers jusqu’à localiser les sauvegardes. Le jour -1 a eu lieu l’exfiltration réelle : environ 2,4 TB de données, compressées à environ 420 GB, via la chaîne SOCKS vers un stockage cloud externe. Le jour 0 à 04:12 heures, la phase de chiffrement a commencé, en parallèle les sauvegardes en ligne ont été supprimées. À 07:30 heures, les premiers systèmes sont tombés en panne, et à 08:45 heures, la direction informatique a été alertée.

Pourquoi le réseau SIH joue un rôle particulier

Les systèmes d’information hospitalière (SIH) sont des consortiums historiquement établis composés de bases de données de patients, de serveurs DICOM, de systèmes de laboratoire et de résultats, ainsi que d’équipements médicaux spécialisés. L’architecture dans de nombreux établissements est encore aujourd’hui plutôt un « espace plat » qu’un réseau strictement segmenté. Cela a des conséquences : celui qui a un pied dans l’administration atteint souvent avec quelques mouvements latéraux également les bases de données de patients. Dans le cas anonyme, c’est précisément là qu’était la faille critique, car bien que la segmentation VLAN existait, le réseau de sauvegarde du SIH était accessible via un jumphost hérité (legacy), que personne n’avait documenté dans la révision de sécurité actuelle.

Les quatre leçons apprises en détail

Nous écrivons pour des magazines, pas pour la réponse aux incidents. Pourtant, nous apprenons chaque jour à quel point la frontière entre une fonctionnalité informatique et un titre sensationnel est mince. Dans le secteur de la santé, les titres ne sont pas la pire conséquence, mais simplement la partie la plus facile des répercussions.

Leçon 1 : Le durcissement des passerelles RDP n’est pas négociable en 2026

Les passerelles de bureau à distance sont l’une des voies d’entrée les plus fréquentes dans le segment des soins de santé. Dans le cas anonymisé, la vulnérabilité résidait dans une combinaison de trois facteurs : un correctif de sécurité manquant depuis l’automne 2025, une MFA basée sur SMS (vulnérable au phishing et non résistante à l’adversaire au milieu) ainsi qu’un compte de maintenance provenant d’une panne externe de fournisseur tiers dans un lot d’espionnage d’identifiants. Le bloc de mesures correctives spécifique pour les cliniques avec leur propre passerelle RDP : Premièrement, un statut de correctif mensuel dans une fenêtre de maintenance définie, avec escalade en cas de failles de plus de 30 jours. Deuxièmement, des Passkeys FIDO2 ou de plateforme obligatoires pour tous les comptes administratifs avec accès RDP. Troisièmement, un monitoring de l’espionnage d’identifiants via l’API Have-I-Been-Pwned ainsi que des propres sources de renseignements sur les menaces, pour détecter les compromissions à temps.

Leçon 2 : Réseaux de sauvegarde segmentés avec hôtes bastion explicites

La deuxième leçon concernait la chaîne de sauvegarde. Dans le cas, le réseau de sauvegarde en ligne était accessible via un jumphost hérité, dont l’importance n’était plus documentée activement par personne. Ce n’est pas inhabituel : les systèmes informatiques des cliniques ont souvent des chemins d’administration historiquement établis qui ne sont pas clairement reflétés dans la topologie réseau officielle. La mesure corrective est une séparation stricte des réseaux de sauvegarde avec des hôtes bastion explicites, des droits d’accès documentés et une sauvegarde hors ligne physiquement séparée du réseau en ligne. Dans ce cas, le processus de sauvegarde hors ligne a été mis en place dans les semaines suivant la panne et a réduit le temps de récupération dans le test de simulation ultérieur de 14 jours à 4 jours.

Leçon 3 : Politique uniforme de traçabilité d’audit sur tous les systèmes médicaux spécialisés

L’un des plus grands défis de la phase de réponse aux incidents était la reconstruction de l’exfiltration. Les systèmes spécialisés (KIS, PACS, LIS, AIS) géraient chacun leurs propres journaux d’audit avec des formats et des périodes de rétention différents. La consolidation a coûté environ 40 heures, dont environ 25 heures auraient pu être évitées avec une politique de traçabilité d’audit uniforme. La recommandation concrète : un projet SIEM centralisé qui alimente les systèmes médicaux spécialisés et impose une taxonomie d’événements uniforme. Pour les groupes de cliniques de taille moyenne (3 à 8 sites), l’investissement la première année se situe entre 150 000 et 350 000 euros, généralement avec un taux de subvention de 30 à 40 % via le programme de succession KHZG.

Leçon 4 : Chaîne de réponse aux incidents entraînée avec BSI, protection des données et communication

L’obligation de déclaration NIS2 s’applique dans les 24 heures suivant la connaissance d’un incident significatif. La déclaration RGPD à l’autorité de contrôle doit avoir lieu dans les 72 heures. Parallèlement, les cascades de communication internes (direction de la clinique, direction médicale, comité d’entreprise) et les parties prenantes externes (représentants des patients, pour les organismes cotés en bourse, des communications ad-hoc supplémentaires) sont en cours. Quiconque n’entraîne pas ces cascades dans le cadre d’exercices de simulation annuels perd les délais en cas de situation réelle. Dans ce cas, le groupe de cliniques avait établi une simulation semestrielle ; c’est précisément cette routine qui explique pourquoi la déclaration initiale au BSI a été effectuée après seulement 21 heures, la déclaration RGPD après 58 heures, et l’information aux patients après 9 jours.

Ce que cela signifie pour votre organisation

La vague de violations de données dans le secteur de la santé en avril 2026 n’est pas un hasard. Les groupes de ransomware ont identifié ce segment comme une cible lucrative, car la combinaison d’infrastructures critiques, de forte propension à payer des rançons et de réseaux historiquement faiblement segmentés est attractive pour les attaquants. La conséquence pour les services informatiques des cliniques de la région DACH (Allemagne, Autriche, Suisse) : les quatre leçons apprises devraient être visibles dans les mesures prises d’ici la fin du deuxième trimestre 2026, et non après un incident survenu dans leur propre établissement.

Une étape intermédiaire pragmatique : un exercice de simulation basé sur le scénario de 96 heures décrit ici, en collaboration avec les services informatiques, la protection des données, la direction de la clinique et une firme externe de réponse aux incidents. Le temps nécessaire est d’une demi-journée, mais le gain en termes de connaissances est considérable dans la pratique. Si, après un tel exercice, trois mesures concrètes ne peuvent pas être déduites, cela signifie soit que l’informatique est exceptionnellement bonne, soit que la direction de l’hôpital est exceptionnellement honnête. Les deux cas sont plus rares dans la réalité qu’on ne pourrait le penser.

Ce que la direction et le conseil de surveillance attendent après un incident

En plus de la réponse technique à l’incident, un second bloc de travail attend de nombreuses organisations, souvent sous-estimé : la post-analyse par les organes de surveillance. Le conseil de surveillance d’un groupe hospitalier ou d’une entreprise pharmaceutique attend trois artefacts concrets après un tel incident. Premièrement, un rapport de leçons apprises qui identifie les causes sans ménagement et ne dissimule aucune demi-vérité. Deuxièmement, un plan d’action avec des responsabilités claires et des délais jusqu’à la prochaine réunion. Troisièmement, un budget qui priorise les investissements supplémentaires pour le renforcement de la sécurité et les justifie par la déclaration NIS2.

Celui qui ne fournit pas ces trois artefacts dans les deux premières semaines après la maîtrise de l’incident perd l’initiative face aux questions externes (assureurs, auditeurs, autorités de surveillance). Les post-analyses les plus réussies combinent la profondeur technique avec une communication de direction honnête. Les moins réussies sont un mélange de « c’était de la malchance » et « nous avions tout fait correctement », et ces deux affirmations sont rarement vraies dans un rapport d’incident de cette envergure.

Regard sur la vague d’avril : ce qui se dégage des incidents

Les cinq incidents publics, de CareCloud à Covenant Health en passant par les victimes des groupes ANUBIS et Lynx, montrent trois schémas communs. Premièrement, la compromission initiale se fait principalement via des accès à distance (RDP, VPN, portails de télétravail). Deuxièmement, l’exfiltration est utilisée comme principal moyen de pression avant le chiffrement, et non l’inverse. Troisièmement, les groupes de ransomware ne publient pas seulement des demandes de rançon, mais aussi des exemples de preuves de violation sur des sites de fuite pour augmenter leur pouvoir de négociation. Chacun de ces trois points présente des contre-mesures pertinentes ; chaque organisation devrait les évaluer dans sa propre situation.

La dimension de l’assurance cyber, souvent absente des discussions au sein des conseils d’administration

Un aspect souvent pris au sérieux dans les groupes hospitaliers seulement après le deuxième ou troisième incident est le rôle de l’assurance cyber et des obligations qui y sont liées. De nombreuses polices exigent, comme condition de prestation, non seulement des normes de sécurité de base, mais aussi des exercices de simulation démontrables et des processus de réponse aux incidents documentés. Celui qui constate, en cas de sinistre, que ces obligations ne sont pas correctement remplies peut perdre jusqu’à 100 % des prestations d’assurance, bien que les primes aient été payées pendant des années. La recommandation : passer en revue chaque année les obligations de votre police cyber avec votre courtier et documenter la conformité avec les opérations de sécurité réelles.

Un second aspect de plus en plus pertinent dans l’assurance cyber pour le secteur de la santé en 2026 est le plafond des montants de couverture pour les pannes de dispositifs biomédicaux dans de nombreuses polices. Les organisations qui ne peuvent restaurer que partiellement les systèmes OT (dispositifs médicaux, équipements de laboratoire, systèmes d’imagerie) en cas de ransomware peuvent se retrouver avec des dommages non couverts. La conséquence opérationnelle est une cartographie granulaire des risques de votre paysage OT avec une évaluation explicite des conséquences des pannes par catégorie de dispositif. Sans cette cartographie, les arguments en cas de sinistre manquent de fondement. Un après-midi de cartographie peut éviter un trimestre de discussions avec l’assureur.

Questions fréquentes

Comment la directive NIS2 s’applique-t-elle en cas de violation de données dans le secteur de la santé ?

Les établissements essentiels et importants (y compris la plupart des grandes cliniques) doivent signaler les incidents majeurs au BSI (Bundesamt für Sicherheit in der Informationstechnik) dans les 24 heures (alerte précoce), fournir une notification d’incident avec une évaluation initiale dans les 72 heures, et soumettre un rapport final dans le mois. La déclaration se fait via le portail de déclaration du BSI. Les détails sur la qualification d’un « incident majeur » sont régis par le règlement spécifique du BSI.

Que doit faire un directeur de clinique dans les deux premières heures ?

Trois actions : Premièrement, convoquer une cellule de crise (IT, délégué à la protection des données, direction médicale, communication, service juridique). Deuxièmement, faire préparer les documents relatifs à l’obligation de déclaration NIS2 et à la notification RGPD pour ne pas dépasser les délais. Troisièmement, activer une société externe de réponse aux incidents si l’équipe interne n’est pas suffisante. Les organisations qui accomplissent ces trois tâches dans les deux premières heures auront une longueur d’avance sur celles qui commencent à coordonner à la quatrième heure.

Comment communiquer avec les patients sans créer de panique ?

Le RGPD exige que les personnes concernées soient informées en cas de risque élevé, dans un langage clair et simple. En pratique, des lettres FAQ courtes avec trois sections sont efficaces : ce qui s’est passé, quelles données sont concernées, et ce que les personnes concernées doivent faire. La panique survient généralement à cause d’une communication tardive ou défensive, et non d’une information claire. Une communication proactive et factuelle réduit le nombre d’appels au standard de la clinique de 40 à 60 %, selon nos observations.

Faut-il payer une rançon si des vies de patients sont en danger ?

En Allemagne, le paiement n’est pas interdit par la loi, mais il est clairement déconseillé par le BSI et le BKA (Bundeskriminalamt). Éthiquement et pratiquement, la décision est complexe : un paiement finance la prochaine campagne et, dans environ 30 % des cas, ne permet pas la récupération complète des données. Dans un cas anonymisé, la rançon n’a pas été payée ; la récupération a été effectuée via des sauvegardes hors ligne avec un délai de récupération de 4 jours. Une base de décision documentée (comité d’éthique, direction, direction médicale) devrait être en place avant une situation d’urgence.

Quel rôle joue le successeur du KHZG pour les investissements en cybersécurité ?

Le Krankenhauszukunftsgesetz (KHZG) avait prévu des fonds importants pour la cybersécurité de 2020 à 2024. Les programmes de suivi (projets fédéraux-régionaux pour la sécurité informatique dans le secteur de la santé) poursuivent ce financement sous de nouvelles conditions. Pour les cliniques, il est intéressant d’examiner les fenêtres de financement actuelles, car les projets SIEM, la segmentation du réseau et les tests d’intrusion peuvent souvent être cofinancés à hauteur de 30 à 50 %.

Combien de temps faut-il à une clinique pour être réellement « prête pour NIS2 » ?

Pour un groupe hospitalier de taille moyenne, nous estimons qu’il faudra entre 9 et 15 mois pour être pleinement conforme à NIS2, en fonction du niveau de maturité actuel. Les trois premiers mois sont généralement consacrés à l’analyse des écarts, les mois quatre à douze à la mise en œuvre des mesures critiques, et les trois derniers mois aux exercices de simulation et à la documentation. Ceux qui commencent plus tard risquent de se retrouver avec une documentation incomplète lors des vagues d’inspection du BSI en 2026 et 2027.

Réseau : Lire la suite dans Security Today

• Analyse de la vague d’adaptive-MFA et de l’attaque de phishing par code d’appareil
• Regard sur la conformité avec DORA 2.0 et la politique de la UK-FCA du 16 avril 2026
• Conseil sur le plan Microsoft-ASP.NET-CVE hors bande de 72h

Source de l’image de couverture : Pexels / Cottonbro Studio (px:3970330)

À propos de l'auteur: Tobias Massow

Plus d'articles de Tobias Massow