WannaCry du NHS: les logiciels obsolètes comme dépendance commune du service public

Résumé

• L'épidémie de WannaCry en mai 2017 a exposé le NHS à une défaillance de mode commun: de nombreuses organisations de soins locales dépendaient de systèmes Windows vulnérables, d'un déploiement inégal des correctifs, d'hypothèses de service partagées et de communications d'urgence qui pouvaient toutes échouer en même temps lorsque le ransomware se propageait par la même faille.
• La question de la responsabilité n'est pas de savoir si un hôpital, une version logicielle ou un administrateur a causé la perturbation. Il s'agit de savoir qui avait le contrôle pratique sur la suppression des anciens systèmes, le déploiement des correctifs, la gouvernance de la confiance, la segmentation du réseau, les directives centrales et la preuve que la continuité des soins ne dépendait plus d'une faille exploitable unique.
• La National Audit Office, le Department of Health and Social Care, le National Cyber Security Centre, NHS Digital, Microsoft, CISA et les archives du Parlement montrent ensemble qu'un correctif était disponible avant l'épidémie, que de nombreuses organisations étaient encore vulnérables et que la conséquence publique a été des rendez-vous annulés, des ambulances détournées et des opérations cliniques dégradées.
• La réparation durable doit être mesurée comme une protection des soins: inventaire des actifs, logiciels supportés, conformité des correctifs, détection des points de terminaison, plans de continuité hors ligne, résultats d'exercices locaux, escalade régionale et preuves visibles par le conseil que le service clinique peut se dégrader sans perdre la capacité de traiter les patients en toute sécurité.

L'incident était un ransomware, mais la dépendance était plus ancienne

WannaCry a atteint le NHS le 12 mai 2017, exploitant une vulnérabilité Windows wormable qui avait déjà été corrigée par la mise à jour de sécurité MS17-010 de Microsoft. Le bulletin de sécurité MS17-010 de Microsoft a été publié en mars 2017, et les conseils aux clients de Microsoft lors des attaques WannaCrypt décrivaient la nécessité d'appliquer la mise à jour, de protéger les systèmes non supportés et de bloquer les voies d'attaque. L' alerte de mai 2017 de la CISA et la déclaration publique d'Europol ont montré que l'épidémie était mondiale plutôt que spécifique au NHS.

La signification pour le NHS provenait de l'exposition en mode commun. L'enquête de la National Audit Office sur WannaCry et le NHS a révélé que l'attaque avait touché au moins 80 des 236 fiducies du NHS en Angleterre, plus 603 organisations du NHS, y compris des cabinets de médecins généralistes et d'autres organismes du NHS. Le rapport complet de la NAO en PDF a également enregistré des milliers de rendez-vous et opérations annulés, des détournements d'ambulances affectés et le fait qu'aucune organisation du NHS n'a payé la rançon.

Ces faits font de ce cas un événement de continuité du service public, et non une simple infection par un logiciel malveillant.

Le problème de mode commun était que de nombreuses organisations pouvaient échouer à cause de la même classe de faiblesse. Une fiducie locale pouvait avoir corrigé certaines machines, en avoir laissé d'autres exposées, s'être appuyée sur des systèmes d'exploitation non supportés, avoir connecté des équipements diagnostiques ou administratifs plus anciens à des réseaux plus larges, ou manquer d'un inventaire complet des actifs. Une autre fiducie pouvait avoir un déploiement de correctifs plus solide mais dépendre encore de partenaires régionaux, de canaux de référencement partagés ou de services en réseau.

Le ransomware devient alors un test de continuité pour l'ensemble de l'environnement de service de santé, car les soins aux patients dépendent de la préparation simultanée de nombreux systèmes locaux.

La question de la responsabilité est pratique. Qui aurait pu réduire la dépendance partagée avant mai 2017? Les organismes locaux du NHS contrôlaient leurs propres actifs, la discipline de correction, la segmentation du réseau et les exercices de continuité des activités. Les organismes nationaux contrôlaient les directives, la pression de financement, l'assurance, les attentes contractuelles et la visibilité des risques non résolus. Les fournisseurs contrôlaient les conditions de support, la disponibilité des correctifs et les dépendances logicielles des dispositifs médicaux.

Les ministres et les conseils contrôlaient la durée pendant laquelle les anciens systèmes étaient tolérés comme un compromis d'économie de coûts. Les patients ne contrôlaient rien de tout cela.

Un correctif existait, mais un correctif n'est pas un déploiement

L'existence de MS17-010 est centrale car elle montre la différence entre disponibilité et mise en œuvre. Microsoft a publié la mise à jour pertinente avant l'épidémie. Ce fait ne prouve pas que tous les organismes du NHS ont ignoré une instruction simple. Les environnements de santé comportent des équipements anciens, des configurations qualifiées par le fournisseur, des contraintes de planification clinique et des réseaux qui ne peuvent pas toujours être modifiés sans risque pour le service. Mais cela montre que le problème est passé d'une vulnérabilité purement logicielle à une gouvernance de déploiement.

Un correctif disponible sur un site fournisseur ne protège pas un patient si la machine affectée reste non corrigée dans le service, la clinique, le laboratoire ou le bureau administratif.

L' alerte cyber CareCERT CC-1353 de NHS Digital a averti les organisations du NHS d'appliquer les mises à jour Microsoft et de protéger les systèmes. L' examen des leçons apprises du Department of Health and Social Care a ensuite insisté sur la gestion des actifs, le déploiement de correctifs, les antivirus, les systèmes non supportés, la segmentation du réseau et la réponse aux incidents. La version PDF de l'examen est importante car elle traite la préparation cyber comme une responsabilité système plutôt qu'une simple correction technique.

C'est là que le cycle de vie et la dépendance entrent dans le dossier de responsabilité. Les systèmes non supportés sont souvent conservés parce que le remplacement est coûteux, que les logiciels spécialisés dépendent d'anciennes plateformes, que les dispositifs cliniques ont une longue durée de vie et que les organisations locales font face à des pressions concurrentes. Chaque raison peut être compréhensible. L'effet combiné est dangereux lorsque de nombreuses organisations partagent la même ancienne faiblesse.

Le risque de cycle de vie logiciel devient une dépendance du service public car le service de santé peut porter une exposition de continuité cachée que les patients découvrent seulement lorsque des rendez-vous sont annulés.

Les preuves de réparation doivent donc éviter l'affirmation étroite selon laquelle « le déploiement de correctifs s'est amélioré ». Un dossier mature montrerait quels systèmes critiques restent non supportés, lesquels ont des contrôles compensatoires, lesquels sont isolés, lesquels ont des engagements de mise à niveau des fournisseurs, lesquels ne peuvent être remplacés sans modifications des équipements cliniques, et quels conseils ont accepté le risque résiduel dans un langage d'intérêt public. Les logiciels anciens ne sont pas automatiquement imprudents.

Des logiciels anciens invisibles et non gérés dans les opérations cliniques sont le vrai problème.

Le contrôle local et le contrôle national étaient imbriqués

Le NHS n'est pas une seule salle des machines. C'est un service public fédéré avec des organisations locales, des organismes nationaux, des fournisseurs, des équipes cliniques et une infrastructure partagée. Cette structure complique la responsabilité, mais ne la supprime pas. Le rapport de la NAO et le rapport de 2018 du Public Accounts Committee sur la cyberattaque ont tous deux souligné le défi de savoir si tous les organismes locaux avaient suivi les directives et si les organismes centraux avaient une visibilité suffisante pour assurer la préparation.

Les organismes locaux avaient un contrôle direct sur de nombreuses mesures de protection pratiques. Ils pouvaient tenir des inventaires d'actifs, appliquer des mises à jour de sécurité, remplacer des systèmes non supportés, segmenter les réseaux, former le personnel, tester les plans de continuité et surveiller les indicateurs de logiciels malveillants. Ils pouvaient s'assurer que les fonctions cliniques critiques disposaient de procédures papier ou hors ligne de repli et que les canaux d'escalade survivaient à une panne numérique.

Ils pouvaient également enregistrer quand des préoccupations de risque clinique retardaient l'application de correctifs et quels contrôles compensatoires étaient appliqués.

Les organismes nationaux contrôlaient une couche différente. Ils pouvaient définir des normes obligatoires, coordonner le renseignement, financer l'amélioration, appliquer des délais, collecter des preuves d'assurance et établir une réponse régionale aux incidents. NHS Digital, NHS England, le Department of Health, et plus tard NHSX et les organismes apparentés ont chacun joué un rôle dans l'environnement de préparation nationale.

La réflexion un an après WannaCry du National Cyber Security Centre et ses directives sur l'atténuation des attaques de logiciels malveillants et de ransomware montrent comment les directives cyber centrales ont encadré les leçons pour les organisations publiques et privées.

La structure partagée crée un risque récurrent: les organismes locaux peuvent dire qu'ils étaient sous-financés, contraints ou dépendants des systèmes centraux; les organismes centraux peuvent dire que les fiducies locales étaient responsables de leurs propres correctifs; les fournisseurs peuvent dire que des mises à niveau étaient disponibles sous réserve d'achat; les conseils peuvent dire que la demande clinique rendait les pannes inacceptables. Chaque affirmation peut contenir une part de vérité. La responsabilité demande qui pouvait rendre l'ensemble du système moins dépendant de la même faiblesse.

Cela nécessite une visibilité nationale sur le risque local et une mise en œuvre locale des normes nationales.

Le préjudice pour les patients était indirect mais réel

WannaCry n'avait pas besoin de chiffrer tous les systèmes cliniques pour affecter les soins. La NAO a enregistré des rendez-vous annulés, des services de médecins généralistes perturbés, des détournements d'ambulances et des diagnostics affectés. Ces résultats sont indirects car le logiciel malveillant a attaqué des ordinateurs, pas des patients. Ils sont réels car les soins dépendent des ordinateurs pour la planification, les dossiers, l'imagerie, la communication, la prescription, les références et la coordination.

Un incident cyber dans un service de santé devient un problème de sécurité des patients lorsque le travail clinique ralentit, est détourné ou perd des informations nécessaires.

Cela compte pour la mesure de l'impact. Si une organisation ne compte que les paiements de rançon ou les fichiers corrompus, elle manque le préjudice pour le service public. Le NHS n'a pas payé de rançon, mais les patients ont quand même perdu des rendez-vous et le service a encouru des coûts de récupération. Certains systèmes ont été mis hors ligne par précaution même là où l'infection n'avait pas eu lieu. Certaines organisations ont dû annuler des soins parce qu'elles ne pouvaient pas faire confiance à l'environnement numérique. Certaines ont pu continuer parce qu'elles avaient une meilleure segmentation ou un repli.

Le préjudice était réparti sur l'ensemble du service, et cette répartition est la leçon.

Un dossier d'impact plus solide relierait les états techniques aux états de soins. Quels systèmes ont été infectés? Lesquels ont été déconnectés par précaution? Quels rendez-vous ont été annulés parce que des systèmes spécifiques étaient indisponibles? Quels détournements d'ambulances ont résulté de problèmes de capacité ou de confiance locaux? Quels laboratoires, services d'imagerie et systèmes de dossiers ont été affectés? Quelles organisations ont maintenu les soins grâce à des replis testés?

Sans cette cartographie, le public voit une perturbation importante mais ne peut pas dire quels contrôles ont protégé les patients et lesquels ont échoué.

Le travail ultérieur de cyber-résilience du NHS doit donc être évalué par rapport à la continuité clinique. Il est utile de compter les appareils corrigés, la couverture des points de terminaison et l'achèvement des formations cyber. Il est plus utile de savoir si une fiducie peut continuer en toute sécurité les soins urgents tout en isolant les systèmes affectés; si les cliniciens peuvent accéder aux informations essentielles sur les patients lorsque les réseaux sont dégradés; si les partenaires régionaux savent comment orienter les patients;

et si les commandants d'incidents cyber peuvent prendre des décisions avec les dirigeants cliniques plutôt que de traiter l'événement comme un problème informatique seul.

Le problème des systèmes non supportés est un problème de gouvernance

Les logiciels non supportés ne sont pas simplement une catégorie de dette technique. Dans un environnement de santé publique, c'est une décision de gouvernance sur qui porte le risque. Une fiducie peut conserver une vieille machine parce qu'un dispositif clinique est coûteux à remplacer. Un fournisseur peut supporter un dispositif uniquement sur une plateforme héritée. Un processus d'achat peut reporter le remplacement. Un conseil peut accepter un risque parce que le budget d'investissement est serré. Le patient, cependant, ne fait l'expérience que de l'échec éventuel de la continuité.

L'examen des leçons apprises du Royaume-Uni a traité les systèmes non supportés comme l'un des thèmes de remédiation importants. C'est juste, mais le statut non supporté en soi n'est pas le seul indicateur. Un système supporté mais non corrigé peut être vulnérable. Un système non supporté mais isolé, étroitement surveillé et programmé pour être remplacé peut présenter un risque opérationnel plus faible qu'un système supporté sans propriétaire. La question de gouvernance est de savoir si chaque actif à haut risque a un propriétaire désigné, un plan de cycle de vie, des contrôles compensatoires et une visibilité au conseil.

La technologie médicale et opérationnelle complique la question. Certains dispositifs cliniques ne peuvent pas être corrigés sans validation du fournisseur. Certains anciens systèmes supportent des flux de travail spécialisés. Certains remplacements nécessitent des temps d'arrêt qui affectent les soins. Ces contraintes sont réelles, mais elles doivent être visibles comme des exceptions, pas cachées comme des opérations ordinaires. Si une machine ne peut pas être corrigée, le dossier devrait montrer pourquoi, comment elle est isolée, combien de temps elle restera, quel service en dépend et ce qui se passerait si elle échouait.

La leçon du secteur public au Royaume-Uni s'étend au-delà du NHS. Les écoles, les conseils, la police, les transports et les services d'urgence ont tous des logiciels anciens quelque part. Le cas du NHS est frappant car les soins aux patients sont directs, mais le modèle de mode commun est plus large. Les services publics ont besoin d'un moyen de savoir quand de nombreux organismes locaux dépendent de la même technologie non supportée ou non corrigée, car un attaquant ou un ver ne respectera pas les limites organisationnelles.

L'automatisation de la sécurité ne peut aider qu'après clarification de la propriété

L'automatisation de la sécurité est tentante après WannaCry. Les outils de point de terminaison, les scanners de vulnérabilité, l'orchestration des correctifs, la découverte d'actifs, les flux de renseignement sur les menaces et le confinement automatisé peuvent tous réduire l'exposition. Mais l'automatisation ne peut pas réparer un actif dont personne n'est propriétaire, un dispositif clinique qui ne peut pas être corrigé, un réseau qui n'a jamais été cartographié, ou un conseil qui traite les logiciels anciens comme un problème de coût invisible. L'automatisation renforce la gouvernance; elle ne peut pas s'y substituer.

L'automatisation la plus précieuse répondrait d'abord aux questions de base. Quels dispositifs existent? Quels systèmes d'exploitation utilisent-ils? Lesquels ne sont pas supportés? Lesquels ont des correctifs critiques manquants comme MS17-010 ou équivalents? Quels systèmes sont accessibles les uns aux autres? Lesquels sont connectés aux flux de travail cliniques? Lesquels sont exclus de l'analyse en raison de restrictions du fournisseur? Quels organismes locaux ont des lacunes inexpliquées? Ces réponses transforment un risque général en un registre géré.

La couche suivante est l'action. Le déploiement automatisé de correctifs peut appliquer des mises à jour là où c'est sûr. La gestion des vulnérabilités peut prioriser les expositions critiques. La surveillance du réseau peut détecter un trafic de type ver. La détection des points de terminaison peut contenir les logiciels malveillants. Les systèmes de sauvegarde peuvent soutenir la récupération. Mais chaque action automatisée a besoin d'un processus d'exception pour la sécurité clinique.

Si une mise à jour ne peut pas être appliquée parce qu'elle pourrait perturber un dispositif de diagnostic, cette exception devrait déclencher une planification d'isolement et de remplacement plutôt qu'une tolérance indéfinie.

Les directives générales sur les ransomwares du NCSC sont utiles car elles lient prévention, sauvegarde, réponse aux incidents et récupération. WannaCry montre pourquoi ces catégories vont ensemble. Un service de santé ne peut pas traiter la résilience aux ransomwares comme un seul achat de produit. Il a besoin d'une gouvernance des correctifs, d'une segmentation, d'une sauvegarde, d'une formation des utilisateurs, d'une récupération testée et d'une escalade clinique. La dépendance de mode commun disparaît seulement lorsque plusieurs mesures de sécurité se chevauchent.

Les preuves de réparation doivent être suffisamment publiques pour établir la confiance

Les patients n'ont pas besoin de l'adresse IP de chaque dispositif vulnérable. Ils ont besoin d'avoir confiance que le service de santé a appris d'une perturbation qui a annulé des soins. L'assurance publique peut être conçue sans exposer les attaquants à des cartes détaillées. Elle peut indiquer combien d'organisations respectent les normes cyber actuelles, comment évolue le nombre de systèmes non supportés, à quelle fréquence les exercices de continuité sont réalisés, à quelle vitesse les correctifs critiques sont appliqués et comment les conseils gèrent les exceptions.

Elle peut également indiquer si des audits indépendants trouvent des lacunes systémiques non résolues.

Les dossiers de la NAO et du Public Accounts Committee montrent pourquoi l'assurance indépendante est importante. Avant WannaCry, des directives existaient, mais l'assurance de la mise en œuvre locale était incomplète. Après WannaCry, la leçon n'était pas seulement de donner de meilleurs conseils. Il s'agissait de savoir si les conseils avaient changé l'état des systèmes qui fournissent les soins. Un organisme national qui ne peut pas voir la mise en œuvre locale ne peut pas dire au public si la dépendance de mode commun a été réduite.

Le dossier de réparation doit également distinguer la résilience de la réponse. La réponse demande si le NHS peut détecter, contenir et se remettre d'un incident. La résilience demande si l'incident peut être évité ou limité avant que les soins soient annulés. Les deux comptent. Un hôpital qui peut se rétablir rapidement nuit encore aux patients si de nombreux rendez-vous sont annulés. Un hôpital qui empêche la propagation mais n'a pas de repli peut encore lutter lors d'arrêts défensifs. La position la plus forte réduit la probabilité d'infection, limite la propagation, préserve les soins essentiels et récupère rapidement les preuves.

Le critère centré sur le patient est simple: le service de santé peut-il continuer les soins urgents lorsqu'une faiblesse logicielle commune est exploitée? Ce critère oblige les dirigeants à se poser des questions opérationnelles plutôt que seulement techniques. Les procédures papier sont-elles à jour? Les cliniciens peuvent-ils identifier les patients sans le système électronique? Les ambulances peuvent-elles être redirigées en toute sécurité? Les résultats de diagnostic peuvent-ils être communiqués en toute sécurité? Les soins primaires peuvent-ils maintenir un service suffisant?

Les organismes nationaux peuvent-ils coordonner rapidement les faits locaux? Ces questions font de la cyber résilience une discipline de continuité des soins.

Un futur événement de mode commun ne devrait pas être une surprise

WannaCry a été spectaculaire car il s'est propagé rapidement et mondialement. Le prochain événement de mode commun pourrait être plus silencieux. Il pourrait s'agir d'une mise à jour compromise, d'une panne d'identité cloud, d'une défaillance de certificat, d'un bogue de sécurité de point de terminaison, d'une violation de fournisseur ou d'une vulnérabilité dans un logiciel médical largement utilisé. La leçon partagée est que de nombreuses organisations de service public locales peuvent dépendre de la même condition technologique sans se considérer comme conjointement exposées.

Le NHS peut réduire ce risque en traitant l'homogénéité technologique comme une exposition à mesurer. Si de nombreuses fiducies s'appuient sur le même système non supporté, c'est un risque de mode commun. Si de nombreuses fiducies ne peuvent pas corriger une classe de dispositifs en raison de contraintes de fournisseur, c'est un risque de mode commun. Si de nombreux organismes locaux dépendent du même produit d'accès à distance, fournisseur d'identité ou produit de sauvegarde, c'est un risque de mode commun. Le registre des risques ne doit pas être seulement local; il doit agréger les modèles à travers le service.

La fonction d'achat a un rôle ici. Les contrats pour la technologie clinique et administrative doivent exiger un support de cycle de vie, une transparence des correctifs, une divulgation des vulnérabilités et des chemins de mise à niveau testés. Les affirmations des fournisseurs doivent être liées aux devoirs de continuité des soins. Un dispositif qui ne peut pas être corrigé sans des mois de négociation n'est pas seulement un inconvénient technique; c'est une dépendance pour la sécurité des patients. Un fournisseur qui contrôle le chemin de mise à niveau devrait partager la responsabilité de rendre ce chemin réalisable.

Le rôle du conseil est tout aussi important. Les documents du conseil ne doivent pas seulement dire que le risque cyber est élevé. Ils doivent identifier les systèmes non supportés, les exceptions de correctifs, les dépendances critiques des services, les résultats d'exercices et les contraintes non résolues des fournisseurs. Les dirigeants doivent être capables d'expliquer ce qui se passerait si une vulnérabilité wormable apparaissait demain. Les dirigeants cliniques doivent être inclus car la priorité est la continuité des soins, pas seulement la restauration technologique.

Les dirigeants financiers doivent être inclus car le remplacement des anciens systèmes est souvent une décision d'investissement.

La leçon publique de WannaCry n'est pas que chaque ancien système doit disparaître du jour au lendemain. C'est que les logiciels anciens deviennent dangereux lorsqu'ils deviennent invisibles, partagés et non gouvernés. Le dossier de responsabilité du NHS doit donc être jugé sur la question de savoir si le risque des anciens systèmes et des correctifs est suffisamment visible pour agir avant que les patients ne le ressentent. Un correctif existait. Des directives existaient. Ce qui manquait, c'était une préparation assurée à l'échelle du service.

C'est pourquoi WannaCry reste un cas de dépendance de mode commun plutôt qu'un simple souvenir de ransomware.

Les fenêtres de correctifs doivent être conçues autour des soins, pas contre les soins

L'une des raisons pour lesquelles l'application de correctifs échoue dans les hôpitaux est que les temps d'arrêt peuvent eux-mêmes être risqués. Un système de service, un dispositif d'imagerie, une machine de laboratoire ou une plateforme de planification peut supporter des soins en direct. Une mise à jour imprudente peut interrompre le service, casser une configuration de dispositif validée ou forcer les équipes cliniques à utiliser des contournements dangereux. Cette réalité devient souvent l'argument du retard. La meilleure réponse en matière de responsabilité n'est pas d'exiger des correctifs imprudents;

c'est de créer des fenêtres de correctifs adaptées aux soins, planifiées, testées et escaladées en cas de non-respect. Une fiducie doit savoir quels systèmes peuvent être mis à jour automatiquement, lesquels ont besoin d'une validation du fournisseur, lesquels nécessitent une approbation de temps d'arrêt clinique et lesquels comportent des contrôles compensatoires en attendant.

L'incident du NHS a montré que l'absence de gouvernance planifiée des correctifs peut créer des temps d'arrêt pires plus tard. Annuler une fenêtre de maintenance limitée est parfois plus facile que d'expliquer une brève interruption de service. Mais si de nombreux organismes locaux prennent cette décision à plusieurs reprises, le service de santé accumule une exposition cachée. Un ver n'attend pas un calendrier clinique pratique. La question de la responsabilité devient de savoir si les dirigeants ont rendu le risque visible avant que l'attaquant ne le rende visible.

Une exception locale doit avoir une date, un propriétaire, une justification clinique, une justification de sécurité, un contrôle compensatoire et un point d'examen. Lorsque la même exception apparaît dans de nombreuses fiducies, les organismes nationaux doivent la traiter comme un risque partagé qui nécessite un financement, une négociation avec le fournisseur ou un changement architectural.

Le langage plus large de cyber-résilience du gouvernement britannique après WannaCry a évolué dans cette direction. Le Cabinet Office et le NCSC ont à plusieurs reprises présenté la cyber-sécurité du secteur public comme une question de résilience opérationnelle, et le Cyber Assessment Framework du NCSC donne aux organisations une structure pour les fonctions essentielles, la protection, la détection, la réponse et la récupération. Le CAF n'est pas une source forensique pour WannaCry, mais c'est un moyen utile d'exprimer la leçon: la fonction pertinente est le soin aux patients, pas la simple existence d'un système informatique.

Les correctifs et les contrôles de cycle de vie doivent être jugés par leur contribution à cette fonction essentielle.

Les dirigeants cliniques appartiennent donc à la gouvernance des correctifs. Un conseil purement technique peut savoir quelle mise à jour manque mais pas quel service serait dangereux lors d'une installation précipitée. Un conseil purement clinique peut connaître le risque de service mais pas l'exposition cyber d'un retard indéfini. La décision a besoin des deux. Si un correctif ne peut pas être appliqué cette semaine parce qu'un dispositif de diagnostic est très utilisé, le dossier doit indiquer ce qui protège ce dispositif aujourd'hui, quelle action du fournisseur est nécessaire et quand la décision sera réexaminée.

Si la réponse est répétée pendant des mois, cela doit devenir un risque au niveau du conseil plutôt qu'une note de bas de page du service d'assistance.

Cette approche améliore également l'explication publique. Lors d'un autre incident cyber au NHS, le public n'a pas besoin d'une déclaration générique indiquant que les systèmes sont en cours de restauration. Il a besoin d'avoir confiance que les dirigeants savaient déjà quels systèmes comptaient le plus, quels risques avaient été acceptés et quels services avaient des plans de repli. Plus le dossier d'exception de correctifs est discipliné avant l'incident, plus l'explication publique peut être rapide après.

Un service de santé ne peut pas partager tous les détails techniques, mais il peut partager le fait que les exceptions sont gouvernées plutôt qu'oubliées.

La segmentation est un contrôle de continuité des soins

La propagation wormable de WannaCry a rendu la segmentation du réseau centrale. La segmentation est souvent décrite dans des schémas techniques, mais dans le contexte du NHS, c'est un contrôle de continuité des soins. Elle détermine si une machine administrative vulnérable peut affecter les services cliniques, si un site local peut en contaminer un autre, si les dispositifs de diagnostic peuvent être isolés sans perdre tout accès, et si un incident peut être contenu pendant que les soins urgents continuent.

Si chaque partie de l'environnement fait confiance à chaque autre partie, une seule ancienne faiblesse peut devenir une interruption à l'échelle du service.

La segmentation doit également être utilisable en période de crise. Un réseau qui ne peut être segmenté que par une petite équipe pendant les heures de bureau est moins utile lorsque le ransomware se propage rapidement. Une fiducie doit savoir quelles connexions peuvent être fermées, quel effet clinique la fermeture a, et comment les cliniciens travailleront si un service est isolé. Elle doit tester l'isolement dans des conditions réalistes. Un hôpital peut-il déconnecter un segment de réseau suspect tout en continuant à traiter les patients en urgence?

Un cabinet de médecine générale peut-il continuer son service essentiel pendant que les systèmes centraux sont indisponibles? Une région peut-elle rediriger les patients lorsqu'une fiducie perd confiance dans les systèmes numériques? Ce sont des questions cyber seulement parce qu'elles sont d'abord des questions de soins.

Le rapport de la NAO a enregistré que certaines organisations ont déconnecté des systèmes par précaution et que la communication entre organisations a été affectée. Cela signifie que la segmentation et les communications d'urgence sont liées. Si une fiducie isole des systèmes pour empêcher la propagation, elle a encore besoin de moyens sûrs de communiquer avec les partenaires régionaux, les services d'ambulance, les organismes nationaux et les patients. Un canal de sauvegarde qui dépend du même réseau affecté n'est pas une sauvegarde. Une procédure papier qui n'a pas été pratiquée n'est pas une procédure.

Une liste de contacts stockée uniquement sur un système inaccessible devient une autre dépendance de mode commun.

Un indicateur de réparation utile est donc le « temps d'isolement sûr ». Combien de temps faut-il à une organisation locale pour identifier un ver suspect, isoler les segments affectés, préserver les soins urgents et signaler l'état au commandement régional? Un autre indicateur est le « temps de communication de confiance ». Combien de temps avant que l'organisation puisse dire au personnel quels systèmes utiliser, dire aux patients quels services sont affectés et dire aux partenaires si les ambulances ou les références doivent être redirigées?

Ces indicateurs sont plus significatifs que le nombre d'échantillons de logiciels malveillants bloqués car ils relient l'action technique à la continuité du service public.

La segmentation révèle également la dépendance aux fournisseurs. Certains dispositifs cliniques et systèmes hérités sont difficiles à isoler car ils n'ont jamais été conçus pour les menaces réseau modernes. Les contrats doivent exiger que les fournisseurs supportent un fonctionnement sécurisé, l'application de correctifs, la journalisation et la séparation réseau. Si un fournisseur ne peut pas rendre un dispositif compatible avec une segmentation sûre, l'acheteur doit le savoir avant l'achat. Si un dispositif hérité reste, le risque doit être visible dans les achats, la gouvernance clinique et l'assurance cyber.

C'est ainsi que les vieux équipements cessent d'être une exposition de mode commun cachée.

Les leçons doivent être mesurées sur l'ensemble du service

Après WannaCry, les améliorations individuelles sont nécessaires mais insuffisantes. Une fiducie peut devenir plus forte tandis que le service dans son ensemble reste exposé si de nombreuses autres fiducies partagent la même faiblesse. La leçon de mode commun nécessite une mesure agrégée.

Les dirigeants nationaux doivent être capables de répondre à combien d'organisations ont des systèmes critiques non supportés, combien de vulnérabilités critiques dépassent les délais de correction, combien de fiducies ont testé la continuité des ransomwares au cours de la dernière année, combien de contraintes de fournisseur bloquent l'application de correctifs, et combien d'exceptions locales n'ont pas de chemin de remplacement financé.

Le NHS Data Security and Protection Toolkit, disponible via le portail du toolkit de NHS England, est un mécanisme pour collecter des informations d'auto-évaluation et d'assurance. L'auto-évaluation ne suffit pas à elle seule, mais elle donne une structure pour comparer les organisations et escalader les lacunes. Les tests indépendants, les exercices régionaux, l'assurance du conseil et le financement ciblé doivent l'accompagner. Le risque est qu'une liste de contrôle devienne un objet de confort plutôt qu'un contrôle.

La question doit toujours être de savoir si la conformité déclarée protégerait réellement les soins aux patients lors d'une vulnérabilité wormable.

Le Information Commissioner's Office compte également car le risque lié aux données de santé fait partie du même tableau de continuité. Les directives de l'ICO sur la sécurité au titre du RGPD britannique mettent l'accent sur des mesures techniques et organisationnelles appropriées. WannaCry n'a pas été principalement retenu pour l'exfiltration de données, mais les ransomwares et les logiciels malveillants destructeurs peuvent encore affecter la confidentialité, l'intégrité et la disponibilité.

Dans le domaine de la santé, la disponibilité est une préoccupation de protection des données et de soins aux patients car des dossiers indisponibles peuvent retarder le traitement. La gouvernance de la sécurité doit donc traiter la disponibilité comme un devoir envers les patients, pas seulement comme un objectif de service informatique.

La mesure doit inclure le risque résiduel, pas seulement les histoires de réussite. Si une fiducie a d'anciens systèmes en attente de remplacement, la question d'intérêt public est de savoir si le retard est compris, financé et contrôlé. Si une fiducie a des outils de point de terminaison solides mais une faible continuité hors ligne, cette lacune compte. Si une fiducie peut corriger rapidement les serveurs mais ne peut pas corriger les dispositifs cliniques, cette dépendance doit être agrégée au niveau national. Si une fiducie a de bons plans mais pas d'exercice récent, le plan reste non prouvé.

Un service de santé qui ne rapporte que des améliorations sans lacunes non résolues invite une autre surprise.

Les exercices régionaux peuvent rendre le tableau agrégé réel. Un exercice utile simulerait une vulnérabilité critique activement exploitée dans plusieurs organismes locaux. Il nécessiterait un isolement local, des décisions régionales de flux de patients, des communications nationales, une escalade des fournisseurs, une gestion de la presse et une priorisation clinique. Il mesurerait si le service peut identifier les systèmes exposés, protéger les soins urgents et communiquer en toute sécurité alors que les faits sont incomplets. Il testerait également si la faiblesse d'une organisation crée une charge déraisonnable pour ses voisins.

Le résultat devrait alimenter le financement, les achats et la responsabilité du conseil, pas seulement une note de retour d'expérience.

Le NHS devrait également comparer la continuité cyber avec d'autres disciplines de préparation en santé publique. Les systèmes de santé planifient déjà pour la pression hivernale, les maladies infectieuses, les grèves et les incidents majeurs. Les perturbations cyber devraient siéger à côté de ces risques car elles peuvent supprimer la capacité, l'information ou la coordination au moment même où la demande est élevée. Un exercice cyber qui n'atteint jamais le commandement opérationnel manque le but. Un exercice clinique d'incident majeur qui suppose que tous les systèmes numériques sont disponibles manque le but dans l'autre direction.

La responsabilité appartient aux personnes qui peuvent raccourcir l'exposition

Le test le plus utile après un cas comme WannaCry est le temps d'exposition. Combien de temps le service a-t-il porté un risque wormable connu avant l'épidémie? Combien de temps a-t-il fallu pour identifier les actifs vulnérables? Combien de temps les organismes locaux ont-ils eu besoin pour appliquer les correctifs? Combien de temps les systèmes non supportés sont-ils restés sans contrôle compensatoire? Combien de temps a-t-il fallu pour restaurer des soins sûrs? Combien de temps a-t-il fallu pour apprendre et financer les correctifs?

Chaque horloge pointe vers un propriétaire différent, mais ensemble, elles décrivent la responsabilité du service.

Les équipes informatiques locales sont souvent les plus visibles après un incident, mais elles ne sont pas les seuls acteurs responsables. Les conseils approuvent l'appétit pour le risque et les budgets. Les dirigeants cliniques approuvent les priorités de temps d'arrêt et de remplacement. Les équipes d'achat choisissent les fournisseurs et les conditions de support. Les organismes nationaux fixent les normes et surveillent la conformité. Les ministres fixent les conditions de financement et les priorités publiques. Les fournisseurs conçoivent des produits corrigibles ou laissent les acheteurs avec des dépendances héritées fragiles.

La responsabilité ne doit pas effondrer toute cette complexité sur la personne censée appliquer un correctif un jour particulier.

La responsabilité ne doit pas non plus se dissoudre dans la complexité. Si tout le monde est impliqué, quelqu'un doit encore agir. Une norme nationale devrait définir à quoi ressemble un bon état. Un conseil local devrait savoir s'il respecte la norme. Un fournisseur devrait savoir si son produit supporte la norme. Un régulateur ou un auditeur devrait savoir si les affirmations correspondent aux preuves. Un patient devrait savoir que le système a appris d'un échec passé. La dépendance de mode commun diminue lorsque chaque couche raccourcit l'exposition qu'elle contrôle.

C'est pourquoi le dossier WannaCry reste pertinent des années plus tard. Ce n'est pas seulement un événement historique de ransomware. C'est un modèle de la façon dont les logiciels anciens, la gouvernance des correctifs non testée, la préparation locale inégale et les lacunes d'assurance centrales peuvent se combiner en un préjudice pour le service public. L'exploit exact peut s'estomper. Le modèle de dépendance demeure. Si le NHS peut montrer qu'il voit, gouverne, exerce et finance maintenant ces dépendances sur l'ensemble du service, WannaCry devient une leçon durement apprise.

Sinon, il reste un avertissement attendant un nouveau déclencheur.

Le dernier critère de responsabilité est donc la preuve d'une exposition partagée réduite. Une fiducie qui remplace un ancien serveur améliore sa position locale. Un service national qui peut prouver que les actifs critiques non supportés sont connus, que les exceptions sont financées, que les fournisseurs sont responsables, que les correctifs sont rapides, que la segmentation est testée et que le repli clinique fonctionne a changé le système. La différence compte car les patients ne choisissent pas quelle organisation locale est la plus forte le jour où un ver arrive. Ils comptent sur le service de santé en tant qu'institution publique.

Le devoir est de rendre la dépendance commune la plus faible visible avant qu'elle ne devienne la prochaine raison pour laquelle les soins sont annulés.

Ce critère maintient également l'analyse équitable. Il ne prétend pas que tout risque peut être éliminé. Les soins de santé auront toujours des dispositifs spécialisés, des budgets contraints, des calendriers cliniques urgents et des relations complexes avec les fournisseurs. Il insiste sur le fait que ces contraintes soient gouvernées assez ouvertement pour que les dirigeants puissent agir. Une machine non corrigée cachée est un problème technique. Une exception connue, possédée, isolée, financée et limitée dans le temps est un risque géré. WannaCry a montré ce qui se passe lorsque trop d'exceptions restent invisibles en même temps.

Pour la responsabilité future, le chiffre public le plus important pourrait ne pas être le nombre d'attaques bloquées. Il pourrait être le nombre de services cliniques essentiels qui peuvent continuer à fonctionner pendant qu'une faiblesse technologique partagée est contenue. Ce chiffre relierait la cyber-sécurité à la promesse de service sur laquelle les patients comptent réellement. Le NHS ne doit pas au public un réseau parfait. Il doit prouver qu'une seule faille logicielle ancienne ne peut pas devenir silencieusement une défaillance de mode commun des soins, même pendant une semaine clinique chargée.

Cette preuve doit être maintenue avant l'arrivée de la prochaine alerte. Un service qui ne peut lister ses actifs vulnérables qu'après une perturbation a déjà accepté trop d'incertitude. Un service qui peut les lister, les isoler, financer le remplacement et répéter les soins dégradés a transformé le problème des logiciels anciens en un travail de continuité gouvernée.