Microsoft Storm-0558 und der Signaturschlüsselfehler, der Cloud-Identität zu einem öffentlichen Verantwortlichkeitsproblem machte

Zusammenfassung

• Storm-0558 hat nicht die Passwortkontrollen einer Bundesbehörde überwunden. Der Angreifer nutzte einen Microsoft-Consumer-Signaturschlüssel, um scheinbar gültige Identitätstoken zu erstellen, und profitierte anschließend von einem Validierungsfehler von Microsoft, der diese Consumer-signierten Token den Zugriff auf Enterprise-Exchange-Online-Postfächer ermöglichte.
• Der Weg der Schlüsselgewinnung bleibt ungeklärt. Microsofts Erklärung vom September 2023 mit einem Crash-Dump wurde später auf eine Leit-Hypothese eingeschränkt, nachdem das Unternehmen eingeräumt hatte, weder einen Crash-Dump mit dem betroffenen Schlüssel noch Protokolle gefunden zu haben, die eine Exfiltration belegen. Der veraltete Schlüssel, der validierungsfehler über Grenzen hinweg, die schwache Anomalieerkennung von Token und die begrenzte forensische Vorhaltezeit sind besser belegte Fehlerbefunde.
• Verantwortlichkeit folgt der Kontrollfähigkeit. Microsoft allein konnte den Plattformschlüssel rotieren, den dienstseitigen Validator korrigieren, unmögliche Token-Kombinationen in seiner Cloud erkennen, die relevanten internen Beweise sichern und den Angriffsvektor schließen. Kunden konnten ihre Überwachung und Reaktion verbessern, aber 2023 war die entscheidende MailItemsAccessed-Telemetrie an die teurere E5/G5-Lizenzierung gebunden.

Ein Identitätskontrollfehler, kein konventioneller Postfach-Einbruch

Die Storm-0558-Intrusion lässt sich leicht in einen vertrauten Satz komprimieren: Chinesische Hacker stahlen einen Microsoft-Schlüssel und lasen Regierungs-E-Mails. Dieser Satz ist tendenziell wahr, aber analytisch unzureichend. Er vermischt die Handlung des Angreifers, den ungeklärten Verlust von kryptografischem Material bei Microsoft, einen separaten Software-Validierungsfehler, eine Entscheidung zum Lebenszyklus eines veralteten Schlüssels, einen kundenseitigen Erkennungserfolg und eine Reaktion des Dienstanbieters in einem Ereignis. Sobald diese Mechanismen getrennt sind, wird die Verteilung der Verantwortung viel klarer.

Bei der Intrusion handelte es sich nicht hauptsächlich um einen Regierungsmitarbeiter, der sein Passwort preisgab, um eine Behörde, die keine Multi-Faktor-Authentifizierung einsetzte, oder um einen ungepatchten Server in einem Ministerium. Storm-0558 besaß die private Hälfte eines 2016 erstellten Microsoft-Konto-Consumer-Signaturschlüssels. Ein privater Signaturschlüssel ermöglicht es seinem Inhaber, Token zu erzeugen, deren Signaturen gegen den entsprechenden öffentlichen Schlüssel verifiziert werden können. Der Akteur konnte daher Identitäten behaupten, ohne die Passwörter der Opfer zu erhalten.

Ein zweiter Microsoft-Fehler erlaubte es einem für Consumer-Konten vorgesehenen Schlüssel, Anfragen gegen Enterprise-Exchange-Online zu authentifizieren. Das Ergebnis war eine plattformweite Identitätsvortäuschungsfähigkeit, die die Grenze zwischen Microsofts Consumer- und Organisations-Identitätssystemen überschritt.

Microsoftstechnische Analyse vom Juli 2023erklärt den grundlegenden Mechanismus: Der Akteur fälschte Azure-Active-Directory-Token mit dem erlangten Consumer-Schlüssel, nutzte einen legitimen Outlook-Web-Access-Flow, bezog über die GetAccessTokenForResource-Schnittstelle Exchange-Online-Token und rief E-Mails über die OWA-API ab. Microsoft sagte, ein Designfehler habe es dem Akteur auch ermöglicht, neue Zugriffstoken zu erhalten, indem er ein zuvor von dieser Schnittstelle ausgestelltes Token präsentierte. Dies war nicht einfach die Wiederverwendung gestohlener Anmeldedaten. Es war die unbefugte Herstellung und Erneuerung von Anmeldedaten, die Microsofts Dienste als gültig behandelten.

Diese Unterscheidung ist wichtig für die Cloud-Verantwortlichkeit. Kunden bleiben normalerweise verantwortlich für ihre Identitäten, Gerätehygiene, Berechtigungen, Anwendungskonfiguration und Incident-Response. Aber ein Kunde kann das kryptografische Wurzelmaterial eines Cloud-Anbieters nicht einsehen oder rotieren, den produktiven Token-Validator des Anbieters nicht patchen oder einen Detektor in der Identitätsausstellungsebene des Anbieters nicht einsetzen.

Wenn der Fehler in Kontrollen seinen Ursprung hat, die nur dem Anbieter zur Verfügung stehen, beschreibt die Bezeichnung des Ereignisses als Problem der geteilten Verantwortung, ohne anzugeben, wer welche Sicherheitsvorkehrung kontrollierte, mehr, als es erklärt.

Es ist auch wichtig, das Ereignis nicht fälschlich als Dienstausfall zu klassifizieren. Die öffentliche Aufzeichnung zeigt nicht, dass Exchange Online für die betroffenen Behörden nicht verfügbar war. Der Schaden war der Verlust von Vertraulichkeit und vertrauenswürdiger Kommunikation, gefolgt von einer erheblichen Untersuchungslast. Kontinuität im öffentlichen Sektor umfasst mehr als die Erreichbarkeit eines Dienstes. Diplomatische, wirtschaftliche, gesetzgeberische und nationale Sicherheitsarbeit hängt davon ab, dass Amtsträger ein Kommunikationssystem nutzen können, ohne dass ein Gegner es stillschweigend mitliest.

Eine Cloud kann technisch „oben“ bleiben, während die öffentliche Funktion, die sie unterstützt, weniger vertrauenswürdig wird.

Was gesichert ist, was gefolgert wird und was unbekannt bleibt

Drei Evidenzkategorien sollten getrennt bleiben.

Erstens belegt die öffentliche Aufzeichnung eindeutig, dass Storm-0558 einen 2016 von Microsoft erstellten MSA-Consumer-Signaturschlüssel zur Fälschung von Token verwendete; dass ein Microsoft-Validierungsfehler diesen Token den Zugriff auf Enterprise-Exchange-Online-Konten ermöglichte; dass das Außenministerium verdächtige Aktivitäten durch erweiterte Postfachzugriffsprotokolle fand; und dass Microsoft die bekannte Technik durch eine Reihe von dienstseitigen Änderungen entschärfte.

Die Offenlegungen von Microsoft, die Reaktionsberatung von CISA, die Stellungnahmen betroffener Behörden und die Rekonstruktion des Cyber Safety Review Board konvergieren zu diesen Punkten.

Zweitens traf der Cyber Safety Review Board (CSRB) Feststellungen zur Vermeidbarkeit, zum Kontrolldesign, zur Sicherheitskultur, zur Offenlegung und zur Branchenpraxis. Seinevollständige Überprüfung der Intrusion im Sommer 2023kam zu dem Schluss, dass der Vorfall vermeidbar war und nie hätte passieren dürfen. Das Board befragte 20 Organisationen, erhielt die Zusammenarbeit von Microsoft, verglich Kontrollen bei anderen großen Cloud-Dienstanbietern und fand eine Kaskade vermeidbarer Fehler. Dies sind unabhängige Prüfungsfeststellungen, keine gerichtlichen Feststellungen, aber sie sind wesentlich stärker als Kommentare, die nur auf Microsofts frühen Blogs basieren.

Drittens bleibt der tatsächliche Weg, auf dem Storm-0558 den privaten Schlüssel von 2016 erlangte, in der öffentlichen Aufzeichnung unbekannt. Diese Unsicherheit ist zentral. Microsoft veröffentlichte im September 2023 eine detaillierte Crash-Dump-Geschichte, fügte dann im März 2024 eine Korrektur hinzu, dass es keinen Crash-Dump mit dem betroffenen Schlüsselmaterial gefunden habe. Der CSRB berichtete, dass Microsoft 46 Schlüsseldiebstahl-Hypothesen untersuchte und immer noch nicht weiß, wie oder wann der Akteur den Schlüssel erlangte. Jede Darstellung, die den Crash-Dump als nachgewiesene Grundursache präsentiert, überschätzt die Evidenz.

Die Aufzeichnung belegt auch keine endgültige rechtliche Verteilung des Schadens. Die Prüfung durch den Kongress, Ermittlungsersuchen und die Annahme der CSRB-Feststellungen durch Microsoft sind relevant für die Verantwortlichkeit. Sie ersetzen kein Gerichtsurteil, keine Behördenentscheidung, keine Vertragsauslegung und keine quantifizierte Schadensanalyse. Die richtige Schlussfolgerung ist enger: Microsoft kontrollierte mehrere fehlgeschlagene Sicherheitsvorkehrungen und übernahm die Verantwortung für die vom CSRB angeführten Probleme; die verfügbaren Quellen begründen keine endgültige zivil-, straf- oder aufsichtsrechtliche Haftung.

Forensische Chronologie

2016–2021: Ein langlebiger Schlüssel und eine verschobene Migration

Microsoft erstellte den Consumer-Signaturschlüssel im Jahr 2016. Das Alter eines Schlüssels ist an sich kein Beweis für Unsicherheit, aber das Alter wird materiell, wenn eine Organisation nicht sicher zeigen kann, dass sie den Schlüssel durchgehend in Gewahrsam hatte, und wenn eine Rotation die Nutzungsdauer von gestohlenem Material begrenzt. Der CSRB stellte fest, dass Microsofts Consumer-MSA-System auf manuelle Rotation angewiesen war, während sein Enterprise-Identitätssystem sich in Richtung Automatisierung bewegt hatte.

Das Unternehmen beabsichtigte, das Consumer-System auf die automatisierte Technologie zu migrieren, hatte diese Arbeit jedoch vor der Intrusion nicht abgeschlossen.

Laut CSRB stellte Microsoft die manuelle Rotation von Consumer-Signaturschlüsseln im Jahr 2021 nach einem größeren Cloud-Ausfall ein, der mit dem manuellen Prozess zusammenhing. Es setzte danach weder einen automatisierten Rotationsersatz noch einen Alarm ein, der die verantwortlichen Teams über alternde aktive Schlüssel informiert hätte. Der Schlüssel von 2016 blieb daher 2023 akzeptiert.

Dies ist eine klassische Entscheidung zwischen Verfügbarkeit und Sicherheit mit versteckten aufgeschobenen Kosten: Das Anhalten eines riskanten manuellen Verfahrens kann das unmittelbare Ausfallrisiko verringern, aber das Unterlassen der kompensierenden Automatisierung erhält das Sicherheitsrisiko auf unbestimmte Zeit aufrecht.

Die Feststellung des Boards ist nützlicher als die bloße Aussage, dass ein „abgelaufener“ Schlüssel funktionierte. Ein Schlüssel wird je nach der aktuellen Vertrauenskonfiguration des Dienstes akzeptiert oder abgelehnt. Der entscheidende Fehler war, dass ein zur Stilllegung vorgesehener Schlüssel innerhalb des Vertrauenssatzes blieb. Der aktuelleLeitfaden zum Signaturschlüssel-Rollovervon Microsoft selbst besagt, dass Anwendungen den periodischen und Notfall-Rollover programmatisch handhaben sollten, und empfiehlt Standardbibliotheken, um subtile Fehler zu vermeiden. Diese Anleitung beschreibt das kundenseitige Validierungsverhalten, aber das zugrunde liegende Prinzip gilt allgemeiner: Der Schlüsselaustausch muss eine entwickelte Fähigkeit sein, keine fragile Zeremonie, deren Durchführung zu riskant wird.

Im September 2018 führte Microsoft einen gemeinsamen Metadaten-Endpunkt für Schlüssel ein, um der Nachfrage nach Anwendungen gerecht zu werden, die sowohl Consumer- als auch Enterprise-Nutzer bedienten. Microsofts späterer Bericht sagte, die Dokumentation sei aktualisiert worden, um die Schlüsselbereichsvalidierung zu erklären, aber Hilfsbibliotheken wurden nicht aktualisiert, um diesen Bereich automatisch durchzusetzen. Exchange-Mail-Systeme begannen 2022, den gemeinsamen Metadaten-Endpunkt zu nutzen.

Entwickler nahmen an, dass die Bibliothek eine vollständige Validierung durchführte, und fügten die erforderliche Aussteller- oder Bereichsprüfung nicht hinzu. Der gemeinsame Endpunkt erhöhte daher die Interoperabilität und schuf gleichzeitig eine Vertrauensgrenzgefahr: Kryptografische Gültigkeit wurde mit Autorisierung innerhalb der korrekten Identitätsdomäne verwechselt.

Die Rekonstruktion des CSRB ordnet ein weiteres relevantes Ereignis im Jahr 2021 ein. Storm-0558 kompromittierte zwischen April und August das Unternehmensnetzwerk von Microsoft über ein Konto eines Ingenieurs. Der Ingenieur arbeitete für Affirmed Networks, das Microsoft 2020 übernommen hatte; Microsoft glaubte, dass das Gerät vor der Übernahme kompromittiert worden war und sich später mit Unternehmensanmeldedaten mit der Microsoft-Umgebung verband. Der Akteur erfasste und spielte ein Authentifizierungstoken wieder ein und griff auf Material in SharePoint zu, darunter Informationen zur Azure-Dienstverwaltung und Identität.

Das Board kritisierte Microsoft dafür, dass es das kompromittierte Gerät des übernommenen Unternehmens nicht erkannte, bevor es die Verbindung zum Unternehmensnetzwerk zuließ.

Diese Kompromittierung von 2021 ist ein Hinweis auf den Zugriff und das Interesse des Angreifers. Sie ist kein Beweis dafür, dass der Akteur damals den MSA-Schlüssel von 2016 erlangte. Microsoft teilte dem Board mit, dass die Intrusion von 2021 wahrscheinlich damit zusammenhänge, da es die einzige andere bekannte Storm-0558-Intrusion in Microsofts Netzwerk im aufgezeichneten Speicher sei, aber das Unternehmen legte keine spezifischen Beweise vor, die sie mit dem Schlüsseldiebstahl verbanden. Eine disziplinierte Darstellung muss diese Lücke bewahren.

Mai–Juni 2023: Zugriff beginnt, bevor der Anbieter ihn erkennt

Storm-0558 richtete identifizierte externe Infrastruktur ein und begann spätestens am 15. Mai 2023 auf gezielte Exchange-Online-Konten zuzugreifen. Der CSRB warnte davor, dass das Kompromittierungsfenster früher hätte beginnen können, da Microsofts standardmäßige 30-tägige Protokollaufbewahrung den retrospektiven Blick einschränkte, der nach Beginn der Untersuchung verfügbar war. „Erstmalig gesehen“ ist daher eine Evidenzgrenze, nicht unbedingt der wahre Beginn des Angriffs.

Die Ziele spiegelten Spionageprioritäten wider. Die endgültige CSRB-Abrechnung identifizierte 22 Organisationen und mehr als 500 Einzelpersonen weltweit, darunter Opfer in den Vereinigten Staaten, dem Vereinigten Königreich und anderswo. Zu den Konten gehörten die von Handelsministerin Gina Raimondo, US-Botschafter in China R. Nicholas Burns, dem stellvertretenden Außenminister für ostasiatische und pazifische Angelegenheiten Daniel Kritenbrink und Kongressabgeordnetem Don Bacon. Die ersteVorfallmeldung von Microsoft vom 11. Julibezog sich auf etwa 25 Organisationen und damit verbundene Consumer-Konten. Der Unterschied ist am besten als Änderung in der Vorfallbuchhaltung zwischen einer frühen Unternehmensmitteilung und der späteren unabhängigen Rekonstruktion zu behandeln, nicht als Hinweis auf eine neue Intrusion.

Das Außenministerium, nicht Microsoft, entdeckte die Kampagne. Am 15. Juni beobachtete das Sicherheitsoperationszentrum des Ministeriums Anomalien. Am 16. Juni generierte eine intern als Big Yellow Taxi bekannte benutzerdefinierte Regel Warnungen aus dem MailItemsAccessed-Audit-Ereignis, das den Zugriff auf Exchange-Online-Postfachelemente aufzeichnet. Das Ministerium untersuchte trotz der Möglichkeit falsch positiver Ergebnisse und kontaktierte Microsoft noch am selben Tag. Bis zum 19.

Juni hatte das Ministerium festgestellt, dass auf sechs Konten zugegriffen worden war, darunter Konten, die mit den Vorbereitungen für die Reise des Außenministers nach Peking verbunden waren. Es identifizierte sechs weitere Konten, auf die zwischen dem 21. und 24. Juni zugegriffen wurde, und ein weiteres durch die Analyse eines beschlagnahmten virtuellen privaten Servers.

Die Daten zeigen, dass Entdeckung und Eindämmung sich mit anhaltendem Zugriff überschnitten. Die Warnung des Ministeriums war ein Erkennungserfolg, aber sie enthüllte nicht sofort eine gefälschte Plattform-Anmeldeinformation. Microsoft untersuchte zunächst naheliegende Erklärungen wie kompromittierte Geräte und gestohlene korrekt ausgestellte Token. Seine Analysten sahen dann, dass Exchange-Online-Authentifizierungsartefakte nicht mit den erwarteten Azure-AD-Token in den Protokollen korrespondierten. Am oder um den 26.

Juni stellte Microsoft fest, dass der Akteur den Consumer-Schlüssel von 2016 verwendete, um Token zu erstellen, die sowohl gegen Consumer- als auch Enterprise-Mail funktionierten.

DieCISA-FBI-Beratung AA23-193Aist ungewöhnlich direkt bezüglich der Verteilung der Abhilfefähigkeit. Sie besagt, dass alle Abhilfemaßnahmen für diese Aktivität in der Verantwortung von Microsoft lagen, da die betroffene Infrastruktur cloudbasiert war. Sie sagt auch, dass den Behörden keine anderen Audit-Protokolle oder Ereignisse bekannt seien, die die Aktivität erkannt hätten. Der Kunde entdeckte den Vorfall, aber nur der Anbieter konnte die Technik schließen.

26. Juni – 3. Juli: Gestaffelte Eindämmung statt eines einzelnen Schalters

Microsofts detaillierte Chronologie verzeichnet mehrere getrennte Aktionen:

• Am 26. Juni stellte OWA die Annahme von Token ein, die von GetAccessTokenForResource zur Erneuerung ausgestellt wurden, und schloss das vom Akteur missbrauchte Erneuerungsverhalten.
• Am 27. Juni blockierte Microsoft die Verwendung von Token durch OWA, die mit dem erlangten MSA-Schlüssel signiert waren, und verhinderte so weiteren Enterprise-Mail-Zugriff über den beobachteten Pfad.
• Am 29. Juni schloss Microsoft den Austausch des Schlüssels ab, widerrief alle MSA-Signaturschlüssel, die während des Vorfalls gültig waren, und gab neue Schlüssel aus gehärteten Systemen aus.
• Am 3. Juli blockierte Microsoft die Verwendung des Schlüssels für betroffene Consumer-Kunden, um die Verwendung zuvor ausgestellter Token zu verhindern.

Diese Abfolge zeigt, warum „der Schlüssel wurde widerrufen“ keine ausreichende Beschreibung der Eindämmung ist. Eine Kampagne mit gefälschten Token kann zwischengespeicherte Validierungsmetadaten, nachgelagerte Zugriffsartefakte, Erneuerungsschnittstellen, Consumer- und Enterprise-Dienste sowie bereits ausgestellte Token umfassen. Eine dauerhafte Eindämmung erfordert die Kartierung jedes Ortes, an dem die alte Vertrauensentscheidung fortbesteht.

Microsoft sagte, es habe beobachtet, dass Storm-0558 nach der Blockierung des bekannten Token-Fälschungspfads auf Phishing und andere Techniken umschwenkte, und es habe keine weiteren schlüsselbezogenen Aktivitäten gesehen. Dies stützt die Wirksamkeit der sofortigen Abhilfemaßnahmen gegen die beobachtete Methode. Es beweist nicht, dass der ursprüngliche Erlangungspfad identifiziert wurde oder dass der Akteur nie anderes sensibles Material erlangte. Der CSRB sagte ausdrücklich, dass die Möglichkeit des Zugriffs auf andere Schlüssel und Daten ungeklärt bleibe.

Juli 2023 – März 2024: Offenlegung, Protokollierungsreform und eine korrigierte Grundursachenbehauptung

Microsoft legte die Kampagne am 11. Juli öffentlich offen und veröffentlichte am 14. Juli eine tiefere technische Analyse. Seine frühen Beiträge beschrieben korrekt den Schlüsselmissbrauch und den Validierungsfehler, während sie sagten, dass die Schlüsselgewinnung noch untersucht werde. Am 19. Juli, nach Koordination mit CISA, kündigte Microsoft an, dass detaillierte E-Mail-Zugriffsprotokolle und mehr als 30 andere Audit-Ereignistypen Standard-Kunden ohne zusätzliche Kosten zur Verfügung gestellt würden. Das Unternehmen sagte auch, dass die standardmäßige Aufbewahrungsdauer für Audit Standard von 90 auf 180 Tage erhöht werde. MicrosoftsProtokollierungsankündigungist eine substanzielle Reaktion, weil sie ändert, wer die Evidenz sehen kann, die zur Erkennung anbieterverursachten Missbrauchs erforderlich ist.

Am 6. September veröffentlichte Microsoft das, was es als Ergebnisse seiner wichtigsten technischen Untersuchungen bezeichnete. Der ursprüngliche Bericht behauptete, dass ein Absturz des Consumer-Signatursystems im April 2021 einen Crash-Dump produzierte; dass eine Race-Bedingung den Schlüssel in den Dump gelangen ließ; dass der Dump aus einer isolierten Produktionsumgebung in eine internetverbundene Unternehmensdebugging-Umgebung gelangte; dass Anmeldeinformationsscanner ihn übersahen; und dass Storm-0558 später ein Ingenieurkonto mit Zugriff auf diese Umgebung kompromittierte.

Da relevante Protokolle aufgebraucht waren, nannte Microsoft dies den wahrscheinlichsten Erlangungsmechanismus.

Diese Erzählung lieferte eine kohärente Kette, aber die Kette wurde nicht durch direkte Evidenz gestützt. Microsoftsversionierter September-Berichtbeginnt nun mit einem Update vom 12. März 2024. Das Unternehmen sagt, seine Haupthypothese bleibe, dass operative Fehler dazu führten, dass Schlüsselmaterial die sichere Signaturumgebung verließ und dass auf das Material über ein kompromittiertes Ingenieurkonto zugegriffen wurde. Es sagt auch, dass es keinen Crash-Dump gefunden habe, der den betroffenen Schlüssel enthielt, die zitierte Race-Bedingung beeinflusste, ob ein Dump die Signaturumgebung verlassen konnte, nicht ob Schlüsselmaterial vorhanden sein konnte, und das Entfernen solchen Materials kein Standardprozess war, aber zu diesem Zeitpunkt nicht verboten war.

Die Korrektur ändert den erkenntnistheoretischen Status des Berichts. Eine plausible Hypothese ist kein Grundursachenbefund. Der CSRB berichtete, dass Microsoft dem Board im November 2023 mitteilte, dass es kurz nach der Veröffentlichung erkannt habe, dass die September-Aussagen ungenau seien, aber die Korrektur erst im März 2024 nach wiederholten Fragen des Boards veröffentlichte. Diese Verzögerung wurde Teil der Feststellung des Boards zur Sicherheitskultur, da Kunden Offenlegungen von Grundursachen verwenden, um zu beurteilen, ob der tatsächliche Erlangungspfad geschlossen wurde.

Grundursache, Auslöser und Erkennungsfehler

Die Vorfallanalyse ist präziser, wenn sie den Auslöser von Grundursachen und von Fehlern bei der Erkennung und Reaktion trennt.

Auslöser

Der operative Auslöser war die Verwendung des gestohlenen privaten MSA-Signaturschlüssels von 2016 durch Storm-0558 zur Erstellung von Token und deren Präsentation über Exchange-Online-Zugriffspfade. Der Akteur wählte Ziele aus, betrieb Infrastruktur, prägte Behauptungen, griff auf E-Mails zu und exfiltrierte Nachrichten. Der Akteur ist für die böswillige Intrusion verantwortlich. Die Zuordnung zu einem Spionageakteur, der mit der Volksrepublik China in Verbindung gebracht wird, ist eine Intelligenzbewertung, die von Microsoft und dem CSRB berichtet wurde; dieser Artikel schreibt keine staatliche Steuerung unabhängig zu.

Technische Grundursachen und ermöglichende Bedingungen

Die erste Grundursachenfrage, wie der private Schlüssel die Kontrolle von Microsoft verließ, ist ungeklärt. Sie sollte als offene materielle Tatsache festgehalten werden, nicht mit der Crash-Dump-Hypothese gefüllt werden.

Die zweite Ursache ist viel besser belegt: Der alte Schlüssel blieb vertrauenswürdig. Die manuelle Consumer-Schlüsselrotation wurde 2021 nach einem Ausfall eingestellt, der automatisierte Ersatz war nicht bereit, und kein wirksamer Alarm aufgrund des Alters erzwingt eine Lösung. Der Diebstahl eines kurzlebigen oder rechtzeitig zurückgezogenen Schlüssels hätte eine kleinere Gelegenheit geschaffen. Der Diebstahl eines Schlüssels, der jahrelang akzeptiert blieb, erzeugte dauerhafte Signierungsmacht.

Die dritte Ursache war das Versagen des Token-Validierungsbereichs. Der Dienst überprüfte eine Signatur gegen Schlüsselmaterial, das über gemeinsame Metadaten verfügbar war, prüfte aber nicht ausreichend, ob die Identitätsdomäne des Schlüssels berechtigt war, die angeforderte Unternehmensressource zu autorisieren. Microsofts aktuelleDokumentation zur Zugriffstoken-Validierungsagt Resourcenserver, dass sie Tokensignatur, Zielgruppe, Aussteller, Mandanten und Signaturschlüssel-Aussteller validieren sollen. Der Storm-0558-Fall zeigt, warum diese Prüfungen nicht redundant sind. Eine mathematisch gültige Signatur beantwortet, wer einen privaten Schlüssel besaß; sie beantwortet nicht von selbst, ob dieser Schlüssel für diesen Mandanten, diese Kontoklasse, diesen Dienst oder diese Ressource autorisiert war.

Die vierte Ursache war der Designfehler bei der OWA-Token-Erneuerung. Sobald die gefälschte Identität durch einen legitimen Flow akzeptiert wurde, erlaubte GetAccessTokenForResource einem Token, ein anderes zu erhalten, auf eine Weise, die Microsoft später änderte, um zwischen Azure-AD- und MSA-Ausstellung zu unterscheiden. Dies schuf nicht die ursprüngliche Signierungsfähigkeit, aber es machte den Zugriffspad nützlicher und dauerhafter.

Die fünfte ermöglichende Bedingung war eine unzureichende anbieterseitige Anomalieerkennung. Microsoft sagte, dass das Token-Muster des Akteurs im Nachhinein offensichtlich war, da kein legitimes Microsoft-System Token in dieser Kombination signierte. Dennoch alarmierte der Anbieter nicht auf diesen unmöglichen oder hochgradig anomalen Zustand, bevor ein Kunde Postfachverhalten meldete.

Der CSRB stellte fest, dass andere Cloud-Anbieter Kontrollen hatten, die Microsoft fehlten, und empfahl, dass Anbieter proprietäre Daten in Token-Generierungsalgorithmen und Validierungssignalen verwenden, um gefälschte Behauptungen zu erkennen, selbst wenn eine Signatur verifiziert.

Erkennungs- und Reaktionsfehler

Die Erkennung hing von einem Kunden mit einer Premium-Lizenz, einer benutzerdefinierten Analyse, qualifizierten Bedienern und der Bereitschaft ab, einen moderaten Alarm zu verfolgen, der zuvor falsch positive Ergebnisse erzeugt hatte. Dies ist eine beeindruckende Kontrolle des Außenministeriums. Es ist auch ein instabiles systemweites Sicherheitsmodell. Tausende von Kunden können nicht erwarten, die kryptografische Kompromittierung eines Anbieters aus optionalen Postfach-Ereignissen zu rekonstruieren, insbesondere wenn das für diese Kampagne benötigte Ereignis für Benutzer mit Standardlizenz nicht verfügbar war.

Zu dieser Zeit war MailItemsAccessed über Microsoft Purview Audit Premium verfügbar und erforderte eine E5- oder G5-Lizenzierung. Das Ministerium hatte G5 und konnte Big Yellow Taxi erstellen. Anderen Opfern ohne Premium-Protokollierung fehlte die gleiche historische Sichtbarkeit. Die Beratung von CISA und FBI drängte daher Organisationen, die Premium-Protokollierung zu aktivieren, während sie ausdrücklich die Lizenzanforderung erwähnte. Sieben Tage später verpflichtete sich Microsoft, die Tarifbarriere für wichtige Ereignistypen zu beseitigen. CISA-Direktorin Jen Easterly beschrieb die Änderung inCISAs Stellungnahme vom 19. Julials Schritt in Richtung „Secure-by-Design“-Praxis.

Die Reaktion wurde auch durch die Aufbewahrung von Anbieterevidenz eingeschränkt. Microsoft hatte nicht die Protokolle, die notwendig waren, um zu bestimmen, wie oder wann der Schlüssel gestohlen worden war. Dreißig-Tage-Fenster begrenzten die früheste beobachtbare Kundenaktivität, während ältere Unternehmens- und Produktionsereignisse, die für die Hypothese von 2021 benötigt wurden, nicht verfügbar waren.

Protokollaufbewahrung trägt immer Kosten, Datenschutz- und Zugriffskontrollverpflichtungen, aber ein Anbieter kann glaubwürdig nicht behaupten, kryptografische Kronjuwelen zu schützen, wenn sein Evidenzhorizont kürzer ist als die Zeit, die ausgefeilte Akteure still bleiben können.

Schließlich war die verspätete Korrektur des September-Kausalberichts ein Reaktionsfehler. Sie ermöglichte nicht die ursprüngliche Intrusion, aber sie beeinträchtigte das öffentliche Vertrauen. Ein Bericht nach einem Vorfall sollte Fakten, bewertete Hypothesen, Vertrauen, widersprüchliche Evidenz und ungelöste Fragen trennen. Die Veröffentlichung eines vollständig klingenden Mechanismus und seine Korrektur erst sechs Monate später machte es für Kunden und Aufsichtsbehörden schwieriger zu beurteilen, ob die Abhilfe den tatsächlichen Pfad adressierte.

Das Protokollierungs- und Lizenzierungsproblem

Protokollierung wird manchmal als nebensächliches Produktmerkmal behandelt. In diesem Vorfall war sie eine Sicherheitskontrolle und eine Quelle von Informationsasymmetrie.

Microsoft besaß dienstweite Telemetrie und interne Identitätssystemsicht, die keinem Kunden zur Verfügung stand. Jeder Kunde konnte nur seinen Mandanten und nur die Ereignistypen beobachten, die in seinem Abonnement und seiner Konfiguration enthalten waren. Der entscheidende Alarm kam von MailItemsAccessed, einem Ereignis, das entwickelt wurde, um anzuzeigen, wann auf Postfachelemente zugegriffen wurde. CISA und das FBI erklärten, dass ihnen kein anderes Audit-Ereignis bekannt sei, das diese Aktivität erkannt hätte.

Ein Kunde ohne das Ereignis konnte immer noch kontextuelle Anzeichen bemerken, aber ihm fehlte die gleiche direkte Evidenzoberfläche.

Dies schafft eine problematische kommerzielle Grenze. Premium-Sicherheitsprodukte können vernünftigerweise für fortschrittliche Analysen, Automatisierung, lange Aufbewahrung und verwaltete Untersuchung Gebühren erheben. Die Mindestevidenz, die erforderlich ist, um zu wissen, ob ein anbietero­perierter Dienst auf Kundendaten zugegriffen hat, ist anders. Wenn ein Anbieter allein das System kontrolliert und ein Kunde extra bezahlen muss, um den Zugriff zu beobachten, der aus dem eigenen Identitätsfehler des Anbieters resultiert, wird der Kunde gebeten, Sichtbarkeit in ein Risiko zu kaufen, das der Kunde nicht direkt beheben kann.

Die Änderung nach dem Vorfall erkennt diese Unterscheidung an. Microsoft verpflichtete sich, breitere Cloud-Sicherheitsprotokolle weltweit ohne zusätzliche Kosten zur Verfügung zu stellen, detaillierte E-Mail-Zugriffsereignisse zu Audit Standard hinzuzufügen und die standardmäßige Standardaufbewahrung auf 180 Tage zu verdoppeln. Im Februar 2024 kündigten CISA, das Office of Management and Budget, das Office of the National Cyber Director und Microsoft an, dass erweiterte Protokollierung allen Bundesbehörden, die Purview Audit verwenden, unabhängig von der Stufe zur Verfügung gestellt wird, mit automatischer Aktivierung und der längeren Standardaufbewahrung. Diegemeinsame Umsetzungsankündigungrahmte hochwertige Audit-Protokolle ohne zusätzliche Kosten oder Konfiguration als Secure-by-Design-Erwartung ein.

Die Reform beseitigt nicht die Verantwortung des Kunden. Protokolle müssen in durchsuchbare Systeme geleitet, gemäß Risiko und rechtlichen Anforderungen aufbewahrt, mit Basislinien versehen, abgefragt und mit Reaktionsverfahren verbunden werden. CISAs Beratung empfiehlt genau diese Maßnahmen. Aber die operative Disziplin des Kunden wird nur sinnvoll, nachdem der Anbieter das relevante Ereignis ausgibt und es zugänglich macht. Telemetrieverfügbarkeit und Telemetrienutzung sind zwei verschiedene Kontrollen, die verschiedenen Parteien gehören.

Die Lizenzierung beeinflusste auch die forensische Gleichheit unter den Opfern. Die G5-Umgebung des Ministeriums hatte eine stärkere historische Aufzeichnung als Umgebungen der Standardstufe. Die Aktivierung eines Ereignisses nach einem Vorfall rekonstruiert nicht, was nie aufgezeichnet wurde. Dies bedeutet, dass derselbe Anbieterfehler unterschiedliche Vertrauensniveaus über die Auswirkungen basierend auf dem Abonnement eines Kunden erzeugen kann, obwohl keiner der Kunden den zugrunde liegenden Signaturschlüssel kontrollierte.

Mindestforensische Evidenz sollte daher als Teil der Sicherheitsbasislinie des Dienstes behandelt werden, nicht nur als Upsell.

Auswirkungen auf Bundeskunden und Kontinuität des öffentlichen Sektors

Die Kompromittierung betraf nicht klassifizierte E-Mails, aber „nicht klassifiziert“ bedeutet nicht operativ trivial. Die Postfächer hochrangiger Beamter enthalten Zeitpläne, politische Erwägungen, Kontaktnetzwerke, Verhandlungspositionen, Entwürfe und das gewöhnliche Bindegewebe der Regierung. Ein Nachrichtendienst kann aus Aggregation, Zeitpunkt, Beziehungen und Kontext einen Wert ableiten, ohne formell klassifizierte Dokumente zu erhalten.

Das Außenministerium sagte später, dass etwa 60.000 E-Mails von 10 Konten heruntergeladen wurden. In seinemPressebriefing vom 28. September 2023beschrieb das Ministerium das betroffene Material als nicht klassifiziert und sagte, dass keine klassifizierten E-Mail-Systeme gehackt wurden. Die breitere Rekonstruktion des CSRB identifizierte mehr staatliche Konten, auf die zugegriffen wurde, was unterschiedliche Arten der Zählung von Konto-Zugriff und die Teilmenge widerspiegelt, von der Nachrichten heruntergeladen wurden. Der Artikel folgert nicht auf den Inhalt von Nachrichten über das hinaus, was Behörden offengelegt haben.

Die offiziellen und privaten Postfächer des Handelsministers gehörten laut CSRB zu den betroffenen. Auch das US-Repräsentantenhaus war im betroffenen Satz, einschließlich Kongressabgeordneter Don Bacon. EineUntersuchung des House Oversight Committee vom August 2023forderte Briefings von State und Commerce zu Entdeckung, Auswirkungen, Reaktion und zukünftiger Sicherheit. Diese Fakten belegen sensible Exposition des öffentlichen Sektors und Aufsichtsbesorgnis; sie belegen nicht, dass sich bestimmte politische Entscheidungen aufgrund der Intrusion geändert haben.

Kontinuität hat in diesem Zusammenhang mindestens fünf Dimensionen.

Erstens ist die Vertraulichkeitskontinuität: Amtsträger brauchen eine dauerhafte Erwartung, dass routinemäßige Cloud-Kommunikation nicht stillschweigend von einem ausländischen Nachrichtendienst kopiert wird.

Zweitens ist die Entscheidungskontinuität: Teams, die diplomatische Reisen oder Wirtschaftspolitik vorbereiten, müssen in der Lage sein zu beraten, ohne anzunehmen, dass der Gegner gleichzeitigen Zugriff auf ihre E-Mails hat.

Drittens ist die Evidenzkontinuität: Behörden benötigen genügend aufbewahrte Daten, um zu rekonstruieren, wer wann worauf zugegriffen hat. Ohne diese können Führungskräfte den Vorfall nicht sicher eingrenzen oder entscheiden, welche Beziehungen und Entscheidungen eine erneute Validierung erfordern.

Viertens ist die Reaktionskontinuität: Eine Anbieterkompromittierung zwingt Behörden dazu, Sicherheits-, Rechts-, diplomatische, Aufzeichnungs- und Führungskapazitäten umzuleiten. Selbst wenn E-Mails verfügbar bleiben, absorbiert die Missionsarbeit eine versteckte Incident-Response-Steuer.

Fünftens ist die Vertrauenskontinuität: Die Nutzung gemeinsamer Cloud-Dienste durch Bundesbehörden hängt von der Zusicherung ab, dass der Anbieter Fehler in seiner eigenen Kontrollebene erkennt, sie genau offenlegt und den Kunden nutzbare Evidenz liefert. Ein Dienst kann ein Verfügbarkeitsziel erreichen, während er diesen breiteren Kontinuitätstest nicht besteht.

Der Vorfall offenbarte auch Konzentrationsrisiken. Microsoft stellt Identitäts-, E-Mail-, Produktivitäts-, Betriebssystem-, Sicherheits- und Cloud-Dienste in weiten Teilen der Regierung und des privaten Sektors bereit. Integration kann Verwaltung und Erkennung verbessern, aber sie kann auch zulassen, dass ein anbieterseitiger Identitätsfehler in globalem Maßstab organisatorische Grenzen überschreitet. Der CSRB beschrieb die Zentralität von Microsoft als Grund, die höchsten Standards an Sicherheit, Verantwortlichkeit und Transparenz zu fordern.

Konzentration führt nicht automatisch zu dem Schluss, dass jede Behörde Microsoft aufgeben oder doppelte E-Mail-Systeme unterhalten sollte. Migration selbst schafft Kosten und Risiken, und mehrere Anbieter können ähnliche Identitätsschwächen aufweisen. Die stärkere Schlussfolgerung ist, dass Beschaffung und Aufsicht den Common-Mode-Identitätsfehler explizit bewerten müssen: Schlüsselsegmentierung, anbieterseitige Anomalieerkennung, Audit-Zugriff, Evidenzaufbewahrung, Vorfallbenachrichtigung, unabhängige Tests und Ausstiegs- oder Kontinuitätsvereinbarungen sollten als Serviceanforderungen behandelt werden.

Die Feststellungen des CSRB und warum sie wichtig sind

DieVeröffentlichungsseite des CSRBbeschreibt den Bericht als unabhängige Überprüfung operativer und strategischer Entscheidungen und sagt, dass er Praktiken für Industrie und Regierung empfiehlt. Seine Kernfeststellungen sind schwerwiegend, aber spezifisch.

Das Board kam zu dem Schluss, dass die Sicherheitskultur von Microsoft unzureichend war und einer Überholung bedurfte. Es stützte diese Schlussfolgerung auf die vermeidbare Kaskade, das Versagen, die Kompromittierung eines kritischen Signaturschlüssels zu erkennen, die Abhängigkeit von einem Kunden für die Entdeckung, den Vergleich mit Kontrollen bei anderen Anbietern, die Kompromittierung des erworbenen Geräts von 2021, die verspätete Korrektur ungenauer öffentlicher Aussagen und eine separate staatliche Akteurskompromittierung von 2024, die außerhalb des Rahmens dieser Überprüfung lag.

Die Feststellung ist organisatorisch, da kein einzelner Codierungsfehler erklärt, warum der Schlüssel akzeptiert blieb, warum die Domänentrennung versagte, warum unmögliche Token-Muster nicht alarmierten, warum Evidenz nicht verfügbar war und warum eine Kausalbehauptung den Beweis überholte.

Das Board lieferte auch konkrete kontrafaktische Szenarien. Wenn die manuelle Rotation nicht ohne einen abgeschlossenen automatisierten Ersatz gestoppt worden wäre oder wenn ein Alarm aufgrund des Schlüsselalters Maßnahmen erzwungen hätte, wäre der Schlüssel von 2016 im Jahr 2023 nicht mehr gültig gewesen. Wenn die Consumer- und Enterprise-Validierung korrekt getrennt worden wäre, wäre die Reichweite des Akteurs viel enger gewesen und hätte keine Enterprise-Kunden eingeschlossen.

Wenn Microsoft Token erkannt hätte, die nicht seinem eigenen Generierungsalgorithmus entsprachen, wäre die Kampagne möglicherweise blockiert oder anbieterseitig erkannt worden. Wenn eine stärkere forensische Aufbewahrung existiert hätte, hätte Microsoft die Schlüsselgewinnungsfrage möglicherweise beantworten können.

Diese kontrafaktischen Szenarien demonstrieren ein abgestuftes Sicherheitsprinzip. Die Intrusion erforderte nicht, dass jede Kontrolle auf die gleiche Weise versagte. Jede von mehreren unabhängigen Kontrollen hätte die Enterprise-Kompromittierung verhindern oder wesentlich verkürzen können:

• Sicherer Gewahrsam hätte den Schlüsselverlust verhindern können.
• Häufige automatische Rotation hätte den gestohlenen Schlüssel vor 2023 unbrauchbar machen können.
• Bereichsbewusste Validierung hätte einen Consumer-Schlüssel auf Consumer-Dienste beschränken können.
• Statusbehaftete oder proprietäre Token-Prüfungen hätten ein Token erkennen können, das Microsoft selbst nie ausstellen würde.
• Anbieterweite Überwachung hätte die unmögliche Signatur-Domänen-Kombination aufdecken können.
• Basislinien-Kundenprotokolle hätten mehr Opfern ermöglicht, Zugriff zu erkennen und einzugrenzen.
• Längere Anbieteraufbewahrung hätte das Vertrauen in die Grundursache verbessern können.

Deshalb verhindert der ungeklärte Diebstahlspfad nicht die Verantwortlichkeitsanalyse. Das Unbekannte ist wichtig, aber mehrere unabhängig ausreichende oder wirkungsbegrenzende Fehler sind dokumentiert. Ein Anbieter kann ein fehlendes Grundursachen-Glied nicht dadurch beantworten, dass er die gesamte Kette als unerkennbar behandelt.

Die Empfehlungen des Boards gingen über Microsoft hinaus. Sie forderten moderne Schlüsselverwaltungspraktiken, automatische und häufige Rotation, hardwaregeschützte Schlüssel, gemeinsame Authentifizierungsbibliotheken, stärkere digitale Identitätsstandards, minimale Kundenprotokollierung ohne zusätzliche Gebühren, mindestens sechs Monate angemessene kundenzugängliche Protokolle, bessere Benachrichtigung der Opfer und transparentere Offenlegung von Cloud-Sicherheitslücken. Diese Maßnahmen adressieren eine Industriestruktur, in der Anbieter sowohl die privilegierte Kontrolle als auch die beste Evidenz halten.

Microsofts Reaktion

Microsofts unmittelbare Reaktion korrigierte die bekannten Validator- und Erneuerungsfehler, blockierte den gestohlenen Schlüssel, widerrief die damals aktiven MSA-Signaturschlüssel, bewegte Consumer-Schlüssel in Richtung des gehärteten Enterprise-Schlüsselspeichers, erhöhte die Isolation und verfeinerte die Schlüsselsystemüberwachung. Diese Maßnahmen adressierten direkt die beobachtete Kampagne. Microsoft benachrichtigte auch betroffene Organisationen und veröffentlichte Infrastrukturindikatoren für Verteidiger.

Das Unternehmen nahm dann eine kommerzielle Kontrolländerung vor, indem es den Audit-Zugriff erweiterte. Diese Maßnahme ist in der Produktverpflichtung und der bundesstaatlichen Einführung unabhängig beobachtbar, obwohl die praktische Vollständigkeit der Ereignisabdeckung immer noch vom Dienst, der Konfiguration, der Aufbewahrung und den Kundenoperationen abhängt.

Im November 2023 startete Microsoft die Secure Future Initiative. Ihreerste SFI-Ankündigungverpflichtete sich zu einem einheitlichen, vollautomatischen Consumer- und Enterprise-Schlüsselverwaltungssystem unter Verwendung von vertraulichem Computing und Hardware-Sicherheitsmodulen, mit einer Architektur, die Schlüssel selbst dann unzugänglich hält, wenn zugrunde liegende Prozesse kompromittiert sind. Ein begleitender technischer Beitrag verpflichtete sich zu hochfrequenter automatischer Rotation ohne menschlichen Zugriff.

Nach dem CSRB-Bericht und einer separaten russischen staatlichen Intrusion in Microsofts Unternehmens-E-Mail erweiterte das Unternehmen SFI im Mai 2024. Microsoftserweitertes Programmsetzte Ziele, darunter schnelle automatische Rotation und Hardwareschutz für Signaturschlüssel, standardmäßige Identitäts-SDKs in allen Anwendungen, zustandsbehaftete und dauerhafte Validierung für Identitätstoken, feinere Schlüsselpartitionierung, Beseitigung lateraler Identitätspivotpunkte, zweijährige Aufbewahrung für Sicherheitsprotokolle und sechs Monate angemessene Protokolle für Kunden. Es sagte auch, dass ein Teil der Vergütung der oberen Führungsebene von Sicherheitsmeilensteinen abhängen würde.

Im Juni 2024 sagte Microsofts Vizepräsident und Präsident Brad Smith vor dem Homeland Security Committee des Repräsentantenhauses, dass das Unternehmen die Verantwortung für jeden im CSRB-Bericht angeführten Punkt übernehme. Seineschriftliche Aussagesagte, dass Microsoft alle 16 für das Unternehmen relevanten Empfehlungen des Boards umsetze, das Äquivalent von 34.000 Vollzeit-Ingenieuren für SFI bereitstelle, die Consumer- und Enterprise-Identitätssysteme auf ein hardwaregestütztes Schlüsselverwaltungssystem umstelle und Fortschritte bei der automatischen Rotation, gemeinsamen Authentifizierungsbibliotheken und Token-Validierungssignalen gemacht habe. DasSitzungsprotokoll des Kongressesliefert den öffentlichen Aufsichtskontext und die Befragung.

Bis September 2024 berichtete Microsoft über einen Cybersecurity Governance Council, stellvertretende Chief Information Security Officers für Ingenieursabteilungen, Sicherheit in Mitarbeiterleistungsbeurteilungen und regelmäßige Prüfung durch Führungsebene und Vorstand. DerSFI-Fortschrittsbericht des Unternehmensist ein Beleg für Governance-Änderungen und angegebenen Umsetzungsfortschritt.

Diese Reaktionen sind substanzielle Verpflichtungen. Sie sollten dennoch als Verpflichtungen und vom Unternehmen berichteter Fortschritt beschrieben werden, wo keine unabhängige Überprüfung öffentlich ist. Der CSRB empfahl spezifische Architekturen und Kontrollen, bescheinigte aber nicht deren spätere Fertigstellung.

Ein glaubwürdiger Abschlussstandard würde messbare Schlüsselrotationsabdeckung, Nachweise, dass Legacy-Validatoren stillgelegt wurden, Tests, die zeigen, dass Consumer- und Enterprise-Grenzen sicher schließen, aufbewahrte Telemetrie, die ausreicht, um Schlüsselereignisse zu untersuchen, und externe Zusicherung, dass Ausnahmen nicht stillschweigend bestehen bleiben können, erfordern.

Verantwortlichkeit durch Kontrollfähigkeit

Eine nützliche Verantwortlichkeitskarte beginnt damit, wer jeden Fehler verhindern, erkennen, begrenzen oder verkürzen konnte.

Microsoft kontrollierte die Schlüsselerzeugung, -speicherung, -rotation, -stilllegung und den produktiven Vertrauenssatz. Es kontrollierte die gemeinsame Metadatenarchitektur, die Hilfsbibliotheken, den Exchange-Online-Validator, die OWA-Token-Erneuerungsschnittstelle und die dienstweite Erkennungslogik. Es kontrollierte die interne Produktions- und Unternehmensevidenzaufbewahrung. Es kontrollierte auch die Genauigkeit und den Zeitpunkt öffentlicher technischer Offenlegungen. Die Verantwortung für diese Oberflächen liegt in erster Linie bei Microsoft.

Das Außenministerium kontrollierte seine Mandantenüberwachung, benutzerdefinierte Alarmanwendungen, Triage, Eskalation und Koordination mit CISA und dem FBI. Es führte diese Aufgaben effektiv genug aus, um eine Anbieter-Intrusion zu entdecken. Andere Kunden kontrollierten ihre eigene Überwachung und Reaktion innerhalb der ihnen verfügbaren Telemetrie. Die Kundenverantwortung bleibt real, aber sie kann keine Anbieterkontrollen ersetzen, die Kunden nicht sehen oder ändern können.

CISA, OMB und Beschaffungsbeamte der Behörden kontrollierten Teile der föderalen Basislinie: Protokollierungsanforderungen, Konfigurationsleitlinien, Vertragserwartungen, behördenübergreifende Koordination und den Einfluss, um sicherere Standardeinstellungen zu fordern. Ihre Protokollierungsarbeit nach dem Vorfall verringerte eine Ungleichheit. Ein ausgereiftes Beschaffungsregime sollte sich nicht auf eine Krise verlassen müssen, um festzustellen, dass Kunden Zugriff auf Postfachzugriffs-Evidenz benötigen.

Storm-0558 kontrollierte die feindliche Operation und trägt die Verantwortung für die Intrusion. Diese offensichtliche Tatsache löscht nicht die Vermeidbarkeit aus. Sicherheitsuntersuchungen untersuchen routinemäßig, warum eine böswillige oder gefährliche Eingabe geschützte Systeme erreichte, trotz der Schuld des Akteurs. Attribution und defensive Verantwortlichkeit beantworten verschiedene Fragen.

Unternehmensvorstände und Führungskräfte kontrollieren die Ressourcenzuteilung, Risikoakzeptanz, Anreize und Fristen. Die Pause der manuellen Schlüsselrotation nach einem Ausfall war nicht nur ein isolierter Ingenieursfehler; die Sicherheitsfolge blieb bestehen, weil Automatisierung und Alarmierung nicht ausreichend priorisiert wurden oder blieben. Microsofts spätere Entscheidung, die Führungsvergütung an Sicherheitsmeilensteine zu binden, erkennt implizit an, dass die relevante Kontrollebene über dem Team liegt, das den Validator schrieb.

Die Zuteilung sollte nicht mechanisch in einen Prozentsatz der rechtlichen Haftung umgewandelt werden. Verträge, Staatenimmunität, Schadensersatz, Kausalität, Offenlegungspflichten und regulatorische Zuständigkeit variieren. Die Anfrage von Senator Ron Wyden vomJuli 2023forderte das Justizministerium, die Federal Trade Commission und den CSRB auf, Microsofts Praktiken zu untersuchen. Dieses Ersuchen ist ein Beleg für regulatorische Besorgnis, kein Beleg dafür, dass die beauftragten Behörden zu einem Durchsetzungsbefund gelangt sind. Keine hier verwendete Quellenangabe begründet ein endgültiges rechtliches Urteil für Storm-0558.

Was dauerhafte Abhilfe beweisen sollte

Der Vorfall sollte nur in Bezug auf die beobachtete 2016-Schlüssel-Technik als operativ geschlossen betrachtet werden. Das breitere Zusicherungsproblem bleibt offen, bis Abhilfe in mehreren Dimensionen nachgewiesen werden kann.

Schlüsselgewahrsam und Lebenszyklus

Microsoft sollte nachweisen können, dass Consumer- und Enterprise-Signaturschlüssel in hardwaregeschützten Systemen erzeugt und verwendet werden, nicht in Debugging- oder allgemeine Unternehmensumgebungen exportiert werden können, automatisch mit einer ihrer Macht angemessenen Häufigkeit rotieren und umsetzbare Alarme erzeugen, wenn Alter oder Richtlinienausnahmen Grenzwerte überschreiten. Notfallrotation sollte ohne die Art von Ausfall durchgeführt werden können, die zur Pause von 2021 führte. Die Schlüsselsegmentierung sollte die Anzahl der Mandanten, Dienste und Kontoklassen reduzieren, die durch einen einzelnen Schlüssel gefährdet werden.

Validierungskorrektheit

Jeder abhängige Dienst sollte genehmigte Bibliotheken verwenden, die Signatur, Aussteller, Zielgruppe, Mandanten, Kontoklasse, Schlüsselaussteller, Lebensdauer und dienstspezifische Autorisierung validieren. MicrosoftsOpenID Connect-Dokumentationerklärt, dass Discovery-Metadaten Anbieterendpunkte und öffentliche Signaturschlüssel offenlegt; sie macht nicht jeden aufgeführten Schlüssel für jede Ressource austauschbar. Konformitätstests sollten absichtlich korrekt signierte, aber falsch skopierte Token präsentieren und die Zurückweisung verifizieren.

Fälschungsresistenz über zustandslose Signaturen hinaus

Ein signaturbasiertes Inhabertoken kann auch nach Diebstahl des Signaturschlüssels überzeugend bleiben. Zustandsbehaftete Validierung, Proof-of-Possession-Ansätze, proprietäre Ausstellungsmarker, begrenzte Lebensdauern und schneller Widerruf können dieses Risiko verringern. Ziel ist nicht die Aufgabe von Standards, sondern die Sicherstellung, dass der Besitz eines Schlüssels keine unbeobachtbare globale Autorität schafft.

Anbieter- und Kundentelemetrie

Der Anbieter sollte unmögliche Token-Kombinationen im gesamten Dienst erkennen und interne Evidenz lange genug aufbewahren, um anspruchsvolle Kampagnen zu unterstützen. Kunden sollten Postfachzugriffs- und Identitätsereignisse standardmäßig erhalten, ohne eine Premium-Schranke, in einem dokumentierten, das in unabhängige Analysetools exportiert werden kann. Sechs Monate kundenzugängliche Protokolle, wie vom CSRB empfohlen und als SFI-Ziel übernommen, sollten eine Untergrenze für hochwertige Cloud-Identitätsaktivitäten sein, keine erstrebenswerte Obergrenze.

Vorfallkommunikation

Technische Offenlegungen sollten Versionsgeschichte, Vertrauensniveaus und explizit ungelöste Fragen enthalten. Wenn eine veröffentlichte Hypothese ihre Evidenzstütze verliert, sollte die Korrektur zeitnah und prominent erfolgen. Ein Anbieter sollte nicht benötigen, dass ein Aufsichtsgremium wiederholt fragt, ob ein ungenauer Grundursachenbericht korrigiert wird.

Unabhängige Zusicherung

Fortschrittsberichte von Unternehmen sind nützlich, aber unzureichend für eine Kontrollebene mit Abhängigkeit des öffentlichen Sektors. Bundeskunden benötigen Zusicherungsmechanismen, die Rotation, Schlüsselisolation, Validatorenabdeckung, Alarmleistung und forensische Aufbewahrung testen können, ohne Geheimnisse preiszugeben. Es geht nicht um die Veröffentlichung sensibler Architektur. Es geht um den Nachweis, dass angegebene Kontrollen in der Produktion funktionieren, einschließlich Legacy-Systemen und erworbenen Umgebungen.

Praktische Lehren für Cloud-Kunden und öffentliche Käufer

Kunden können das Signatursystem eines Anbieters nicht reparieren, aber sie können die Abhängigkeit beherrschbarer machen.

Erstens: Beschaffen Sie Evidenz, nicht nur Funktionen. Verträge und Dienstbasislinien sollten identifizieren, welche Zugriffs-, Identitäts-, Verwaltungs-, Token- und Postfach-Ereignisse verfügbar sind; wie schnell sie eintreffen; wie lange sie durchsuchbar bleiben; und ob Kunden sie exportieren können. Die Protokollierung sollte vor einem Vorfall mit simulierten Ereignissen getestet werden.

Zweitens: Bauen Sie Analysen um den Datenzugriff sowie um die Anmeldung auf. Ein gefälschtes Token kann die Anomalien umgehen, die Verteidiger von Passwortdiebstahl erwarten. MailItemsAccessed war wichtig, weil es die geschützte Aktion beobachtete, nicht nur die Authentifizierungszeremonie. Hochwertige Umgebungen sollten ungewöhnlichen Postfachzugriff, Anwendungsidentifikatoren, Geografie, Client-Verhalten und Zugriffsvolumen als Basislinie erfassen.

Drittens: Unterhalten Sie einen Eskalationspfad, der annimmt, dass der Anbieter Teil des Vorfalls sein könnte. Ein Mandantenteam sollte wissen, wie es die Sicherheitsantwortorganisation des Anbieters, CISA oder die zuständige nationale Behörde, Strafverfolgungsbehörden und die Führungsebene erreichen kann, ohne sich auf den möglicherweise kompromittierten E-Mail-Kanal zu verlassen.

Viertens: Behandeln Sie Identitätskonzentration als Kontinuitätsrisiko. Käufer sollten wissen, welche kritischen Dienste eine Identitätswurzel gemeinsam nutzen, was eine anbieterweite Schlüsselkompromittierung erreichen könnte und welche Funktionen fortgesetzt werden können, während das Cloud-Vertrauen wiederhergestellt wird. Dies kann eine Segmentierung, separate Verwaltungsidentitäten, unabhängige Protokollspeicherung oder selektive Diversität für die sensibelsten Arbeitsabläufe rechtfertigen.

Fünftens: Testen Sie die Benachrichtigungs- und Evidenzverpflichtungen des Anbieters. Ein Versprechen, „betroffene Kunden“ zu benachrichtigen, ist nur so nützlich wie die Fähigkeit des Anbieters, sie zu identifizieren. Bei Storm-0558 konnte nur Microsoft die meisten Opfer identifizieren, da die gefälschten Token innerhalb seines Dienstes operierten. Das macht anbieterweite Telemetrie und zeitnahe Kontaktaufnahme zu einem Teil der Erkennungsarchitektur des Kunden.

Schließlich: Verwechseln Sie geteilte Verantwortung nicht mit gleicher Fähigkeit. Kunden sollten sichern, was sie kontrollieren. Anbieter sollten für anbieterexklusive Kontrollen verantwortlich sein. Regulierungsbehörden und Käufer sollten sich auf die Grenze zwischen ihnen konzentrieren, denn dort werden Sicherheitsanforderungen am ehesten mehrdeutig, optional oder monetarisiert.

Bewertung

Die Storm-0558-Exchange-Online-Intrusion war ein vermeidbarer Cloud-Identitätsfehler mit einem ungeklärten anfänglichen Schlüsselerlangungspfad. Die öffentliche Evidenz stützt einen Befund mit hohem Vertrauen, dass Microsoft einen alten Consumer-Signaturschlüssel vertrauenswürdig bleiben ließ, die Grenze zwischen Consumer- und Enterprise-Token-Validierung nicht durchsetzte, keine ausreichende anbieterseitige Erkennung für Token-Kombinationen hatte, die seine eigenen Systeme nicht ausstellen würden, und zu wenig Evidenz aufbewahrte, um die Flucht des Schlüssels zu rekonstruieren.

Sie stützt auch einen Befund, dass die hinter einer Premium-Schranke versteckte Kundenprotokollierung wesentlich beeinflusste, wer die Kampagne erkennen und untersuchen konnte.

Microsofts Reaktion adressierte den beobachteten Zugriffspfad und erweiterte sich später auf Reformen der Schlüsselverwaltung, Validierung, Protokollierung, Governance und Anreize. Brad Smiths Annahme der CSRB-Feststellungen ist bedeutsam. Ebenso die Beseitigung der Protokollierungs-Bezahlschranke für Kernereignisse und der Schritt hin zu hardwaregestützter automatischer Rotation. Die verbleibende Verantwortlichkeitsfrage ist, ob diese Änderungen vollständig, dauerhaft und unabhängig überprüfbar in Microsofts Legacy- und aktueller Identitätsinfrastruktur sind.

Die breitere Lehre des Vorfalls ist nicht, dass Cloud-Dienste von Natur aus unsicherer sind als kundenbetriebene Systeme. Große Anbieter können Kontrollen, Intelligenz und Abhilfe in einem Umfang einsetzen, den die meisten Kunden nicht können. Die Lehre ist, dass Größe auch versteckte Autorität konzentriert. Wenn ein Signaturschlüssel und ein Validierungsfehler Organisationen weltweit erreichen können, hängt die Sicherheit von der internen Schlüsseldisziplin des Anbieters und von Evidenz ab, die Kunden nicht selbst erzeugen können.

Die Kontinuität des öffentlichen Sektors erfordert daher eine breitere Definition von Dienstzuverlässigkeit. Verfügbarkeit ist notwendig, aber ebenso Vertraulichkeit, vertrauenswürdige Identität, rekonstruierbare Evidenz, zeitnahe Offenlegung und ein glaubwürdiger Weg zur Wiederherstellung des Vertrauens nach einer anbieterseitigen Kompromittierung. Storm-0558 ließ Exchange Online laufen. Es störte dennoch die Prämisse, unter der Regierungen es nutzten. Deshalb gehört der Vorfall in die Aufzeichnung als ein Cloud-Verantwortlichkeitsversagen, nicht nur als eine weitere erfolgreiche Spionageoperation.