NHS WannaCry: quand les logiciels obsolètes deviennent une dépendance commune des services publics

Résumé

• L’épidémie WannaCry de mai 2017 a exposé le NHS à une défaillance de mode commun: de nombreuses organisations locales de soins dépendaient de systèmes Windows vulnérables, de correctifs inégaux, de présupposés de services partagés et de communications d’urgence qui pouvaient toutes échouer ensemble 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 est à l’origine de la perturbation. Il s’agit de déterminer qui avait le contrôle pratique sur la suppression des anciens systèmes, le déploiement des correctifs, la gouvernance des trusts, la segmentation du réseau, les directives centrales et la preuve que la continuité des soins ne dépendait plus d’une seule faille exploitable.
• Le National Audit Office, le Department of Health and Social Care, le National Cyber Security Centre, NHS Digital, Microsoft, la CISA et les archives parlementaires montrent ensemble qu’un correctif était disponible avant l’épidémie, que de nombreuses organisations étaient encore vulnérables et que les conséquences publiques ont été des rendez-vous annulés, des ambulances détournées et des opérations cliniques dégradées.
• Une réparation durable devrait être mesurée en termes de protection des soins: inventaire des actifs, logiciels pris en charge, conformité des correctifs, détection aux points terminaux, plans de continuité hors ligne, résultats des exercices locaux, remontée régionale et preuves visibles pour le conseil d’administration que le service clinique peut 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, en exploitant une vulnérabilité Windows à propagation automatique qui avait déjà été corrigée par la mise à jour de sécurité MS17-010 de Microsoft. Lebulletin de sécurité MS17-010 de Microsofta été publié en mars 2017, et lesconseils aux clients pendant les attaques WannaCryptde Microsoft recommandaient d’appliquer la mise à jour, de protéger les systèmes non pris en charge et de bloquer les chemins d’attaque. L’alerte de mai 2017 de la CISAet ladéclaration publique d’Europolont montré que l’épidémie était mondiale plutôt que spécifique au NHS.

L’importance pour le NHS venait d’une exposition en mode commun. L’enquête du National Audit Office sur WannaCry et le NHSa révélé que l’attaque a touché au moins 80 des 236 trusts du NHS en Angleterre, ainsi que 603 organisations du NHS, y compris des cabinets de médecine générale et d’autres organismes du NHS. Lerapport complet en PDF du NAOa également enregistré des milliers de rendez-vous et d’opérations annulés, des détournements d’ambulances et le fait qu’aucune organisation du NHS n’a payé la rançon. Ces faits font de cet événement un problème de continuité des services publics, et pas seulement une infection par un logiciel malveillant.

Le problème du mode commun était que de nombreuses organisations pouvaient échouer par la même catégorie de faiblesse. Un trust local pouvait avoir corrigé certaines machines, laissé d’autres exposées, s’être appuyé sur des systèmes d’exploitation non pris en charge, avoir connecté d’anciens systèmes de diagnostic ou administratifs à des réseaux plus vastes, ou ne pas disposer d’un inventaire complet des actifs. Un autre trust pouvait avoir de meilleurs correctifs mais dépendre encore de partenaires régionaux, de canaux de référence partagés ou de services en réseau.

Le ransomware devient alors un test de continuité pour l’ensemble de l’environnement des services 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, les pressions budgétaires, 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 d’administration contrôlaient la durée pendant laquelle les anciens systèmes étaient tolérés comme un compromis de réduction des 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 validées par les fournisseurs, des contraintes de planification clinique et des réseaux qui ne peuvent pas toujours être modifiés sans risque de service. Mais cela montre que le problème est passé d’une simple vulnérabilité logicielle à une gouvernance du déploiement.

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

L’alerte cyber CareCERT CC-1353 de NHS Digitala averti les organisations du NHS d’appliquer les mises à jour Microsoft et de protéger leurs systèmes. L’examen des leçons apprises du Department of Health and Social Carea ensuite mis l’accent sur la gestion des actifs, les correctifs, les antivirus, les systèmes non pris en charge, la segmentation du réseau et la réponse aux incidents. Laversion PDF de l’examenest importante car elle traite la préparation cyber comme une responsabilité systémique plutôt que comme une simple solution technique.

C’est là que le cycle de vie et la dépendance fournisseur entrent dans le registre des responsabilités. Les systèmes non pris en charge sont souvent conservés parce que leur remplacement est coûteux, que des logiciels spécialisés dépendent d’anciennes plates-formes, que les dispositifs cliniques ont une longue durée de vie et que les organisations locales sont confrontées à des pressions concurrentes. Chaque raison peut être compréhensible. L’effet combiné est dangereux lorsque de nombreuses organisations partagent la même vieille faiblesse.

Le risque du cycle de vie logiciel devient une dépendance des services publics, car le service de santé peut être porteur d’une exposition cachée à la continuité que les patients ne découvrent que lorsque les rendez-vous sont annulés.

Les preuves de réparation devraient donc éviter l’affirmation étroite selon laquelle « les correctifs se sont améliorés ». Un bilan mature montrerait quels systèmes critiques restent non pris en charge, lesquels ont des contrôles compensatoires, lesquels sont isolés, lesquels ont des engagements de mise à niveau par le fournisseur, lesquels ne peuvent pas être remplacés sans changement d’équipement clinique et quels conseils d’administration ont accepté le risque résiduel dans des termes d’intérêt public. Les vieux logiciels ne sont pas automatiquement imprudents.

Le vrai problème, ce sont les vieux logiciels invisibles et non gérés dans les opérations cliniques.

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é composé d’organisations locales, d’organismes nationaux, de fournisseurs, d’équipes cliniques et d’infrastructures partagées. Cette structure complique la responsabilité, mais ne la supprime pas. Le rapport du NAO et lerapport de 2018 du Public Accounts Committee sur la cyberattaqueont tous deux souligné la difficulté de savoir si tous les organismes locaux avaient suivi les directives et si les organismes centraux avaient une visibilité suffisante pour garantir 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 les systèmes non pris en charge, 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 essentielles disposaient de procédures de repli sur papier ou hors ligne et que les canaux de remontée d’information survivaient à une panne numérique.

Ils pouvaient également documenter quand des préoccupations de risque clinique retardaient l’application des 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 les améliorations, imposer des échéances, recueillir des preuves d’assurance et mettre en place une réponse régionale aux incidents. NHS Digital, NHS England, le Department of Health et plus tard NHSX et des organismes connexes ont chacun joué un rôle dans l’environnement de préparation nationale. Laréflexion sur WannaCry un an après du National Cyber Security Centreet sesconseils sur l’atténuation des logiciels malveillants et des attaques par ransomwaremontrent comment les directives cyber centrales ont formulé 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 trusts locaux étaient responsables de leurs propres correctifs; les fournisseurs peuvent dire que des mises à niveau étaient disponibles sous réserve d’achat; les conseils d’administration peuvent dire que la demande clinique rendait les interruptions inacceptables. Chaque déclaration peut contenir une part de vérité. La responsabilité consiste à se demander 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. Le NAO a enregistré des rendez-vous annulés, des services de médecine générale perturbés, des détournements d’ambulances et des services de diagnostic affectés. Ces résultats sont indirects car le logiciel malveillant a attaqué des ordinateurs, pas des patients. Ils sont réels parce que 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 les services 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 importe pour la mesure de l’impact. Si une organisation ne compte que les paiements de rançon ou les fichiers corrompus, elle passe à côté du préjudice pour les services publics. Le NHS n’a pas payé de rançon, mais des patients ont perdu des rendez-vous et le service a tout de même subi des coûts de récupération. Certains systèmes ont été mis hors ligne par mesure de précaution, même là où il n’y avait pas eu d’infection. Certaines organisations ont dû annuler des soins parce qu’elles ne pouvaient pas faire confiance à l’environnement numérique.

D’autres ont pu continuer parce qu’elles avaient une meilleure segmentation ou des solutions de repli. Le préjudice a été réparti sur l’ensemble du service, et cette répartition est la leçon à en tirer.

Un bilan d’impact plus solide relierait les états techniques aux états de soins. Quels systèmes ont été infectés? Quels 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 résultaient de problèmes de capacité locale ou de confiance? Quels laboratoires, services d’imagerie et systèmes de dossiers ont été affectés? Quelles organisations ont maintenu les soins grâce à des solutions de repli testées?

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é.

Les travaux ultérieurs du NHS sur la cyber-résilience devraient donc être évalués en fonction de la continuité clinique. Il est utile de compter les appareils corrigés, la couverture des points terminaux et l’achèvement des formations cyber.

Il est plus utile de savoir si un trust peut poursuivre 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 réorienter les patients; et si les commandants d’incidents cyber peuvent prendre des décisions avec les responsables cliniques plutôt que de traiter l’événement comme un simple problème informatique.

La question des systèmes non pris en charge est une question de gouvernance

Les logiciels non pris en charge 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 assume le risque. Un trust peut conserver une vieille machine parce qu’un appareil clinique est coûteux à remplacer. Un fournisseur peut ne prendre en charge un appareil que sur une plate-forme ancienne. Un processus d’achat peut reporter le remplacement. Un conseil d’administration peut accepter un risque parce que le budget d’investissement est serré. Le patient, lui, ne ressent que la défaillance ultime de la continuité.

L’examen des leçons apprises du Royaume-Uni a traité les systèmes non pris en charge comme l’un des thèmes importants de remédiation. C’est juste, mais le statut de non prise en charge n’est pas le seul indicateur. Un système pris en charge mais non corrigé peut être vulnérable. Un système non pris en charge mais isolé, étroitement surveillé et dont le remplacement est programmé peut présenter un risque opérationnel plus faible qu’un système pris en charge sans propriétaire.

La question de gouvernance est de savoir si chaque actif à haut risque a un propriétaire nommé, un plan de cycle de vie, des contrôles compensatoires et une visibilité au niveau du conseil d’administration.

La technologie médicale et opérationnelle complique la question. Certains appareils cliniques ne peuvent pas être corrigés sans validation du fournisseur. Certains anciens systèmes prennent en charge 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 en tant qu’exceptions, et non cachées comme des opérations ordinaires.

Si une machine ne peut pas être corrigée, le dossier doit indiquer pourquoi, comment elle est isolée, combien de temps elle restera, quels services en dépendent et ce qui se passerait en cas de défaillance.

La leçon pour le secteur public du Royaume-Uni va au-delà du NHS. Les écoles, les conseils municipaux, la police, les organismes de transport et les services d’urgence ont tous quelque part de vieux logiciels. Le cas du NHS est frappant parce que les soins aux patients sont directs, mais le schéma de mode commun est plus large. Les services publics doivent pouvoir savoir quand de nombreux organismes locaux dépendent de la même technologie non prise en charge ou non corrigée, car un attaquant ou un ver ne respectera pas les frontières organisationnelles.

L’automatisation de la sécurité ne peut aider qu’une fois la propriété clairement établie

L’automatisation de la sécurité est tentante après WannaCry. Les outils de protection des points terminaux, les scanners de vulnérabilités, 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 que personne ne possède, un appareil clinique qui ne peut pas être corrigé, un réseau qui n’a jamais été cartographié ou un conseil d’administration qui considère les vieux logiciels 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 à des questions élémentaires. Quels appareils existent? Quels systèmes d’exploitation exécutent-ils? Lesquels ne sont pas pris en charge? Lesquels n’ont pas les correctifs critiques MS17-010 ou équivalents? Quels systèmes sont accessibles les uns depuis les autres? Lesquels sont connectés aux flux de travail cliniques? Lesquels sont exclus des analyses en raison de restrictions des fournisseurs? Quels organismes locaux présentent des lacunes inexpliquées? Ces réponses transforment un risque général en un registre géré.

La couche suivante est l’action. L’application automatisée des correctifs peut déployer des mises à jour lorsque cela est sûr. La gestion des vulnérabilités peut hiérarchiser les expositions critiques. La surveillance du réseau peut détecter un trafic de type ver. La détection aux points terminaux peut contenir les logiciels malveillants. Les systèmes de sauvegarde peuvent soutenir la récupération. Mais chaque action automatisée nécessite 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 appareil de diagnostic, cette exception doit déclencher l’isolement et la planification du remplacement plutôt qu’une tolérance indéfinie.

Lesconseils généraux du NCSC sur les ransomwaressont utiles car ils associent la prévention, la sauvegarde, la réponse aux incidents et la récupération. WannaCry montre pourquoi ces catégories vont de pair. Un service de santé ne peut pas traiter la résilience aux ransomwares comme un achat de produit unique. Il a besoin d’une gouvernance des correctifs, d’une segmentation, de sauvegardes, d’une éducation des utilisateurs, d’une récupération testée et d’une remontée clinique. La dépendance en mode commun ne disparaît que lorsque plusieurs mesures de protection se chevauchent.

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

Les patients n’ont pas besoin de l’adresse IP de chaque appareil vulnérable. Ils ont besoin d’avoir confiance que le service de santé a tiré les leçons 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 pris en charge, à quelle fréquence les exercices de continuité sont menés, à quelle vitesse les correctifs critiques sont appliqués et comment les conseils d’administration gèrent les exceptions.

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

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

Le bilan de la réparation devrait également distinguer la résilience de la réponse. La réponse consiste à savoir si le NHS peut détecter, contenir et se remettre d’un incident. La résilience consiste à savoir si l’incident peut être évité ou limité avant que les soins ne soient annulés. Les deux comptent. Un hôpital qui peut restaurer rapidement ses systèmes nuit tout de même aux patients si de nombreux rendez-vous sont annulés. Un hôpital qui empêche la propagation mais qui n’a pas de solution de repli peut tout de même être en difficulté lors d’arrêts défensifs.

La posture la plus solide 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 à fournir des soins urgents lorsqu’une faiblesse logicielle commune est exploitée? Ce critère oblige les dirigeants à poser des questions opérationnelles plutôt que purement 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 de manière sécurisée? Les soins primaires peuvent-ils maintenir suffisamment de services en fonctionnement?

Les organismes nationaux peuvent-ils coordonner rapidement les informations locales? 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é dramatique parce qu’il s’est propagé rapidement et mondialement. Le prochain événement de mode commun pourrait être plus discret. Cela pourrait être une mise à jour compromise, une panne d’identité cloud, une défaillance de certificat, un bogue dans la sécurité des points terminaux, une violation chez un fournisseur ou une vulnérabilité dans un logiciel médical largement utilisé. La leçon commune est que de nombreuses organisations locales de services publics peuvent dépendre de la même condition technologique sans se percevoir comme exposées conjointement.

Le NHS peut réduire ce risque en traitant la similitude technologique comme une exposition à mesurer. Si de nombreux trusts s’appuient sur le même système non pris en charge, c’est un risque de mode commun. Si de nombreux trusts ne peuvent pas corriger une classe d’appareils en raison de contraintes des fournisseurs, c’est un risque de mode commun. Si de nombreux organismes locaux dépendent du même produit d’accès à distance, du même fournisseur d’identité ou du même produit de sauvegarde, c’est un risque de mode commun. Le registre des risques ne devrait pas être uniquement local; il devrait agréger les schémas à travers le service.

La fonction d’approvisionnement a un rôle à jouer ici. Les contrats pour la technologie clinique et administrative devraient exiger un support du cycle de vie, une transparence des correctifs, la divulgation des vulnérabilités et des chemins de mise à niveau testés. Les allégations des fournisseurs devraient être liées aux obligations de continuité des soins. Un appareil qui ne peut pas être corrigé sans des mois de négociation n’est pas simplement 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 de mise à niveau réalisable.

Le rôle du conseil d’administration est tout aussi important. Les documents du conseil ne devraient pas se contenter de dire que le risque cyber est élevé. Ils devraient identifier les systèmes non pris en charge, les exceptions de correctifs, les dépendances critiques des services, les résultats des exercices et les contraintes non résolues avec les fournisseurs. Les dirigeants devraient être en mesure d’expliquer ce qui se passerait si une vulnérabilité à propagation automatique apparaissait demain.

Les responsables cliniques devraient être inclus car la priorité est la continuité des soins, et pas seulement la restauration de la technologie. Les responsables financiers devraient ê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 vieux système doit disparaître du jour au lendemain. C’est que les vieux logiciels deviennent dangereux lorsqu’ils sont invisibles, partagés et non gouvernés. Le bilan de responsabilité du NHS devrait donc être jugé selon que le risque lié aux vieux systèmes et aux correctifs est suffisamment visible pour agir avant que les patients ne le ressentent. Un correctif avait existé. Des directives avaient existé. La partie manquante était une préparation assurée à l’échelle du service. C’est pourquoi WannaCry reste un cas de dépendance en mode commun plutôt qu’un simple souvenir de ransomware.

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

L’une des raisons pour lesquelles l’application des 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 appareil d’imagerie, une machine de laboratoire ou une plate-forme de planification peut prendre en charge des soins en direct. Une mise à jour négligente peut interrompre le service, casser une configuration de dispositif validée ou obliger les équipes cliniques à des solutions de contournement dangereuses. Cette réalité devient souvent l’argument du retard.

La meilleure réponse en termes 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 lorsqu’elles sont manquées. Un trust doit savoir quels systèmes peuvent être mis à jour automatiquement, lesquels nécessitent une validation du fournisseur, lesquels exigent une approbation pour temps d’arrêt clinique et lesquels portent des contrôles compensatoires en attendant.

L’incident du NHS a montré que l’absence de gouvernance planifiée des correctifs peut entraîner des temps d’arrêt plus importants par la suite. 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 de façon répétée, le service de santé construit une exposition cachée. Un ver n’attend pas un calendrier clinique pratique. La question de responsabilité devient alors: les dirigeants ont-ils 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 de révision. Lorsque la même exception apparaît dans de nombreux trusts, les organismes nationaux doivent la traiter comme un risque partagé nécessitant un financement, une négociation avec le fournisseur ou un changement architectural.

Le langage plus large du gouvernement britannique sur la cyber-résilience après WannaCry a évolué dans cette direction. Le Cabinet Office et le NCSC ont régulièrement présenté la cybersécurité du secteur public comme une question de résilience opérationnelle, et leCyber Assessment Framework du NCSCdonne 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 sur WannaCry, mais c’est un moyen utile d’exprimer la leçon: la fonction pertinente est le soin des patients, et non la simple existence d’un système informatique. Les contrôles des correctifs et du cycle de vie doivent être jugés en fonction de leur contribution à cette fonction essentielle.

Les responsables cliniques ont donc leur place dans la gouvernance des correctifs. Un conseil purement technique peut savoir quelle mise à jour est manquante, 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 report indéfini. La décision a besoin des deux. Si un correctif ne peut pas être appliqué cette semaine parce qu’un appareil de diagnostic est très utilisé, le dossier doit indiquer ce qui protège cet appareil 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, elle doit devenir un risque au niveau du conseil d’administration plutôt qu’une note de service informatique.

Cette approche améliore également l’explication publique. Lorsqu’un autre incident cyber du NHS se produit, 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 étaient les plus importants, quels risques avaient été acceptés et quels services disposaient de plans de repli. Plus l’enregistrement des exceptions de correctifs est discipliné avant l’incident, plus l’explication publique peut être rapide après celui-ci.

Un service de santé ne peut pas partager chaque détail technique, 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 autoréplicative 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, il s’agit d’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 se poursuivent.

Si chaque partie de l’environnement fait confiance à toutes les autres, une vieille faiblesse peut devenir une interruption à l’échelle du service.

La segmentation doit également être utilisable en cas 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. Un trust doit savoir quelles connexions peuvent être fermées, quel effet clinique la fermeture a et comment les cliniciens travailleront si un service est isolé. Il 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 d’urgence?

Un cabinet de médecine générale peut-il continuer un service essentiel lorsque les systèmes centraux sont indisponibles? Une région peut-elle réorienter les patients lorsqu’un trust perd confiance dans les systèmes numériques? Ce sont des questions cyber uniquement parce qu’elles sont d’abord des questions de soins.

Le rapport du NAO a noté que certaines organisations avaient déconnecté des systèmes par précaution et que la communication entre les organisations avait été affectée. Cela signifie que la segmentation et les communications d’urgence sont liées. Si un trust isole des systèmes pour empêcher la propagation, il a toujours besoin de moyens sûrs pour communiquer avec les partenaires régionaux, les services d’ambulance, les organismes nationaux et les patients. Un canal de secours qui dépend du même réseau affecté n’est pas un secours. 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 en mode commun.

Une mesure utile de réparation est donc le « délai d’isolement sécurisé ». 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? Une autre mesure est le « délai 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 détournées?

Ces mesures sont plus significatives que le nombre d’échantillons de logiciels malveillants bloqués parce qu’elles relient l’action technique à la continuité des services publics.

La segmentation révèle également la dépendance envers les fournisseurs. Certains dispositifs cliniques et systèmes anciens sont difficiles à isoler parce qu’ils n’ont jamais été conçus pour les menaces réseau modernes. Les contrats devraient exiger que les fournisseurs prennent en charge le fonctionnement sécurisé, la capacité de correction, la journalisation et la séparation du réseau. Si un fournisseur ne peut pas faire en sorte qu’un dispositif prenne en charge une segmentation sûre, l’acheteur devrait le savoir avant l’achat.

Si un dispositif ancien subsiste, le risque devrait être visible dans l’approvisionnement, la gouvernance clinique et l’assurance cyber. C’est ainsi que les anciens équipements cessent d’être une exposition cachée en mode commun.

Les leçons doivent être mesurées à l’échelle de l’ensemble du service

Après WannaCry, les améliorations individuelles sont nécessaires mais insuffisantes. Un trust peut devenir plus solide alors que le service dans son ensemble reste exposé si de nombreux autres trusts partagent la même faiblesse. La leçon du mode commun exige une mesure agrégée.

Les dirigeants nationaux devraient être en mesure de répondre combien d’organisations ont des systèmes critiques non pris en charge, combien de vulnérabilités critiques dépassent les échéances de correctifs, combien de trusts ont testé la continuité face aux ransomwares au cours de l’année écoulée, combien de contraintes fournisseurs bloquent l’application des correctifs et combien d’exceptions locales n’ont pas de chemin de remplacement financé.

Le NHS Data Security and Protection Toolkit, accessible via leportail toolkit de NHS England, est un mécanisme de collecte d’auto-évaluation et d’informations d’assurance. L’auto-évaluation ne suffit pas à elle seule, mais elle fournit une structure pour comparer les organisations et escalader les lacunes. Des tests indépendants, des exercices régionaux, l’assurance du conseil d’administration et un financement ciblé devraient l’accompagner. Le risque est qu’une liste de contrôle devienne un objet de confort plutôt qu’un contrôle. La question devrait toujours être de savoir si la conformité déclarée protégerait effectivement les soins aux patients lors d’une vulnérabilité à propagation automatique.

Le Bureau du commissaire à l’information (Information Commissioner’s Office) importe également car le risque pour les données de santé fait partie intégrante du même tableau de continuité. Les conseils de l’ICO sur lasécurité au titre du RGPD britanniquemettent l’accent sur les mesures techniques et organisationnelles appropriées. WannaCry n’est pas principalement resté dans les mémoires pour l’exfiltration de données, mais les ransomwares et les logiciels malveillants destructeurs peuvent toujours affecter la confidentialité, l’intégrité et la disponibilité. Dans les soins de 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é devrait donc traiter la disponibilité comme un devoir envers les patients, et pas seulement comme un objectif de service informatique.

La mesure devrait inclure le risque résiduel, pas seulement les réussites. Si un trust 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 un trust dispose d’outils de protection des points terminaux solides mais d’une continuité hors ligne faible, cette lacune compte. Si un trust 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 un trust a de bons plans mais pas d’exercice récent, le plan reste non prouvé.

Un service de santé qui ne rend compte 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 exigerait un isolement local, des décisions régionales sur le flux de patients, des communications nationales, une escalade chez le fournisseur, 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 voisines.

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

Le NHS devrait également comparer la continuité cyber avec les autres disciplines de préparation en santé publique. Les systèmes de santé planifient déjà pour la pression hivernale, les maladies infectieuses, les actions syndicales et les incidents majeurs. La perturbation cyber devrait figurer à côté de ces risques, car elle peut supprimer des capacités, des informations ou de la coordination au moment même où la demande est élevée. Un exercice cyber qui n’atteint jamais le commandement opérationnel passe à côté de l’essentiel.

Un exercice clinique d’incident majeur qui suppose que tous les systèmes numériques sont disponibles passe à côté de l’essentiel dans l’autre sens.

La responsabilité appartient à ceux qui peuvent réduire le temps d’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 connu et à propagation automatique 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 pris en charge sont-ils restés sans contrôle compensatoire? Combien de temps a-t-il fallu pour rétablir 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 d’administration approuvent l’appétence au risque et les budgets. Les responsables cliniques approuvent les temps d’arrêt et les priorités de remplacement. Les équipes d’approvisionnement choisissent les fournisseurs et les conditions de support. Les organismes nationaux fixent les normes et contrôlent 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 anciennes fragiles. La responsabilité ne doit pas réduire toute cette complexité à la personne qui était censée appliquer un correctif un jour donné.

La responsabilité ne doit pas non plus se dissoudre dans la complexité. Si tout le monde est impliqué, il faut quand même que quelqu’un agisse. Une norme nationale devrait définir ce qu’est une bonne pratique. Un conseil d’administration local devrait savoir s’il respecte la norme. Un fournisseur devrait savoir si son produit prend en charge la norme. Un régulateur ou un auditeur devrait savoir si les déclarations correspondent aux preuves. Un patient devrait savoir que le système a tiré les leçons d’une défaillance passée. La dépendance en mode commun diminue lorsque chaque couche réduit le temps d’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 manière dont les vieux logiciels, la gouvernance non testée des correctifs, la préparation locale inégale et les lacunes d’assurance centrale peuvent se combiner pour nuire au service public. L’exploit exact peut s’estomper. Le schéma de dépendance reste. Si le NHS peut démontrer qu’il voit, gouverne, exerce et finance désormais ces dépendances à travers l’ensemble du service, alors WannaCry devient une leçon durement assimilée.

Sinon, il reste un avertissement en attente d’un nouveau déclencheur.

La norme finale de responsabilité est donc la preuve d’une exposition partagée réduite. Un trust qui remplace un vieux serveur améliore sa position locale. Un service national qui peut prouver que les actifs critiques non pris en charge sont connus, que les exceptions sont financées, que les fournisseurs sont responsables, que les correctifs sont ponctuels, que la segmentation est testée et que le repli clinique fonctionne a changé le système. La différence importe parce que les patients ne choisissent pas quelle organisation locale se trouve être la plus solide le jour où un ver arrive.

Ils dépendent du service de santé en tant qu’institution publique. Le devoir est de rendre visible la dépendance commune la plus faible avant qu’elle ne devienne la prochaine raison pour laquelle les soins sont annulés.

Cette norme maintient également l’équité de l’analyse. Elle ne prétend pas que tout risque peut être éliminé. Les soins de santé impliqueront toujours des dispositifs spécialisés, des budgets contraints, des calendriers cliniques urgents et des relations complexes avec les fournisseurs. Elle insiste sur le fait que ces contraintes doivent être régies de manière suffisamment ouverte pour que les dirigeants puissent agir. Une machine non corrigée et cachée est un problème technique. Une exception connue, attribué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 n’est peut-être pas le nombre d’attaques bloquées. C’est peut-être le nombre de services cliniques essentiels qui peuvent continuer à fonctionner pendant qu’une faiblesse technologique partagée est contenue. Ce chiffre relierait la cybersécurité à la promesse de service sur laquelle les patients comptent réellement. Le NHS ne doit pas au public un réseau parfait. Il lui doit la preuve qu’une faille dans un vieux logiciel ne peut pas silencieusement devenir une défaillance des soins en mode commun, 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 la perturbation a déjà accepté trop d’incertitude. Un service qui peut les lister, les isoler, financer leur remplacement et répéter des soins dégradés a transformé le problème des vieux logiciels en un travail de continuité gouverné.

Typographie

La typographie est l’art et la technique d’agencer les caractères pour rendre le langage écrit lisible, compréhensible et visuellement attrayant. Elle implique le choix des polices, des tailles de points, des longueurs de ligne, de l’interlignage et de l’espacement des lettres.

• La typographie est née avec l’invention des caractères mobiles par Johannes Gutenberg au XVe siècle.
• Les éléments clés comprennent le choix de la police, le crénage, l’approche et l’interlignage.
• Une bonne typographie améliore la lisibilité et transmet une ambiance ou un ton dans le design.