Microsoft Storm-0558: 署名キー障害がクラウドアイデンティティを公的説明責任の問題にした経緯

要約

• Storm-0558 は、連邦機関のパスワード管理を破ったわけではない。Microsoft のコンシューマー署名キーを使い、見かけ上有効な ID トークンを偽造し、さらに Microsoft の検証欠陥によって、それらのコンシューマー署名トークンが企業向け Exchange Online メールへ到達することを許した。
• キー取得経路は未解決のままである。Microsoft の2023年9月のクラッシュダンプ説明は、後に、同社がキーを含むクラッシュダンプや抜き取りを証明するログを発見できなかったことを認めたことで、主要な仮説に絞り込まれた。陳腐化したキー、境界を越えた検証欠陥、脆弱なトークン異常検知、限られたフォレンジック保存期間が、より確かな障害所見である。
• 説明責任は制御能力に従う。Microsoft だけがプラットフォームキーをローテーションし、サービス側バリデータを修正し、クラウド全体にわたって不可能なトークンの組み合わせを検出し、関連する内部証拠を保存し、攻撃経路を閉じることができた。顧客は監視と対応を改善できたが、2023年時点で決定的な MailItemsAccessed テレメトリは高価な E5/G5 ライセンスに結びついていた。

通常のメールボックス侵害ではない、ID 管理の障害

Storm-0558 による侵入は、「中国のハッカーが Microsoft のキーを盗み、政府のメールを読んだ」という耳慣れた言葉に短縮されやすい。その表現は方向性としては正しいが、分析としては不十分だ。攻撃者の行為、Microsoft の未解決の暗号材料喪失、別個のソフトウェア検証欠陥、古いキーのライフサイクル判断、顧客側の検出成功、サービスプロバイダーの対応を一つの出来事にまとめている。これらのメカニズムを分解すれば、責任の所在ははるかに明確になる。

この侵入は、主に政府職員がパスワードを漏らしたとか、機関が多要素認証を導入しなかったとか、省内にパッチ未適用のサーバーがあったという類の話ではない。Storm-0558 は、2016年に作成された Microsoft アカウント(MSA)のコンシューマー署名キーの秘密鍵を保持していた。秘密署名キーがあれば、対応する公開鍵で署名を検証できるトークンを作成できる。したがって、攻撃者は被害者のパスワードを入手しなくても、アイデンティティを主張できた。第二の Microsoft の欠陥により、コンシューマーアカウント向けのキーが企業の Exchange Online に対するリクエストを認証することを許した。その結果、Microsoft のコンシューマーID システムと組織 ID システムの境界を越える、プラットフォームレベルでのなりすまし能力が生まれた。

Microsoft の2023年7月の技術分析は、基本的なメカニズムを説明している。攻撃者は入手したコンシューマーキーで Azure Active Directory トークンを偽造し、正規の Outlook Web Access フローを使い、GetAccessTokenForResource インターフェースを通じて Exchange Online トークンを取得し、OWA API を介してメールを取得した。Microsoft によると、設計上の欠陥により、攻撃者はそのインターフェースが以前発行したトークンを提示することで新たなアクセストークンを得ることも可能だったという。これは単なる盗んだ資格情報のリプレイではない。Microsoft のサービスが有効と見なした資格情報の不正な生成と更新だった。

この区別はクラウドの説明責任にとって重要である。顧客は通常、自身のアイデンティティ、デバイスの衛生状態、アクセス許可、アプリケーション構成、インシデント対応に責任を負う。しかし、顧客はクラウドプロバイダーのルート署名材料を検査したりローテーションしたり、本番トークンバリデータにパッチを当てたり、プロバイダーの ID 発行プレーン内部に検出器を設置したりすることはできない。障害がプロバイダーだけに可能な制御に起因する場合、どの保護策を誰が管理していたかを明示せずに、この事象を「責任共有」の問題と説明するのは、説明以上に曖昧にしてしまう。

また、この事象をサービス停止と誤って分類しないことも重要だ。公の記録によれば、影響を受けた機関で Exchange Online が利用不可能になったわけではない。被害は機密性と信頼できる通信の喪失であり、その後に多大な調査負担が続いた。公共セクターの継続性には、単にサービスを到達可能に保つ以上のものが含まれる。外交、経済、立法、国家安全保障の業務は、敵対者に秘かに読まれることなく、職員が通信システムを使えることに依存している。クラウドは技術的には「稼働」していても、それが支える公共機能の信頼性は低下しうる。

確立されたこと、推測されること、未だ不明なこと

三つの証拠カテゴリーを分けて考えるべきだ。

第一に、公的記録によって、Storm-0558 が2016年に Microsoft が作成した MSA コンシューマー署名キーを使ってトークンを偽造したこと、Microsoft の検証欠陥によりそれらのトークンが企業の Exchange Online アカウントにアクセスできたこと、国務省が強化されたメールボックスアクセスログを通じて不審な活動を発見したこと、そして Microsoft が一連のサービス側変更によって既知の技術を緩和したこと、がしっかりと確立されている。Microsoft の開示、CISA の対応勧告、影響を受けた機関の声明、そしてサイバー安全審査委員会(CSRB)の再構築は、これらの点で一致している。

第二に、CSRB は、防止可能性、制御設計、セキュリティ文化、情報開示、業界慣行について所見をまとめた。2023年夏の侵入に関する詳細なレビューでは、このインシデントは防止可能であり、決して起こるべきではなかったと結論づけている。委員会は20の組織にインタビューし、Microsoft の協力を得て、他の主要クラウドサービスプロバイダーの管理策と比較し、回避可能な失敗の連鎖を発見した。これらは独立したレビュー所見であり、司法的な所見ではないが、Microsoft の初期のブログのみに基づく解説よりはるかに強力である。

第三に、Storm-0558 が2016年の秘密鍵を実際にどのような経路で入手したのかは、公的記録上依然として不明である。この不確実性は中心的である。Microsoft は2023年9月に詳細なクラッシュダンプの説明を公開した後、2024年3月に、影響を受けたキー材料を含むクラッシュダンプは発見されなかったとする訂正を追加した。CSRB は、Microsoft が46のキー盗難仮説を調査したが、攻撃者がいつどのようにしてキーを入手したのかは依然として分かっていないと報告している。クラッシュダンプを証明された根本原因として提示するいかなる説明も、証拠を誇張している。

また、記録は最終的な法的損失配分を確立していない。議会の精査、調査の要請、CSRB の所見に対する Microsoft の受け入れは、説明責任に関連する。しかし、それらは裁判所の判決、行政機関の執行決定、契約解釈、または定量化された損害分析の代わりにはならない。より正確な結論は、Microsoft がいくつかの失敗した保護策を管理しており、CSRB が挙げた問題に対する責任を受け入れたということ、そして入手可能な情報源からは最終的な民事上、刑事上、規制上の責任は確立されていないということである。

フォレンジック時系列

2016年～2021年: 長寿命キーと延期された移行

Microsoft は2016年にコンシューマー署名キーを作成した。キーの経年自体は安全性の欠如の証明ではないが、組織が継続的な保管を確信を持って示せず、ローテーションが盗まれた材料の使用可能期間を制限する場合、キーの経年は重要性を持つ。CSRB は、Microsoft のコンシューマーMSA システムは手動ローテーションに依存していたが、企業 ID システムは自動化に向かっていたことを確認した。同社はコンシューマーシステムを自動化技術に移行する意向だったが、侵入前にその作業を完了していなかった。

CSRB によると、Microsoft は手動プロセスに関連する大規模なクラウド停止の後、2021年にコンシューマー署名キーの手動ローテーションを停止した。その後、自動ローテーションの代替手段も、経年したアクティブキーを責任チームに通知するアラートも導入しなかった。したがって、2016年のキーは2023年でも受け入れられたままだった。これは、可用性対セキュリティの典型的な決定であり、隠れた先送りコストを伴う。リスクのある手動手順を一時停止すれば当面の停止リスクは減るかもしれないが、補償する自動化を未完成のままにすれば、セキュリティエクスポージャーは無期限に持続する。

「期限切れ」のキーが機能したと言うだけより、委員会の所見の方が有用だ。キーは、サービスの有効な信頼設定に従って受け入れられたり拒否されたりする。決定的な欠陥は、廃止予定のキーが信頼セット内に残っていたことだ。Microsoft 自身の現在の署名キーロールオーバーガイダンスでは、アプリケーションは定期的かつ緊急のロールオーバーをプログラムで処理すべきであり、微妙な欠陥を避けるために標準ライブラリを推奨している。このガイダンスは顧客向けの検証動作を説明しているが、根底にある原則はより広範に適用される。キー置換は、脆い儀式ではなく、工学的な能力でなければならない。

2018年9月、Microsoft はコンシューマーと企業の両方のユーザーにサービスを提供するアプリケーションの需要に応えて、共通のキーメタデータ公開エンドポイントを導入した。Microsoft の後日の説明によると、文書はキースコープ検証を説明するように更新されたが、ヘルパーライブラリはそのスコープを自動的に強制するようには更新されなかった。Exchange メールシステムは2022年に共通メタデータエンドポイントを使用し始めた。開発者はライブラリが完全な検証を行うと想定し、必要な発行者やスコープのチェックを追加しなかった。このため、共通エンドポイントは相互運用性を高める一方で、暗号的に有効であることが正しい ID ドメイン内での認可と誤解されるという信頼境界の危険も生み出した。

CSRB の再構築では、2021年の別の関連イベントが位置づけられている。Storm-0558 は、4月から8月までの間に、あるエンジニアのアカウントを通じて Microsoft の企業ネットワークに侵入した。このエンジニアは、Microsoft が2020年に買収した Affirmed Networks で働いており、Microsoft はこのデバイスが買収前に侵害され、後に企業資格情報で Microsoft の環境に接続したと考えていた。攻撃者は認証トークンを取得してリプレイし、SharePoint 内の資料にアクセスした。これには Azure サービス管理と ID に関する情報が含まれていた。委員会は、Microsoft が買収企業の侵害済みデバイスを企業ネットワークに接続する前に検出できなかったことを批判した。

この2021年の侵害は、攻撃者のアクセスと関心の証拠である。攻撃者がその時点で2016年の MSA キーを入手したことの証明ではない。Microsoft は委員会に対し、2021年の侵入は、記録された記憶の中で Microsoft のネットワークへの唯一の他の既知の Storm-0558 侵入であったため、おそらく関連していると述べたが、同社はそれをキー盗難に結びつける具体的な証拠は何も提示しなかった。規律ある説明は、このギャップを保持しなければならない。

2023年5月～6月: プロバイダーが検知する前にアクセスが開始

Storm-0558 は特定された外部インフラを確立し、2023年5月15日までに標的の Exchange Online アカウントへのアクセスを開始した。CSRB は、Microsoft の標準的な30日間のログ保持期間が、調査開始時点で利用可能な遡及的ビューを制約しているため、侵害の期間はもっと早く始まっていた可能性があると警告した。「最初に確認された」ことは、したがって証拠上の境界であり、必ずしも攻撃の真の開始時点ではない。

標的はスパイ活動の優先順位を反映していた。CSRB の最終的な集計では、世界中の22組織と500人以上の個人が特定され、被害者には米国、英国、その他の国々の者が含まれていた。アカウントには、商務長官 Gina Raimondo 氏、駐中国米国大使 R. Nicholas Burns 氏、東アジア・太平洋担当国務次官補 Daniel Kritenbrink 氏、下院議員 Don Bacon 氏のものも含まれていた。Microsoft の当初の7月11日のインシデント通知では、約25の組織と関連するコンシューマーアカウントに言及していた。この違いは、初期の企業通知と後の独立した再構築との間のインシデント集計の変更と見るのが最善であり、新たな侵入の証拠ではない。

キャンペーンを検知したのは Microsoft ではなく国務省だった。6月15日、国務省のセキュリティオペレーションセンターは異常を観測した。6月16日、内部的に「Big Yellow Taxi」として知られるカスタムルールが、Exchange Online メールボックスアイテムへのアクセスを記録する MailItemsAccessed 監査イベントからアラートを生成した。国務省は誤検知の可能性にもかかわらず調査を行い、同日 Microsoft に連絡した。6月19日までに、国務省は6つのアカウントがアクセスされたと判断した。これには国務長官の北京訪問準備に関連するアカウントも含まれていた。さらに、6月21日から24日にかけて6つの追加アカウントがアクセスされたこと、そして押収された仮想プライベートサーバーの分析から別のアカウントを特定した。

日付が示すように、発見と封じ込めは進行中のアクセスと重なっていた。国務省のアラートは検出成功だったが、偽造されたプラットフォーム資格情報を即座に明らかにしたわけではなかった。Microsoft は当初、侵害されたデバイスや盗まれた正規に発行されたトークンなど、よくある説明を調べた。その後、同社のアナリストは、Exchange Online の認証アーティファクトが、期待されるログ内の Azure AD トークンと一致しないことを確認した。6月26日頃、Microsoft は、攻撃者が2016年のコンシューマーキーを使用して、コンシューマーメールと企業メールの両方に対して機能するトークンを作成していると断定した。

CISA-FBI 共同注意喚起 AA23-193Aは、緩和能力の配分について異例なほど率直である。そこでは、影響を受けたインフラがクラウドベースであるため、この活動に対する全ての緩和措置は Microsoft の責任であると述べている。また、この活動を検出できたであろう他の監査ログやイベントを両機関は認識していないとも述べている。顧客がインシデントを検出したが、その手法を閉じることができたのはプロバイダーだけだった。

6月26日～7月3日: 単一のスイッチではなく段階的な緩和

Microsoft の詳細な時系列には、いくつかの明確な措置が記録されている。

• 6月26日、OWA は GetAccessTokenForResource によって発行されたトークンの更新の受け入れを停止し、攻撃者が悪用していた更新動作を閉じた。
• 6月27日、Microsoft は取得された MSA キーで署名されたトークンの OWA 使用をブロックし、観測された経路によるそれ以上の企業メールアクセスを阻止した。
• 6月29日、Microsoft はキーの交換を完了し、インシデント発生中に有効だった全ての MSA 署名キーを失効させ、強化されたシステムから新しいキーを発行した。
• 7月3日、Microsoft は影響を受けたコンシューマー顧客に対して、以前に発行されたトークンの使用を防ぐため、このキーの使用をブロックした。

この一連の流れは、「キーは失効された」という説明が封じ込めの十分な説明にならない理由を示している。偽造トークンキャンペーンには、キャッシュされた検証メタデータ、下流のアクセスアーティファクト、更新インターフェース、コンシューマーおよび企業サービス、そして既に発行されたトークンが含まれうる。永続的な封じ込めには、古い信頼決定が残っているあらゆる場所をマッピングする必要がある。

Microsoft は、既知のトークン偽造経路がブロックされた後、Storm-0558 がフィッシングや他の手法に転換したのを観測し、キー関連のその後の活動は見られなかったと述べた。これは、観測された手法に対する即時の緩和策の有効性を裏付ける。しかし、当初の取得経路が特定されたこと、あるいは攻撃者が他の機密材料を一切入手しなかったことを証明するものではない。CSRB は、他のキーやデータへのアクセスの可能性は未解決のままであると明示的に述べている。

2023年7月～2024年3月: 情報開示、ロギング改革、訂正された根本原因の主張

Microsoft は7月11日にこのキャンペーンを公表し、7月14日により詳細な技術分析を公開した。初期の投稿では、キー取得は調査中であるとしつつ、キーの悪用と検証エラーを正しく説明していた。7月19日、CISA との調整後、Microsoft は、詳細なメールアクセスログと30を超える他の監査イベントタイプを、追加費用なしで標準階層の顧客に提供することを発表した。また、Audit Standard のデフォルト保持期間が90日から180日に延長されることも発表した。Microsoft のロギングに関する発表は、プロバイダー起因の不正行為を検出するために必要な証拠を誰が見られるかを変えるものだったため、重要な対応だった。

9月6日、Microsoft は主要な技術調査の結果と呼ぶものを公開した。当初の説明では、2021年4月のコンシューマー署名システムのクラッシュがクラッシュダンプを生成し、競合状態によりキーがそのダンプに入り、ダンプが隔離された本番環境からインターネット接続された企業デバッグ環境に移動し、資格情報スキャナーがそれを検出できず、後に Storm-0558 がその環境にアクセスできるエンジニアアカウントを侵害した、と主張していた。関連ログが期限切れになっていたため、Microsoft はこれを最も可能性の高い取得メカニズムと呼んだ。

この説明は筋の通った連鎖を提供したが、その連鎖は直接的な証拠によって裏付けられてはいなかった。Microsoft の版管理された9月の報告書は現在、2024年3月12日のアップデートで始まっている。同社は、主要な仮説は依然として、運用上のエラーによってキー材料がセキュアな署名環境から出てしまい、その材料が侵害されたエンジニアリングアカウントを通じてアクセスされたというものだと述べている。また、影響を受けたキーを含むクラッシュダンプは見つからなかったこと、言及されていた競合状態はキー材料が存在し得るかどうかではなく、ダンプが署名環境から出られるかどうかに影響していたこと、そのような材料の除去は標準プロセスではなかったが、当時禁止されてはいなかったことを認めている。

この訂正は、説明の認識論的な地位を変える。もっともらしい仮説は根本原因の特定ではない。CSRB は、Microsoft が公表後すぐに9月の声明が不正確であることに気づいていたが、委員会からの度重なる質問の後、2024年3月まで訂正を公表しなかったと、2023年11月に委員会に語ったと報告している。この遅延は、顧客が根本原因の開示を用いて実際の取得経路が閉ざされたかどうかを判断するため、委員会のセキュリティ文化に関する所見の一部となった。

根本原因、トリガー、検出の失敗

インシデント分析は、トリガーを根本原因や検出・対応の失敗から分離するとき、より正確になる。

トリガー

運用上のトリガーは、Storm-0558 が盗んだ2016年の MSA 秘密署名キーを使用してトークンを作成し、Exchange Online アクセス経路を通じて提示したことだった。攻撃者は標的を選択し、インフラを運用し、アサーションを鋳造し、メールにアクセスし、メッセージを抜き取った。攻撃者が悪意ある侵入の責任を負う。中華人民共和国に関連するスパイ活動アクターへの帰属は、Microsoft と CSRB によって報告された情報評価であり、本稿は国家の指令を独自に帰属させるものではない。

技術的な根本原因と可能にした条件

第一の根本原因の疑問、つまり秘密鍵がどのように Microsoft の管理下から逃れたのかは、未解決である。これは未解決の重要な事実として記録されるべきであり、クラッシュダンプ仮説で埋められるべきではない。

第二の原因は、より確固として確立されている。古いキーが信頼されたままであったことだ。停止の後、2021年に手動のコンシューマーキーローテーションが停止され、自動化された代替手段は準備できておらず、有効なエージングアラートも解決を強制しなかった。短命または速やかに廃棄されたキーの盗難であれば、機会はより小さかっただろう。何年も受け入れられたままのキーの盗難は、持続的な署名力を生み出した。

第三の原因は、トークン検証のスコープ失敗だった。サービスは共通メタデータを通じて利用可能なキー材料に対して署名をチェックしたが、そのキーの ID ドメインが要求された企業リソースを認可することを許可されていることを適切に証明しなかった。Microsoft の現在のアクセストークン検証ドキュメントは、リソースサーバーに対し、トークンの署名、対象者、発行者、テナント、署名キー発行者を検証するよう指示している。Storm-0558 の事例は、これらのチェックが冗長でない理由を示している。数学的に有効な署名は、誰が秘密鍵を保持していたかは答えるが、それ自体では、そのキーがこのテナント、アカウントクラス、サービス、またはリソースに対して認可されていたかどうかは答えない。

第四の原因は、OWA のトークン更新に関する設計上の欠陥だった。偽造されたアイデンティティが正当なフローを通じて受け入れられると、GetAccessTokenForResource は、あるトークンが別のトークンを取得することを許したが、Microsoft は後に Azure AD と MSA の発行を区別するように変更した。これは当初の署名能力を生み出したわけではないが、アクセス経路をより有用かつ持続的なものにした。

第五の可能にした条件は、プロバイダー側の不十分な異常検出である。Microsoft は、正当な Microsoft システムがその組み合わせでトークンに署名することはないため、攻撃者のトークンパターンは振り返ってみれば明白だったと述べた。しかし、顧客がメールボックスの挙動を報告する前に、プロバイダーはその不可能または非常に異常な状態についてアラートを発しなかった。CSRB は、他のクラウドプロバイダーは Microsoft に欠けていた管理策を持っていることを確認し、署名が検証される場合でも偽造アサーションを検出するために、プロバイダーがトークン生成アルゴリズムと検証シグナルに独自データを使用することを推奨した。

検出および対応の失敗

検出は、プレミアムライセンスを持つ顧客、カスタム分析、熟練したオペレーター、そして以前に誤検知を生み出した中程度のアラートを追及する意欲に依存していた。これは国務省の印象的な管理策である。また、システム全体としては不安定な安全モデルでもある。何千もの顧客が、オプションのメールボックスイベントからプロバイダーの暗号侵害を再構築することは期待できない。特に、このキャンペーンに必要だったイベントはスタンダードライセンスのユーザーには利用できなかったのだから。

当時、MailItemsAccessed は Microsoft Purview Audit Premium を通じて利用可能で、E5 または G5 ライセンスが必要だった。国務省は G5 を保有しており、Big Yellow Taxi を作成できた。プレミアムロギングを持たない他の被害者は、同じ過去の可視性を欠いていた。そのため、CISA と FBI の共同勧告は、ライセンス要件を明示的に指摘しつつ、組織にプレミアムロギングを有効にするよう促した。7日後、Microsoft は主要イベントタイプに関する階層の障壁を取り除くことを約束した。CISA の Jen Easterly 長官は、CISA の7月19日の声明で、この変更を「セキュア・バイ・デザイン」の実践に向けた一歩と評した。

対応は、プロバイダーの証拠保存によっても制約された。Microsoft は、キーがいつどのように盗まれたのかを特定するために必要なログを保有していなかった。30日間の保持期間は顧客の最も早い観測可能な活動を制約し、2021年の仮説に必要となるより古い企業および本番のイベントは入手不可能だった。ログ保持には常にコスト、プライバシー、アクセス制御の義務が伴うが、高度な攻撃者が静かに潜伏しうる期間よりも証拠の地平が短いのであれば、プロバイダーは暗号の至宝を保護していると信用できる主張はできない。

最後に、9月の原因説明の訂正の遅れは、対応の失敗だった。それは当初の侵入を可能にしたわけではないが、公的な保証を損なった。インシデント後の報告書は、事実、評価された仮説、確信度、矛盾する証拠、未解決の疑問を分離すべきだ。完成されたように聞こえるメカニズムを公表し、わずか6ヶ月後に訂正することは、顧客と監督者が、修復が実際の経路に対処したかどうかを判断するのを難しくした。

ロギングとライセンスの問題

ロギングは時として付属的な製品機能として扱われる。今回のインシデントでは、それは安全制御であり、情報の非対称性の源だった。

Microsoft は、どの顧客も利用できないサービス全体のテレメトリと内部的な ID システムの可視性を保持していた。各顧客は自分のテナントと、そのサブスクリプションと設定に含まれるイベントタイプのみを観測できた。決定的なアラートは、メールボックスアイテムがいつアクセスされたかを示すために設計されたイベント、MailItemsAccessed から来た。CISA と FBI は、この活動を検出できたであろう他の監査イベントを知らないと述べた。このイベントを持たない顧客でも文脈的な兆候に気づくことはできたが、同じ直接的な証拠面を欠いていた。

これは問題のある商業的境界を生み出す。プレミアムセキュリティ製品は、高度な分析、自動化、長期保持、管理された調査に対して合理的に課金しうる。ベンダー運用サービスが顧客データにアクセスしたかどうかを知るために必要な最小限の証拠は異なる。プロバイダーだけがシステムを管理し、顧客がプロバイダー自身の ID 障害から生じるアクセスを観測するために追加料金を支払わなければならない場合、顧客は自身が直接修復できないリスクに対する可視性を購入するよう求められている。

インシデント後の変更は、その区別を認識している。Microsoft は、より広範なクラウドセキュリティログを世界中で追加費用なしで利用可能にし、詳細なメールアクセスイベントを Audit Standard に追加し、デフォルトの標準保持期間を180日に倍増することを約束した。2024年2月、CISA、行政管理予算局(OMB)、国家サイバー局長室(ONCD)、Microsoft は、Purview Audit を使用する全ての連邦機関に対し、階層に関係なく拡張ロギングが利用可能になり、自動有効化とより長いデフォルト保持が伴うことを発表した。共同実装発表は、追加料金や設定なしでの高品質な監査ログを「セキュア・バイ・デザイン」の期待として位置づけた。

この改革は顧客の責任を排除しない。ログは検索可能なシステムにルーティングされ、リスクと法的要件に従って保持され、ベースライン化され、クエリされ、対応手順に接続されなければならない。CISA のアドバイザリはまさにそれらの措置を推奨している。しかし、顧客の運用規律は、プロバイダーが関連イベントを発出し、それをアクセス可能にした後に初めて意味を持つ。テレメトリの可用性とテレメトリの使用は、異なる主体が所有する二つの別個の管理策である。

ライセンスはまた、被害者間のフォレンジックな平等性にも影響を与えた。国務省の G5 環境は、標準階層の環境よりも強力な履歴記録を持っていた。インシデント後にイベントを有効にしても、決して記録されなかったことは再構築できない。これは、どちらの顧客も根底にある署名キーを管理していなかったにもかかわらず、同じプロバイダーの障害が、顧客のサブスクリプションに基づいて影響に関する異なる確信度を生み出しうることを意味する。したがって、最小限のフォレンジック証拠は、単なるアップセルとしてではなく、サービスのセキュリティベースラインの一部として扱われるべきである。

連邦政府顧客への影響と公共セクターの継続性

この侵害は非機密メールに影響を与えたが、「非機密」は運用上無意味という意味ではない。高官のメールボックスには、スケジュール、政策審議、連絡先ネットワーク、交渉ポジション、草案の文言、そして政府のありふれた結合組織が含まれている。情報機関は、正式に機密指定された文書を入手しなくても、集約、タイミング、関係性、文脈から価値を引き出せる。

国務省は後に、約6万通のメールが10のアカウントからダウンロードされたと発表した。2023年9月28日の記者会見で、同省は影響を受けた資料を非機密と説明し、機密メールシステムはハッキングされなかったと述べた。CSRB のより広範な再構築では、より多くの国務省アカウントがアクセスされたと特定しており、これはアカウントアクセスの数え方やメッセージがダウンロードされたサブセットの違いを反映している。本稿は、各機関が開示した以上のメッセージの内容を推測するものではない。

CSRB によると、商務長官の公式および個人のメールボックスも影響を受けたものに含まれていた。米国下院も影響を受けた集合内にあり、ドン・ベーコン下院議員も含まれていた。2023年8月の下院監視委員会の調査は、国務省と商務省に対し、発見、影響、対応、将来のセキュリティについての説明を求めた。これらの事実は、機密性の高い公共セクターのエクスポージャーと監視上の懸念を確立する。これらは、特定の政策決定がこの侵入のために変更されたことを確立するものではない。

この文脈における継続性には、少なくとも5つの次元がある。

第一は、機密性の継続性である。職員は、日常的なクラウド通信が外国の情報アクターによって密かにコピーされないという持続的な期待を必要とする。

第二は、意思決定の継続性である。外交旅行や経済政策を準備するチームは、敵対者が自分たちのメールに同時期にアクセスしていると想定せずに審議できなければならない。

第三は、証拠の継続性である。機関は、誰がいつ何にアクセスしたかを再構築するために十分な保持データを必要とする。それがなければ、指導者は自信を持ってインシデントの範囲を確定したり、どの関係や決定に再検証が必要かを判断したりできない。

第四は、対応の継続性である。プロバイダーの侵害は、各機関がセキュリティ、法務、外交、記録、リーダーシップの能力を転用することを強いる。たとえメールが利用可能なままであっても、ミッション作業は隠れたインシデント対応のコストを吸収する。

第五は、信頼の継続性である。共有クラウドサービスの連邦政府による採用は、プロバイダーが自身のコントロールプレーンでの障害を検出し、それを正確に開示し、顧客に利用可能な証拠を提供するという保証に依存している。サービスはアップタイム目標を達成しながら、このより広範な継続性テストに失敗しうる。

このインシデントはまた、集中リスクを露呈した。Microsoft は、政府および民間セクターの大部分にわたって、アイデンティティ、メール、生産性、オペレーティングシステム、セキュリティ、クラウドサービスを提供している。統合は管理と検出を改善しうるが、一つのプロバイダー側の ID 欠陥が組織の境界を越えてグローバルな規模で広がることも許しうる。CSRB は、Microsoft の中心性を、セキュリティ、説明責任、透明性の最高水準を要求する理由として説明した。

集中は、自動的に全ての機関が Microsoft を放棄するか、複製メールシステムを維持すべきだという結論にはつながらない。移行自体がコストとリスクを生み出し、複数のプロバイダーが同様の ID 弱点を再現する可能性もある。より強い結論は、調達と監督が、共通モードの ID 障害を明示的に価格づけしなければならないということだ。キーのセグメンテーション、プロバイダー側の異常検出、監査アクセス、証拠保持、インシデント通知、独立したテスト、エグジットまたは継続性の取り決めは、サービス要件として扱われるべきだ。

CSRB の所見とその重要性

CSRB の公開ページは、この報告書を運用上および戦略上の決定に関する独立したレビューと説明し、業界と政府のための慣行を推奨しているとしている。その中心的所見は厳しいが具体的である。

委員会は、Microsoft のセキュリティ文化は不十分であり、全面的な見直しが必要だと結論づけた。その結論の根拠は、回避可能な連鎖、重要な署名キーの侵害の検出失敗、発見のための顧客への依存、他社プロバイダーの管理策との比較、2021年の買収デバイスの侵害、不正確な公開声明の訂正の遅れ、そして本レビューの範囲外である別の2024年の国家による侵害である。この所見が組織的なのは、なぜキーが受け入れられ続けたのか、なぜドメイン分離が失敗したのか、なぜ不可能なトークンパターンがアラートにならなかったのか、なぜ証拠が入手不可能だったのか、なぜ原因の主張が証拠を追い越したのかを、単一のコーディングエラーでは説明できないからだ。

委員会はまた、具体的な反実仮想を提供した。自動化された代替手段が完了せずに手動ローテーションが一時停止されず、あるいは経年キーアラートが対処を強制していれば、2016年のキーは2023年でも有効なままではなかっただろう。コンシューマーと企業の検証が正しく分離されていれば、攻撃者の到達範囲ははるかに狭く、企業顧客を含まなかっただろう。Microsoft が自社の生成アルゴリズムに適合しないトークンを検出していれば、キャンペーンはブロックされるか、プロバイダー側で検出されていたかもしれない。より強力なフォレンジック保持があれば、Microsoft はキー取得の疑問に答えられたかもしれない。

これらの反実仮想は、階層化された安全原則を示している。この侵入は、全ての管理策が同じように失敗することを必要としなかった。いくつかの独立した管理策のどれか一つでも、企業の侵害を防ぐか、実質的に短縮できたであろう。

• 安全な保管はキー喪失を防げたかもしれない。
• 頻繁な自動ローテーションは、盗まれたキーを2023年より前に使用不能にできただろう。
• スコープを認識した検証は、コンシューマーキーをコンシューマーサービスに限定できただろう。
• ステートフルまたは独自のトークンチェックは、Microsoft 自身が決して発行しないトークンを検出できただろう。
• プロバイダー全体の監視は、不可能な署名ドメインの組み合わせを表面化させられたかもしれない。
• ベースラインの顧客ログは、より多くの被害者がアクセスを検出し範囲を確定するのを許したかもしれない。
• より長いプロバイダーの保持は、根本原因の確信度を改善したかもしれない。

これこそが、未解決の窃取経路が説明責任の分析を妨げない理由である。未知の部分は重要だが、いくつかの独立して十分な、あるいは影響を制限する失敗が文書化されている。プロバイダーは、連鎖全体を不可知として扱うことで、欠けている根本原因のリンクに答えることはできない。

委員会の推奨は Microsoft を超えて及んだ。現代的なキー管理手法、自動化された頻繁なローテーション、ハードウェア保護されたキー、共通認証ライブラリ、より強力なデジタル ID 標準、追加料金なしでの最小限の顧客ロギング、少なくとも6ヶ月間の適切な顧客がアクセス可能なログ、より良い被害者通知、クラウド脆弱性のより透明性の高い開示を求めた。これらの措置は、プロバイダーが特権的な管理と最良の証拠の両方を保持する業界構造に対処するものである。

Microsoft の対応

Microsoft の即時対応は、既知のバリデータと更新の欠陥を修正し、盗まれたキーをブロックし、当時有効だった MSA 署名キーを失効させ、コンシューマーキーを強化された企業キーストアに移行し、分離を強化し、キーシステムの監視を洗練させた。これらの措置は、観測されたキャンペーンに直接対処した。Microsoft はまた、影響を受けた組織に通知し、防御者向けのインフラ指標を公開した。

その後、同社は監査アクセスを拡大することで、商業的管理の変更を行った。この措置は、製品のコミットメントと連邦政府向け展開において独立して観察可能だが、イベントカバレッジの実質的な完全性は依然としてサービス、設定、保持、顧客の運用に依存する。

2023年11月、Microsoft は Secure Future Initiative（SFI）を開始した。当初の SFI 発表では、機密コンピューティングとハードウェアセキュリティモジュールを使用し、基盤となるプロセスが侵害されてもキーにアクセスできないように設計されたアーキテクチャで、統合され完全自動化されたコンシューマー・企業キー管理システムにコミットした。関連するエンジニアリング投稿では、人間のアクセスなしでの高頻度な自動ローテーションが約束された。

CSRB 報告書と別のロシア国家による Microsoft 企業メール侵入の後、同社は2024年5月に SFI を拡大した。Microsoft の拡大プログラムは、署名キーの迅速な自動ローテーションとハードウェア保護、全アプリケーションにわたる標準のアイデンティティ SDK、アイデンティティトークンのステートフルで永続的な検証、より細かいキー分割、水平方向のアイデンティティピボットの排除、セキュリティログの2年間保持、顧客向けの適切なログの6ヶ月間保持などの目標を設定した。また、上級リーダーシップの報酬の一部がセキュリティのマイルストーンに依存することも述べた。

2024年6月、Microsoft のバイスチェア兼プレジデントである Brad Smith 氏は、下院国土安全保障委員会に対し、同社は CSRB 報告書で引用された全ての問題について責任を受け入れると述べた。彼の書面による証言は、Microsoft が同社に適用可能な委員会の16の勧告全てに取り組んでいること、34,000人の常勤エンジニア相当を SFI に専任させていること、コンシューマーと企業のアイデンティティシステムをハードウェア支援のキー管理システムに移行中であること、そして自動ローテーション、共通認証ライブラリ、トークン検証シグナルで進展があったことを述べた。議会公聴会の記録は、公的な監視の背景と質問を提供している。

2024年9月までに、Microsoft はサイバーセキュリティガバナンス評議会、エンジニアリング部門の副 CISO、従業員の業績評価へのセキュリティの組み込み、定期的なエグゼクティブおよび取締役会のレビューを報告した。同社のSFI 進捗アップデートは、ガバナンスの変更と表明された実装の進捗の証拠である。

これらの対応は実質的なコミットメントである。独立した検証が公開されていない場合、それらは依然としてコミットメントおよび企業が報告する進捗として記述されるべきだ。CSRB は特定のアーキテクチャと管理策を推奨したが、その後の完了を認定したわけではない。信頼できるクロージャ基準は、測定可能なキーローテーションカバレッジ、レガシーバリデータが廃棄された証拠、コンシューマーと企業の境界が失敗時に閉じることを示すテスト、キーイベントを調査するのに十分な保持されたテレメトリ、そして例外が静かに存続し得ないという外部保証を必要とするだろう。

制御能力による説明責任

有用な説明責任マップは、誰が各失敗を防止し、検出し、制限し、または短縮できたかから始まる。

Microsoft は、キー生成、保存、ローテーション、廃棄、および本番の信頼セットを管理していた。共通メタデータアーキテクチャ、ヘルパーライブラリ、Exchange Online バリデータ、OWA トークン更新インターフェース、サービス全体の検出ロジックも管理していた。内部の本番および企業証拠の保持も管理していた。また、公開される技術開示の正確性とタイミングも管理していた。これらの面の責任は、主に Microsoft にある。

国務省は、テナント監視、カスタムアラートロジック、トリアージ、エスカレーション、CISA および FBI との調整を管理していた。そして、プロバイダー規模の侵入を発見するのに十分なほど効果的にこれらのタスクを遂行した。他の顧客は、利用可能なテレメトリの範囲内で自身の監視と対応を管理していた。顧客の責任は依然として実在するが、顧客が見ることも変更することもできないプロバイダーの管理策を代替することはできない。

CISA、OMB、および機関の調達担当者は、連邦政府のベースラインの一部、すなわちロギング要件、設定ガイダンス、契約上の期待、省庁間調整、より安全なデフォルトを要求する影響力を管理していた。彼らのインシデント後のロギング作業は、不均衡を縮小した。成熟した調達制度は、顧客がメールボックスアクセス証拠へのアクセスを必要としていることを確立するために危機に頼るべきではない。

Storm-0558 は敵対的な作戦を管理し、侵入の責任を負う。その明白な事実は防止可能性を消し去らない。安全性調査は通常、行為者の有責性にもかかわらず、なぜ悪意あるまたは危険な入力が保護されたシステムに到達したのかを検証する。帰属と防御的な説明責任は異なる問いに答える。

企業の取締役会と役員は、リソース配分、リスク受容、インセンティブ、期限を管理する。停止後の手動キーローテーションの一時停止は、単に孤立したエンジニアリングエラーではなかった。自動化とアラートが十分な優先度を受け取らなかったか維持しなかったために、セキュリティ上の結果が持続した。Microsoft が後にリーダーシップの報酬をセキュリティのマイルストーンに結びつけた決定は、関連する管理レベルがバリデータを作成したチームより上に及ぶことを暗黙的に認識している。

この配分は、機械的に法的責任の割合に変換されるべきではない。契約、主権免除、損害賠償、因果関係、開示義務、規制管轄区域は様々である。Ron Wyden 上院議員の2023年7月の要請は、司法省、連邦取引委員会、CSRB に Microsoft の慣行を調査するよう求めた。この要請は規制上の懸念の証拠であり、要請された機関が執行上の認定に達した証拠ではない。ここで使用されているいかなる情報源も、Storm-0558 に対する最終的な法的判断を確立するものではない。

永続的な修復が証明すべきこと

このインシデントは、観測された2016年キーの手法に関してのみ、運用上クローズされたと見なされるべきだ。より広範な保証上の問題は、いくつかの側面にわたって修復が実証されるまで、未解決のままである。

キーの保管とライフサイクル

Microsoft は、コンシューマーおよび企業の署名キーがハードウェア保護されたシステム内で生成・使用され、デバッグや一般的な企業環境にエクスポートできず、その権限に比例した頻度で自動的にローテーションされ、経年またはポリシー例外が制限を超えた場合に実行可能なアラートを生成することを示せるべきだ。緊急ローテーションは、2021年の一時停止につながったような停止を引き起こすことなく実行されるべきである。キーのセグメンテーションは、一つのキーによって露出するテナント、サービス、アカウントクラスの数を減らすべきだ。

検証の正確性

全ての依存サービスは、署名、発行者、対象者、テナント、アカウントクラス、キー発行者、有効期間、サービス固有の認可を検証する承認済みライブラリを使用すべきだ。Microsoft のOpenID Connect ドキュメントは、ディスカバリメタデータがプロバイダーのエンドポイントと公開署名キーを公開することを説明している。それは、リストされた全てのキーをあらゆるリソースに対して交換可能にするものではない。適合テストは、正しく署名されているが誤ったスコープのトークンを意図的に提示し、拒否を確認すべきである。

ステートレスな署名を超えた耐偽造性

署名のみのベアラートークンは、署名キーが盗まれた後も説得力を持ちうる。ステートフルな検証、所有証明アプローチ、独自の発行マーカー、制限された有効期間、迅速な失効が、そのリスクを減らせる。目標は標準を放棄することではなく、一つのキーの所有が観測不可能なグローバルな権限を生み出さないことを確実にすることだ。

プロバイダーと顧客のテレメトリ

プロバイダーは、サービス全体で不可能なトークンの組み合わせを検出し、高度なキャンペーンに十分な期間、内部証拠を保存すべきだ。顧客は、デフォルトで、プレミアムゲートなしで、独立した分析ツールにエクスポート可能な文書化されたスキーマで、メールボックスアクセスおよびアイデンティティイベントを受信すべきだ。CSRB が推奨し、SFI の目標として採用された、少なくとも6ヶ月間の顧客がアクセス可能なログは、願望的な上限ではなく、高価値クラウドアイデンティティ活動の最低基準とすべきだ。

インシデントコミュニケーション

技術的開示には、バージョン履歴、確信度、明示的な未解決の疑問を付すべきだ。公表された仮説が証拠の裏付けを失った場合、訂正は迅速かつ目立つ形で行われるべきだ。プロバイダーは、不正確な根本原因の説明が修正されるかどうかを監督機関が繰り返し尋ねることを必要とする状況であってはならない。

独立した保証

企業の進捗報告は有用だが、公共セクターが依存するコントロールプレーンにとっては不十分だ。連邦政府の顧客は、秘密を露出させることなく、ローテーション、キー分離、バリデーターカバレッジ、アラートパフォーマンス、フォレンジック保持をテストできる保証メカニズムを必要としている。重要なのはセンシティブなアーキテクチャの公開ではない。それは、レガシーシステムや買収環境を含めた本番環境全体で、表明された管理策が機能している証拠だ。

クラウド顧客と公共調達者のための実践的な教訓

顧客はプロバイダーの署名システムを修理できないが、依存関係をより統治可能にすることはできる。

第一に、機能だけでなく証拠を調達せよ。契約とサービスのベースラインは、どのアクセス、アイデンティティ、管理、トークン、メールボックスイベントが利用可能か、どれだけ迅速に到着するか、どれだけ長く検索可能か、顧客がそれらをエクスポートできるか、を特定すべきだ。ロギングは、インシデント前にシミュレートされたイベントでテストされるべきだ。

第二に、サインインだけでなくデータアクセスにも分析を構築せよ。偽造トークンは、防御者がパスワード盗難から期待する異常をバイパスするかもしれない。MailItemsAccessed が重要だったのは、それが単なる認証の儀式ではなく、保護されたアクションを観測したからだ。高価値環境では、異常なメールボックスアクセス、アプリケーション識別子、地理、クライアントの振る舞い、アクセス量のベースラインを作成すべきだ。

第三に、プロバイダーがインシデントの一部である可能性を想定したエスカレーションパスを維持せよ。テナントチームは、潜在的に侵害されたメールチャネルに頼ることなく、プロバイダーのセキュリティ対応組織、CISA または関連する国内当局、法執行機関、エグゼクティブリーダーシップに連絡する方法を知っておくべきだ。

第四に、アイデンティティの集中を継続性リスクとして扱え。バイヤーは、どの重要なサービスがアイデンティティルートを共有しているか、プロバイダー全体のキー侵害が何に到達しうるか、クラウドの信頼が再確立される間にどの機能が継続できるかを知るべきだ。これは、最も機密性の高いワークフローに対するセグメンテーション、分離された管理アイデンティティ、独立したログストレージ、または選択的な多様性を正当化しうる。

第五に、プロバイダーの通知と証拠のコミットメントをテストせよ。「影響を受けた顧客」に通知するという約束は、プロバイダーがそれらを特定する能力と同等の有用性しかない。Storm-0558 では、偽造トークンがそのサービス内で動作したため、ほとんどの被害者を特定できたのは Microsoft だけだった。このことは、プロバイダー全体のテレメトリとタイムリーなアウトリーチを、顧客の検出アーキテクチャの一部としている。

最後に、責任共有を同等の能力と混同してはならない。顧客は、自身が管理するものをセキュアにすべきだ。プロバイダーは、プロバイダー専有の管理策について説明責任を負うべきだ。規制当局とバイヤーは、両者の境界に焦点を当てるべきだ。なぜなら、そこは安全要件が曖昧になったり、オプションになったり、収益化されたりする可能性が最も高い場所だからだ。

評価

Storm-0558 による Exchange Online 侵入は、未解決の初期キー取得経路を伴う、防止可能なクラウドアイデンティティ障害だった。公開された証拠は、Microsoft が古いコンシューマー署名キーを信頼されたままにし、コンシューマーと企業のトークン検証の境界を強制することに失敗し、自身のシステムが発行しないトークンの組み合わせに対する十分なプロバイダー側の検出を欠き、キーの流出を再構築するにはあまりにも少ない証拠しか保持していなかったという、確信度の高い所見を支持する。また、プレミアムでゲートされた顧客ロギングが、誰がキャンペーンを検出し調査できるかを実質的に形作ったという所見も支持する。

Microsoft の対応は、観測されたアクセス経路に対処し、後にキー管理、検証、ロギング、ガバナンス、インセンティブ改革に拡大された。Brad Smith 氏の CSRB 所見の受け入れは重要だ。コアイベントに対するロギングのペイウォールの撤廃や、ハードウェア支援の自動ローテーションへの移行も同様である。残る説明責任の問いは、これらの変更が完全で、永続的で、Microsoft のレガシーおよび現在のアイデンティティインフラ全体にわたって独立して検証可能かどうかである。

このインシデントのより広い教訓は、クラウドサービスが顧客運用システムより本質的に安全性が低いということではない。大規模プロバイダーは、ほとんどの顧客ができない規模で管理策、インテリジェンス、修復を展開できる。教訓は、その規模が隠れた権限も集中させるということだ。一つの署名キーと一つの検証ミスが世界中の組織に到達しうるとき、セキュリティはプロバイダーの内部的なキー規律と、顧客が自ら生成できない証拠に依存する。

したがって、公共セクターの継続性には、サービス信頼性のより広い定義が必要だ。可用性は必要だが、機密性、信頼できるアイデンティティ、再構築可能な証拠、迅速な開示、プロバイダー側の侵害後に信頼を回復する信頼できるルートも同様に必要だ。Storm-0558 は Exchange Online を稼働させたままにした。それでもなお、政府がそれを利用する前提を破壊した。だからこそ、このインシデントは単に成功した別のスパイ活動としてではなく、クラウド説明責任の失敗として記録に残るべきなのだ。