Microsoft Storm-0558: le contrôle opérationnel des jetons comme test de responsabilité publique

Résumé

• Storm-0558 a utilisé une clé de signature grand public de Microsoft et une défaillance de validation pour accéder à des boîtes aux lettres Exchange Online d'entreprise. Cela a fait du contrôle opérationnel des dommages une responsabilité principalement côté fournisseur, car les clients ne pouvaient pas faire tourner la clé de Microsoft, corriger le validateur de jetons de Microsoft ni inspecter l'environnement de signature interne de Microsoft.
• Le test de responsabilité publique le plus important est survenu après la défaillance de confiance: la rapidité avec laquelle Microsoft a pu identifier le chemin des jetons falsifiés, arrêter le renouvellement des jetons, bloquer l'acceptation de la clé, remplacer le matériel de signature, étendre les journaux clients et expliquer ce qui restait inconnu.
• Le Cyber Safety Review Board a conclu par la suite que l'incident était évitable et a critiqué la culture de sécurité de Microsoft, la gestion des clés, les contrôles de validation, l'accès à la journalisation et la correction d'une explication antérieure sur l'acquisition de la clé. Microsoft a accepté les conclusions du CSRB et a annoncé des travaux dans le cadre de la Secure Future Initiative, mais une grande partie des preuves de mise en œuvre reste autodéclarée par le fournisseur.
• Le chemin d'acquisition non résolu est important. Le récit de Microsoft sur l'image mémoire a été réduit à une hypothèse principale après que la société a déclaré ne pas avoir trouvé d'image mémoire contenant la clé concernée. La responsabilité repose donc sur des défaillances de contrôle avérées et une incertitude résiduelle, et non sur une chaîne de vol entièrement prouvée.

Carte des preuves

Les dommages liés aux jetons sont un mode de défaillance contrôlé par le fournisseur

Storm-0558 est souvent décrit à travers l'objet le plus dramatique: une clé de signature grand public Microsoft créée en 2016. La clé était importante. Une clé de signature privée permet à un acteur de créer des jetons que les services peuvent accepter si les règles de validation échouent. Mais le test de responsabilité est plus large que le vol d'une clé.

Il inclut la durée pendant laquelle la clé est restée approuvée, la manière dont les services ont validé l'émetteur et la portée des jetons, le comportement des chemins de renouvellement, la détection ou non de combinaisons de jetons impossibles, et la capacité des clients à voir les preuves d'accès aux boîtes aux lettres. Ces contrôles incombaient largement à Microsoft.

C'est pourquoi le contrôle opérationnel des dommages est le prisme central. Les clients peuvent renforcer les comptes, exiger une authentification multifactorielle, réduire les privilèges, surveiller les journaux et réagir rapidement. Ils ne peuvent pas faire tourner les clés de signature internes de Microsoft. Ils ne peuvent pas modifier le code de validation côté serveur d'Exchange Online. Ils ne peuvent pas voir tous les chemins d'émission de jetons internes. Ils ne peuvent pas conserver les images mémoire internes de Microsoft ou les journaux de l'environnement de signature.

Lorsque l'infrastructure de confiance d'un fournisseur cloud échoue, la capacité du client à prévenir le premier préjudice est fortement limitée.

L'avis CISA-FBI a rendu cette répartition inhabituellement explicite. Il indiquait que les mesures d'atténuation de l'activité incombaient à Microsoft car l'infrastructure concernée était basée sur le cloud. Cette phrase est importante. Elle ne signifie pas que les clients n'avaient aucun rôle dans la détection ou la réponse. La détection par le Département d'État a été cruciale. Elle signifie que les actions de confinement décisives étaient du côté du fournisseur: cesser d'accepter le chemin falsifié, bloquer la clé, remplacer le matériel de signature et étendre les preuves. C'est cela, le contrôle opérationnel des dommages.

L'événement n'était pas une compromission ordinaire de boîte aux lettres. Storm-0558 n'a pas eu besoin de hameçonner le mot de passe de chaque cible. Il a abusé d'une décision de confiance d'identité cloud. Cela rend le préjudice public d'une manière qui dépasse les organisations victimes. Les gouvernements, les entreprises réglementées et le public s'appuient sur le plan d'identité du fournisseur comme infrastructure partagée. Si une frontière de jetons contrôlée par le fournisseur échoue, la responsabilité ne peut pas être réduite à la configuration du client.

Le dossier public exige également de la précision. L'incident a principalement été une défaillance de confidentialité et de communications de confiance, et non une panne de disponibilité d'Exchange Online. Le courrier a continué à fonctionner. Le préjudice a été un accès silencieux aux messages et la perte de confiance dans le fait que la frontière d'identité du service avait tenu. La continuité du secteur public inclut ce type de préjudice. Une boîte aux lettres diplomatique peut rester joignable alors que son contenu est compromis.

Le récit de l'acquisition de la clé est resté non résolu

L'article de Microsoft de septembre 2023 sur l'acquisition de la clé proposait initialement un compte rendu détaillé impliquant une image mémoire. Il décrivait un plantage d'avril 2021 dans un système de signature grand public, une image mémoire qui avait été transférée vers un environnement de débogage d'entreprise, une analyse des informations d'identification qui n'avait pas détecté le matériel de clé, et une compromission ultérieure du compte d'un ingénieur. Ce récit est devenu une explication publique de la cause racine. En mars 2024, Microsoft a ajouté une correction réduisant cette affirmation.

La société a déclaré n'avoir trouvé aucune image mémoire contenant la clé concernée et que le scénario de l'image mémoire restait une hypothèse principale plutôt qu'un fait avéré.

Le CSRB a fait de cette incertitude un point central. Il a rapporté que Microsoft avait enquêté sur de nombreuses hypothèses et ne savait toujours pas exactement comment ni quand Storm-0558 avait obtenu la clé privée MSA de 2016. Ce chemin non résolu n'est pas un détail secondaire. Si la voie d'acquisition est inconnue, le fournisseur ne peut pas prouver publiquement que le même chemin a été entièrement fermé. Il peut renforcer la gestion des clés, isoler les systèmes de signature, améliorer les journaux, automatiser la rotation et réduire le rayon d'action futur. Ce sont de véritables contrôles.

Ils n'établissent pas rétroactivement la chaîne de vol.

La responsabilité doit donc reposer sur deux catégories. La première est une défaillance avérée ou fortement étayée: une clé périmée est restée approuvée, la validation a échoué à la frontière entre le grand public et l'entreprise, les journaux améliorés n'étaient pas largement disponibles pour les clients, et la première explication publique de Microsoft a surestimé la certitude du chemin d'acquisition. La seconde est l'incertitude résiduelle: comment exactement la clé a quitté le contrôle de Microsoft, si du matériel sensible connexe a été exposé, et si une piste de preuves interne complète a jamais existé.

Cette distinction n'est pas un pédantisme. Les clients utilisent les explications de cause racine pour décider si la remédiation correspond à la défaillance. Si le chemin de l'image mémoire est prouvé, alors la gestion des images mémoire et l'accès de débogage d'entreprise deviennent les points de fermeture directs. Si le chemin est inconnu, la remédiation doit être plus large: isolation des clés, rotation, inventaire, journalisation, validation des jetons, moindre privilège, contrôles de l'environnement développeur et vérification indépendante. La charge d'assurance publique est plus élevée lorsque le chemin n'est pas résolu.

La correction de Microsoft est également devenue un élément du dossier de responsabilité en raison du timing. Le CSRB a rapporté que Microsoft avait réalisé que l'explication de septembre était inexacte avant la correction publique de mars. Un fournisseur peut commettre une erreur de bonne foi dans une explication d'incident. Le devoir après avoir découvert l'erreur est de la corriger rapidement et clairement. Dans une infrastructure de confiance cloud, une histoire de cause racine inexacte peut induire les clients en erreur sur la fermeture du chemin de préjudice central.

Le contrôle des dommages a commencé par des actions de validation et de clé

La séquence d'atténuation publique montre que le confinement n'était pas un simple interrupteur. Microsoft a déclaré avoir empêché OWA d'accepter les jetons émis par GetAccessTokenForResource pour le renouvellement, bloqué l'utilisation par OWA des jetons signés avec la clé MSA acquise, remplacé la clé, révoqué les clés de signature MSA qui étaient valides pendant l'incident, émis de nouvelles clés à partir de systèmes renforcés et bloqué l'utilisation pour les clients grand public affectés afin d'empêcher l'utilisation de jetons précédemment émis. Il s'agissait d'un programme de contrôle des dommages par étapes.

Cette séquence illustre le préjudice lié aux jetons. Une campagne de jetons falsifiés peut persister via le comportement de renouvellement, les métadonnées en cache, les services en aval, les jetons précédemment émis et les frontières de confiance entre le grand public et l'entreprise. Un fournisseur doit trouver tous les endroits où la mauvaise décision de confiance survit. Le blocage d'un chemin peut empêcher la création future tout en laissant les jetons existants utilisables. La rotation d'une clé peut ne pas invalider immédiatement chaque artefact si les services mettent en cache les clés ou les jetons.

Les points de terminaison de renouvellement peuvent prolonger le préjudice s'ils ne sont pas fermés.

Les clients doivent comprendre cette séquence car elle affecte l'enquête. Une boîte aux lettres consultée avant le remplacement de la clé peut encore nécessiter un examen même si le chemin est fermé plus tard. Un jeton accepté par un service mais pas par un autre peut réduire la portée. Un chemin de renouvellement modifie la durée d'accès. La divulgation publique doit donc décrire non seulement que le problème a été atténué, mais aussi quelles décisions de confiance ont été modifiées et quelles preuves résiduelles client restent pertinentes.

Les rapports techniques de Microsoft ont fourni une séquence d'atténuation plus claire que de nombreuses divulgations d'incidents. C'est une force. La limitation publique est que les clients devaient toujours compter sur Microsoft pour les preuves côté service. Ils ne pouvaient pas vérifier indépendamment chaque modification de validation interne ou l'effet de la révocation de clé. C'est la nature des infrastructures de confiance cloud. Cela augmente la charge du fournisseur de publier des explications précises, testables et corrigées.

L'incident montre aussi pourquoi l'âge de la clé compte comme un risque opérationnel, pas seulement une hygiène cryptographique. Une clé à longue durée de vie qui reste approuvée au-delà de son cycle de vie prévu donne à un attaquant une cible de valeur plus grande et une fenêtre d'utilité potentielle plus longue. Le CSRB a constaté que la rotation des clés de signature grand public de Microsoft était devenue manuelle, puis interrompue après une crainte de panne, sans remplacement automatisé achevé. C'est un compromis disponibilité-sécurité dont le coût différé est apparu dans un incident de confidentialité.

Le contrôle opérationnel des dommages inclut le fait de rendre la rotation des clés suffisamment banale pour que la peur d'une panne ne gèle pas le cycle de vie de la sécurité.

La journalisation était le pivot de la responsabilité publique

Le Département d'État a détecté une activité suspecte grâce aux journaux améliorés d'accès aux boîtes aux lettres. Ce fait a changé l'incident. Il a montré que les clients pouvaient fournir un signal crucial même lorsque le fournisseur contrôlait l'atténuation. Il a également exposé un problème de licence. À l'époque, l'avis CISA-FBI soulignait l'importance des événements d'audit MailItemsAccessed et notait que la journalisation pertinente était liée à des licences de niveau supérieur. La CISA a par la suite salué publiquement l'engagement de Microsoft à étendre les journaux importants sans coût supplémentaire.

La journalisation n'est pas seulement une fonctionnalité client. C'est une infrastructure de contrôle des dommages. Si les clients ne peuvent pas voir l'accès aux éléments de boîte aux lettres, ils ne peuvent pas détecter de manière fiable un abus d'une défaillance de jeton provenant du fournisseur. Si les journaux sont conservés trop brièvement, la découverte après coup est limitée par ce qui existe encore. Si les événements critiques sont proposés comme fonctionnalités premium, les clients de niveau inférieur peuvent avoir des preuves plus faibles précisément au moment où ils ont le plus besoin de la responsabilité du fournisseur.

L'annonce de Microsoft de juillet 2023 sur la journalisation s'est engagée à élargir l'accès aux journaux détaillés d'accès aux courriels et à plus de 30 autres événements d'audit pour les clients standard, et à augmenter la rétention par défaut d'Audit Standard de 90 à 180 jours. La CISA, l'OMB, l'ONCD et Microsoft ont ensuite annoncé une journalisation étendue pour les agences fédérales, avec activation automatique et rétention par défaut de 180 jours. Ces changements étaient substantiels car ils ont fait passer les preuves d'un module complémentaire payant à une attente de sécurité de base.

La leçon de responsabilité est plus large qu'un seul type de journal. Les fournisseurs cloud doivent traiter les journaux nécessaires pour détecter les défaillances de contrôle côté fournisseur comme faisant partie de la couche de sécurité du service. Les clients ne devraient pas avoir à acheter une visibilité premium pour découvrir qu'une clé ou un défaut de validation du fournisseur a été exploité. Les fournisseurs peuvent facturer des analyses avancées, le stockage et la détection gérée. Mais les événements de sécurité bruts nécessaires pour reconstituer l'accès aux données client appartiennent à la base de référence.

L'incident a également montré que la détection peut venir d'un client avant que le fournisseur ne comprenne la défaillance. Le Département d'État a vu des anomalies. Microsoft a ensuite enquêté et identifié le chemin des jetons falsifiés. Cette séquence n'est saine que si les clients disposent de suffisamment de journaux pour donner l'alerte et de canaux pour escalader. Sans la journalisation améliorée et l'enquête du Département d'État, le calendrier public aurait pu être pire. L'atténuation contrôlée par le fournisseur n'efface pas le succès de la détection par le client.

La continuité du secteur public inclut les communications de confiance

Les comptes affectés comprenaient des boîtes aux lettres du secteur public et gouvernementales. Le Département d'État a déclaré plus tard que près de 60 000 courriels avaient été téléchargés à partir de 10 comptes et que le système compromis était non classifié, le courrier classifié n'ayant pas été piraté. Le CSRB a identifié 22 organisations et plus de 500 individus affectés dans le monde. Ces détails cadrent le préjudice avec soin: il ne s'agissait pas d'un effondrement de la disponibilité de la messagerie gouvernementale, et le dossier public ne divulgue pas le contenu des messages.

Cela restait une grave défaillance des communications de confiance.

Le travail moderne du secteur public dépend du courrier électronique cloud pour la diplomatie, le commerce, les politiques, la planification, les négociations et la coordination administrative. La perte de confidentialité peut modifier le comportement même si le service reste en ligne. Les fonctionnaires peuvent devoir supposer que les communications ont été lues, les sources ou les plans peuvent nécessiter une protection, et les communications futures peuvent être déplacées vers d'autres canaux. Le service n'avait pas besoin de tomber en panne pour imposer un coût opérationnel.

C'est pourquoi Storm-0558 appartient à la continuité du secteur public ainsi qu'à la cybersécurité. La continuité est souvent définie par la disponibilité: l'agence peut-elle continuer à fonctionner? Un modèle plus mature inclut le fonctionnement de confiance: l'agence peut-elle continuer à utiliser le service pour sa fonction publique prévue sans visibilité de l'adversaire? Une boîte aux lettres qui fonctionne techniquement mais est lisible silencieusement par un adversaire est une infrastructure dégradée.

La question de la responsabilité publique devient plus aiguë parce que les gouvernements sont des clients dépendants. Ils peuvent définir des exigences d'approvisionnement, exiger de la journalisation, mener des contrôles et déplacer des charges de travail en théorie. En pratique, ils dépendent d'un petit nombre de fournisseurs cloud pour l'identité et les communications de base. Cette dépendance signifie que la remédiation du fournisseur n'est pas seulement un service client. C'est une réparation d'infrastructure publique.

Les lettres du Congrès, les audiences et l'examen du CSRB ont reflété cette dépendance. Elles n'ont pas établi de jugement de tribunal ni de constat de responsabilité réglementaire, mais elles ont mis à la vue du public la culture de sécurité du fournisseur, sa gestion des clés et ses choix de journalisation. Cela est approprié pour une défaillance dans une infrastructure d'identité cloud partagée utilisée par des agences publiques.

La culture de sécurité est devenue un contrôle opérationnel

Le rapport du CSRB ne s'est pas limité à un seul défaut de code. Il a critiqué la culture de sécurité de Microsoft et décrit une cascade de défaillances évitables. Ce cadrage est important parce que le cycle de vie des clés de signature, la validation des jetons, les valeurs par défaut de journalisation, la compromission du réseau d'entreprise, la correction de la cause racine et la visibilité client ne sont pas des bogues isolés. Ce sont les résultats de la priorité organisationnelle, des systèmes d'ingénierie, de l'acceptation des risques et de la gouvernance.

La culture de sécurité peut sembler vague. Dans cet incident, elle a pris des formes concrètes. Un processus de rotation manuelle des clés a été interrompu après des craintes de panne sans remplacement automatisé achevé. Une hypothèse de validation a franchi une frontière grand public-entreprise. La journalisation premium a limité la visibilité client. Une première explication publique est restée trop certaine trop longtemps après que Microsoft a su qu'elle nécessitait une correction. Ce ne sont pas des attitudes; ce sont des décisions opérationnelles et des états de contrôle.

Microsoft a répondu avec la Secure Future Initiative et des extensions ultérieures. L'entreprise a décrit la gestion automatisée des clés, les modules de sécurité matériels, l'informatique confidentielle, les SDK d'identité standard, la validation avec état, le partitionnement des clés, les journaux étendus, les changements de gouvernance, les RSSI adjoints, les modifications des évaluations de performance et les liens avec la rémunération des cadres. Le témoignage au Congrès de Brad Smith a accepté chaque problème soulevé par le CSRB et décrit les mesures prises pour mettre en œuvre les recommandations.

Ces engagements sont importants. Ils sont également largement autodéclarés par le fournisseur dans les sources publiques examinées ici. La norme de responsabilité doit donc distinguer les programmes annoncés de l'efficacité opérationnelle vérifiée de manière indépendante.

Les clients et les gouvernements devraient vouloir des preuves que les clés sont inventoriées, tournées, isolées et capables de rotation d'urgence; que les bibliothèques de validation appliquent les limites d'émetteur et de portée; que les services ne peuvent pas contourner la validation standard; que les journaux sont conservés et disponibles; et que les corrections de cause racine sont publiées rapidement lorsque les preuves changent.

L'autodéclaration du fournisseur n'est pas inutile. C'est ainsi que de nombreux contrôles cloud deviennent visibles pour la première fois. Mais après une défaillance évitable de l'infrastructure de confiance, l'autodéclaration doit évoluer vers une assurance mesurable. Le public n'a pas besoin de tous les détails internes. Il a besoin de suffisamment de preuves pour savoir que les contrôles nommés après l'incident fonctionnent, sont testés et gouvernés.

La validation des jetons doit être banale, centralisée et difficile à contourner

Une leçon technique est que la validation des jetons ne devrait pas dépendre de chaque équipe de service se souvenant indépendamment de chaque condition de frontière. L'explication post-incident de Microsoft a décrit un point de terminaison de métadonnées commun et une incapacité à valider correctement l'émetteur ou la portée dans le chemin affecté. Les systèmes d'identité modernes sont complexes, mais cette complexité est précisément pourquoi la validation devrait être centralisée dans des bibliothèques bien entretenues et des modèles de service renforcés.

La documentation actuelle sur l'identité de Microsoft explique des concepts tels que l'émetteur, l'audience, les clés de signature, les métadonnées de découverte, les jetons d'accès et la rotation des clés. Ces documents sont des références destinées aux clients, pas des preuves de l'état du code de 2023. Ils montrent néanmoins la logique de contrôle: une signature valide ne suffit pas si le jeton a été émis pour un domaine d'identité, une audience, un locataire ou un service différents. La validité cryptographique répond à une question. Le contexte d'autorisation répond à une autre.

Le travail du fournisseur est de faire du chemin sûr le chemin facile. Si un service doit accepter des jetons d'identité, il devrait utiliser une bibliothèque standard qui applique les règles d'émetteur, d'audience, de locataire, de portée, de provenance de clé et de rafraîchissement des métadonnées. Les déviations devraient être rares, examinées, journalisées et testées. La rotation d'urgence des clés devrait être répétée. Les services devraient rejeter les combinaisons impossibles par défaut. La surveillance devrait détecter les jetons dont la relation entre la clé de signature, l'émetteur, la ressource et le locataire n'a pas de sens.

Les clients bénéficient lorsque la validation du fournisseur devient banale. Ils ne devraient pas avoir à se demander si chaque équipe de service Microsoft a correctement implémenté la validation des jetons. Ils devraient pouvoir s'appuyer sur des contrôles d'identité centraux et une assurance indépendante. L'incident Storm-0558 a montré ce qui se passe lorsqu'une frontière qui aurait dû être systémique devient suffisamment spécifique au service pour qu'un défaut ait de l'importance.

Cette leçon s'étend au-delà de Microsoft. Chaque grand fournisseur cloud exploite une infrastructure de jetons qui traverse les produits, les locataires, les domaines d'identité et les API. La validation centralisée, le cycle de vie automatisé des clés et les preuves visibles par le client sont des exigences de sécurité communes. L'incident a rendu ces exigences publiques parce que la défaillance a touché le courrier gouvernemental.

L'incertitude résiduelle modifie la charge d'assurance

Certains incidents se terminent par une cause racine précise et une fermeture précise. Storm-0558 ne le fait pas, du moins dans le dossier public. Le chemin d'acquisition de la clé reste non résolu. Le CSRB a rapporté que Microsoft n'a pas pu déterminer comment ni quand la clé a été obtenue. Cette incertitude n'empêche pas la remédiation. Elle modifie la charge d'assurance.

Lorsque le chemin de vol est inconnu, le fournisseur doit supposer une classe plus large de défaillances possibles. Le matériel de clé aurait pu quitter un environnement de signature par une erreur opérationnelle. Il aurait pu être exposé par une compromission d'entreprise. Il aurait pu être mal géré par un processus non capturé dans les journaux survivants. La réponse n'est pas de spéculer publiquement au-delà des preuves. La réponse est de renforcer le cycle de vie complet: génération, stockage, utilisation, rotation, mise hors service, journalisation, débogage, sauvegarde, réponse aux incidents et accès privilégié.

L'incertitude résiduelle affecte également la confiance des clients. Les clients peuvent accepter que tous les faits ne soient pas récupérables. On ne devrait pas leur demander d'accepter une fermeture vague. Le fournisseur devrait dire ce qui reste inconnu, quelles preuves manquaient, quels contrôles ont été renforcés malgré l'incertitude, et comment les preuves futures seront préservées. Un inconnu transparent peut construire plus de confiance qu'une histoire trop confiante qui doit ensuite être corrigée.

Le processus du CSRB a aidé à créer cette transparence en forçant une distinction publique entre les faits prouvés et les hypothèses. Il a également montré la valeur d'un examen indépendant pour les incidents cloud dont les preuves se trouvent en grande partie chez le fournisseur. Les clients ne peuvent pas mener leur propre enquête complète sur l'environnement de signature de Microsoft. Un examen public-privé indépendant n'est pas un tribunal, mais il peut rendre les faits contrôlés par le fournisseur suffisamment visibles pour la responsabilité publique.

L'assurance future devrait être continue. Un rapport ponctuel après un incident majeur est utile, mais le cycle de vie des clés et la validation des jetons sont des contrôles continus. Les gouvernements et les entreprises clientes devraient demander des preuves récurrentes de tests de rotation d'urgence des clés, d'adoption de bibliothèques de validation, de couverture de journalisation et de processus de correction de cause racine. La défaillance de contrôle n'était pas statique; l'assurance ne devrait pas non plus être statique.

L'asymétrie des preuves a défini le plafond du client

Storm-0558 a également exposé un plafond dur pour l'enquête côté client. Un client pouvait inspecter les événements d'audit de la boîte aux lettres, corréler les accès suspects, conserver les journaux de locataire et escalader vers Microsoft. Il ne pouvait pas inspecter l'environnement de signature, lister chaque décision de confiance de clé interne de Microsoft, prouver si la clé avait été utilisée contre d'autres services, ou déterminer si l'acteur avait obtenu la clé via une image mémoire, une compromission d'entreprise ou une autre voie. Les preuves les plus importantes se trouvaient à l'intérieur du fournisseur.

Cette asymétrie est inhérente aux services cloud, mais elle devient aiguë lorsque la défaillance implique l'infrastructure d'identité du fournisseur. Dans une compromission de compte ordinaire, un client peut être en mesure d'examiner les appareils utilisateur, les messages de hameçonnage, les invites MFA, les politiques d'accès conditionnel et les journaux locaux. Dans Storm-0558, la question décisive était de savoir pourquoi les services de Microsoft acceptaient des jetons falsifiés et comment l'acteur avait obtenu le matériel de signature contrôlé par Microsoft. Cette question était hors de portée du client.

Le devoir de preuve du fournisseur augmente donc à mesure que la visibilité du client diminue. Microsoft a dû enquêter sur les systèmes internes, conserver les preuves disponibles, expliquer les lacunes, corriger les déclarations publiques et rendre les journaux destinés aux clients plus accessibles. Les clients devaient faire confiance à Microsoft pour la moitié interne de l'histoire. L'examen du CSRB a réduit cet écart de confiance en apportant un examen public indépendant sur les faits détenus par le fournisseur, mais il n'a pas éliminé toutes les inconnues.

Il pouvait rapporter ce que Microsoft et d'autres entités pouvaient reconstituer; il ne pouvait pas fabriquer des journaux qui n'existaient pas.

L'asymétrie des preuves devrait être une entrée de conception. Les fournisseurs cloud devraient conserver les journaux internes pertinents pour la sécurité suffisamment longtemps pour soutenir l'enquête sur un abus d'identité découvert lentement. Ils devraient maintenir des registres de garde des clés, des journaux d'accès au système de signature, des contrôles d'environnement de débogage et des enregistrements de rotation d'urgence. Ils devraient donner aux clients des journaux de locataire suffisants pour détecter l'utilisation abusive d'artefacts de confiance provenant du fournisseur.

Ils devraient également publier les limitations lorsque les journaux sont manquants ou que la rétention a expiré. Le silence sur les limites de preuve fait que les clients supposent soit de la confiance, soit de la dissimulation; ni l'un ni l'autre n'est utile.

Les clients peuvent répondre en inscrivant les attentes en matière de preuves dans les examens d'approvisionnement et de risque. Ils devraient demander quels événements d'audit sont inclus par défaut, combien de temps les journaux côté fournisseur sont conservés, quels résumés d'incident seront partagés après des défaillances contrôlées par le fournisseur, et si un examen indépendant est disponible pour les incidents de confiance majeurs. Les réponses ne donneront jamais aux clients un accès interne complet. Elles peuvent toujours établir si le fournisseur traite les preuves comme faisant partie du produit.

La rotation d'urgence des clés est une capacité de continuité

La rotation des clés est souvent discutée comme une tâche de maintenance cryptographique. Storm-0558 a montré qu'il s'agit également d'une capacité de continuité. Si une clé de signature est suspectée ou confirmée compromise, le fournisseur doit la tourner ou la révoquer sans casser l'authentification légitime à une échelle inacceptable. Cela signifie que les applications, les services, les points de terminaison de métadonnées, les caches, les clients et les bibliothèques de validation doivent tolérer le changement de clé.

Si le chemin de rotation est fragile, les équipes de sécurité peuvent hésiter, retarder ou laisser les anciennes clés approuvées plus longtemps que nécessaire.

La discussion du CSRB sur la rotation des clés de signature grand public rend ce point concret. Microsoft avait interrompu la rotation manuelle après une crainte de panne et n'avait pas terminé le remplacement automatisé. Cette décision a peut-être réduit le risque immédiat de disponibilité, mais elle a laissé une clé périmée approuvée. La défaillance plus profonde n'était pas simplement l'âge de la clé. C'était l'absence d'un chemin de rotation sûr, automatisé et mesurable capable de gérer à la fois les changements routiniers et d'urgence.

Le guide actuel de rotation des clés de signature de Microsoft pour les clients met l'accent sur la gestion programmatique des changements de clé, le rafraîchissement des métadonnées et les bibliothèques standard. Le même principe d'ingénierie s'applique à l'intérieur du fournisseur. Les services devraient s'attendre à des changements de clé, les bibliothèques de validation devraient se rafraîchir en toute sécurité, et la rotation d'urgence devrait être testée dans des conditions réalistes. Si la rotation est redoutée comme un déclencheur de panne, le système a converti un contrôle de sécurité en un risque de disponibilité.

Une infrastructure mature rend la rotation suffisamment ordinaire pour être exécutée.

La rotation d'urgence a également une composante de communication client. Lorsqu'un fournisseur tourne les clés après une suspicion de compromission, les clients peuvent avoir besoin de savoir si leurs applications ou intégrations nécessitent une action, si les caches de jetons sont affectés, si des échecs d'authentification sont attendus et si les anciens jetons restent valides. Pendant Storm-0558, Microsoft contrôlait le chemin Exchange Online affecté, mais le principe plus large s'applique à l'identité cloud. La sécurité des clés et la continuité client sont liées.

C'est pourquoi la gestion des clés devrait être rapportée comme une métrique de résilience. Les fournisseurs peuvent divulguer, à un niveau agrégé, si les clés sont inventoriées, attribuées à des propriétaires, tournées selon un calendrier, protégées par des contrôles matériels, soumises à des exercices d'urgence et surveillées pour l'âge ou les déviations de politique. Les clients n'ont pas besoin du matériel de clé privé pour évaluer la maturité. Ils ont besoin de preuves que les clés ne sont pas autorisées à devenir des ancres de confiance oubliées.

La journalisation de base a changé qui payait pour l'incertitude

Avant l'expansion de la journalisation par Microsoft, les preuves d'accès aux boîtes aux lettres les plus utiles n'étaient pas également disponibles pour tous les clients. C'est plus qu'un détail de packaging produit. Cela alloue l'incertitude. Un client sans les journaux pertinents peut devoir supposer une compromission, dépenser plus pour une enquête externe ou accepter une conclusion plus faible. Un client avec les journaux peut identifier les accès suspects, réduire la portée et escalader avec des preuves.

Le Département d'État disposait de la journalisation améliorée nécessaire pour détecter les accès anormaux aux boîtes aux lettres. Ce succès a montré ce qu'une bonne télémétrie peut faire. Il a également soulevé la question d'équité: pourquoi la capacité à détecter une défaillance d'identité provenant du fournisseur devrait-elle dépendre du niveau de licence? La déclaration publique de la CISA selon laquelle les journaux importants devraient être disponibles sans coût supplémentaire a transformé une décision produit en un problème de responsabilité.

L'engagement de Microsoft à étendre les événements et la rétention d'Audit Standard n'était donc pas simplement un geste de succès client. Il a changé le modèle d'allocation des préjudices. Si les clients de base reçoivent plus de journaux, ils peuvent participer à la détection et à la délimitation lorsque les contrôles du fournisseur échouent. Si les agences fédérales reçoivent une activation automatique et une rétention plus longue, elles sont moins dépendantes d'une reconstruction après coup. Plus de journaux n'empêchent pas la compromission de la clé. Ils réduisent la période pendant laquelle les clients sont aveugles.

La journalisation affecte également la certitude juridique et opérationnelle. Une organisation qui peut prouver quels éléments de courrier ont été consultés peut adapter la notification, la remédiation interne, la réponse diplomatique ou les mesures de continuité des activités. Une organisation sans journaux peut devoir traiter une population plus large comme potentiellement affectée. En ce sens, les journaux réduisent le préjudice secondaire. Ils n'aident pas seulement à trouver les attaquants; ils aident à éviter une incertitude trop large.

La norme de base devrait être claire: les événements nécessaires pour détecter l'accès non autorisé aux données client, en particulier lorsque la cause racine peut se situer dans l'infrastructure contrôlée par le fournisseur, devraient être inclus dans le cadre du service. La corrélation avancée, la détection gérée, l'archivage à long terme et les analyses peuvent rester des offres premium. Les preuves minimales nécessaires pour savoir si les données client ont été consultées ne devraient pas être une fonctionnalité de luxe.

Les corrections des fournisseurs font partie de la réponse aux incidents

Storm-0558 a également fait de la correction publique un élément de la responsabilité opérationnelle. Microsoft a publié un avis d'incident initial, une analyse technique, puis un article d'enquête sur l'acquisition de la clé. L'article de septembre offrait une explication détaillée qui a dû être réduite par la suite. La correction de mars 2024 n'a pas simplement modifié une note historique. Elle a changé ce que les clients pouvaient raisonnablement croire sur la cause racine.

La réponse aux incidents traite souvent la communication publique comme distincte de la remédiation technique. Dans les incidents de confiance cloud, elles sont liées. Un client qui décide de faire confiance à la clôture du fournisseur a besoin d'un compte rendu précis des contrôles qui ont échoué. Si le chemin d'acquisition est décrit comme une image mémoire, le client s'attend à ce que les contrôles de l'image mémoire et de l'environnement de débogage ferment le problème. Si le chemin d'acquisition est inconnu, le client s'attend à un renforcement plus large du cycle de vie des clés et à une préservation plus forte des preuves.

Les mots déterminent la demande d'assurance.

Les corrections devraient donc être rapides, visibles et explicites. Un fournisseur ne devrait pas enterrer un changement de niveau de confiance dans la cause racine dans un article versionné sans indiquer clairement ce qui a changé et pourquoi. Microsoft a effectivement ajouté une mise à jour en mars 2024, et le CSRB a ensuite discuté du timing et de la signification de la correction. La leçon de responsabilité est que la confiance dans la cause racine est elle-même un fait divulgué. Lorsque la confiance passe de "c'est arrivé" à "cela reste notre hypothèse principale", les clients doivent le savoir.

Cette norme protège les fournisseurs aussi bien que les clients. Une correction honnête empêche le dossier public de se figer autour d'une fausse explication. Elle permet à la remédiation de s'élargir de manière appropriée. Elle signale que le fournisseur est prêt à distinguer les preuves de la commodité narrative. Dans une infrastructure de confiance cloud de haut niveau, cette distinction fait partie de la crédibilité du service.

La responsabilité partagée nécessite une carte des surfaces de contrôle

Storm-0558 est un antidote utile au langage vague de la responsabilité partagée. L'expression "responsabilité partagée" peut devenir un brouillard si elle ne nomme pas les surfaces de contrôle. Dans cet incident, Microsoft contrôlait le cycle de vie des clés, la validation des jetons, l'atténuation côté service, la disponibilité de la journalisation de base, la préservation des preuves internes et la plupart des preuves de cause racine. Les clients contrôlaient la surveillance du locataire, l'escalade des incidents, l'examen des boîtes aux lettres, l'hygiène des comptes et la configuration des politiques.

Les gouvernements contrôlaient la pression des achats, la supervision et les mécanismes d'examen public. Ces rôles sont différents.

Une carte des surfaces de contrôle empêche deux mauvais arguments. Le premier mauvais argument dit que les clients sont responsables de leur propre sécurité cloud et qu'ils auraient donc dû prévenir l'incident. Cela échoue parce que les clients ne pouvaient pas empêcher les services de Microsoft d'accepter des jetons falsifiés signés avec du matériel contrôlé par Microsoft. Le deuxième mauvais argument dit que le fournisseur contrôlait la cause racine et que les clients n'avaient donc aucun rôle significatif.

Cela échoue également parce que la détection par le Département d'État, les journaux clients et l'escalade ont changé matériellement la réponse publique.

Le meilleur modèle pose quatre questions. Qui pouvait prévenir cette classe de défaillance? Qui pouvait la détecter en premier? Qui pouvait la contenir? Qui pouvait en prouver la portée? Pour Storm-0558, Microsoft avait le contrôle de prévention et de confinement le plus fort. Un client, en l'occurrence le Département d'État, a eu un rôle de détection crucial parce qu'il possédait et utilisait des journaux de boîte aux lettres améliorés.

La preuve de la portée était partagée mais asymétrique: les clients pouvaient inspecter leurs locataires si des journaux existaient, tandis que Microsoft devait expliquer les preuves de confiance et de clé côté fournisseur.

Les achats devraient refléter cette carte. Un client qui achète du courrier électronique et de l'identité cloud devrait poser des questions non seulement sur la disponibilité et les certifications de conformité, mais aussi sur la rotation des clés, la validation des jetons, les tests de frontière d'émetteur, les événements d'audit par défaut, la rétention des journaux côté fournisseur, la politique de correction des incidents et les options d'examen indépendant. Ce ne sont pas des contrôles ésotériques. Ce sont les contrôles qui décident de ce qui se passe lorsque le tissu de confiance du fournisseur échoue.

Les agences publiques ont un devoir supplémentaire parce que leur dépendance peut façonner les normes du marché. Lorsque les clients gouvernementaux insistent pour que les journaux critiques soient de base, les fournisseurs peuvent modifier leurs offres pour des populations plus larges. L'expansion de la journalisation après Storm-0558 montre que la responsabilité publique peut améliorer la posture de sécurité par défaut. Le défi est de rendre cette amélioration systématique plutôt que motivée par les incidents.

Note sur la typographie et la lisibilité

La typographie est l'art et la technique de disposer les caractères pour rendre la langue écrite lisible, agréable à l'œil et attrayante. Elle implique la sélection des polices, des tailles de caractères, des longueurs de ligne, de l'espacement des lignes et de l'espacement des lettres.

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

Le test de responsabilité

Microsoft Storm-0558 a fait du contrôle opérationnel des dommages liés aux jetons un test de responsabilité publique parce que les contrôles décisifs se trouvaient à l'intérieur du cloud de Microsoft. Les clients pouvaient détecter, escalader et enquêter sur leurs propres boîtes aux lettres, mais Microsoft seul pouvait remplacer la clé, corriger la validation, modifier le comportement de renouvellement des jetons, étendre les journaux de base et expliquer les lacunes des preuves internes.

La meilleure norme est le contrôle des dommages vérifiable par le fournisseur. Un fournisseur d'identité cloud devrait connaître chaque clé de signature active, tourner les clés via des chemins automatisés et testés, appliquer la validation des jetons via des bibliothèques standard, détecter l'utilisation impossible de jetons, conserver les preuves suffisamment longtemps pour une analyse rétrospective et donner aux clients les journaux de base nécessaires pour détecter les défaillances de contrôle provenant du fournisseur. Lorsqu'une hypothèse de cause racine change, le fournisseur devrait corriger le dossier rapidement.

Le chemin d'acquisition de la clé non résolu fait partie de la leçon, pas une gêne à dissimuler. Les clients cloud peuvent vivre avec une incertitude honnête si le fournisseur prouve que toute la classe de préjudices est en train d'être réduite. Ils ne peuvent pas vivre en sécurité avec un système de confiance dont les défaillances les plus privilégiées ne sont expliquées qu'après que les clients ont découvert les dommages.