Microsoft Storm-0558：署名鍵の障害がクラウド ID の説明責任問題に

概要

Storm-0558 は連邦機関のパスワード管理を破ったわけではない。同攻撃者は Microsoft のコンシューマー署名鍵を使用して一見正規の ID トークンを偽造し、その後 Microsoft の検証上の欠陥を利用してそのコンシューマー署名トークンがエンタープライズの Exchange Online メールに到達できるようにした。
鍵の取得経路はいまだ解明されていない。Microsoft は 2023 年 9 月にクラッシュダンプ説を発表したが、後にその説明を限定し、当該鍵を含むクラッシュダンプや流出を示すログは見つかっていないと認めた。古い鍵、境界を越えた検証欠陥、弱いトークン異常検知、限定的なフォレンジック保存は、より確かな障害所見である。
説明責任は制御能力に従う。Microsoft だけがプラットフォーム鍵をローテーションし、サービス側の検証機構を修正し、クラウド全体で不可能なトークンの組み合わせを検出し、関連する内部証拠を保存し、攻撃ベクターを閉じることができる。顧客は監視と対応を改善できるが、2023 年には決定的な MailItemsAccessed テレメトリは高価格の E5/G5 ライセンスに結びついていた。

従来のメールボックス侵害ではなく、アイデンティティ管理の失敗

Storm-0558 の侵入はよくある文にまとめられがちである：中国のハッカーが Microsoft の鍵を盗み、政府のメールを読んだ。この文は方向としては正しいが、分析としては不十分である。攻撃者の行為、Microsoft による暗号素材の未解決の紛失、別個のソフトウェア検証の欠陥、期限切れ鍵のライフサイクル上の判断、顧客側の検知成功、サービスプロバイダーの対応が一つの出来事にまとめられている。これらのメカニズムが分離されれば、責任の配分ははるかに明確になる。

この侵入は、政府職員がパスワードを渡した、代理店が多要素認証を導入できなかった、または省庁内に未パッチのサーバーがあったという主な事例ではない。Storm-0558 は 2016 年に作成された Microsoft Account (MSA) コンシューマー署名鍵の秘密鍵を保有していた。秘密鍵を持つ者は、対応する公開鍵で検証できるトークンを生成できる。そのため、攻撃者は被害者のパスワードを入手せずに ID を主張できた。第二の Microsoft の欠陥により、コンシューマーアカウント向けの鍵がエンタープライズ Exchange Online に対するリクエストを認証できるようになった。その結果、Microsoft のコンシューマーと組織の ID システムの境界を越えたプラットフォームレベルのなりすまし能力が生まれた。

Microsoft の2023 年 7 月の技術分析は基本的なメカニズムを説明している：攻撃者は入手したコンシューマー鍵を使用して Azure Active Directory トークンを偽造し、正当な Outlook Web Access フローを使用し、GetAccessTokenForResource インターフェースを介して Exchange Online トークンを取得し、OWA API を介してメールを取得した。Microsoft は、設計上の欠陥により、攻撃者がそのインターフェースで以前に発行されたトークンを提示することで新しいアクセストークンを取得できるとも述べている。これは単なる盗まれた認証情報の再生ではない。Microsoft のサービスが有効として扱う認証情報の不正な製造と更新である。

この区別はクラウドの説明責任にとって重要である。通常、顧客は自身の ID、デバイスの衛生状態、権限、アプリケーション設定、インシデント対応に責任を負う。しかし、顧客はクラウドプロバイダーのルート署名素材を検査またはローテーションしたり、プロバイダーの実稼働トークン検証ツールにパッチを当てたり、プロバイダーの ID 発行プレーン内に検知器を展開したりすることはできない。障害がプロバイダーのみが利用できる管理手段に起因する場合、その出来事を「共有責任の問題」と表現し、誰がどの防御策を管理していたかを特定しないことは、説明を不明瞭にする。

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

確立された事実、推測される事実、不明な事実

3 つの証拠カテゴリを分けておくべきである。

第一に、公開記録は、Storm-0558 が Microsoft が作成した 2016 年の MSA コンシューマー署名鍵を使用してトークンを偽造したこと、Microsoft の検証上の欠陥によりそれらのトークンがエンタープライズ Exchange Online アカウントにアクセスできるようになったこと、国務省が強化されたメールボックスアクセスログを通じて不審な活動を発見したこと、そして Microsoft が一連のサービス側の変更により既知の手法を緩和したことを確固として立証している。Microsoft の開示、CISA の対応勧告、影響を受けた機関の声明、そして Cyber Safety Review Board の再構築はこれらの点で一致している。

第二に、Cyber Safety Review Board (CSRB) は、防止可能性、管理設計、セキュリティ文化、開示、業界慣行に関する所見を発表した。2023 年夏の侵入に関する完全なレビューは、このインシデントは防止可能であり、決して発生すべきではなかったと結論付けた。委員会は 20 の組織にインタビューし、Microsoft の協力を得て、他の主要なクラウドサービスプロバイダーの管理と比較し、回避可能な障害の連鎖を発見した。これらは独立したレビュー所見であり、司法判断ではないが、Microsoft の初期のブログのみに基づくコメントよりもはるかに強力である。

第三に、Storm-0558 が 2016 年の秘密鍵を実際にどのように入手したかは公開記録では不明のままである。この不確実性が中心である。Microsoft は 2023 年 9 月に詳細なクラッシュダンプ説を発表し、その後 2024 年 3 月に、影響を受けた鍵素材を含むクラッシュダンプは見つかっていないとする修正を追加した。CSRB は、Microsoft が 46 の鍵窃取仮説を検討したが、攻撃者がいつ、どのように鍵を入手したかは依然として不明であると報告した。クラッシュダンプを実証済みの根本原因として提示する説明は証拠を過大評価している。

また、記録は損失の法的な最終配分を確定していない。議会の精査、調査請求、Microsoft の CSRB 所見の受け入れは説明責任に関連する。しかし、これらは裁判所の判決、機関の執行決定、契約解釈、または定量化された損害賠償分析の代わりにはならない。適切な結論はより狭い：Microsoft はいくつかの失敗した防御策を管理し、CSRB が引用した問題に対して責任を受け入れた。入手可能な情報源は民事、刑事、または規制上の最終責任を確定していない。

フォレンジック年表

2016-2021 年：長寿命の鍵と先延ばしにされた移行

Microsoft は 2016 年にコンシューマー署名鍵を作成した。鍵の経過年数自体は安全性の証明ではないが、組織が継続的な管理を確信して示せず、ローテーションによって盗まれた素材の有効期間が制限される場合、鍵の経過年数は重要になる。CSRB は、Microsoft のコンシューマー MSA システムは手動ローテーションに依存していたが、エンタープライズ ID システムは自動化に向けて移行していたことを明らかにした。同社はコンシューマーシステムを自動化技術に移行する意図を持っていたが、侵入前にその作業を完了していなかった。

CSRB によると、Microsoft は 2021 年に手動プロセスに関連する大規模なクラウド障害の後、コンシューマー署名鍵の手動ローテーションを停止した。その後、自動ローテーションの代替手段や、経年したアクティブな鍵について責任チームに通知するアラートを展開しなかった。そのため、2016 年の鍵は 2023 年も受け入れられ続けた。これは典型的な可用性とセキュリティのトレードオフであり、隠れた繰延コストが伴う：リスクの高い手動手順を一時停止することで即時の停止リスクは減少するかもしれないが、補償となる自動化を完了しないままにしておくと、セキュリティ上のエクスポージャーが無期限に持続する。

委員会の所見は、単に「期限切れ」の鍵が機能したと言うよりも有用である。鍵が受け入れられるか拒否されるかは、サービスの稼働中の信頼設定に依存する。重要な failure は、廃止されるはずの鍵が信頼セット内に残っていたことである。Microsoft 自身の現在の署名鍵ロールオーバーガイダンスは、アプリケーションが定期的および緊急のロールオーバーをプログラムで処理し、微妙な欠陥を避けるために標準ライブラリを使用することを推奨している。そのガイダンスは顧客向けの検証動作を説明しているが、根本的な原則はより広く適用される：鍵の交換は、実行するにはリスクが高すぎる脆弱な儀式ではなく、エンジニアリングされた機能でなければならない。

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

CSRB の再構築は、2021 年に別の関連イベントを配置している。Storm-0558 は 4 月から 8 月の間に、エンジニアのアカウントを通じて Microsoft の企業ネットワークに侵入した。そのエンジニアは、Microsoft が 2020 年に買収した Affirmed Networks で働いていた。Microsoft は、そのデバイスが買収前に侵害され、その後企業認証情報で Microsoft の環境に接続したと考えている。攻撃者は認証トークンをキャプチャして再生し、Azure サービス管理や ID に関連する情報を含む SharePoint の素材にアクセスした。委員会は、Microsoft が侵害された買収企業のデバイスを企業ネットワークに許可する前に検出できなかったことを批判した。

この 2021 年の侵入は、攻撃者のアクセスと関心の証拠である。攻撃者がその時点で 2016 年の MSA 鍵を入手したという証明ではない。Microsoft は委員会に対し、2021 年の侵入は記録上唯一知られている Storm-0558 による Microsoft ネットワークへの侵入であるため関連している可能性が高いと述べたが、同社はそれを鍵窃取に結びつける具体的な証拠を提示しなかった。規律ある説明ではそのギャップを保持しなければならない。

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 日から 6 月 24 日の間にさらに 6 つのアカウントがアクセスされ、その後押収された仮想プライベートサーバーの分析を通じてさらに 1 つのアカウントが特定された。

これらの日付は、発見と封じ込めが継続中のアクセスと重なっていたことを示している。国務省のアラートは検出の成功であったが、偽造されたプラットフォーム資格情報を即座に明らかにするものではなかった。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 以上の他の監査イベントタイプを、追加コストなしで標準階層の顧客が利用できるようにすると発表した。また、監査標準のデフォルト保存期間を 90 日から 180 日に延長することも発表した。Microsoft のログ記録の発表は、プロバイダー発の悪用を検出するために必要な証拠を誰が確認できるかを変えるため、重要な対応である。

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

その説明は一貫性のある連鎖を提供したが、その連鎖は直接的な証拠によって裏付けられていなかった。Microsoft のバージョン管理された 9 月のレポートは現在、2024 年 3 月 12 日の更新で始まる。同社は、運用上のエラーにより鍵素材が安全な署名環境から流出し、その素材が侵害されたエンジニアリングアカウントを通じてアクセスされたというのが依然として主要な仮説であると述べている。また、影響を受けた鍵を含むクラッシュダンプは見つかっていないこと、引用された競合状態は鍵素材が存在する可能性ではなく、ダンプが署名環境を離れることができるかどうかに影響するものであったこと、そのような素材の除去は標準的なプロセスではなかったが、当時禁止されていなかったことも述べている。

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

根本原因、トリガー、および検出・対応の failure

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

トリガー

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

技術的根本原因と促進条件

最初の根本原因の質問、秘密鍵がどのように Microsoft の管理から流出したかは未解決である。クラッシュダンプ仮説で埋めるのではなく、未解決の重要事実として記録すべきである。

2 番目の原因ははるかに確立されている：古い鍵が信頼され続けたことである。コンシューマー鍵の手動ローテーションは 2021 年に停止され、自動化された代替手段は準備されておらず、効果的な経年アラートが解決を強制しなかった。短命または即座に失効された鍵の窃取は、より小さな機会を生み出したであろう。何年も受け入れられ続けた鍵の窃取は、永続的な署名能力を生み出した。

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

4 番目の原因は、OWA トークン更新の設計上の欠陥である。偽造された ID が正当なフローを通じて受け入れられると、GetAccessTokenForResource は、Microsoft が後に Azure AD と MSA の発行を区別するように変更した方法で、あるトークンが別のトークンを取得することを可能にした。これは元の署名能力を生み出したわけではないが、アクセス経路をより有用で永続的なものにした。

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

検出と対応の failure

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

当時、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 月の因果関係説明の遅れた修正は対応の failure であった。元の侵入を可能にしたわけではないが、公的な信頼を損なった。インシデント後の報告書は、事実、評価された仮説、確信度、矛盾する証拠、未解決の質問を分離すべきである。完全に聞こえるメカニズムを公開し、6 か月後にのみ修正することは、顧客と監視者が是正措置が実際の経路に対処したかどうかを判断することを困難にした。

ログ記録とライセンスの問題

ログ記録は時として補助的な製品機能として扱われる。このインシデントでは、それは安全制御であり、情報非対称性の原因であった。

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

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

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

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

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

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

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

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

CSRB によれば、商務長官の公式および個人のメールボックスも影響を受けたものに含まれていた。米国下院も影響を受けたセットに含まれており、下院議員 Don Bacon もその中にいた。2023 年 8 月の下院監視委員会の調査は、国務省と商務省に発見、影響、対応、および将来のセキュリティについての説明を求めた。これらの事実は、機密性の高い公共セクターの露出と監視上の懸念を確立するが、特定の政策決定がこの侵入によって変わったことを確立するものではない。

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

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

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

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

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

第五は信頼の継続性である：共有クラウドサービスの連邦採用は、プロバイダーが自らの管理プレーンでの障害を検出し、正確に開示し、顧客に使用可能な証拠を提供するという保証に依存している。サービスは稼働時間目標を達成しながら、このより広範な継続性テストに failure する可能性がある。

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

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

CSRB の所見とその重要性

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

委員会は、Microsoft のセキュリティ文化は不十分であり、抜本的な見直しが必要であると結論付けた。その結論は、回避可能な連鎖、重要な署名鍵の侵害の検出 failure、発見を顧客に依存していること、他のプロバイダーの管理との比較、2021 年の買収企業デバイスの侵害、不正確な公的声明の遅れた修正、およびこのレビューの範囲外である別の 2024 年の国家主体による侵害に基づいている。この所見は組織的なものである。なぜなら、鍵が受け入れられ続けた理由、ドメイン分離が failure した理由、不可能なトークンパターンがアラートを発しなかった理由、証拠が利用できなかった理由、因果関係の主張が証明を上回った理由を説明する単一のコーディングエラーは存在しないからである。

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

これらの反事実は、階層化された安全原則を示している。侵入にはすべての管理が同じように failure する必要はなかった。独立したいくつかの管理のいずれかが、エンタープライズ侵害を防止または実質的に短縮できた可能性がある：

安全な保管は鍵の損失を防ぐことができた。
頻繁な自動ローテーションは、盗まれた鍵を 2023 年までに使用不能にできた。
スコープ認識検証は、コンシューマー鍵をコンシューマーサービスに限定できた。
ステートフルまたは独自のトークンチェックは、Microsoft 自体が決して発行しないトークンを検出できた。
プロバイダー全体の監視は、不可能な署名ドメインの組み合わせを表面化できた。
ベースラインの顧客ログは、より多くの被害者がアクセスを検出し境界付けることを可能にできた。
より長いプロバイダーの保存期間は、根本原因の確信度を改善できた。

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

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

Microsoft の対応

Microsoft の即時対応は、既知の検証者および更新の欠陥を修正し、盗まれた鍵をブロックし、その時点でアクティブだった MSA 署名鍵を失効させ、コンシューマー鍵を強化されたエンタープライズ鍵ストアに移行し、分離を強化し、鍵システムの監視を改善した。これらの行動は観測されたキャンペーンに直接対処した。Microsoft はまた、影響を受けた組織に通知し、防御側のためのインフラ指標を公開した。

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

2023 年 11 月、Microsoft は Secure Future Initiative を開始した。その初期の SFI 発表は、機密計算とハードウェアセキュリティモジュールを使用した統一された完全自動化されたコンシューマーおよびエンタープライズ鍵管理システムを約束し、基盤となるプロセスが侵害されても鍵にアクセスできないように設計されたアーキテクチャを備えていた。付随するエンジニアリング投稿は、人間のアクセスなしでの高頻度の自動ローテーションを約束した。

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

2024 年 6 月、Microsoft の副会長兼社長 Brad Smith は下院国土安全保障委員会に対し、同社は CSRB 報告書で引用されたすべての問題に対して責任を受け入れると述べた。彼の書面による証言は、Microsoft が同社に適用可能な 16 の委員会勧告すべてに行動しており、34,000 人のフルタイムエンジニア相当を SFI に専念させ、コンシューマーとエンタープライズの ID システムをハードウェアバックアップされた鍵管理システムに移行しており、自動ローテーション、共通認証ライブラリ、トークン検証信号について進捗を遂げていると述べた。議会公聴会記録は、公的な監視の文脈と質問を提供している。

2024 年 9 月までに、Microsoft はサイバーセキュリティガバナンス評議会、エンジニアリング部門の副最高情報セキュリティ責任者、従業員の業績評価におけるセキュリティ、定期的な経営陣と取締役会のレビューを報告した。同社のSFI 進捗状況の更新は、ガバナンスの変更と表明された実装の進捗の証拠である。

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

制御能力による説明責任

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

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

国務省は、テナント監視、カスタムアラートロジック、トリアージ、エスカレーション、および CISA および FBI との調整を管理していた。プロバイダーレベルの侵入を発見するのに十分な効果的にそれらのタスクを実行した。他の顧客は、自分たちが利用できるテレメトリ内で独自の監視と対応を管理していた。顧客の責任は依然として現実的であるが、顧客が見たり変更したりできないプロバイダー管理の代わりにはならない。

CISA、OMB、および機関調達担当者は、連邦ベースラインの一部：ログ記録要件、構成ガイダンス、契約期待、機関間調整、より安全なデフォルトを要求するレバレッジを管理していた。インシデント後のログ記録作業は不平等を減少させた。成熟した調達制度は、顧客がメールボックスアクセス証拠へのアクセスを必要としていることを確定するために危機に頼るべきではない。

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

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

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

永続的な是正措置が証明すべきこと

このインシデントは、観測された 2016 年鍵の手法に関連してのみ運用上閉じられたと見なされるべきである。より広範な保証問題は、是正措置がいくつかの側面で実証されるまで未解決のままである。

鍵の管理とライフサイクル

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

検証の正確性

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

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

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

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

プロバイダーは、サービス全体で不可能なトークンの組み合わせを検出し、洗練されたキャンペーンを調査するのに十分な期間内部証拠を保存すべきである。顧客は、プレミアムゲートなしでデフォルトでメールボックスアクセスおよび ID イベントを受け取り、独立した分析ツールにエクスポートできる文書化されたスキーマで受け取るべきである。CSRB によって推奨され、SFI 目標として採用された 6 か月の顧客アクセス可能ログは、高価値のクラウド ID アクティビティにとって、野心的な上限ではなく下限であるべきである。

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

技術開示には、バージョン履歴、確信度、明示的な未解決の質問が含まれるべきである。公開された仮説が証拠の支持を失った場合、修正は迅速かつ顕著であるべきである。プロバイダーは、監視機関に不正確な根本原因説明が修正されるかどうかを繰り返し質問させるべきではない。

独立した保証

企業の進捗報告は有用であるが、公共セクターの依存関係がある管理プレーンにとっては不十分である。連邦顧客は、秘密を暴露することなく、ローテーション、鍵の分離、バリデータカバレッジ、アラートパフォーマンス、フォレンジック保存をテストできる保証メカニズムを必要とする。目的は機密アーキテクチャの公開ではない。表明された管理が、レガシーシステムや買収環境を含む本番全体で動作しているという証拠である。

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

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

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

第二に、サインインだけでなくデータアクセスに関する分析を構築する。偽造トークンは、防御側がパスワード窃取から期待する異常を回避する可能性がある。MailItemsAccessed が重要だったのは、認証儀式ではなく保護されたアクションを観測したからである。高価値環境は、異常なメールボックスアクセス、アプリケーション識別子、地理、クライアント動作、アクセス量をベースライン化すべきである。

第三に、プロバイダーがインシデントの一部である可能性を前提とするエスカレーションパスを維持する。テナントチームは、侵害される可能性のあるメールチャネルに依存せずに、プロバイダーのセキュリティ対応組織、CISA または関連する国家当局、法執行機関、経営陣に連絡する方法を知っているべきである。

第四に、ID の集中を継続性リスクとして扱う。購入者は、どの重要サービスが ID ルートを共有しているか、プロバイダー全体の鍵侵害が何に到達できるか、クラウドの信頼が再確立されている間にどの機能を継続できるかを知るべきである。これは、分割、別個の管理 ID、独立したログ保存、または最も機密性の高いワークフローに対する選択的な多様性を正当化する可能性がある。

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

最後に、共有責任と同等の能力を混同しないこと。顧客は自分たちが管理するものを保護すべきである。プロバイダーはプロバイダー専有の管理に対して説明責任を負うべきである。規制当局と購入者は、安全要件が最も曖昧で、オプションで、または収益化される可能性が高いため、それらの境界に焦点を当てるべきである。

評価

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

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

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

したがって、公共セクターの継続性には、サービス信頼性のより広い定義が必要である。可用性は必要であるが、機密性、信頼できる ID、再構築可能な証拠、迅速な開示、およびプロバイダー側の侵害後に信頼を回復するための信頼できる経路も必要である。Storm-0558 は Exchange Online を稼働させたままにした。それでも、政府がそれを使用する前提を混乱させた。そのため、このインシデントは、単なる別の成功した諜報活動ではなく、クラウド説明責任の failure として記録に残るのである。