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 vaincu les contrôles de mot de passe d'une agence fédérale. Il a utilisé une clé de signature grand public de Microsoft pour fabriquer des jetons d'identité apparemment valides, puis a bénéficié d'un défaut de validation de Microsoft qui permettait à ces jetons signés par un consommateur d'atteindre les boîtes aux lettres Exchange Online de l'entreprise.
• Le chemin d'acquisition de la clé reste non résolu. L'explication du vidage sur incident de septembre 2023 de Microsoft a ensuite été réduite à une hypothèse principale après que l'entreprise a reconnu n'avoir trouvé ni vidage contenant la clé ni journaux prouvant l'exfiltration. La clé obsolète, le défaut de validation transfrontalière, la faible détection des anomalies de jeton 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 pivoter 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 à des licences E5/G5 plus chères.

Un échec du contrôle d'identité, pas une violation de boîte aux lettres classique

L'intrusion de Storm-0558 se laisse facilement résumer en une phrase familière: des hackers chinois ont volé une clé Microsoft et lu des courriels gouvernementaux. Cette phrase est approximativement vraie mais analytiquement insuffisante. Elle fusionne en un seul événement l'acte de l'attaquant, la perte non résolue de matériel cryptographique par Microsoft, un défaut logiciel distinct de validation, une décision de cycle de vie d'une clé obsolète, une réussite de détection côté client et la réponse du fournisseur de services. Une fois ces mécanismes séparés, la répartition des responsabilités devient beaucoup plus claire.

L'intrusion n'était pas principalement un cas où un employé gouvernemental a cédé un mot de passe, une agence n'ayant pas déployé l'authentification multifacteur, ou un serveur non corrigé situé à l'intérieur d'un ministère. Storm-0558 possédait la moitié privée d'une clé de signature grand public Microsoft Account (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 second défaut de Microsoft a permis qu'une clé destinée aux comptes grand public authentifie des requêtes contre 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 en présentant un précédemment émis par cette interface. Il ne s'agissait pas simplement d'une relecture d'identifiants volés. C'était la fabrication et le renouvellement non autorisés d'identifiants que les services de Microsoft traitaient comme valides.

La distinction est importante pour la responsabilité du 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 pivoter le matériel de signature racine d'un fournisseur de cloud, corriger le validateur de jetons de production du fournisseur, ou déployer un détecteur à l'intérieur du 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 sauvegarde obscurcit plus qu'il n'explique.

Il est également important de ne pas classer l'événement comme une panne de service. Le dossier public ne montre pas Exchange Online devenu indisponible pour les agences concernées. Le préjudice était une perte de confidentialité et de communications de confiance, suivie d'une charge d'enquête substantielle. La continuité du secteur public inclut 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 fiable.

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

Trois catégories de preuves doivent rester séparées.

Premièrement, le dossier public établit fermement que Storm-0558 a utilisé une clé de signature grand public MSA créée par Microsoft en 2016 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 trouvé une activité suspecte grâce à des journaux d'accès aux boîtes aux lettres améliorés; 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 concernées et la reconstruction du Cyber Safety Review Board convergent sur ces points.

Deuxièmement, le Cyber Safety Review Board (CSRB) a fait des constatations sur la préventibilité, la conception des contrôles, la culture de sécurité, la divulgation et la pratique industrielle. Sonexamen complet de l'intrusion de l'été 2023a conclu que l'incident était évitable et n'aurait jamais dû se produire. Le Conseil a interviewé 20 organisations, reçu la coopération de Microsoft, comparé les contrôles chez d'autres grands fournisseurs de services cloud, et trouvé une cascade de défaillances évitables. Ce sont des conclusions d'examen indépendant, pas des conclusions judiciaires, mais elles sont substantiellement 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 le dossier public. Cette incertitude est centrale. Microsoft a publié une histoire détaillée de vidage sur incident en septembre 2023, puis a ajouté une correction en mars 2024 indiquant qu'il n'avait pas trouvé de vidage contenant le matériel de clé impacté. Le CSRB a rapporté que Microsoft a exploré 46 hypothèses de vol de clé et ne sait toujours pas comment ou quand l'acteur a obtenu la clé. Tout récit qui présente le vidage sur incident comme la cause racine prouvée exagère les preuves.

Le dossier n'établit pas non plus une répartition 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 de tribunal, une décision d'application de l'agence, une interprétation contractuelle ou une analyse quantifiée des dommages.

La conclusion appropriée est plus étroite: Microsoft contrôlait plusieurs sauvegardes défaillantes et a accepté la responsabilité pour les problèmes cités par le CSRB; les sources disponibles n'établissent pas une responsabilité civile, pénale ou réglementaire définitive.

Chronologie forensique

2016-2021: une clé de longue durée 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 l'âge de la clé devient matériel 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 ensuite déployé ni un remplacement de rotation automatisé ni une alerte qui informerait 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 disponibilité contre sécurité avec un coût différé caché: suspendre une procédure manuelle risquée peut réduire le risque immédiat de panne, mais laisser l'automatisation compensatoire inachevée préserve l'exposition de sécurité indéfiniment.

La constatation du Conseil est plus utile que de dire simplement 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. Lesdirectives actuelles de roulement de clés de signature de Microsoftdisent que les applications doivent gérer le roulement périodique et d'urgence par programmation 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é conçue, pas 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 des métadonnées de clé en réponse à la demande d'applications servant à la fois les utilisateurs grand public et d'entreprise. Le récit ultérieur de Microsoft a indiqué que la documentation avait été mise à jour pour expliquer la validation de la portée de la clé, mais que les bibliothèques d'assistance 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 danger 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 un compte d'ingénieur entre avril et août. L'ingénieur travaillait pour Affirmed Networks, que Microsoft avait acquise en 2020; Microsoft croyait 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, y compris des informations relatives à la gestion des services Azure et à l'identité.

Le Conseil 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 obtenu la clé MSA de 2016 à ce moment-là. Microsoft a dit au Conseil 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 dans la mémoire enregistrée, mais l'entreprise n'a produit aucune preuve spécifique la reliant au vol de la clé. Un récit discipliné 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 aux comptes Exchange Online ciblés à partir du 15 mai 2023. Le CSRB a mis en garde que la fenêtre de compromission aurait pu commencer plus tôt car la rétention standard de 30 jours des journaux de Microsoft a limité la vue rétrospective disponible une fois l'enquête commencée. « Première observation » est donc une limite probatoire, 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 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 pour l'Asie de l'Est et le 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 comptes grand public associés. La différence est mieux traitée comme un changement dans la comptabilité de l'incident entre un premier avis de l'entreprise et la reconstruction indépendante ultérieure, pas comme une 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é de l'É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 la boîte aux lettres Exchange Online. L'État a enquêté malgré la possibilité de faux positifs et a contacté Microsoft ce jour-là. Le 19 juin, l'É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 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 le confinement ont chevauché l'accès en cours. L'alerte de l'État était un succès de détection, mais elle n'a pas instantanément révélé un identifiant de plateforme forgé. Microsoft a d'abord examiné des explications familières telles que des appareils compromis et des jetons correctement émis volés. Ses analystes ont ensuite vu que les artefacts d'authentification Exchange Online ne correspondaient pas aux jetons Azure AD dans les journaux attendus.

Le 26 juin environ, Microsoft a déterminé que l'acteur utilisait la clé grand public de 2016 pour créer des jetons qui fonctionnaient contre les courriels grand public et d'entreprise.

L'avis conjoint CISA-FBI AA23-193Aest inhabituellement direct sur la répartition des capacités d'atténuation. Il indique que toutes les actions d'atténuation pour cette activité étaient la responsabilité de Microsoft car l'infrastructure affectée était basée sur le cloud. Il indique également que les agences n'étaient pas au courant 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: 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 le renouvellement, fermant le comportement de renouvellement que 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 accès supplémentaire aux courriels d'entreprise via la voie observée.
• 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 jetons forgés peut impliquer des métadonnées de validation mises 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 pivoter vers le hameçonnage et d'autres techniques après le blocage de la voie de falsification de jetons connue, et n'avoir vu aucune autre activité liée à la clé. Cela soutient l'efficacité des atténuations immédiates contre la méthode observée. Cela ne prouve pas que la voie d'acquisition originale a été identifiée ou 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 la cause racine

Microsoft a divulgué publiquement la campagne le 11 juillet et a 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'accès détaillé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 rétention par défaut pour Audit Standard passerait de 90 à 180 jours. L'annonce de journalisation de Microsoftest une réponse matérielle 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'il a appelé les résultats de ses principales enquêtes techniques. Le récit original affirmait qu'un crash du système de signature grand public en avril 2021 avait produit un vidage sur incident; qu'une condition de concurrence avait permis à la clé d'entrer 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 d'identifiants l'avaient manqué; et que Storm-0558 avait ensuite compromis un compte d'ingénieur ayant accès à cet environnement.

Parce que les journaux pertinents avaient expiré, Microsoft a appelé cela le 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é dit que son hypothèse principale reste que des erreurs opérationnelles ont causé la sortie du matériel de clé de l'environnement de signature sécurisé et que le matériel a été accédé via un compte d'ingénieur compromis. Elle dit également qu'elle n'a pas trouvé de vidage sur incident contenant la clé impactée, que la condition de concurrence citée affectait si un vidage pouvait quitter l'environnement de signature plutôt que si le matériel de clé pouvait être présent, et que la suppression de ce matériel n'était pas un processus standard mais n'avait pas été 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 rapporté que Microsoft a dit au Conseil en novembre 2023 qu'il avait réalisé peu après la publication que les déclarations de septembre étaient inexactes, mais n'a publié la correction qu'en mars 2024 après des questions répétées du Conseil. Ce retard est devenu partie de la constatation du Conseil sur la culture de sécurité, car les clients utilisent les divulgations de cause racine pour juger si la voie d'acquisition réelle a été fermée.

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

L'analyse d'incident est plus précise lorsqu'elle sépare le déclencheur des causes racines et des échecs de détection et de réponse.

Déclencheur

Le déclencheur opérationnel était l'utilisation par Storm-0558 de la clé de signature privée MSA 2016 volée pour créer des jetons et les présenter via les voies d'accès Exchange Online. L'acteur a sélectionné des cibles, exploité une infrastructure, frappé 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 de renseignement rapportée par Microsoft et le CSRB; cet article n'attribue pas indépendamment le commandement de l'État.

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, non comblé par l'hypothèse du vidage sur incident.

La deuxième cause est beaucoup mieux établie: l'ancienne clé est restée de confiance. La rotation manuelle des clés grand public a cessé 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 réduite. 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 portée de validation des jetons. Le service a vérifié une signature par rapport au matériel de clé disponible via les métadonnées communes mais n'a pas prouvé 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 validation des jetons d'accès de Microsoftdit 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, 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 que l'identité forgée a été acceptée via un flux légitime, GetAccessTokenForResource a permis à un jeton d'en obtenir un autre d'une manière que Microsoft a ensuite modifiée pour distinguer l'émission Azure AD et MSA. Cela n'a pas créé la capacité de signature originale, mais cela a rendu la voie d'accès plus utile et durable.

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

Le CSRB a constaté que d'autres fournisseurs de cloud avaient des contrôles qui manquaient à Microsoft 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 forgées même lorsqu'une signature vérifie.

Échecs 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é à l'échelle du système instable. Des milliers de clients ne peuvent pas être censés reconstruire une compromission cryptographique d'un fournisseur à partir d'événements de boîte aux lettres facultatifs, 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. L'État disposait de G5 et pouvait créer Big Yellow Taxi. D'autres victimes sans journalisation premium manquaient de 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 conception sécurisée par défaut dans ladéclaration de la CISA du 19 juillet.

La réponse a également été contrainte 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 30 jours limitaient l'activité client observable la plus ancienne, tandis que les événements plus anciens d'entreprise et de production nécessaires pour l'hypothèse de 2021 étaient indisponibles.

La rétention des journaux comporte toujours des obligations de coût, de confidentialité et de contrôle d'accès, mais un fournisseur ne peut pas prétendre de manière crédible protéger les joyaux de la couronne 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 était un échec de réponse. Elle n'a pas permis l'intrusion originale, 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 à sonorité complète et ne le corriger que six mois plus tard a rendu plus difficile pour les clients et les superviseurs de déterminer si la correction traitait la voie réelle.

Le problème de la journalisation et des licences

La journalisation est parfois traitée comme une fonctionnalité de produit auxiliaire. Dans cet incident, c'é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é indisponibles 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 provenait de MailItemsAccessed, un événement conçu pour montrer quand les éléments de la 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 sans l'événement pouvait encore remarquer des signes contextuels, mais il manquait de 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, de l'automatisation, une rétention longue et une enquête gérée. La preuve minimale nécessaire pour savoir si un service exploité par un fournisseur a accédé aux données du client 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, le client est invité à acheter une visibilité sur un risque qu'il ne peut pas corriger directement.

Le changement post-incident reconnaît cette distinction. Microsoft s'est engagé à mettre à disposition des journaux de sécurité cloud plus larges dans le monde entier sans coût supplémentaire, à ajouter des événements d'accès détaillé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 élargie 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é des journaux d'audit de haute qualité sans frais supplémentaires ni configuration comme une attente de conception sécurisée par défaut.

La réforme n'élimine pas la responsabilité du client. Les journaux doivent être acheminés vers des systèmes interrogeables, conservés selon les exigences de risque et légales, établis comme base, 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 émet l'événement pertinent et le rend accessible. La disponibilité de la télémétrie et l'utilisation de la télémétrie sont deux contrôles distincts appartenant à des parties différentes.

Les licences ont également affecté l'égalité forensique entre les victimes. L'environnement G5 de l'État disposait d'un 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 quant à l'impact en fonction de l'abonnement du client, même si aucun des deux clients ne contrôlait la clé de signature sous-jacente.

Les preuves forensiques minimales devraient donc être traitées comme faisant partie de la base de référence de sécurité du service, pas simplement comme une vente incitative.

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

La compromission a affecté les courriels non classifiés, mais « non classifié » ne signifie pas opérationnellement trivial. Les boîtes aux lettres des hauts responsables contiennent des calendriers, des délibérations politiques, des réseaux de contacts, des positions de négociation, des projets 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 ensuite déclaré 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 concerné comme non classifié et a déclaré qu'aucun système de courriel classifié n'avait été piraté. La reconstruction plus large du CSRB a identifié plus de comptes de l'État 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 n'infère 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 étaient 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 représentant Don Bacon. Uneenquête de la Chambre des représentants d'août 2023a demandé des briefings à l'É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é à cause de l'intrusion.

La continuité dans ce contexte comporte 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 sont 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 une politique économique 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 reconstruire qui a accédé à quoi et quand. Sans cela, les dirigeants ne peuvent pas délimiter avec confiance l'incident ou 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 les capacités de sécurité, juridiques, diplomatiques, d'archives et de direction. Même lorsque les courriels restent disponibles, le travail de la mission subit 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é un risque de concentration. Microsoft fournit des services d'identité, de courriel, de productivité, de système d'exploitation, de sécurité et de cloud dans 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 seul défaut d'identité côté fournisseur de traverser 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 courriel dupliqués. 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 solide est que les achats et la surveillance doivent explicitement évaluer le risque de défaillance d'identité en mode commun: la segmentation des clés, la détection des anomalies côté fournisseur, l'accès aux audits, la rétention des preuves, la notification des incidents, les tests indépendants et les arrangements de sortie ou de continuité doivent être traités comme des exigences de service.

Les constatations du CSRB et pourquoi elles comptent

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

Le Conseil a conclu que la culture de sécurité de Microsoft était inadéquate et nécessitait une refonte. Il a basé cette conclusion sur la cascade évitable, l'échec à 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 chez 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 constatation est organisationnelle car aucune seule erreur de codage 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 alerté, pourquoi les preuves étaient indisponibles, et pourquoi une affirmation causale a dépassé la preuve.

Le Conseil a également fourni des contrefactuels concrets. Si la rotation manuelle n'avait pas été interrompue sans un remplacement automatisé achevé, ou si une alerte de vieillissement de clé 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 d'entreprise. Si Microsoft avait détecté des jetons qui ne correspondaient pas à 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 forensique plus forte 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 de l'entreprise ou la raccourcir matériellement:

• Une garde sécurisée aurait pu empêcher la perte de 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 surface la combinaison impossible de domaine de signature.
• Des journaux clients de base auraient permis à 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 racine.

C'est pourquoi la voie de vol non résolue 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 maillon manquant de cause racine en traitant toute la chaîne comme inconnaissable.

Les recommandations du Conseil s'étendaient 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 matériel, des bibliothèques d'authentification communes, des normes d'identité numérique plus fortes, une journalisation minimale des clients 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.

La 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é, augmenté l'isolement et affiné la surveillance du système de clés. Ces actions ont directement traité la campagne observée. Microsoft a également notifié les organisations affectées et publié des indicateurs d'infrastructure pour les défenseurs.

L'entreprise a ensuite effectué un changement de contrôle commercial en élargissant l'accès aux audits. Cette action est indépendamment observable 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 du client.

En novembre 2023, Microsoft a lancé la Secure Future Initiative. Sonannonce initiale de SFIs'est engagée à un système de gestion des clés unifié, entièrement automatisé, pour les consommateurs et les entreprises, utilisant le calcul confidentiel 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 compagnon s'est engagé à 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, l'entreprise a élargi SFI en mai 2024. Leprogramme élargia 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 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 déclaré qu'une partie de la rémunération de la haute direction dépendrait d'étapes de sécurité.

En juin 2024, le vice-président et président de Microsoft, Brad Smith, a déclaré au Comité 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. Sontémoignage écrita indiqué que Microsoft agissait sur les 16 recommandations du Conseil applicables à l'entreprise, avait dédié l'équivalent de 34 000 ingénieurs à temps plein à SFI, transitionnait les systèmes d'identité grand public et d'entreprise vers un système de gestion des clés soutenu par du matériel, et avait réalisé des progrès sur la rotation automatisée, les bibliothèques d'authentification communes et les signaux de validation de jetons. Lecompte rendu de l'audience du Congrèsfournit le contexte de surveillance publique et les questions.

En septembre 2024, Microsoft a rapporté un conseil de gouvernance de la cybersécurité, des responsables adjoints de la sécurité de l'information pour les divisions d'ingénierie, la sécurité dans les évaluations de performance des employés et un examen régulier par la direction et le conseil d'administration. Lamise à jour des progrès de SFIde l'entreprise 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. Elles devraient encore être décrites comme des engagements et des progrès rapportés par l'entreprise là où une 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, des preuves que les validateurs existants 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 de clé, et une assurance externe que les exceptions ne peuvent pas persister silencieusement.

Responsabilité par capacité de contrôle

Une carte utile de la responsabilité 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 et l'ensemble de confiance de production des clés. Il contrôlait l'architecture de métadonnées communes, les bibliothèques d'assistance, 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 rétention des preuves internes de production et d'entreprise. Il contrôlait également l'exactitude et le calendrier des divulgations techniques publiques. La responsabilité pour ces surfaces incombe principalement à Microsoft.

Le Département d'État contrôlait la surveillance de son locataire, la logique d'alerte personnalisée, le triage, l'escalade et la coordination avec la CISA et le FBI. Il a effectué ces tâches assez 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é du client reste réelle, mais elle ne peut pas se substituer aux contrôles du fournisseur que les clients ne peuvent pas voir ou 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 directives de configuration, les attentes contractuelles, la coordination interagences et le levier pour exiger des valeurs par défaut plus sûres. Leur travail de journalisation post-incident a réduit une inégalité. Un régime d'achat mature ne devrait pas compter 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 préventibilité. Les enquêtes de sécurité examinent systématiquement 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 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 à des étapes 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.

La répartition 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 juridiction réglementaire varient. Lademande de juillet 2023 du sénateur Ron Wydena demandé 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, pas une preuve que les agences sollicitées ont abouti à une conclusion d'application de la loi. Aucun dossier public sourcé utilisé ici n'établit un jugement juridique définitif pour Storm-0558.

Ce qu'une correction durable devrait prouver

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

Garde et cycle de vie des clés

Microsoft devrait être en mesure de montrer que les clés de signature grand public et d'entreprise sont générées et utilisées à l'intérieur de systèmes protégés par matériel, ne peuvent pas être exportées vers des environnements de débogage ou généraux d'entreprise, tournent automatiquement à une fréquence proportionnée à leur pouvoir, et génèrent des alertes actionnables 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 de confiance 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é répertoriée interchangeable pour chaque ressource. Les tests de conformité devraient intentionnellement présenter des jetons correctement signés mais mal cadrés et vérifier le rejet.

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

Un jeton porteur à signature unique peut rester convaincant après le vol de la clé de signature. La validation avec état, les approches de preuve de possession, les marqueurs d'émission propriétaires, les durées de vie limitées et la révocation rapide peuvent réduire ce risque. L'objectif n'est pas d'abandonner les normes mais de garantir 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 tout le service et préserver les preuves internes assez longtemps pour les campagnes sophistiquées. Les clients devraient recevoir par défaut des événements d'accès à la boîte aux lettres et d'identité, sans passerelle 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 être un plancher pour l'activité d'identité cloud de grande valeur plutôt qu'un plafond ambitieux.

Communication des incidents

Les divulgations techniques devraient porter 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 devrait être rapide et visible. Un fournisseur ne devrait pas avoir besoin qu'un organe de surveillance demande à plusieurs reprises si un récit de cause racine inexact sera amendé.

Assurance indépendante

Les rapports de progrès de l'entreprise sont utiles mais insuffisants pour un plan de contrôle dépendant 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 forensique sans exposer les secrets. Le point n'est pas la publication d'une architecture sensible. C'est la preuve que les contrôles déclarés fonctionnent dans la production, y compris les systèmes existants 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é, administratifs, de jeton 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 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 forgé 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 seulement la cérémonie d'authentification. Les environnements de grande valeur devraient établir une base de référence pour les accès inhabituels à la boîte aux lettres, les identifiants d'application, la géographie, le comportement du client et le volume d'accès.

Troisièmement, maintenez une voie d'escalade qui suppose que le fournisseur peut faire partie de l'incident. Une équipe locataire devrait 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 courriel potentiellement compromis.

Quatrièmement, traitez la concentration de l'identité 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 aussi utile que la capacité du fournisseur à les identifier. Dans Storm-0558, seul Microsoft pouvait identifier la plupart des victimes car les jetons forgés opéraient à l'intérieur de son service. Cela fait de la télémétrie à l'échelle du fournisseur et de la sensibilisation en temps opportun une partie de l'architecture de détection du client.

Enfin, ne confondez pas responsabilité partagée et capacité égale. Les clients devraient sécuriser ce qu'ils contrôlent. Les fournisseurs devraient ê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, facultatives ou monétisées.

Évaluation

L'intrusion Storm-0558 dans Exchange Online était un échec évitable de l'identité cloud avec une voie d'acquisition de clé initiale non résolue. Les preuves publiques soutiennent une conclusion de 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 d'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 reconstruire la fuite de la clé.

Elles soutiennent également une conclusion que la journalisation client premium a façonné de manière matérielle qui pouvait détecter et enquêter sur la campagne.

La réponse de Microsoft a traité la voie d'accès observée 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. De même, la suppression du péage de journalisation pour les événements de base et le passage à une rotation automatisée soutenue par matériel. La question de responsabilité restante est de savoir si ces changements sont complets, durables et indépendamment vérifiables dans l'infrastructure d'identité existante 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 exploités par les clients. Les grands fournisseurs peuvent déployer des contrôles, du renseignement et des corrections à 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 des clés du fournisseur et des 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 aussi la confidentialité, une identité de confiance, des preuves reconstructibles, une divulgation rapide et une voie crédible pour restaurer la confiance après une compromission côté fournisseur. Storm-0558 a laissé Exchange Online en fonctionnement. Il a néanmoins perturbé le prémisses sur lesquelles les gouvernements l'utilisaient. C'est pourquoi l'incident appartient au dossier en tant qu'échec de responsabilité du cloud plutôt que simplement une autre opération d'espionnage réussie.