Il y a un peu plus d’une semaine, j’ai rédigé un article sur ce qui semblait être une défaillance mondiale des services de Microsoft, en me demandant ce que les entreprises devraient faire lorsque l’infrastructure sur laquelle elles comptent échoue.
À ce moment-là, le monde subissait des impacts majeurs dans les secteurs du transport, de la finance, du commerce de détail et d’autres systèmes, bien que le Royaume-Uni ait semblé échapper à cet incident relativement indemne, à l’exception des difficultés rencontrées par ceux qui tentaient de prendre un rendez-vous chez un médecin généraliste.
Il est rapidement devenu évident que le problème ne provenait pas du service Azure de Microsoft, comme cela avait d’abord été supposé, mais d’un fournisseur de logiciels unique, CrowdStrike, qui avait publié une mise à jour défectueuse de son logiciel, laquelle a été diffusée rapidement à travers le monde via les réseaux mondiaux d’Azure.
Selon Computer Weekly, ce « mauvais patch » a été disponible en ligne pendant 78 minutes, et durant ce laps de temps, il a été distribué à 8,5 millions de machines Microsoft qui se sont retrouvées bloquées dans un cycle de démarrage et sont devenues inutilisables.
Une fois qu’il a été établi que la source des problèmes n’était pas une cyberattaque organisée par des individus inconnus, la situation a commencé à se stabiliser.
L’impact sur les entreprises touchées et le grand public a été, dans certains cas, considérable, mais en ce qui concerne les pannes des hyperscalers, la mémoire collective est courte, et les choses sont rapidement revenues à la normale.
Technologie Une autre panne ?
Cependant, le 30 juillet 2024, les services cloud de Microsoft ont subi une nouvelle panne, affectant des entreprises à l’échelle mondiale, et encore une fois, sans aucun avertissement.
Cependant, cette panne n’avait rien à voir avec le fiasco de CrowdStrike en termes de cause, d’impact ou même d’implications.
Ce dernier incident met en lumière un problème fondamental : notre dépendance à des services cloud qui pourraient ne pas être aussi fiables qu’on le pense.
Mais avant d’approfondir les raisons pour lesquelles ces deux pannes étaient différentes, examinons d’abord les caractéristiques essentielles de la sécurité informatique.
Les professionnels de la sécurité informatique s’efforcent d’identifier et de gérer les risques liés aux données et aux systèmes informatiques, en tenant compte de trois caractéristiques clés : la confidentialité, l’intégrité et la disponibilité.
Maintenir ces caractéristiques dans des plages définies et acceptables est l’essence même de la cybersécurité.
Il est pratiquement impossible de maintenir un équilibre parfait entre confidentialité, intégrité et disponibilité. De plus, chaque organisation a besoin d’un mélange différent de ces trois éléments pour fonctionner de manière optimale.
Il est courant que les experts en sécurité informatique se concentrent sur la confidentialité comme étant la plus grande préoccupation, et en effet, le Schéma de classification de la sécurité du gouvernement britannique se concentre principalement sur l’attribution de classifications à la confidentialité des données. Cependant, dans certains cas, la confidentialité peut être le facteur le moins important, tandis que l’intégrité et la disponibilité revêtent une importance capitale.
Considérons l’exemple des pompiers. Lorsqu’un incendie est signalé, il est crucial que l’emplacement de l’incendie soit aussi précis que possible, et que les pompiers sur le terrain communiquent de manière claire pour s’assurer qu’ils obtiennent les ressources nécessaires pour combattre le feu.
Dans cet exemple, l’intégrité et la disponibilité sont des priorités élevées, tandis que garder l’incendie secret est peu probable.
Ce dont nous avons besoin, si nous voulons garantir la sécurité informatique, c’est d’une forme de ces trois éléments. Et lorsque l’équilibre n’est pas respecté, cela pose problème.
Technologie Panne contre violation
Les médias utilisent deux termes différents pour décrire ces problèmes, selon la caractéristique qui est compromise. Une perte de confidentialité est généralement qualifiée de violation, tandis qu’une perte d’intégrité ou de disponibilité est souvent appelée panne.
Cela décrit les effets visibles du compromis, mais pas toujours la cause du problème. C’est pourquoi les deux rapports sur les pannes de Microsoft en un peu plus d’une semaine doivent être considérés séparément.
Bien qu’ils puissent sembler identiques aux yeux du public et être mentionnés de la même manière dans la presse, il s’agit de phénomènes différents, et comprendre cela est à la fois important et nécessaire pour tirer des leçons de chaque incident.
L’incident de CrowdStrike a entraîné une perte d’intégrité d’un fichier unique dans son logiciel, ce qui a conduit à une perte de disponibilité du service global.
En revanche, l’incident du 30 juillet ne semble pas du tout être le même. Bien qu’il ait été de courte durée, ne durant que quelques heures, après quoi la plupart des services sont revenus en ligne sans trop de dommages, il pourrait en réalité être beaucoup plus sérieux.
La dernière « panne » a été une perte générale et répandue de disponibilité des services de mise en réseau de Microsoft pour son service Azure mondial, apparemment causée par un »pic d’utilisation », ce qui pourrait être un euphémisme de Microsoft pour une attaque par déni de service (DoS) orchestrée par un acteur malveillant inconnu.
Une attaque DoS se produit lorsqu’un utilisateur (généralement malveillant) consomme toutes les ressources de service disponibles, laissant rien pour les autres.
Tant que l’attaquant conserve ces ressources, le service restera inaccessible pour ses utilisateurs légitimes. Pendant ce temps, l’entreprise ou l’utilisateur touché sera généralement incapable de fonctionner.
Les attaques par déni de service représentent des menaces majeures pouvant entraîner des situations financières graves et des risques pour la vie, et d’importants moyens sont investis pour prévenir leur survenue, ce que Microsoft gère généralement assez bien.
Cependant, cette fois-ci, il semble qu’il y ait eu un dysfonctionnement, ce qui pourrait être dû à un échec des mesures de sécurité mises en place pour stopper ces attaques.
Ou il se pourrait simplement que les attaquants aient trouvé un moyen d’intensifier leur attaque.
Technologie Le timing est crucial
Le timing de l’attaque n’aurait pas pu être plus mal choisi pour Microsoft, survenant le jour même où ils annoncent leurs résultats financiers aux investisseurs.
Cela renforce la crédibilité des suggestions selon lesquelles il s’agissait d’une attaque ciblée, et non d’une erreur accidentelle ou d’une mauvaise pratique administrative.
Microsoft a connu une mauvaise journée, mais il est probable qu’ils la mettent rapidement derrière eux et reprennent leurs activités habituelles. Il est fort probable que de nombreux utilisateurs en fassent de même.
Le problème, bien sûr, est que les systèmes informatiques échouent, et ils échouent plus souvent que beaucoup d’entre nous ne veulent l’admettre. Pour les services d’urgence, de tels échecs sont littéralement une question de vie ou de mort pour le public, et beaucoup de réflexion a été consacrée à la création de systèmes informatiques résilients au sein de ces groupes et organisations sur lesquels nous comptons pour notre sécurité.
Pendant environ 20 ans, c’était mon métier : j’ai travaillé sur l’architecture, la construction et l’assurance de ces services afin que, lorsque tout autour d’eux s’effondrait en période de crise, ils continuent de fonctionner.
Jusqu’à il y a quelques années, cela était géré par des investissements dans des systèmes nationaux et des réseaux dédiés de police et autres services d’urgence qui fonctionnaient selon des conditions commerciales spéciales avec un groupe spécifique de fournisseurs britanniques approuvés, expérimentés dans la fourniture de systèmes informatiques « sans échec ».
De plus, chaque force et service opérait sous un mécanisme d’entraide, où chaque force de police, chaque service d’ambulance ou de pompiers avait des relations avec leurs homologues voisins pour s’assurer que si leurs propres systèmes échouaient, quelqu’un d’autre prendrait le relais immédiatement et sans dégradation de service.
Cela fonctionnait également dans les cas où l’incident local était si grave qu’un intervenant local devait engager toutes ses ressources pour gérer cet incident et devait demander de l’aide ailleurs, avec des systèmes gérant ces circonstances. Le National Mutual Aid Telephony (NMAT) et le Casualty Bureau (CasWeb) en sont deux exemples.
Ces systèmes étaient conçus en tenant compte des échecs, afin de garantir que lorsque des systèmes échouaient, quelqu’un serait toujours en mesure de répondre à l’urgence.
À ce stade, je ne dis pas que notre capacité nationale à le faire a été complètement dégradée, et ceux qui en sont responsables aujourd’hui soutiendront certainement le contraire.
Cependant, il est indéniable que, ces cinq dernières années, la police (ainsi que les pompiers et les ambulances, ainsi que d’autres secteurs critiques) ont transféré des services vers les clouds hyperscale d’Amazon Web Services (AWS) et de Microsoft, sans tenir compte de la capacité de réponse critique si ces services échouent.
Plutôt que de considérer la possibilité de ces systèmes échouant, les décideurs ont choisi de supposer qu’ils resteraient disponibles en toutes circonstances, même s’ils sont des produits de consommation courante utilisés par le grand public et n’ont pas de conditions spéciales ou de priorisation.
Cela a inévitablement introduit des risques dans notre résilience nationale que nous n’avons jamais rencontrés auparavant.
L’utilisation du cloud de Microsoft pour héberger des services critiques et de sécurité publique est principalement due au fait que nos responsables informatiques des services d’urgence et d’infrastructure nationale critique n’ont pas pris le temps de lire les petites lignes des Conditions de licence universelles de Microsoft pour leurs services en ligne et de sa politique d’utilisation acceptable.
Celles-ci identifient clairement que les services en ligne de Microsoft, dont Azure et M365 font partie, ne sont pas conçus pour un « usage à haut risque » et ne devraient pas être utilisés comme tel.
« Ni le client, ni ceux qui accèdent à un service en ligne par le biais du client, ne peuvent utiliser un service en ligne dans une application ou une situation où l’échec du service en ligne pourrait entraîner la mort ou des blessures graves pour quiconque, ou des dommages physiques ou environnementaux graves, sauf conformément à la section sur l’usage à haut risque ci-dessous », stipulent les termes.
La section sur l’usage à haut risque précise : « Les services en ligne ne sont pas conçus ni destinés à soutenir un usage dans lequel une interruption de service, un défaut, une erreur ou un autre échec d’un service en ligne pourrait entraîner la mort ou des blessures graves pour quiconque ou des dommages physiques ou environnementaux. »
Les dirigeants qui ont choisi d’utiliser ces services ont soit négligé de faire leur diligence raisonnable, soit choisi d’accepter des risques que leurs prédécesseurs n’auraient jamais acceptés et qui pourraient même ne pas respecter leurs obligations légales.
Ce travail a été sanctionné au plus haut niveau, étant largement financé par le ministère de l’Intérieur et facilité par leurs programmes, ainsi que par le Service numérique de la police, avec le soutien du Conseil national des chefs de police et du Commissaire à la police et à la criminalité.
L’adoption de nouveaux services cloud publics a apporté des capacités basées sur des commodités nécessaires pour rationaliser et moderniser la gestion des données policières.
Cependant, en plus des problèmes juridiques déjà abordés en profondeur par Computer Weekly, ils pourraient également avoir exposé le Royaume-Uni à des risques critiques pour la sécurité publique qui n’ont pas été correctement pris en compte.
Microsoft ne peut pas totalement échapper à sa responsabilité ici, même avec ses clauses de limitation de responsabilité dans sa politique d’utilisation acceptable (AUP).
Étant donné les relations directes de l’entreprise avec le Service numérique de la police et des forces clés, il est clair que l’entreprise sait que sa politique d’utilisation acceptable est enfreinte et a peut-être joué un rôle dans cette violation par les utilisateurs policiers.
Nous parlons souvent d’œufs et de paniers comme une métaphore pour exposer des risques critiques pour la sécurité, mais il existe des preuves croissantes que, au Royaume-Uni, nous avons peut-être déjà fait cela, ou du moins que nous sommes sur le point de le faire.
Deux forces (la police métropolitaine et la police du nord du Pays de Galles) ont annoncé ces dernières années qu’elles prévoyaient de transférer leurs services de salle de contrôle vers le cloud public Azure, et j’ai examiné la sagesse ou non de cela par le passé.
Ce qui est clair, c’est que quiconque est désormais responsable d’initiatives comme celles-ci au sein de notre nouveau gouvernement - et en effet pour l’adoption plus large du cloud public par les services nationaux critiques du Royaume-Uni – doit prendre pleinement conscience des problèmes rencontrés par les systèmes de Microsoft le 30 juillet 2024.
À tous égards, si les services essentiels du Royaume-Uni n’ont pas été touchés hier, cela signifie qu’une autre balle a été évitée.
Cependant, cette fois-ci, il y a des indications que celle-ci pourrait avoir été tirée par un acteur malveillant, et si tel est le cas - pour la première fois – il faut considérer que le service cloud »toujours disponible » de Microsoft pourrait être tout aussi vulnérable aux pannes de disponibilité.
Comme il a déjà montré qu’il était plus faible que prévu en matière de compromis d’intégrité et de confidentialité.
La balle évitée cette fois pourrait bien provenir d’un attaquant qui vient de trouver une mitrailleuse DoS qu’il peut déchaîner sur Azure quand il le souhaite.
Je suis certain qu’aux États-Unis, les dirigeants de Microsoft seront convoqués dans des comités gouvernementaux pour expliquer les circonstances de cet incident mondial dans les jours à venir.
Je suis également sûr que sous l’administration précédente, le Royaume-Uni n’aurait pas agi de la même manière.
J’espère que ce nouveau gouvernement sera plus avisé et réalisera que, tout comme les problèmes de surpopulation carcérale et de situation financière qu’ils prétendent avoir découverts en prenant leurs fonctions, nous faisons face à une autre crise possible dans le cloud public pour les services critiques.
Microsoft devrait être convoqué dans un comité parlementaire britannique ou un autre comité de surveillance publique dès que possible pour expliquer tout ce qui a été abordé aux États-Unis au nouveau gouvernement et au public britannique.
Cela ne doit pas être un exercice de mise à mort ou de honte publique – c’est une occasion d’apprendre des leçons, à partir desquelles nous pourrions choisir de prendre un chemin différent pour nos fournisseurs de services d’infrastructure nationale critique.
Si après cela, le gouvernement britannique ne le fait pas, alors cela ne pose pas de problème, car ce sera une décision éclairée sur les risques pour laquelle le nouveau gouvernement aura pris la responsabilité.
Aujourd’hui, ils font face au risque politique plus important d’être laissés avec le fardeau lorsque la musique s’arrête, et d’être tenus responsables des échecs du gouvernement précédent qu’ils ont simplement choisi de ne pas examiner ou corriger, ce qui pourrait être pire.
Quoi qu’il en soit, le perdant dans une telle situation est le public britannique, qui dépend de services qui ne doivent pas échouer, mais qui reposent de plus en plus sur des plateformes inadaptées à la fourniture de services critiques.
