Microsoft Storm-0558 a fait du contrôle opérationnel des dommages liés aux jetons un test de responsabilité publique

Résumé

• Storm-0558 a utilisé une clé de signature grand public Microsoft et une défaillance de validation pour accéder aux courriels Exchange Online d'entreprise. Cela a fait du contrôle des dommages opérationnels une responsabilité principalement du côté du fournisseur, car les clients ne pouvaient pas renouveler 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: avec quelle rapidité Microsoft pouvait 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 plus tard 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é le travail de l'initiative Secure Future, mais une grande partie des preuves de mise en œuvre reste fournie 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é impacté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

Le dommage par jeton est un mode de défaillance contrôlé par le fournisseur

Storm-0558 est souvent décrit par son 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 fiable, la manière dont les services validaient l'émetteur et le périmètre du jeton, le comportement des chemins de renouvellement, si des combinaisons de jetons impossibles ont été détectées et si les clients pouvaient voir les preuves d'accès aux boîtes aux lettres. Ces contrôles incombaient en grande partie à Microsoft.

C'est pourquoi le contrôle opérationnel des dommages est la perspective centrale. Les clients peuvent renforcer les comptes, exiger une authentification multifacteur, réduire les privilèges, surveiller les journaux et réagir rapidement. Ils ne peuvent pas renouveler 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 chaque chemin d'émission de jeton interne. Ils ne peuvent pas préserver les images mémoire internes de Microsoft ni 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 dommage 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é relevaient de la responsabilité de Microsoft car l'infrastructure affectée était basée sur le cloud. Cette phrase est importante. Cela 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. Cela signifie que les actions de confinement décisives relevaient 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'avait pas 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 dommage 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 jeton contrôlée par le fournisseur échoue, la responsabilité ne peut être réduite à la configuration du client.

Le dossier public exige également de la précision. L'incident était avant tout 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 dommage a été un accès silencieux aux messages et la perte de confiance dans le fait que la frontière d'identité du service ait tenu. La continuité du service public inclut ce type de dommage. Une boîte aux lettres diplomatique peut rester joignable alors que son contenu est compromis.

L'histoire de l'acquisition de la clé restait non résolue

La publication de Microsoft de septembre 2023 sur l'acquisition de la clé offrait initialement un récit détaillé sur une image mémoire. Elle décrivait un plantage en avril 2021 dans un système de signature grand public, une image mémoire qui a été déplacée vers un environnement de débogage d'entreprise, une analyse des identifiants qui n'a pas détecté le matériel de clé, puis la compromission ultérieure du compte d'un ingénieur. Ce récit est devenu le discours public sur la cause première. En mars 2024, Microsoft a ajouté une correction pour nuancer l'affirmation.

Elle a déclaré ne pas avoir trouvé d'image mémoire contenant la clé affectée et que la piste 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 indiqué que Microsoft avait examiné 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 une note de bas de page. Si le chemin d'acquisition est inconnu, 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'impact futur. Ce sont de vrais contrôles.

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

La responsabilité devrait donc reposer sur deux catégories. La première catégorie concerne les défaillances prouvées ou fortement étayées: une clé périmée est restée fiable, la validation a échoué à travers la frontière grand public-entreprise, les journaux améliorés n'étaient pas largement disponibles pour les clients et la première explication publique de Microsoft a exagéré la certitude du chemin d'acquisition. La deuxième catégorie est l'incertitude résiduelle: exactement comment la clé a quitté le contrôle de Microsoft, si des documents sensibles connexes ont été exposés et s'il a jamais existé une piste de preuves interne complète.

Cette distinction n'est pas du pédantisme. Les clients utilisent les explications des causes premières pour décider si la remédiation correspond à la défaillance. Si le chemin de l'image mémoire est prouvé, alors le traitement des images mémoire et l'accès au 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 de développement et contestation 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 bilan de responsabilité en raison du moment choisi. Le CSRB a indiqué 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 l'explication d'un incident. Le devoir, après avoir découvert l'erreur, est de la corriger rapidement et clairement. Dans l'infrastructure de confiance cloud, un récit inexact des causes premières peut induire les clients en erreur sur la fermeture effective du chemin de dommage central.

Le contrôle des dommages a commencé par la validation et des actions sur les clés

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 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 des jetons émis précédemment. Il s'agissait d'un programme de contrôle des dommages par étapes.

Cette séquence illustre les dommages par jeton. 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 limites de confiance entre le grand public et l'entreprise. Un fournisseur doit trouver chaque endroit où la mauvaise décision de confiance survit. Bloquer un chemin peut arrêter 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 étendre les dommages s'ils ne sont pas fermés.

Les clients doivent comprendre ce séquençage car il affecte l'enquête. Une boîte aux lettres accessible avant le remplacement de la clé peut encore nécessiter un examen même si le chemin est fermé par la suite. Un jeton accepté par un service mais pas par un autre peut réduire le périmètre. Un chemin de renouvellement modifie la durée d'accès. La divulgation publique devrait 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 des clients restent pertinentes.

Les rapports techniques de Microsoft ont effectivement fourni une séquence d'atténuation plus claire que de nombreuses divulgations d'incidents. C'est une force. La limite publique est que les clients devaient encore s'en remettre à Microsoft pour les preuves côté service. Ils ne pouvaient pas vérifier indépendamment chaque changement de validation interne ou l'effet de la révocation des clés. C'est la nature de l'infrastructure de confiance cloud. Cela accroît la charge pour le fournisseur de publier des explications précises, vérifiables et corrigées.

L'incident montre également pourquoi l'âge des clés importe en tant que risque opérationnel, et pas seulement en tant qu'hygiène cryptographique. Une clé à longue durée de vie qui reste fiable après son cycle de vie prévu donne à un attaquant une cible de plus grande valeur 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 avait été 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 consiste notamment à rendre le renouvellement des clés suffisamment banal pour que la crainte d'une panne ne bloque pas le cycle de vie de la sécurité.

La journalisation a été le pivot de la responsabilité publique

Le Département d'État a détecté une activité suspecte grâce aux journaux d'accès aux boîtes aux lettres améliorés. 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 ensuite 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 la boîte aux lettres, ils ne peuvent pas détecter de manière fiable l'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 tarifés comme des fonctionnalités premium, les clients de niveau inférieur peuvent disposer de preuves plus faibles précisément au moment où ils ont le plus besoin de la responsabilité du fournisseur.

L'annonce de juillet 2023 de Microsoft sur la journalisation s'engageait à étendre 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 à faire passer la conservation 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 conservation 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é dépasse un seul type de journal. Les fournisseurs cloud devraient considérer 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é fournisseur ou un défaut de validation a été exploité. Les fournisseurs peuvent facturer les 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 devraient se rapprocher de la base de référence.

L'incident a également montré que la détection peut provenir 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 suffisamment de canaux pour escalader le problème. Sans la journalisation et l'enquête améliorées 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 service 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 qu'environ 60 000 courriels avaient été téléchargés à partir de 10 comptes et que le système compromis était non classifié, les courriels classifiés n'ayant pas été piratés. Le CSRB a identifié 22 organisations et plus de 500 personnes touchées dans le monde. Ces détails définissent le dommage 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.

Il s'agissait néanmoins d'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, la politique, la planification, la négociation et la coordination administrative. La perte de confidentialité peut modifier le comportement même si le service reste en ligne. Les responsables peuvent devoir partir du principe 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 relève à la fois de la continuité du service public et de 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 qui 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 fixer des exigences de passation de marchés, exiger une journalisation, exercer une surveillance et déplacer théoriquement les charges de travail. En pratique, ils s'appuient sur 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. Ils n'ont pas établi de jugement judiciaire ni de conclusion de responsabilité réglementaire, mais ils ont mis en lumière la culture de sécurité, la gestion des clés et les choix de journalisation du fournisseur. Cela est approprié pour une défaillance de l'infrastructure d'identité cloud partagée utilisée par les 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 paramètres de journalisation par défaut, la compromission du réseau d'entreprise, la correction des causes premières et la visibilité des clients 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 manuel de rotation des clés a été interrompu après des craintes de panne sans remplacement automatisé achevé. Une hypothèse de validation a traversé une frontière grand public-entreprise. La journalisation premium a limité la visibilité des clients. Une première explication publique est restée trop certaine trop longtemps après que Microsoft a su qu'elle devait être corrigée. Ce ne sont pas des attitudes; ce sont des décisions opérationnelles et des états de contrôle.

Microsoft a répondu avec l'initiative Secure Future et ses 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 dirigeants. Le témoignage au Congrès de Brad Smith a accepté tous les problèmes soulevés par le CSRB et décrit les étapes vers la mise en œuvre des recommandations.

Ces engagements sont importants. Ils sont aussi en grande partie déclarés par le fournisseur dans les sources publiques examinées ici. La norme de responsabilité devrait 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 la preuve que les clés sont inventoriées, renouvelées, isolées et capables de renouvellement d'urgence; que les bibliothèques de validation appliquent les limites d'émetteur et de périmètre; que les services ne peuvent pas contourner la validation standard; que les journaux sont conservés et disponibles; et que les corrections des causes premières sont publiées rapidement lorsque les preuves changent.

L'auto-déclaration des fournisseurs 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'auto-déclaration devrait é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

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

La documentation d'identité actuelle 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 le renouvellement des clés. Ces documents sont des références destinées aux clients, et non la preuve 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érent. 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 doit utiliser une bibliothèque standard qui applique les règles d'émetteur, d'audience, de locataire, de périmètre, de provenance de la clé et de rafraîchissement des métadonnées. Les déviations devraient être rares, examinées, journalisées et testées. Le renouvellement d'urgence des clés devrait être répété. 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 en bénéficient lorsque la validation du fournisseur devient banale. Ils ne devraient pas avoir à se demander si chaque équipe de service Microsoft a mis en œuvre correctement 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 à un 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 première précise et une clôture précise. Storm-0558 non, du moins dans le dossier public. Le chemin d'acquisition de la clé reste non résolu. Le CSRB a indiqué que Microsoft n'avait pas pu déterminer comment ni quand la clé avait é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 envisager une classe plus large de défaillances possibles. Le matériel de clé a pu quitter un environnement de signature par une erreur opérationnelle. Il a pu être exposé par une compromission d'entreprise. Il a 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 tout le cycle de vie: génération, stockage, utilisation, rotation, retrait, 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 clôture 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 inspirer plus confiance qu'une histoire trop confiante qui doit ensuite être corrigée.

Le processus du CSRB a contribué à créer cette transparence en imposant 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 indépendant public-privé 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 permanents. Les gouvernements et les entreprises clientes devraient demander des preuves récurrentes des tests de renouvellement d'urgence des clés, de l'adoption des bibliothèques de validation, de la couverture de journalisation et des processus de correction des causes premières. 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 du locataire et escalader vers Microsoft. Il ne pouvait pas inspecter l'environnement de signature, lister chaque décision de confiance interne de Microsoft concernant les clés, prouver si la clé avait été utilisée contre d'autres services, ni 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 chez le 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 d'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 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 s'accroît donc à mesure que la visibilité du client diminue. Microsoft devait enquêter sur les systèmes internes, conserver les preuves disponibles, expliquer les lacunes, corriger les déclarations publiques et rendre les journaux accessibles aux clients plus accessibles. Les clients devaient faire confiance à Microsoft pour la moitié interne de l'histoire. L'examen du CSRB a réduit ce déficit de confiance en soumettant les faits détenus par le fournisseur à un examen public indépendant, mais il n'a pas éliminé toutes les inconnues.

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

L'asymétrie des preuves devrait être une donnée de conception. Les fournisseurs cloud devraient conserver les journaux internes pertinents pour la sécurité suffisamment longtemps pour étayer l'enquête sur les abus d'identité découverts tardivement. Ils devraient tenir des registres de garde des clés, des journaux d'accès aux systèmes de signature, des contrôles de l'environnement de débogage et des registres de rotation d'urgence. Ils devraient fournir 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 conservation a expiré. Le silence sur les limites des preuves amène les clients à supposer soit la confiance, soit 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 risques. 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'incidents 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 néanmoins établir si le fournisseur traite les preuves comme faisant partie du produit.

Le renouvellement d'urgence des clés est une capacité de continuité

Le renouvellement des clés est souvent présenté comme une tâche de maintenance cryptographique. Storm-0558 a montré que c'est aussi une capacité de continuité. Si une clé de signature est suspectée ou confirmée compromise, le fournisseur doit la renouveler ou la révoquer sans briser 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 renouvellement est fragile, les équipes de sécurité peuvent hésiter, retarder ou laisser les anciennes clés fiables plus longtemps qu'elles ne le devraient.

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 achevé le remplacement automatisé. Cette décision a peut-être réduit le risque de disponibilité immédiat, mais elle a laissé une clé périmée fiable. L'échec plus profond n'était pas simplement l'âge de la clé. C'était l'absence d'un chemin de renouvellement sûr, automatisé et mesurable capable de gérer à la fois les changements de routine et d'urgence.

Le guide actuel de Microsoft sur le renouvellement des clés de signature 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 le renouvellement d'urgence devrait être testé 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 banale pour être effectuée.

Le renouvellement d'urgence comporte également un volet de communication avec le client. Lorsqu'un fournisseur renouvelle les clés après une compromission suspectée, 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 à prévoir 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 un indicateur de résilience. Les fournisseurs peuvent divulguer, à un niveau agrégé, si les clés sont inventoriées, affectées à des propriétaires, renouvelées selon le calendrier prévu, protégées par des contrôles matériels, soumises à des exercices d'urgence et surveillées pour leur âge ou les écarts 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'extension de la journalisation par Microsoft, les preuves d'accès aux boîtes aux lettres les plus utiles n'étaient pas également accessibles à tous les clients. C'est plus qu'un détail de packaging produit. Cela répartit l'incertitude. Un client sans les journaux pertinents peut devoir supposer une compromission, consacrer davantage de ressources à une enquête externe ou accepter une conclusion plus faible. Un client disposant des journaux peut identifier les accès suspects, réduire le périmètre et escalader avec des preuves.

Le Département d'État disposait de la journalisation améliorée nécessaire pour détecter un accès anormal aux boîtes aux lettres. Ce succès a montré ce que peut faire une bonne télémétrie. Il a également soulevé la question de l'é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 la journalisation importante devrait être disponible sans coût supplémentaire a transformé une décision produit en une question de responsabilité.

L'engagement de Microsoft d'étendre les événements et la conservation d'Audit Standard n'était donc pas simplement un geste de satisfaction client. Il a changé le modèle de répartition des dommages. Si les clients de base reçoivent plus de journaux, ils peuvent participer à la détection et à la délimitation du périmètre lorsque les contrôles du fournisseur échouent. Si les agences fédérales reçoivent une activation automatique et une conservation plus longue, elles sont moins dépendantes de la 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, les mesures correctives internes, 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 les dommages secondaires. 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, surtout lorsque la cause première peut résider dans une infrastructure contrôlée par le fournisseur, devraient être inclus dans le service. La corrélation avancée, la détection gérée, l'archivage à long terme et les analyses peuvent rester des offres premium. Le minimum de preuves nécessaires pour savoir si les données client ont été consultées ne devrait pas être une fonctionnalité de luxe.

Les corrections du fournisseur 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 premier avis d'incident, 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 nuancée par la suite. La correction de mars 2024 n'a pas simplement modifié une note de bas de page historique. Elle a changé ce que les clients pouvaient raisonnablement croire sur la cause première.

La réponse aux incidents traite souvent la communication publique séparément 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 sur les images mémoire et l'environnement de débogage règlent 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 meilleure conservation 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 sur la cause première dans un article versionné sans indiquer clairement ce qui a changé et pourquoi. Microsoft a bien ajouté une mise à jour en mars 2024, et le CSRB a discuté plus tard du moment et de l'importance de la correction. La leçon de responsabilité est que la confiance dans la cause première 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 autant que les clients. Une correction honnête empêche le dossier public de se figer autour d'une explication fausse. Elle permet d'élargir la remédiation de manière appropriée. Elle signale que le fournisseur est prêt à distinguer les preuves de la commodité narrative. Dans une infrastructure cloud de haute confiance, cette distinction fait partie de la crédibilité du service.

La responsabilité partagée nécessite une cartographie 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 conservation des preuves internes et la plupart des preuves de la cause première. Les clients contrôlaient la surveillance des locataires, 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 cartographie des surfaces de contrôle évite deux mauvais arguments. Le premier mauvais argument dit que les clients sont responsables de leur propre sécurité cloud et auraient donc dû empêcher 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 première et que les clients n'avaient donc aucun rôle significatif.

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

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

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

Les achats devraient refléter cette cartographie. Un client qui achète des services de messagerie et d'identité cloud devrait poser des questions non seulement sur la disponibilité et les certifications de conformité, mais aussi sur le renouvellement des clés, la validation des jetons, les tests des limites de l'émetteur, les événements d'audit par défaut, la conservation 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éterminent 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 fassent partie de l'offre de base, les fournisseurs peuvent modifier leurs offres pour des populations plus larges. L'extension 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 consiste à rendre cette amélioration systématique plutôt que dicté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 le langage écrit lisible, compréhensible et visuellement attrayant. Cela implique le choix des polices, des tailles de points, des longueurs de ligne, de l'interlignage 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 des polices, le crénage, l'approche et l'interlignage.
• Une bonne typographie améliore la lisibilité et transmet une ambiance ou un ton dans le design.

Le test de responsabilité

Microsoft Storm-0558 a transformé le contrôle opérationnel des dommages par jetons en un test de responsabilité publique parce que les contrôles décisifs se trouvaient dans le 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 de 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, renouveler les clés par des chemins automatisés et testés, appliquer la validation des jetons via des bibliothèques standard, détecter les utilisations impossibles 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 première change, le fournisseur devrait corriger le dossier rapidement.

Le chemin non résolu d'acquisition de la clé fait partie de la leçon, et non d'un embarras à dissimuler. Les clients du cloud peuvent vivre avec une incertitude honnête si le fournisseur prouve que toute la catégorie de dommages est en cours de réduction. 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 dégâts.