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

Résumé

• Storm-0558 n'a pas contourné 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 exploité un défaut de validation chez Microsoft qui a permis à ces jetons signés avec une clé grand public d'accéder aux courriels d'entreprise Exchange Online.
• Le chemin d'acquisition de la clé reste non résolu. L'explication de Microsoft de septembre 2023 impliquant un fichier de vidage sur incident a ensuite été réduite à une hypothèse principale après que l'entreprise a reconnu qu'elle n'avait trouvé aucun fichier de vidage contenant la clé ni de journaux prouvant l'exfiltration. La clé obsolète, le défaut de validation inter-domaines, la détection inadéquate des anomalies de 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 renouveler la clé de la plateforme, corriger le validateur côté service, détecter les combinaisons de jetons impossibles dans son cloud, préserver 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 se résume facilement en une phrase familière: des pirates chinois ont volé une clé Microsoft et lu des courriels gouvernementaux. Cette phrase est globalement vraie mais analytiquement inadéquate. Elle fusionne l'acte de l'attaquant, la perte non résolue de matériel cryptographique par Microsoft, une faille logicielle de validation distincte, une décision de cycle de vie de clé obsolète, 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 le cas d'un employé gouvernemental cédant son mot de passe, d'une agence ne parvenant pas à déployer l'authentification multifacteur, ou d'un serveur non corrigé situé 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 affirmer des identités sans obtenir les mots de passe des victimes.

Un deuxième défaut Microsoft permettait à une clé destinée aux comptes grand public d'authentifier des requêtes 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 forgé des jetons Azure Active Directory avec la clé grand public acquise, a utilisé un flux légitime Outlook Web Access, a obtenu des jetons Exchange Online via l'interface GetAccessTokenForResource et a récupéré les 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. Il ne s'agissait pas simplement d'une relecture de justificatif volé. C'était la fabrication et le renouvellement non autorisés de justificatifs que les services de Microsoft considéraient comme valides.

La 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 renouveler le matériel de signature racine d'un fournisseur cloud, corriger le validateur de jetons de production du fournisseur, ou 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 classifier à tort l'événement comme une panne de service. Les informations publiques ne montrent pas qu'Exchange Online soit devenu indisponible pour les agences affectées. Le préjudice était une perte de confidentialité et de communications de confiance, suivi 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 fonctionnaires à 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 fiable.

Ce qui est établi, ce qui est déduit et ce qui reste inconnu

Trois catégories de preuves doivent rester distinctes.

Premièrement, les informations publiques établissent fermement que Storm-0558 a utilisé une clé de signature grand public MSA de 2016 créée par Microsoft pour forger des jetons; qu'un défaut de validation de Microsoft a permis à ces jetons d'accéder aux comptes Exchange Online d'entreprise; que le Département d'État a détecté 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érie de modifications côté service.

Les divulgations de Microsoft, l'avis d'intervention de la CISA, les déclarations des agences affectées et la reconstitution du Cyber Safety Review Board convergent sur ces points.

Deuxièmement, le Cyber Safety Review Board (CSRB) a formulé des conclusions sur la possibilité de prévention, 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é 2023conclut que l'incident était évitable et n'aurait jamais dû se produire. Le comité a interrogé 20 organisations, bénéficié de la coopération de Microsoft, comparé les contrôles d'autres grands fournisseurs de services cloud et constaté une cascade de défaillances évitables. Il s'agit de conclusions d'examen indépendantes, non de conclusions judiciaires, mais elles sont nettement plus solides que des commentaires basés uniquement sur les premiers blogs de Microsoft.

Troisièmement, la voie réelle par laquelle Storm-0558 a obtenu la clé privée de 2016 reste inconnue dans les informations publiques. Cette incertitude est centrale. Microsoft a publié un récit détaillé impliquant un fichier de vidage 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é compromis. Le CSRB a indiqué que Microsoft avait 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 présentant le fichier de vidage comme la cause racine avérée exagère les preuves.

Le dossier n'établit pas non plus une attribution juridique définitive des pertes. L'examen par le 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 de tribunal, une décision d'application de la loi par une agence, une interprétation contractuelle ou une analyse quantifiée des dommages.

La conclusion appropriée est plus étroite: Microsoft contrôlait plusieurs mesures de protection 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 judiciaire

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 que 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, alors 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. Elle n'a alors déployé ni un remplacement par 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. Il s'agit d'une décision classique de disponibilité contre 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 maintient l'exposition à la sécurité indéfiniment.

La conclusion du comité est plus utile que de dire simplement qu'une clé « expirée » fonctionnait. Une clé est acceptée ou rejetée selon la configuration de confiance en direct du service. La défaillance cruciale est qu'une clé destinée à être retirée est restée dans l'ensemble de confiance.Les directives actuelles de Microsoft sur le renouvellement des clés de signatureindiquent que les applications doivent gérer le renouvellement périodique et d'urgence de manière programmatique et recommandent des bibliothèques standard pour éviter les défauts subtils. Ces directives 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, et non une cérémonie fragile qui devient trop risquée à exécuter.

En septembre 2018, Microsoft a introduit un point de terminaison commun de publication de métadonnées de clés en réponse à la demande d'applications servant à la fois les utilisateurs grand public et les entreprises. Le récit ultérieur de Microsoft indiquait que la documentation avait été mise à jour pour expliquer la validation de la portée des clés, mais les bibliothèques d'aide n'avaient pas été mises à jour pour appliquer automatiquement cette portée. Les systèmes de messagerie Exchange ont commencé à utiliser le point de terminaison de métadonnées commun en 2022.

Les développeurs supposaient 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 accru 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 reconstitution du CSRB situe 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 justificatifs d'entreprise. L'acteur a capturé et rejoué un jeton d'authentification et a accédé à du contenu dans SharePoint, y compris des informations relatives à la gestion des services Azure et à l'identité.

Le comité a reproché à Microsoft de ne pas avoir détecté l'appareil compromis de l'entreprise acquise avant de lui permettre d'accéder au réseau d'entreprise.

Cette compromission de 2021 est une preuve d'accès et d'intérêt de l'attaquant. Ce n'est pas une preuve que l'acteur a obtenu la clé MSA de 2016 à ce moment-là. Microsoft a déclaré au comité que l'intrusion de 2021 était probablement liée car c'était la seule autre intrusion connue de Storm-0558 dans le réseau de Microsoft en mémoire enregistrée, mais l'entreprise n'a produit aucune preuve spécifique la liant au vol de la 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 conservation standard des journaux de 30 jours par Microsoft limitait la vue rétrospective disponible une fois l'enquête lancée. « Premier vu » est donc une limite de preuve, pas nécessairement le véritable début de l'attaque.

Les cibles reflétaient des 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 comprenaient ceux de la Secrétaire au Commerce Gina Raimondo, de l'Ambassadeur des États-Unis en Chine R. Nicholas Burns, du Secrétaire d'État adjoint aux affaires de l'Asie de l'Est et du Pacifique Daniel Kritenbrink, et du membre du Congrès Don Bacon.L'avis d'incident initial de Microsoft du 11 juilletfaisait référence à environ 25 organisations et à des comptes grand public associés. La différence doit être considérée comme un changement dans la comptabilisation des incidents entre un avis précoce de l'entreprise et la reconstitution indépendante ultérieure, et non comme la preuve d'une nouvelle intrusion.

Le Département d'État, et non Microsoft, a détecté la campagne. Le 15 juin, le centre des opérations de sécurité du Département d'État 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 Département d'État a enquêté malgré la possibilité de faux positifs et a contacté Microsoft ce jour-là.

Le 19 juin, le Département d'État avait déterminé que six comptes avaient été consultés, y compris des comptes associés aux préparatifs du voyage du Secrétaire d'État à Pékin. Il a identifié six autres comptes consultés entre le 21 et le 24 juin et un autre grâce à l'analyse d'un serveur privé virtuel saisi.

Les dates montrent que la découverte et le confinement se sont chevauchés avec l'accès en cours. L'alerte du Département d'État a été un succès de détection, mais elle n'a pas instantanément révélé un justificatif 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 aux alentours, Microsoft a déterminé que l'acteur utilisait la clé grand public de 2016 pour créer des jetons fonctionnant pour le courrier grand public et d'entreprise.

L'avis CISA-FBI AA23-193Aest inhabituellement direct quant à l'attribution des capacités d'atténuation. Il indique que toutes les actions d'atténuation de 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 progressive 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, mettant fin au comportement de renouvellement dont l'acteur avait abusé.
• Le 27 juin, Microsoft a bloqué l'utilisation par OWA des jetons signés avec la clé MSA acquise, empêchant tout nouvel accès au courrier d'entreprise par le chemin observé.
• Le 29 juin, Microsoft a achevé le remplacement de la clé, révoqué toutes les clés de signature MSA qui avaient été 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 du confinement. Une campagne de falsification de jetons 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 confinement durable nécessite de cartographier chaque endroit où l'ancienne décision de confiance survit.

Microsoft a déclaré avoir observé Storm-0558 se tourner vers l'hameçonnage et d'autres techniques après le blocage du chemin connu de falsification de jetons, et qu'aucune autre activité liée à la clé n'avait été observée. 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 correction de l'affirmation de cause racine

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 coût supplémentaire. La société a également déclaré que la période de conservation par défaut pour Audit Standard passerait de 90 à 180 jours.L'annonce de Microsoft sur la journalisationest une réponse importante car elle change qui peut voir les preuves nécessaires pour détecter les abus provenant du fournisseur.

Le 6 septembre, Microsoft a publié ce qu'elle a appelé les résultats de ses enquêtes techniques majeures. Le récit original affirmait qu'un crash du système de signature grand public d'avril 2021 avait produit un fichier de vidage; qu'une condition de concurrence avait permis à la clé de se retrouver dans le vidage; que le vidage était passé d'un environnement de production isolé à un environnement de débogage d'entreprise connecté à Internet; que les scanners de justificatifs l'avaient manqué; et que Storm-0558 avait ensuite compromis un compte d'ingénieur ayant accès à cet environnement.

Les journaux pertinents ayant expiré, Microsoft a qualifié cela de mécanisme d'acquisition le plus probable.

Ce récit fournissait une chaîne cohérente, mais cette chaîne n'était pas étayée par des preuves directes.Le rapport de septembre versionné de Microsoftcommence maintenant par une mise à jour du 12 mars 2024. La société déclare que son hypothèse principale reste que des erreurs opérationnelles ont permis au matériel de clé de quitter 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é compromise, que la condition de concurrence citée affectait la possibilité qu'un vidage quitte l'environnement de signature plutôt que la présence du matériel de clé, et que la suppression d'un tel matériel n'était pas un processus standard mais n'était pas interdite à l'époque.

La correction change le statut épistémique du récit. Une hypothèse plausible n'est pas une conclusion de cause racine. Le CSRB a indiqué que Microsoft avait déclaré au comité en novembre 2023 qu'il s'était rendu compte 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 questions répétées du comité. Ce retard a contribué à la conclusion du comité sur la culture de sécurité, car les clients utilisent les divulgations de cause racine pour juger si le chemin d'acquisition réel a été fermé.

Cause racine, déclencheur et défaillances de détection

L'analyse d'incident est plus précise lorsqu'elle sépare le déclencheur des causes racines 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 de 2016 volée 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, fabriqué des assertions, accédé aux 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 du renseignement rapportée par Microsoft et le CSRB; cet article n'attribue pas indépendamment de commandement étatique.

Causes racines techniques et conditions favorisantes

La première question de cause racine, 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 bien mieux établie: l'ancienne clé est restée de confiance. La rotation manuelle des clés grand public a été arrêtée en 2021 après une panne, le remplacement automatisé n'était pas prêt et aucune alerte efficace de vieillissement n'a forcé la résolution. Le vol d'une clé à courte durée de vie ou rapidement retirée aurait offert une opportunité plus limitée. Le vol d'une clé restée acceptée pendant des années a conféré un pouvoir de signature durable.

La troisième cause était la défaillance de portée de validation des jetons. Le service vérifiait une signature par rapport au matériel de clé disponible via les 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.La documentation 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 à la question de savoir qui détenait une clé privée; elle ne répond pas, en soi, à 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 originale, mais a rendu le chemin d'accès plus utile et durable.

La cinquième condition favorisante était une détection inadéquate des anomalies côté fournisseur. Microsoft a déclaré que le modèle de jeton de l'acteur était évident rétrospectivement, car aucun système Microsoft légitime ne signait de jetons dans cette combinaison. Pourtant, le fournisseur n'a pas alerté sur cet état impossible ou hautement anormal avant qu'un client ne signale un comportement de boîte aux lettres.

Le CSRB a constaté que d'autres fournisseurs cloud disposaient de contrôles que Microsoft n'avait pas 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 se 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 déjà généré des faux positifs. C'est un contrôle impressionnant du Département d'État. 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 la 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 Département d'État avait G5 et pouvait créer Big Yellow Taxi. Les 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 ce changement comme une étape vers une pratique de sécurité dès la conception dansla déclaration de la CISA du 19 juillet.

La réponse a également été limitée par la conservation des preuves du fournisseur. Microsoft ne disposait pas des journaux nécessaires pour déterminer comment ni quand la clé avait été volée. Les fenêtres de 30 jours limitaient l'activité client observable la plus ancienne, tandis que les événements d'entreprise et de production plus anciens nécessaires à l'hypothèse de 2021 étaient indisponibles.

La conservation des journaux comporte 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 preuves 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 initiale, mais elle a nui à l'assurance publique. Un rapport post-incident devrait séparer les faits, les hypothèses évaluées, la confiance, les preuves contradictoires et les questions non résolues. Publier un mécanisme apparemment complet et ne le corriger que 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é auxiliaire du produit. Dans cet incident, c'était un contrôle de sécurité et une source d'asymétrie d'information.

Microsoft disposait d'une télémétrie à l'échelle du service et d'une visibilité interne du système d'identité inaccessible à 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é qu'ils ne connaissaient aucun autre événement d'audit qui aurait détecté cette activité.

Un client ne disposant pas de l'événement pouvait encore 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 conservation et des enquêtes gérées. Le minimum de preuves nécessaires pour savoir si un service géré par un fournisseur a accédé aux données du client est différent. 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 les journaux de sécurité cloud plus larges disponibles dans le monde entier sans coût supplémentaire, à ajouter des événements détaillés d'accès aux courriels à Audit Standard et à doubler la conservation 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 conservation par défaut plus longue.L'annonce de mise en œuvre conjointea présenté les journaux d'audit de haute qualité sans frais ni configuration supplémentaires comme une attente de sécurité dès la conception.

La réforme n'élimine pas la responsabilité du client. Les journaux doivent être acheminés vers des systèmes consultables, conservés conformément aux risques et aux exigences 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 des parties différentes.

Les licences ont également affecté l'égalité judiciaire entre les victimes. L'environnement G5 du Département d'État disposait d'un enregistrement historique plus solide que les environnements de niveau standard. Activer un événement après un incident ne reconstruit 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 sur l'impact en fonction de l'abonnement du client, même si aucun client ne contrôlait la clé de signature sous-jacente.

Les preuves judiciaires minimales devraient donc être traitées comme faisant partie de la base de référence 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 opérationnellement trivial. Les boîtes aux lettres des hauts fonctionnaires contiennent des calendriers, 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, du timing, des relations et du contexte sans obtenir de documents formellement classifiés.

Le Département d'État a déclaré plus tard qu'environ 60 000 courriels avaient été téléchargés à partir de 10 comptes. Lors de 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 courrier classifié n'avait été piraté. La reconstitution plus large du CSRB a identifié davantage de comptes du Département d'État consultés, reflétant différentes façons de compter l'accès aux comptes et le sous-ensemble à partir duquel des 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 officielles et personnelles de la Secrétaire au Commerce figuraient parmi celles affectées, selon le CSRB. La Chambre des représentants des États-Unis faisait également partie de l'ensemble affecté, y compris le membre du Congrès Don Bacon. En août 2023, uneenquête de la commission de surveillance de la Chambrea demandé des briefings au Département d'État et au 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 fonctionnaires 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 contemporain à 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 circonscrire l'incident en toute confiance ni décider quelles relations et décisions nécessitent une revalidation.

Quatrièmement, la continuité de la réponse: une compromission du fournisseur oblige les agences à détourner leurs capacités de sécurité, juridiques, diplomatiques, de gestion des documents et de direction. Même lorsque le courrier 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 par le gouvernement fédéral 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 également permettre à un seul 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 plus solide est que les achats et la supervision doivent chiffrer explicitement les défaillances d'identité de mode commun: la segmentation des clés, la détection d'anomalies côté fournisseur, l'accès à l'audit, la conservation des preuves, la notification d'incident, les tests indépendants et les dispositions de sortie ou de continuité devraient être traités comme des exigences de service.

Les conclusions du CSRB et pourquoi elles sont importantes

La page 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 conclusions principales sont sévères mais spécifiques.

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 en dehors 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 des domaines 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é les preuves.

Le comité a également fourni des contrefactuels concrets. Si la rotation manuelle n'avait pas été suspendue sans un remplacement automatisé terminé, ou si une alerte de clé vieillissante avait forcé l'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 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 conservation judiciaire plus longue avait existé, Microsoft aurait peut-être répondu à 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 matériellement:

• 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 sensible à 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 signature-domaine impossible.
• Des journaux client de base auraient permis à davantage de victimes de détecter et de circonscrire l'accès.
• Une conservation plus longue par le fournisseur aurait amélioré la confiance dans la cause racine.

C'est pourquoi le chemin de vol non résolu n'empêche pas l'analyse de la responsabilité. L'inconnu est important, mais plusieurs défaillances indépendamment suffisantes ou limitant l'impact sont documentées. Un fournisseur ne peut pas répondre à un lien de cause racine 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 strictes, 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 traitent une structure industrielle dans laquelle les fournisseurs détiennent à la fois le contrôle privilégié et les meilleures preuves.

La réponse de Microsoft

La réponse immédiate de Microsoft a corrigé les défauts connus de validation et de 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'isolation et affiné la surveillance du système de clés. Ces actions ont directement traité la campagne observée. Microsoft a également informé les organisations affectées et publié des indicateurs d'infrastructure pour les défenseurs.

L'entreprise a ensuite procédé à un changement de contrôle commercial en élargissant l'accès à l'audit. 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 conservation et des opérations du client.

En novembre 2023, Microsoft a lancé la Secure Future Initiative.Son annonce initiale de SFIs'est engagée à un système de gestion des clés unifié et entièrement automatisé pour les consommateurs et les entreprises, utilisant l'informatique confidentielle et des 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'est engagé à une rotation automatisée à haute fréquence sans accès humain.

Après le rapport du CSRB et une intrusion distincte de l'État russe dans les courriels d'entreprise de Microsoft, l'entreprise a élargi SFI en mai 2024.Le programme élargi de Microsofta fixé des objectifs comprenant 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 conservation 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 cadres supérieurs dépendrait des jalons de sécurité.

En juin 2024, le vice-président et président de Microsoft, Brad Smith, a déclaré à la commission de la sécurité intérieure de la Chambre que l'entreprise acceptait la responsabilité de chaque problème cité dans le rapport du CSRB.Son té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 à SFI, faisait la transition des systèmes d'identité grand public et entreprise vers un système de gestion des clés soutenu par le matériel, et avait progressé sur la rotation automatisée, les bibliothèques d'authentification communes et les signaux de validation des jetons.Le compte rendu de l'audience au Congrèsfournit le contexte de surveillance publique et les questions.

En septembre 2024, Microsoft a fait état d'un Conseil de gouvernance de la cybersécurité, de directeurs adjoints de la sécurité de l'information pour les divisions d'ingénierie, de la sécurité dans les évaluations de performance des employés, et d'un examen régulier par la direction et le conseil d'administration.La mise à jour des progrès de SFIde la société est une preuve des changements de gouvernance et des progrès déclarés dans la mise en œuvre.

Ces réponses sont des engagements substantiels. Elles doivent encore être décrites comme des engagements et des progrès déclarés par l'entreprise là où 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 nécessiterait 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 mode fermé, 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 carte de responsabilité utile commence par qui pouvait prévenir, détecter, limiter ou raccourcir chaque défaillance.

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

Le Département d'État contrôlait sa surveillance de locataire, sa logique d'alerte personnalisée, le tri, l'escalade et la coordination avec la CISA et le FBI. Il a exécuté ces tâches de manière suffisamment efficace 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é du client reste réelle, mais elle ne peut pas se substituer aux contrôles du fournisseur que les clients ne peuvent pas 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 s'appuyer sur 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 possibilité de prévention. 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 cadres 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 l'alerte n'ont pas reçu ou maintenu 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.La demande de juillet 2023 du sénateur Ron Wydena demandé au ministère de la Justice, à la Commission fédérale du commerce 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 de la loi. Aucun dossier public sourcé utilisé ici n'établit de jugement juridique définitif pour Storm-0558.

Ce que la remédiation durable devrait démontrer

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

Conservation et cycle de vie des clés

Microsoft devrait être en mesure de montrer que les clés de signature grand public et 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 dans 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.La documentation 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; elle ne rend pas chaque clé listée interchangeable pour chaque ressource. Les tests de conformité devraient intentionnellement présenter des jetons correctement signés mais dont la portée est erronée 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é mondiale 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 SFI, devraient constituer un plancher pour l'activité d'identité cloud de grande 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 probant, 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 racine sera modifié.

Assurance indépendante

Les rapports d'avancement de l'entreprise sont utiles mais insuffisants pour un plan de contrôle ayant une dépendance vis-à-vis du secteur public. Les clients fédéraux ont besoin de mécanismes d'assurance capables de tester la rotation, l'isolation des clés, la couverture du validateur, les performances des alertes et la conservation judiciaire sans exposer de secrets. Le but n'est pas la publication d'une architecture sensible. C'est 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, achetez des preuves, pas seulement des fonctionnalités. Les contrats et les bases de référence de service devraient identifier quels événements d'accès, d'identité, d'administration, de jeton et de boîte aux lettres sont disponibles; à quelle vitesse ils arrivent; combien de temps ils restent consultables; et si les clients peuvent les exporter. La journalisation devrait ê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 été important parce qu'il observait l'action protégée, et pas seulement la cérémonie d'authentification. Les environnements de grande valeur devraient établir une base de référence pour l'accès inhabituel aux boîtes aux lettres, les identifiants d'application, la géographie, le comportement du client 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 de locataire devrait savoir comment joindre 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 s'appuyer sur le canal de courrier potentiellement compromis.

Quatrièmement, traitez la concentration des identités comme un risque de continuité. Les acheteurs devraient 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 séparées, 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 sensibilisation rapide 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 devraient 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, optionnelles ou monétisées.

Évaluation

L'intrusion Storm-0558 dans Exchange Online était une défaillance d'identité cloud évitable avec un chemin d'acquisition initial de la clé non résolu. Les preuves publiques soutiennent avec une confiance élevée que Microsoft a laissé une ancienne clé de signature grand public rester de confiance, n'a pas réussi à faire 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 que la journalisation client verrouillée derrière une offre 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 à des 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 de la barrière de paiement pour la journalisation des événements principaux et le passage à une rotation automatisée soutenue par le 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'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 le client. Les grands fournisseurs peuvent déployer des contrôles, du renseignement et de la remédiation à une échelle que la plupart des clients ne peuvent pas. La leçon est que l'échelle concentre également l'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é du service. La disponibilité est nécessaire, mais la confidentialité, l'identité digne de confiance, les preuves reconstituables, la divulgation rapide et une voie crédible pour rétablir la confiance après une compromission côté fournisseur le sont tout autant. Storm-0558 a laissé Exchange Online fonctionner. Il a néanmoins perturbé le postulat sur lequel les gouvernements l'utilisaient.

C'est pourquoi l'incident mérite d'être enregistré comme une défaillance de responsabilité dans le cloud plutôt que comme une simple opération d'espionnage réussie de plus.