Microsoft Storm-0558 et la défaillance de clé de signature qui a fait de l'identité cloud un problème de responsabilité publique

Résumé

• Storm-0558 n'a pas vaincu les contrôles de mot de passe d'une agence fédérale. Il a utilisé une clé de signature grand public Microsoft pour fabriquer des jetons d'identité apparemment valides, puis a profité d'un défaut de validation de Microsoft qui permettait à ces jetons signés par une clé grand public d'accéder à la messagerie Exchange Online d'entreprise.
• Le chemin d'acquisition de la clé reste non résolu. L'explication de Microsoft de septembre 2023 basée sur un fichier de vidage mémoire a ensuite été réduite à une hypothèse principale après que la société a reconnu n'avoir trouvé ni fichier de vidage contenant la clé ni journaux prouvant l'exfiltration. La clé périmée, le défaut de validation interdomaine, la faible détection d'anomalies sur les jetons et la rétention limitée des preuves sont des conclusions de défaillance mieux étayées.
• La responsabilité suit la capacité de contrôle. Microsoft seul pouvait faire tourner la clé de plateforme, corriger le validateur côté service, détecter les combinaisons de jetons impossibles dans son cloud, conserver les preuves internes pertinentes et fermer le vecteur d'attaque. Les clients pouvaient améliorer la surveillance et la réponse, mais en 2023, la télémétrie décisive MailItemsAccessed était liée aux licences E5/G5 plus coûteuses.

Une défaillance de contrôle d'identité, pas une violation de boîte aux lettres conventionnelle

L'intrusion Storm-0558 est facile à résumer en une phrase familière: des pirates chinois ont volé une clé Microsoft et lu des courriels gouvernementaux. Cette phrase est approximativement vraie et analytiquement insuffisante. Elle fusionne l'acte de l'attaquant, la perte non résolue de matériel cryptographique par Microsoft, une faille de validation logicielle distincte, une décision de cycle de vie concernant une clé périmée, un succès de détection côté client et une réponse du fournisseur de services en un seul événement. Une fois ces mécanismes séparés, l'attribution des responsabilités devient beaucoup plus claire.

L'intrusion n'était pas principalement un cas où un employé gouvernemental aurait cédé son mot de passe, une agence n'aurait pas déployé l'authentification multifacteur, ou un serveur non corrigé se trouvant dans un ministère. Storm-0558 possédait la moitié privée d'une clé de signature grand public de compte Microsoft (MSA) créée en 2016. Une clé de signature privée permet à son détenteur de produire des jetons dont les signatures peuvent être vérifiées par rapport à la clé publique correspondante. L'acteur pouvait donc revendiquer des identités sans obtenir les mots de passe des victimes. Un deuxième défaut de Microsoft permettait à une clé destinée aux comptes grand public d'authentifier des demandes auprès d'Exchange Online d'entreprise. Le résultat était une capacité d'usurpation d'identité au niveau de la plateforme qui franchissait la frontière entre les systèmes d'identité grand public et organisationnels de Microsoft.

L'analyse technique de Microsoft de juillet 2023explique le mécanisme de base: l'acteur a falsifié des jetons Azure Active Directory avec la clé grand public acquise, utilisé un flux Outlook Web Access légitime, obtenu des jetons Exchange Online via l'interface GetAccessTokenForResource et récupéré des courriels via l'API OWA. Microsoft a déclaré qu'un défaut de conception permettait également à l'acteur d'obtenir de nouveaux jetons d'accès en présentant un jeton précédemment émis par cette interface. Ce n'était pas simplement une relecture de justificatif d'identité volé. C'était la fabrication et le renouvellement non autorisés de justificatifs d'identité que les services de Microsoft traitaient comme valides.

Cette distinction est importante pour la responsabilité dans le cloud. Les clients restent généralement responsables de leurs identités, de l'hygiène des appareils, des autorisations, de la configuration des applications et de la réponse aux incidents. Mais un client ne peut pas inspecter ou faire tourner le matériel de signature racine d'un fournisseur cloud, corriger le validateur de jetons en production du fournisseur, ni déployer un détecteur dans le plan d'émission d'identité du fournisseur. Lorsque la défaillance provient de contrôles disponibles uniquement pour le fournisseur, décrire l'événement comme un problème de responsabilité partagée sans préciser qui contrôlait quelle protection obscurcit plus qu'il n'explique.

Il est également important de ne pas classer à tort l'événement comme une panne de service. Les archives publiques ne montrent pas qu'Exchange Online soit devenu indisponible pour les agences touchées. Le préjudice a été une perte de confidentialité et de communications de confiance, suivie d'une charge d'enquête substantielle. La continuité du secteur public comprend plus que le maintien de l'accessibilité d'un service. Le travail diplomatique, économique, législatif et de sécurité nationale dépend de la capacité des responsables à utiliser un système de communication sans qu'un adversaire ne le lise silencieusement. Un cloud peut rester techniquement « opérationnel » tandis que la fonction publique qu'il soutient devient moins digne de confiance.

Ce qui est établi, ce qui est inféré et ce qui reste inconnu

Trois catégories de preuves doivent rester distinctes.

Premièrement, les archives publiques établissent fermement que Storm-0558 a utilisé une clé de signature grand public MSA de 2016 créée par Microsoft pour falsifier des jetons; qu'un défaut de validation de Microsoft a permis à ces jetons d'accéder à des comptes Exchange Online d'entreprise; que le State Department a trouvé une activité suspecte grâce à des journaux améliorés d'accès aux boîtes aux lettres; et que Microsoft a atténué la technique connue par une séquence de modifications côté service. Les divulgations de Microsoft, l'avis de réponse de la CISA, les déclarations des agences touchées et la reconstruction du Cyber Safety Review Board convergent sur ces points.

Deuxièmement, le Cyber Safety Review Board, ou CSRB, a formulé des conclusions sur la prévisibilité, la conception des contrôles, la culture de sécurité, la divulgation et les pratiques du secteur. Sonexamen complet de l'intrusion de l'été 2023a conclu que l'incident était évitable et n'aurait jamais dû se produire. Le comité a interrogé 20 organisations, a reçu la coopération de Microsoft, a comparé les contrôles d'autres grands fournisseurs de services cloud et a constaté une cascade de défaillances évitables. Ce sont des conclusions d'examen indépendant, pas des conclusions judiciaires, mais elles sont nettement plus solides qu'un commentaire fondé uniquement sur les premiers blogs de Microsoft.

Troisièmement, la manière exacte par laquelle Storm-0558 a obtenu la clé privée de 2016 reste inconnue dans les archives publiques. Cette incertitude est centrale. Microsoft a publié un récit détaillé basé sur un fichier de vidage mémoire en septembre 2023, puis a ajouté une correction en mars 2024 indiquant qu'il n'avait pas trouvé de fichier de vidage contenant le matériel de clé concerné. Le CSRB a signalé que Microsoft a exploré 46 hypothèses de vol de clé et ne savait toujours pas comment ni quand l'acteur avait obtenu la clé. Tout récit qui présente le fichier de vidage comme la cause profonde avérée surestime les preuves.

Les dossiers n'établissent pas non plus une attribution juridique définitive des pertes. L'examen du Congrès, les demandes d'enquête et l'acceptation par Microsoft des conclusions du CSRB sont pertinents pour la responsabilité. Ils ne remplacent pas un jugement judiciaire, une décision d'application d'une agence, une interprétation contractuelle ou une analyse chiffrée des dommages. La conclusion appropriée est plus étroite: Microsoft contrôlait plusieurs garanties défaillantes et a accepté la responsabilité des problèmes cités par le CSRB; les sources disponibles n'établissent pas de responsabilité civile, pénale ou réglementaire définitive.

Chronologie médico-légale

2016-2021: une clé à longue durée de vie et une migration différée

Microsoft a créé la clé de signature grand public en 2016. L'âge d'une clé n'est pas en soi une preuve d'insécurité, mais il devient important lorsqu'une organisation ne peut pas démontrer avec confiance une garde continue et lorsque la rotation limite la durée de vie utile du matériel volé. Le CSRB a constaté que le système MSA grand public de Microsoft reposait sur une rotation manuelle, tandis que son système d'identité d'entreprise s'était orienté vers l'automatisation. L'entreprise avait l'intention de migrer le système grand public vers la technologie automatisée, mais n'avait pas terminé ce travail avant l'intrusion.

Selon le CSRB, Microsoft a arrêté la rotation manuelle des clés de signature grand public en 2021 après une panne majeure du cloud associée au processus manuel. Il n'a pas déployé ensuite un remplacement de rotation automatisée ni une alerte qui avertirait les équipes responsables des clés actives vieillissantes. La clé de 2016 est donc restée acceptée en 2023. C'est une décision classique de compromis entre disponibilité et sécurité avec un coût différé caché: suspendre une procédure manuelle risquée peut réduire le risque de panne immédiat, mais laisser l'automatisation compensatoire inachevée préserve l'exposition à la sécurité indéfiniment.

La conclusion du comité est plus utile que de simplement dire qu'une clé « expirée » a fonctionné. Une clé est acceptée ou rejetée selon la configuration de confiance en direct du service. La défaillance cruciale était qu'une clé destinée à être retirée restait dans l'ensemble de confiance. Lesconseils actuels de Microsoft sur le renouvellement des clés de signatureindiquent que les applications doivent gérer le renouvellement périodique et d'urgence par programme et recommandent des bibliothèques standard pour éviter des défauts subtils. Ces conseils décrivent le comportement de validation côté client, mais le principe sous-jacent s'applique plus largement: le remplacement des clés doit être une capacité technique, pas une cérémonie fragile qui devient trop risquée à réaliser.

En septembre 2018, Microsoft a introduit un point de terminaison commun pour la publication des métadonnées de clé en réponse à la demande d'applications servant à la fois les utilisateurs grand public et les utilisateurs d'entreprise. Le récit ultérieur de Microsoft indiquait que la documentation avait été mise à jour pour expliquer la validation de la portée de la clé, mais les bibliothèques d'aide n'avaient pas été mises à jour pour appliquer cette portée automatiquement. Les systèmes de messagerie Exchange ont commencé à utiliser le point de terminaison de métadonnées commun en 2022. Les développeurs ont supposé que la bibliothèque effectuait une validation complète et n'ont pas ajouté la vérification requise de l'émetteur ou de la portée. Le point de terminaison commun a donc augmenté l'interopérabilité tout en créant un risque de frontière de confiance: la validité cryptographique a été confondue avec l'autorisation dans le domaine d'identité correct.

La reconstruction du CSRB place un autre événement pertinent en 2021. Storm-0558 a compromis le réseau d'entreprise de Microsoft via le compte d'un ingénieur entre avril et août. L'ingénieur travaillait pour Affirmed Networks, que Microsoft avait acquise en 2020; Microsoft pensait que l'appareil avait été compromis avant l'acquisition et s'était ensuite connecté à l'environnement de Microsoft avec des identifiants d'entreprise. L'acteur a capturé et rejoué un jeton d'authentification et a accédé à du matériel dans SharePoint, notamment des informations liées à la gestion des services Azure et à l'identité. Le comité a critiqué Microsoft pour ne pas avoir détecté l'appareil compromis de la société acquise avant de l'autoriser sur le réseau d'entreprise.

Cette compromission de 2021 est une preuve de l'accès et de l'intérêt de l'attaquant. Ce n'est pas une preuve que l'acteur a alors obtenu la clé MSA de 2016. Microsoft a déclaré au comité que l'intrusion de 2021 était probablement liée parce que c'était la seule autre intrusion connue de Storm-0558 dans le réseau de Microsoft en mémoire enregistrée, mais la société n'a produit aucune preuve spécifique la liant au vol de clé. Un récit rigoureux doit préserver cette lacune.

Mai-juin 2023: l'accès commence avant que le fournisseur ne le détecte

Storm-0558 a établi une infrastructure externe identifiée et a commencé à accéder à des comptes Exchange Online ciblés le 15 mai 2023. Le CSRB a averti que la fenêtre de compromission aurait pu commencer plus tôt, car la rétention standard des journaux de 30 jours de Microsoft limitait la vue rétrospective disponible une fois l'enquête lancée. « Première observation » est donc une limite de preuve, pas nécessairement le véritable début de l'attaque.

Les cibles reflétaient les priorités d'espionnage. Le décompte final du CSRB a identifié 22 organisations et plus de 500 individus dans le monde, y compris des victimes aux États-Unis, au Royaume-Uni et ailleurs. Les comptes incluaient ceux de la secrétaire au Commerce Gina Raimondo, de l'ambassadeur des États-Unis en Chine R. Nicholas Burns, du secrétaire adjoint d'État aux affaires de l'Asie de l'Est et du Pacifique Daniel Kritenbrink et du représentant Don Bacon. L'avis d'incident initial de Microsoft du 11 juilletfaisait référence à environ 25 organisations et des comptes grand public liés. La différence est mieux traitée comme un changement dans la comptabilisation des incidents entre un avis précoce de l'entreprise et la reconstruction indépendante ultérieure, et non comme la preuve d'une nouvelle intrusion.

Le State Department, et non Microsoft, a détecté la campagne. Le 15 juin, le centre des opérations de sécurité du State Department a observé des anomalies. Le 16 juin, une règle personnalisée connue en interne sous le nom de Big Yellow Taxi a généré des alertes à partir de l'événement d'audit MailItemsAccessed, qui enregistre l'accès aux éléments de boîte aux lettres Exchange Online. Le State Department a enquêté malgré la possibilité de faux positifs et a contacté Microsoft ce jour-là. Le 19 juin, le State Department avait déterminé que six comptes avaient été consultés, y compris des comptes associés aux préparatifs du voyage de la secrétaire d'État à Pékin. Il a identifié six comptes supplémentaires consultés entre le 21 et le 24 juin et un autre par l'analyse d'un serveur privé virtuel saisi.

Les dates montrent que la découverte et l'endiguement se chevauchaient avec l'accès en cours. L'alerte du State Department a été un succès de détection, mais elle n'a pas révélé instantanément un justificatif d'identité de plateforme falsifié. Microsoft a d'abord examiné des explications familières telles que des appareils compromis et des jetons volés correctement émis. Ses analystes ont ensuite constaté que les artefacts d'authentification Exchange Online ne correspondaient pas aux jetons Azure AD dans les journaux attendus. Le 26 juin ou vers cette date, Microsoft a déterminé que l'acteur utilisait la clé grand public de 2016 pour créer des jetons qui fonctionnaient contre la messagerie grand public et d'entreprise.

L'avis conjoint CISA-FBI AA23-193Aest inhabituellement direct sur l'attribution des capacités d'atténuation. Il indique que toutes les mesures d'atténuation pour cette activité relevaient de la responsabilité de Microsoft car l'infrastructure affectée était basée sur le cloud. Il indique également que les agences n'avaient pas connaissance d'autres journaux d'audit ou événements qui auraient détecté l'activité. Le client a détecté l'incident, mais seul le fournisseur pouvait fermer la technique.

26 juin - 3 juillet: une atténuation par étapes plutôt qu'un seul interrupteur

La chronologie détaillée de Microsoft enregistre plusieurs actions distinctes:

• Le 26 juin, OWA a cessé d'accepter les jetons émis par GetAccessTokenForResource pour renouvellement, fermant le comportement de renouvellement dont l'acteur avait abusé.
• Le 27 juin, Microsoft a bloqué l'utilisation par OWA des jetons signés par la clé MSA acquise, empêchant tout nouvel accès à la messagerie d'entreprise via le chemin observé.
• Le 29 juin, Microsoft a terminé le remplacement de la clé, révoqué toutes les clés de signature MSA qui étaient valides pendant l'incident et émis de nouvelles clés à partir de systèmes renforcés.
• Le 3 juillet, Microsoft a bloqué l'utilisation de la clé pour les clients grand public affectés afin d'empêcher l'utilisation de jetons précédemment émis.

Cette séquence démontre pourquoi « la clé a été révoquée » n'est pas une description suffisante de l'endiguement. Une campagne de jetons falsifiés peut impliquer des métadonnées de validation en cache, des artefacts d'accès en aval, des interfaces de renouvellement, des services grand public et d'entreprise, et des jetons déjà émis. Un endiguement durable nécessite de cartographier chaque endroit où l'ancienne décision de confiance subsiste.

Microsoft a déclaré avoir observé Storm-0558 se tourner vers le phishing et d'autres techniques après le blocage du chemin de falsification de jetons connu, et n'avoir observé aucune autre activité liée à la clé. Cela confirme l'efficacité des atténuations immédiates contre la méthode observée. Cela ne prouve pas que le chemin d'acquisition d'origine a été identifié ni que l'acteur n'a jamais obtenu d'autre matériel sensible. Le CSRB a explicitement déclaré que la possibilité d'accès à d'autres clés et données restait non résolue.

Juillet 2023 - mars 2024: divulgation, réforme de la journalisation et rectification de la cause profonde

Microsoft a divulgué publiquement la campagne le 11 juillet et publié une analyse technique plus approfondie le 14 juillet. Ses premiers articles décrivaient correctement l'abus de clé et l'erreur de validation tout en indiquant que l'acquisition de la clé restait sous enquête. Le 19 juillet, après coordination avec la CISA, Microsoft a annoncé que les journaux détaillés d'accès aux courriels et plus de 30 autres types d'événements d'audit seraient mis à la disposition des clients de niveau standard sans frais supplémentaires. La société a également indiqué que la période de rétention par défaut pour Audit Standard passerait de 90 à 180 jours. L'annonce de journalisation de Microsoftest une réponse importante car elle modifie qui peut voir les preuves nécessaires pour détecter les abus provenant du fournisseur.

Le 6 septembre, Microsoft a publié ce qu'il a appelé les résultats de ses principales enquêtes techniques. Le récit original affirmait qu'un plantage du système de signature grand public en avril 2021 avait produit un fichier de vidage; qu'une condition de concurrence avait permis à la clé de se retrouver dans le fichier; que le fichier était passé d'un environnement de production isolé à un environnement de débogage d'entreprise connecté à Internet; que les scanners de justificatifs d'identité ne l'avaient pas détecté; et que Storm-0558 avait ensuite compromis le compte d'un ingénieur ayant accès à cet environnement. Comme les journaux pertinents avaient expiré, Microsoft a qualifié cela de mécanisme d'acquisition le plus probable.

Ce récit fournissait une chaîne cohérente, mais la chaîne n'était pas étayée par des preuves directes. Lerapport de septembre versionné de Microsoftcommence maintenant par une mise à jour du 12 mars 2024. La société indique que son hypothèse principale reste que des erreurs opérationnelles ont fait que le matériel de clé a quitté l'environnement de signature sécurisé et que le matériel a été consulté via un compte d'ingénierie compromis. Elle indique également qu'elle n'a pas trouvé de fichier de vidage contenant la clé concernée, que la condition de concurrence citée affectait la possibilité qu'un fichier de vidage puisse quitter l'environnement de signature plutôt que la présence possible du matériel de clé, et que la suppression de ce matériel n'était pas un processus standard mais n'avait pas été interdite à l'époque.

La correction modifie le statut épistémique du récit. Une hypothèse plausible n'est pas une conclusion de cause profonde. Le CSRB a signalé que Microsoft avait déclaré au comité en novembre 2023 avoir réalisé peu après la publication que les déclarations de septembre étaient inexactes, mais n'avait publié la correction qu'en mars 2024 après des interrogations répétées du comité. Ce retard est devenu une partie de la conclusion du comité sur la culture de sécurité, car les clients utilisent les divulgations de cause profonde pour juger si le chemin d'acquisition réel a été fermé.

Causes profondes, déclencheur et défaillances de détection

L'analyse des incidents est plus précise lorsqu'elle sépare le déclencheur des causes profondes et des défaillances de détection et de réponse.

Déclencheur

Le déclencheur opérationnel a été l'utilisation par Storm-0558 de la clé de signature privée MSA volée de 2016 pour créer des jetons et les présenter via les chemins d'accès Exchange Online. L'acteur a sélectionné des cibles, exploité une infrastructure, frappé des assertions, accédé à des courriels et exfiltré des messages. L'acteur est responsable de l'intrusion malveillante. L'attribution à un acteur d'espionnage associé à la République populaire de Chine est une évaluation de renseignement rapportée par Microsoft et le CSRB; cet article n'attribue pas de commandement étatique de manière indépendante.

Causes techniques profondes et conditions favorisantes

La première question de cause profonde, comment la clé privée a échappé au contrôle de Microsoft, n'est pas résolue. Elle doit être enregistrée comme un fait matériel ouvert, et non comblée par l'hypothèse du fichier de vidage.

La deuxième cause est beaucoup mieux établie: l'ancienne clé est restée de confiance. La rotation manuelle des clés grand public s'est arrêtée en 2021 après une panne, le remplacement automatisé n'était pas prêt, et aucune alerte de vieillissement efficace n'a forcé la résolution. Le vol d'une clé à courte durée de vie ou rapidement retirée aurait produit une opportunité plus petite. Le vol d'une clé qui est restée acceptée pendant des années a produit un pouvoir de signature durable.

La troisième cause était l'échec de la validation de la portée des jetons. Le service vérifiait une signature par rapport au matériel de clé disponible via des métadonnées communes, mais ne prouvait pas de manière adéquate que le domaine d'identité de la clé était autorisé à autoriser la ressource d'entreprise demandée. Ladocumentation actuelle de Microsoft sur la validation des jetons d'accèsindique aux serveurs de ressources de valider la signature du jeton, le public, l'émetteur, le locataire et l'émetteur de la clé de signature. Le cas Storm-0558 montre pourquoi ces vérifications ne sont pas redondantes. Une signature mathématiquement valide répond à qui détenait une clé privée; elle ne répond pas, par elle-même, à la question de savoir si cette clé était autorisée pour ce locataire, cette classe de compte, ce service ou cette ressource.

La quatrième cause était le défaut de conception du renouvellement des jetons OWA. Une fois l'identité falsifiée acceptée via un flux légitime, GetAccessTokenForResource permettait à un jeton d'en obtenir un autre d'une manière que Microsoft a modifiée par la suite pour distinguer l'émission Azure AD et MSA. Cela n'a pas créé la capacité de signature d'origine, mais a rendu le chemin d'accès plus utile et durable.

La cinquième condition favorisante était une détection d'anomalies insuffisante côté fournisseur. Microsoft a déclaré que le modèle de jetons de l'acteur était évident rétrospectivement car aucun système Microsoft légitime ne signait des jetons dans cette combinaison. Pourtant, le fournisseur n'a pas alerté sur cet état impossible ou hautement anormal avant qu'un client ne signale le comportement des boîtes aux lettres. Le CSRB a constaté que d'autres fournisseurs cloud disposaient de contrôles dont Microsoft manquait et a recommandé que les fournisseurs utilisent des données propriétaires dans les algorithmes de génération de jetons et les signaux de validation pour détecter les assertions falsifiées même lorsqu'une signature vérifie.

Défaillances de détection et de réponse

La détection dépendait d'un client disposant d'une licence premium, d'une analyse personnalisée, d'opérateurs qualifiés et de la volonté de poursuivre une alerte modérée qui avait généré des faux positifs auparavant. C'est un contrôle impressionnant du State Department. C'est aussi un modèle de sécurité instable à l'échelle du système. On ne peut pas s'attendre à ce que des milliers de clients reconstituent une compromission cryptographique d'un fournisseur à partir d'événements de boîte aux lettres optionnels, surtout lorsque l'événement nécessaire pour cette campagne n'était pas disponible pour les utilisateurs de licence standard.

À l'époque, MailItemsAccessed était disponible via Microsoft Purview Audit Premium et nécessitait une licence E5 ou G5. Le State Department avait G5 et pouvait créer Big Yellow Taxi. D'autres victimes sans journalisation premium n'avaient pas la même visibilité historique. L'avis de la CISA et du FBI a donc exhorté les organisations à activer la journalisation premium tout en notant explicitement l'exigence de licence. Sept jours plus tard, Microsoft s'est engagé à supprimer la barrière de niveau pour les types d'événements clés. La directrice de la CISA, Jen Easterly, a décrit le changement comme un pas vers une pratique de sécurité dès la conception dansla déclaration de la CISA du 19 juillet.

La réponse était également limitée par la rétention des preuves du fournisseur. Microsoft ne disposait pas des journaux nécessaires pour déterminer comment ou quand la clé avait été volée. Les fenêtres de trente jours limitaient la première activité client observable, tandis que les événements d'entreprise et de production plus anciens nécessaires pour l'hypothèse 2021 étaient indisponibles. La rétention des journaux implique toujours des coûts, des obligations de confidentialité et de contrôle d'accès, mais un fournisseur ne peut pas prétendre de manière crédible protéger des joyaux cryptographiques si son horizon de preuve est plus court que le temps pendant lequel des acteurs sophistiqués peuvent rester silencieux.

Enfin, la correction tardive du récit causal de septembre a été une défaillance de réponse. Elle n'a pas permis l'intrusion d'origine, mais elle a nui à la confiance du public. Un rapport post-incident doit séparer les faits, les hypothèses évaluées, le niveau de confiance, les preuves contradictoires et les questions non résolues. Publier un mécanisme semblant complet et le corriger seulement six mois plus tard a rendu plus difficile pour les clients et les superviseurs de déterminer si la remédiation traitait le chemin réel.

Le problème de la journalisation et des licences

La journalisation est parfois traitée comme une fonctionnalité produit accessoire. Dans cet incident, elle était un contrôle de sécurité et une source d'asymétrie d'information.

Microsoft possédait une télémétrie à l'échelle du service et une visibilité interne du système d'identité indisponible pour tout client. Chaque client ne pouvait observer que son locataire et uniquement les types d'événements inclus dans son abonnement et sa configuration. L'alerte décisive est venue de MailItemsAccessed, un événement conçu pour montrer quand les éléments de boîte aux lettres étaient consultés. La CISA et le FBI ont déclaré ne connaître aucun autre événement d'audit qui aurait détecté cette activité. Un client sans l'événement pouvait toujours remarquer des signes contextuels, mais il lui manquait la même surface de preuve directe.

Cela crée une frontière commerciale problématique. Les produits de sécurité premium peuvent raisonnablement facturer des analyses avancées, l'automatisation, une longue rétention et des enquêtes gérées. La preuve minimale nécessaire pour savoir si un service géré par un fournisseur a accédé aux données des clients est différente. Lorsqu'un fournisseur contrôle seul le système et qu'un client doit payer un supplément pour observer l'accès résultant de la propre défaillance d'identité du fournisseur, on demande au client d'acheter de la visibilité sur un risque qu'il ne peut pas directement corriger.

Le changement post-incident reconnaît cette distinction. Microsoft s'est engagé à rendre disponibles dans le monde entier des journaux de sécurité cloud plus larges sans frais supplémentaires, à ajouter des événements détaillés d'accès aux courriels à Audit Standard et à doubler la rétention standard par défaut à 180 jours. En février 2024, la CISA, l'Office of Management and Budget, l'Office of the National Cyber Director et Microsoft ont annoncé que la journalisation étendue devenait disponible pour toutes les agences fédérales utilisant Purview Audit, quel que soit le niveau, avec activation automatique et la rétention par défaut plus longue. L'annonce de mise en œuvre conjointea présenté les journaux d'audit de haute qualité sans frais supplémentaires ni configuration comme une attente de sécurité dès la conception.

La réforme n'élimine pas la responsabilité des clients. Les journaux doivent être acheminés vers des systèmes interrogeables, conservés conformément aux exigences de risque et légales, référencés, interrogés et connectés aux procédures de réponse. L'avis de la CISA recommande exactement ces mesures. Mais la discipline opérationnelle du client ne devient significative qu'après que le fournisseur a émis l'événement pertinent et l'a rendu accessible. La disponibilité de la télémétrie et son utilisation sont deux contrôles distincts détenus par différentes parties.

Les licences ont également affecté l'égalité médico-légale entre les victimes. L'environnement G5 du State Department avait un enregistrement historique plus solide que les environnements de niveau standard. Activer un événement après un incident ne reconstitue pas ce qui n'a jamais été enregistré. Cela signifie que la même défaillance du fournisseur peut produire différents niveaux de confiance quant à l'impact en fonction de l'abonnement d'un client, même si aucun client ne contrôlait la clé de signature sous-jacente. Les preuves médico-légales minimales devraient donc être traitées comme faisant partie de la base de sécurité du service, et non simplement comme une vente incitative.

Impact sur les clients fédéraux et continuité du secteur public

La compromission a affecté des courriels non classifiés, mais « non classifié » ne signifie pas trivial sur le plan opérationnel. Les boîtes aux lettres des hauts responsables contiennent des emplois du temps, des délibérations politiques, des réseaux de contacts, des positions de négociation, des ébauches de langage et le tissu conjonctif ordinaire du gouvernement. Un service de renseignement peut tirer de la valeur de l'agrégation, de la chronologie, des relations et du contexte sans obtenir de documents formellement classifiés.

Le State Department a déclaré plus tard qu'environ 60 000 courriels avaient été téléchargés à partir de 10 comptes. Dans sonpoint de presse du 28 septembre 2023, le département a décrit le matériel affecté comme non classifié et a déclaré qu'aucun système de messagerie classifié n'avait été piraté. La reconstruction plus large du CSRB a identifié davantage de comptes du State Department consultés, reflétant différentes façons de compter l'accès aux comptes et le sous-ensemble à partir duquel les messages ont été téléchargés. L'article ne déduit pas le contenu des messages au-delà de ce que les agences ont divulgué.

Les boîtes aux lettres officielle et personnelle de la secrétaire au Commerce faisaient partie des personnes touchées, selon le CSRB. La Chambre des représentants des États-Unis était également dans l'ensemble affecté, y compris le représentant Don Bacon. Uneenquête de la commission de surveillance de la Chambred'août 2023 a demandé des séances d'information au State Department et au département du Commerce sur la découverte, l'impact, la réponse et la sécurité future. Ces faits établissent une exposition sensible du secteur public et une préoccupation de surveillance; ils n'établissent pas que des décisions politiques spécifiques ont changé en raison de l'intrusion.

La continuité dans ce contexte a au moins cinq dimensions.

Premièrement, la continuité de la confidentialité: les responsables ont besoin d'une attente durable que les communications cloud de routine ne soient pas copiées silencieusement par un acteur de renseignement étranger.

Deuxièmement, la continuité des décisions: les équipes préparant des voyages diplomatiques ou des politiques économiques doivent pouvoir délibérer sans supposer que l'adversaire a un accès simultané à leurs courriels.

Troisièmement, la continuité des preuves: les agences ont besoin de suffisamment de données conservées pour reconstituer qui a accédé à quoi et quand. Sans cela, les dirigeants ne peuvent pas délimiter l'incident avec confiance ni décider quelles relations et décisions nécessitent une revalidation.

Quatrièmement, la continuité de réponse: une compromission de fournisseur oblige les agences à détourner des capacités de sécurité, juridiques, diplomatiques, de gestion des archives et de leadership. Même lorsque le courriel reste disponible, le travail de mission absorbe une taxe cachée de réponse aux incidents.

Cinquièmement, la continuité de la confiance: l'adoption fédérale de services cloud partagés dépend de l'assurance que le fournisseur détectera les défaillances dans son propre plan de contrôle, les divulguera avec précision et fournira aux clients des preuves utilisables. Un service peut atteindre un objectif de disponibilité tout en échouant à ce test de continuité plus large.

L'incident a également exposé le risque de concentration. Microsoft fournit des services d'identité, de messagerie, de productivité, de système d'exploitation, de sécurité et de cloud à une grande partie du gouvernement et du secteur privé. L'intégration peut améliorer la gestion et la détection, mais elle peut aussi permettre à un défaut d'identité côté fournisseur de franchir les frontières organisationnelles à l'échelle mondiale. Le CSRB a décrit la centralité de Microsoft comme une raison d'exiger les normes les plus élevées de sécurité, de responsabilité et de transparence.

La concentration ne conduit pas automatiquement à la conclusion que chaque agence devrait abandonner Microsoft ou maintenir des systèmes de messagerie en double. La migration elle-même crée des coûts et des risques, et plusieurs fournisseurs peuvent reproduire des faiblesses d'identité similaires. La conclusion la plus forte est que les achats et la surveillance doivent évaluer explicitement les défaillances d'identité en mode commun: la segmentation des clés, la détection d'anomalies côté fournisseur, l'accès aux audits, la conservation des preuves, la notification des incidents, les tests indépendants et les dispositions de sortie ou de continuité doivent être traités comme des exigences de service.

Les conclusions du CSRB et leur importance

Lapage de publication du CSRBdécrit le rapport comme un examen indépendant des décisions opérationnelles et stratégiques et indique qu'il recommande des pratiques pour l'industrie et le gouvernement. Ses principales conclusions sont sévères mais précises.

Le comité a conclu que la culture de sécurité de Microsoft était inadéquate et nécessitait une refonte. Il a fondé cette conclusion sur la cascade évitable, l'incapacité à détecter la compromission d'une clé de signature critique, la dépendance à un client pour la découverte, la comparaison avec les contrôles d'autres fournisseurs, la compromission de l'appareil acquis en 2021, la correction tardive de déclarations publiques inexactes et une compromission distincte par un État-nation en 2024 qui était hors du champ de cet examen. La conclusion est organisationnelle car aucune erreur de codage unique n'explique pourquoi la clé est restée acceptée, pourquoi la séparation de domaine a échoué, pourquoi les modèles de jetons impossibles n'ont pas déclenché d'alerte, pourquoi les preuves étaient indisponibles et pourquoi une affirmation causale a dépassé la preuve.

Le comité a également fourni des contrefactuels concrets. Si la rotation manuelle n'avait pas été interrompue sans un remplacement automatisé terminé, ou si une alerte de clé vieillissante avait forcé une action, la clé de 2016 ne serait pas restée valide en 2023. Si la validation grand public et entreprise avait été correctement séparée, la portée de l'acteur aurait été beaucoup plus étroite et n'aurait pas inclus les clients d'entreprise. Si Microsoft avait détecté des jetons qui n'étaient pas conformes à son propre algorithme de génération, la campagne aurait pu être bloquée ou détectée côté fournisseur. Si une rétention médico-légale plus forte avait existé, Microsoft aurait pu répondre à la question de l'acquisition de la clé.

Ces contrefactuels démontrent un principe de sécurité en couches. L'intrusion n'a pas nécessité que chaque contrôle échoue de la même manière. N'importe lequel de plusieurs contrôles indépendants aurait pu empêcher la compromission d'entreprise ou la raccourcir considérablement:

• Une garde sécurisée aurait pu empêcher la perte de la clé.
• Une rotation automatique fréquente aurait pu rendre la clé volée inutilisable avant 2023.
• Une validation tenant compte de la portée aurait pu confiner une clé grand public aux services grand public.
• Des vérifications de jetons avec état ou propriétaires auraient pu détecter un jeton que Microsoft lui-même n'émettrait jamais.
• Une surveillance à l'échelle du fournisseur aurait pu faire apparaître la combinaison domaine-signature impossible.
• Des journaux client de base auraient pu permettre à plus de victimes de détecter et de délimiter l'accès.
• Une rétention plus longue du fournisseur aurait pu améliorer la confiance dans la cause profonde.

C'est pourquoi le chemin de vol non résolu n'empêche pas l'analyse de responsabilité. L'inconnu est important, mais plusieurs défaillances indépendantes suffisantes ou limitant l'impact sont documentées. Un fournisseur ne peut pas répondre à un lien de cause profonde manquant en traitant toute la chaîne comme inconnaissable.

Les recommandations du comité allaient au-delà de Microsoft. Elles appelaient à des pratiques modernes de gestion des clés, une rotation automatisée et fréquente, des clés protégées par le matériel, des bibliothèques d'authentification communes, des normes d'identité numérique plus robustes, une journalisation client minimale sans frais supplémentaires, au moins six mois de journaux appropriés accessibles aux clients, une meilleure notification des victimes et une divulgation plus transparente des vulnérabilités du cloud. Ces mesures répondent à une structure industrielle dans laquelle les fournisseurs détiennent à la fois le contrôle privilégié et les meilleures preuves.

Réponse de Microsoft

La réponse immédiate de Microsoft a corrigé les défauts connus du validateur et du renouvellement, bloqué la clé volée, révoqué les clés de signature MSA alors actives, déplacé les clés grand public vers le magasin de clés d'entreprise renforcé, accru l'isolement et affiné la surveillance du système de clés. Ces actions visaient directement la campagne observée. Microsoft a également notifié les organisations touchées et publié des indicateurs d'infrastructure pour les défenseurs.

La société a ensuite apporté un changement de contrôle commercial en élargissant l'accès aux audits. Cette action est observable indépendamment dans l'engagement produit et le déploiement fédéral, bien que l'exhaustivité pratique de la couverture des événements dépende encore du service, de la configuration, de la rétention et des opérations des clients.

En novembre 2023, Microsoft a lancé la Secure Future Initiative. Sonannonce initiale de la SFIs'engageait à un système de gestion des clés unifié et entièrement automatisé pour les consommateurs et les entreprises, utilisant l'informatique confidentielle et les modules de sécurité matériels, avec une architecture conçue pour garder les clés inaccessibles même lorsque les processus sous-jacents sont compromis. Un article d'ingénierie complémentaire s'engageait à une rotation automatisée à haute fréquence sans accès humain.

Après le rapport du CSRB et une intrusion distincte d'un État russe dans les courriels d'entreprise de Microsoft, la société a élargi la SFI en mai 2024. Leprogramme élargi de Microsofta fixé des objectifs incluant une rotation automatique rapide et une protection matérielle pour les clés de signature, des SDK d'identité standard dans toutes les applications, une validation avec état et durable pour les jetons d'identité, un partitionnement plus fin des clés, l'élimination des pivots d'identité latéraux, une rétention de deux ans pour les journaux de sécurité et six mois de journaux appropriés pour les clients. Il a également indiqué qu'une partie de la rémunération des hauts dirigeants dépendrait des jalons de sécurité.

En juin 2024, le vice-président et président de Microsoft, Brad Smith, a déclaré au House Homeland Security Committee que la société acceptait la responsabilité de chaque problème cité dans le rapport du CSRB. Sontémoignage écritindiquait que Microsoft mettait en œuvre les 16 recommandations du comité applicables à l'entreprise, avait consacré l'équivalent de 34 000 ingénieurs à temps plein à la SFI, faisait passer les systèmes d'identité grand public et d'entreprise à un système de gestion des clés adossé au matériel, et avait progressé sur la rotation automatisée, les bibliothèques d'authentification communes et les signaux de validation des jetons. Lecompte rendu d'audience du Congrèsfournit le contexte de surveillance publique et les questions.

En septembre 2024, Microsoft a signalé un Conseil de gouvernance de la cybersécurité, des RSSI adjoints pour les divisions d'ingénierie, la sécurité dans les évaluations de performance des employés et des examens réguliers de la direction et du conseil d'administration. Lamise à jour des progrès de la SFIde la société est une preuve des changements de gouvernance et des progrès de mise en œuvre déclarés.

Ces réponses sont des engagements substantiels. Ils doivent toujours être décrits comme des engagements et des progrès rapportés par l'entreprise lorsque la vérification indépendante n'est pas publique. Le CSRB a recommandé des architectures et des contrôles spécifiques, mais il n'a pas certifié leur achèvement ultérieur. Une norme de clôture crédible exigerait une couverture mesurable de la rotation des clés, la preuve que les validateurs hérités ont été retirés, des tests montrant que les frontières grand public et entreprise échouent en position fermée, une télémétrie conservée suffisante pour enquêter sur les événements clés, et une assurance externe que les exceptions ne peuvent pas persister silencieusement.

Responsabilité par capacité de contrôle

Une cartographie utile des responsabilités commence par qui pouvait prévenir, détecter, limiter ou raccourcir chaque défaillance.

Microsoft contrôlait la génération des clés, le stockage, la rotation, le retrait et l'ensemble de confiance en production. Il contrôlait l'architecture commune des métadonnées, les bibliothèques d'aide, le validateur Exchange Online, l'interface de renouvellement de jetons OWA et la logique de détection à l'échelle du service. Il contrôlait la rétention des preuves internes en production et en entreprise. Il contrôlait également l'exactitude et le calendrier des divulgations techniques publiques. La responsabilité de ces surfaces incombe principalement à Microsoft.

Le State Department contrôlait la surveillance de son locataire, sa logique d'alerte personnalisée, le triage, l'escalade et la coordination avec la CISA et le FBI. Il a exécuté ces tâches suffisamment efficacement pour découvrir une intrusion au niveau du fournisseur. D'autres clients contrôlaient leur propre surveillance et réponse dans les limites de la télémétrie à leur disposition. La responsabilité des clients reste réelle, mais elle ne peut pas remplacer les contrôles du fournisseur que les clients ne peuvent ni voir ni modifier.

La CISA, l'OMB et les responsables des achats des agences contrôlaient des parties de la base de référence fédérale: les exigences de journalisation, les conseils de configuration, les attentes contractuelles, la coordination inter-agences et le levier pour exiger des valeurs par défaut plus sûres. Leur travail de journalisation post-incident a réduit une iniquité. Un régime d'achat mature ne devrait pas dépendre d'une crise pour établir que les clients ont besoin d'accéder aux preuves d'accès aux boîtes aux lettres.

Storm-0558 contrôlait l'opération hostile et porte la responsabilité de l'intrusion. Ce fait évident n'efface pas la prévisibilité. Les enquêtes de sécurité examinent régulièrement pourquoi une entrée malveillante ou dangereuse a atteint des systèmes protégés malgré la culpabilité de l'acteur. L'attribution et la responsabilité défensive répondent à des questions différentes.

Les conseils d'administration et les dirigeants d'entreprise contrôlent l'allocation des ressources, l'acceptation des risques, les incitations et les délais. La pause dans la rotation manuelle des clés après une panne n'était pas simplement une erreur d'ingénierie isolée; la conséquence de sécurité a persisté parce que l'automatisation et les alertes n'ont pas reçu ou conservé une priorité suffisante. La décision ultérieure de Microsoft de lier la rémunération des dirigeants aux jalons de sécurité reconnaît implicitement que le niveau de contrôle pertinent s'étend au-dessus de l'équipe qui a écrit le validateur.

L'attribution ne doit pas être convertie mécaniquement en un pourcentage de responsabilité légale. Les contrats, l'immunité souveraine, les dommages, la causalité, les obligations de divulgation et la compétence réglementaire varient. Lademande de juillet 2023 du sénateur Ron Wydendemandait au ministère de la Justice, à la Federal Trade Commission et au CSRB d'enquêter sur les pratiques de Microsoft. Cette demande est une preuve de préoccupation réglementaire, et non la preuve que les agences sollicitées sont parvenues à une conclusion d'application. Aucun dossier public sourcé utilisé ici n'établit un jugement juridique définitif pour Storm-0558.

Ce que la remédiation durable devrait prouver

L'incident ne doit être considéré comme opérationnellement clos qu'en ce qui concerne la technique observée de la clé de 2016. Le problème d'assurance plus large reste ouvert jusqu'à ce que la remédiation puisse être démontrée sur plusieurs dimensions.

Garde et cycle de vie des clés

Microsoft devrait pouvoir démontrer que les clés de signature grand public et d'entreprise sont générées et utilisées dans des systèmes protégés par le matériel, ne peuvent pas être exportées vers des environnements de débogage ou d'entreprise généraux, tournent automatiquement à une fréquence proportionnelle à leur puissance et génèrent des alertes exploitables lorsque l'âge ou les exceptions de politique dépassent les limites. La rotation d'urgence devrait être exercée sans provoquer le type de panne qui a conduit à la pause de 2021. La segmentation des clés devrait réduire le nombre de locataires, de services et de classes de comptes exposés par une seule clé.

Exactitude de la validation

Chaque service dépendant devrait utiliser des bibliothèques approuvées qui valident la signature, l'émetteur, le public, le locataire, la classe de compte, l'émetteur de la clé, la durée de vie et l'autorisation spécifique au service. Ladocumentation OpenID Connect de Microsoftexplique que les métadonnées de découverte exposent les points de terminaison du fournisseur et les clés de signature publiques; cela ne rend pas chaque clé listée interchangeable pour chaque ressource. Les tests de conformité devraient présenter intentionnellement des jetons correctement signés mais avec une portée incorrecte et vérifier le rejet.

Résistance à la falsification au-delà des signatures sans état

Un jeton porteur à signature seule peut rester convaincant après le vol de la clé de signature. Une validation avec état, des approches de preuve de possession, des marqueurs d'émission propriétaires, des durées de vie limitées et une révocation rapide peuvent réduire ce risque. L'objectif n'est pas d'abandonner les normes mais de s'assurer que la possession d'une clé ne crée pas une autorité globale inobservable.

Télémétrie du fournisseur et du client

Le fournisseur devrait détecter les combinaisons de jetons impossibles dans l'ensemble du service et conserver les preuves internes suffisamment longtemps pour les campagnes sophistiquées. Les clients devraient recevoir par défaut les événements d'accès aux boîtes aux lettres et d'identité, sans barrière premium, dans un schéma documenté pouvant être exporté vers des outils d'analyse indépendants. Six mois de journaux accessibles aux clients, comme recommandé par le CSRB et adopté comme objectif de la SFI, devraient être un plancher pour l'activité d'identité cloud à haute valeur plutôt qu'un plafond ambitieux.

Communication d'incident

Les divulgations techniques devraient comporter un historique des versions, des niveaux de confiance et des questions non résolues explicites. Lorsqu'une hypothèse publiée perd son soutien probatoire, la correction doit être rapide et visible. Un fournisseur ne devrait pas obliger un organisme de surveillance à demander à plusieurs reprises si un compte rendu inexact de la cause profonde sera modifié.

Assurance indépendante

Les rapports d'avancement de l'entreprise sont utiles mais insuffisants pour un plan de contrôle avec une dépendance du secteur public. Les clients fédéraux ont besoin de mécanismes d'assurance qui peuvent tester la rotation, l'isolement des clés, la couverture du validateur, la performance des alertes et la rétention médico-légale sans exposer de secrets. L'objectif n'est pas la publication d'une architecture sensible. Il s'agit de la preuve que les contrôles déclarés fonctionnent en production, y compris les systèmes hérités et les environnements acquis.

Leçons pratiques pour les clients cloud et les acheteurs publics

Les clients ne peuvent pas réparer le système de signature d'un fournisseur, mais ils peuvent rendre la dépendance plus gouvernable.

Premièrement, acquérez des preuves, pas seulement des fonctionnalités. Les contrats et les bases de référence des services doivent identifier quels événements d'accès, d'identité, administratifs, de jetons et de boîte aux lettres sont disponibles; à quelle vitesse ils arrivent; combien de temps ils restent interrogeables; et si les clients peuvent les exporter. La journalisation doit être testée avec des événements simulés avant un incident.

Deuxièmement, construisez des analyses autour de l'accès aux données ainsi que de la connexion. Un jeton falsifié peut contourner les anomalies que les défenseurs attendent du vol de mot de passe. MailItemsAccessed a compté parce qu'il observait l'action protégée, pas simplement la cérémonie d'authentification. Les environnements à haute valeur ajoutée doivent référencer les accès inhabituels aux boîtes aux lettres, les identifiants d'application, la géographie, le comportement des clients et le volume d'accès.

Troisièmement, maintenez un chemin d'escalade qui suppose que le fournisseur peut faire partie de l'incident. Une équipe locataire doit savoir comment contacter l'organisation de réponse de sécurité du fournisseur, la CISA ou l'autorité nationale compétente, les forces de l'ordre et la direction exécutive sans dépendre du canal de messagerie potentiellement compromis.

Quatrièmement, traitez la concentration d'identité comme un risque de continuité. Les acheteurs doivent savoir quels services critiques partagent une racine d'identité, ce qu'une compromission de clé à l'échelle du fournisseur pourrait atteindre et quelles fonctions peuvent continuer pendant que la confiance dans le cloud est rétablie. Cela peut justifier une segmentation, des identités administratives distinctes, un stockage de journaux indépendant ou une diversité sélective pour les flux de travail les plus sensibles.

Cinquièmement, testez les engagements de notification et de preuve du fournisseur. Une promesse de notifier les « clients affectés » n'est utile que dans la mesure où le fournisseur peut les identifier. Dans Storm-0558, seul Microsoft pouvait identifier la plupart des victimes parce que les jetons falsifiés fonctionnaient à l'intérieur de son service. Cela fait de la télémétrie à l'échelle du fournisseur et de la communication en temps utile une partie de l'architecture de détection du client.

Enfin, ne confondez pas la responsabilité partagée avec une capacité égale. Les clients doivent sécuriser ce qu'ils contrôlent. Les fournisseurs doivent être responsables des contrôles exclusifs au fournisseur. Les régulateurs et les acheteurs doivent se concentrer sur la frontière entre eux, car c'est là que les exigences de sécurité sont les plus susceptibles de devenir ambiguës, facultatives ou monétisées.

Évaluation

L'intrusion Storm-0558 dans Exchange Online a été une défaillance d'identité cloud évitable avec un chemin d'acquisition initial de la clé non résolu. Les preuves publiques soutiennent une conclusion à haute confiance que Microsoft a permis à une ancienne clé de signature grand public de rester de confiance, n'a pas fait respecter la frontière entre la validation des jetons grand public et entreprise, manquait de détection suffisante côté fournisseur pour les combinaisons de jetons que ses propres systèmes n'émettraient pas, et a conservé trop peu de preuves pour reconstituer la fuite de la clé. Elles soutiennent également la conclusion que la journalisation client bloquée par une licence premium a matériellement façonné qui pouvait détecter et enquêter sur la campagne.

La réponse de Microsoft a traité le chemin d'accès observé et s'est ensuite étendue aux réformes de la gestion des clés, de la validation, de la journalisation, de la gouvernance et des incitations. L'acceptation par Brad Smith des conclusions du CSRB est significative. La suppression du paywall de journalisation pour les événements principaux et le passage à une rotation automatisée adossée au matériel le sont également. La question de responsabilité restante est de savoir si ces changements sont complets, durables et vérifiables de manière indépendante dans l'ensemble de l'infrastructure d'identité héritée et actuelle de Microsoft.

La leçon plus large de l'incident n'est pas que les services cloud sont intrinsèquement moins sécurisés que les systèmes gérés par les clients. Les grands fournisseurs peuvent déployer des contrôles, du renseignement et des mesures correctives à une échelle que la plupart des clients ne peuvent pas. La leçon est que l'échelle concentre également une autorité cachée. Lorsqu'une seule clé de signature et une seule erreur de validation peuvent atteindre des organisations dans le monde entier, la sécurité dépend de la discipline interne du fournisseur en matière de clés et de preuves que les clients ne peuvent pas générer eux-mêmes.

La continuité du secteur public nécessite donc une définition plus large de la fiabilité des services. La disponibilité est nécessaire, mais la confidentialité, l'identité digne de confiance, les preuves reconstructibles, la divulgation rapide et une voie crédible pour rétablir la confiance après une compromission côté fournisseur le sont aussi. Storm-0558 a laissé Exchange Online fonctionner. Il a néanmoins perturbé la prémisse sur laquelle les gouvernements l'utilisaient. C'est pourquoi l'incident figure dans les dossiers comme une défaillance de responsabilité du cloud plutôt que comme une simple opération d'espionnage réussie de plus.