Microsoft Storm-0558 署名鍵障害とクラウドの公共説明責任

概要

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

ID 制御の失敗であり、従来型のメールボックス侵害ではない

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

この侵入は主に、政府職員がパスワードを漏らしたり、多要素認証を導入していなかったり、省内に未パッチのサーバが置かれていたりしたケースではない。Storm-0558 は、2016 年に作成された Microsoft Account（MSA）consumer 署名鍵の秘密鍵を所有していた。秘密署名鍵を持てば、その保有者は対応する公開鍵で署名検証可能なトークンを生成できる。したがって、攻撃者は被害者のパスワードを入手せずに ID を主張できた。さらに、Microsoft の第 2 の欠陥により、consumer アカウント向けの鍵がエンタープライズ Exchange Online に対するリクエスト認証に使われることが許された。その結果、Microsoft の consumer および組織 ID システム間の境界を越えるプラットフォームレベルのなりすまし能力が生じた。

Microsoft の2023 年 7 月の技術分析では、攻撃者が入手した consumer 鍵で Azure Active Directory トークンを偽造し、正当な Outlook Web Access フローを用い、GetAccessTokenForResource インターフェースを通じて Exchange Online トークンを取得し、OWA API 経由でメールを取得した、という基本的メカニズムが説明されている。Microsoft は、同インターフェースが以前発行したトークンを提示することで新たなアクセストークンを取得できる設計上の欠陥も存在したと述べた。これは単なる認証情報のリプレイではない。Microsoft のサービスが有効と見なす資格情報が不正に製造・更新されたのである。

この区別はクラウドの説明責任にとって重要だ。顧客は通常、自らの ID、デバイス衛生、権限、アプリケーション設定、インシデント対応に責任を負う。しかし、顧客はクラウドプロバイダーのルート署名資材を検査したりローテーションしたりすることはできず、プロバイダーの本番トークンバリデータにパッチを当てることも、プロバイダーの ID 発行プレーン内部に検知器を展開することもできない。どの安全策を誰が管理していたかを特定せずに、この事象を単に「共有責任の問題」と表現するのは、説明するよりも曖昧にするだけである。

また、本件をサービス停止と誤分類しないことも重要だ。公開記録上、Exchange Online が影響を受けた機関にとって利用不能になった形跡はない。害は機密性と信頼できる通信の喪失であり、それに続く多大な調査負担である。公共部門の継続性とは、サービス到達性の維持以上のものを含む。外交、経済、立法、国家安全保障の業務は、関係者が通信システムを敵対者に黙って読まれることなく利用できることに依存する。クラウドは技術的には「稼働」していても、それが支える公共機能は信頼性を低下させうる。

確立されていること、推論されていること、不明のままのこと

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

第一に、公開記録で確固として確立されていることは、Storm-0558 が Microsoft 作成の 2016 年 MSA consumer 署名鍵を用いてトークンを偽造したこと、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 年に consumer 署名鍵を作成した。鍵の経年そのものは不安全の証明ではないが、組織が継続的な保管を自信を持って示せず、ローテーションが盗まれた資材の利用可能期間を制限する場合には、鍵の経年は重要になる。CSRB は、Microsoft の consumer MSA システムが手動ローテーションに依存する一方、エンタープライズ ID システムは自動化へ移行しつつあったことを見出した。同社は consumer システムを自動化された技術に移行する意向だったが、侵入前にその作業を完了していなかった。

CSRB によれば、Microsoft は 2021 年、手動プロセスに関連した大規模クラウド障害の後、consumer 署名鍵の手動ローテーションを停止した。その際、自動ローテーション代替策や、老化しているアクティブキーについて責任チームに通知するアラートを展開しなかった。そのため、2016 年の鍵は 2023 年にも受け入れられたままであった。これは可用性対セキュリティの古典的な意思決定であり、隠れた繰り延べコストを伴う。危険な手動手順を一時停止すれば直近の停止リスクは減るかもしれないが、補償的自動化を未完成のままにすればセキュリティ露出は無期限に持続する。

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

2018 年 9 月、Microsoft は、consumer ユーザーとエンタープライズユーザーの双方にサービスを提供するアプリケーションの需要に応え、共通の鍵メタデータ公開エンドポイントを導入した。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 以上の個人が特定され、被害者には米国、英国、その他の地域の者が含まれた。アカウントには、ジーナ・レモンド商務長官、R・ニコラス・バーンズ駐中国米国大使、ダニエル・クリテンブリンク国務次官補（東アジア・太平洋担当）、ドン・ベーコン下院議員のものが含まれていた。Microsoft の当初の7 月 11 日のインシデント通知では、約 25 の組織と関連 consumer アカウントに言及していた。この差は、初期の企業通知と後の独立再構築との間のインシデント集計の変化として扱うのが最善であり、新たな侵入の証拠と捉えるべきではない。

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

これらの日付は、発見と封じ込めが進行中のアクセスと重なっていたことを示す。国務省のアラートは検知成功だったが、偽造されたプラットフォーム資格情報を即座に明らかにしたわけではない。Microsoft は当初、侵害されたデバイスや正当に発行されたトークンの盗難など、馴染みのある説明を検討した。その後アナリストは、Exchange Online 認証アーティファクトが期待される Azure AD トークンとログ内で一致しないことに気付いた。6 月 26 日頃、Microsoft は攻撃者が 2016 年の consumer 鍵を使って、consumer およびエンタープライズメールに対して有効なトークンを作成していると判断した。

CISA-FBI アドバイザリーAA23-193Aは、緩和能力の配分について異常に直接的である。アドバイザリーは、当該活動のすべての緩和措置は影響を受けたインフラがクラウドベースであるため Microsoft の責任であり、また、本活動を検知できたであろう他の監査ログやイベントを両機関は認識していないと述べている。顧客がインシデントを検知したが、手法を閉鎖できたのはプロバイダーのみであった。

2023 年 6 月 26 日-7 月 3 日：単一スイッチではない段階的緩和

Microsoft の詳細な時系列は、いくつかの明確なアクションを記録している：

6 月 26 日、OWA は GetAccessTokenForResource によって発行されたトークンの更新受け入れを停止し、攻撃者が悪用した更新動作を閉鎖した。
6 月 27 日、Microsoft は入手された MSA 鍵で署名されたトークンの OWA 使用をブロックし、観測された経路を通じた更なるエンタープライズメールアクセスを阻止した。
6 月 29 日、Microsoft は鍵の置き換えを完了し、インシデント期間中に有効だったすべての MSA 署名鍵を失効させ、強化されたシステムから新しい鍵を発行した。
7 月 3 日、Microsoft は影響を受けた consumer 顧客に対して当該鍵の使用をブロックし、以前に発行されたトークンの使用を防止した。

このシーケンスは、「鍵が失効された」という記述が封じ込めの十分な説明でない理由を示している。偽造トークンキャンペーンには、キャッシュされた検証メタデータ、下流のアクセスアーティファクト、更新インターフェース、consumer およびエンタープライズサービス、既に発行済みのトークンが関与しうる。永続的な封じ込めには、古い信頼判断が存続するあらゆる場所をマッピングすることが必要だ。

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 月の consumer 署名システムクラッシュがクラッシュダンプを生成し、競合状態により鍵がダンプに含まれ、ダンプが隔離された本番環境からインターネット接続された企業デバッグ環境に移動し、認証情報スキャナーがそれを見逃し、後に Storm-0558 がその環境にアクセス可能なエンジニアアカウントを侵害したと主張した。関連ログが期限切れになっていたため、Microsoft はこれを最も可能性の高い取得メカニズムとした。

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

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

根本原因、トリガー、および検知の失敗

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

トリガー

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

技術的根本原因と可能化条件

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

第二の原因ははるかに確立されている：古い鍵が信頼され続けた。手動 consumer 鍵ローテーションは停止後に 2021 年に停止され、自動化代替が準備できておらず、効果的な経年アラートが解決を強制しなかった。短期間有効または迅速に退行される鍵の盗難はより小さな機会を生んだであろう。何年も受け入れられ続けた鍵の盗難は永続的な署名力を生み出した。

第三の原因はトークン検証スコープの失敗だった。サービスは共通メタデータを通じて利用可能な鍵資材に対して署名を確認したが、当該鍵の ID ドメインが要求されたエンタープライズリソースを認可する権限があることを十分に立証しなかった。Microsoft の現在のアクセストークン検証ドキュメントは、リソースサーバに対しトークン署名、オーディエンス、発行者、テナント、署名鍵発行者を検証するよう指示している。Storm-0558 事件は、これらのチェックが冗長でない理由を示している。数学的に有効な署名は誰が秘密鍵を保有していたかを答えるが、それだけで当該鍵がこのテナント、アカウントクラス、サービス、リソースに対して認可されていたかどうかを答えるものではない。

第四の原因は OWA トークン更新の設計上の欠陥だった。偽造された ID が正当なフローを通じて受け入れられると、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 のジェン・イースタリー長官は、CISA の 7 月 19 日声明でこの変更を「セキュア・バイ・デザイン」実践への一歩と評した。

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

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

ログとライセンスの問題

ログ取得は、しばしば付随的な製品機能として扱われる。本インシデントでは、それは安全制御であり、情報非対称の源だった。

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

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

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

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

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

連邦顧客への影響と公共部門の継続性

侵害は非機密メールに影響を与えたが、「非機密」は運用上些細であることを意味しない。上級職員のメールボックスには、スケジュール、政策審議、接触ネットワーク、交渉姿勢、草案文書、政府の通常の結合組織が含まれる。情報機関は、正式に機密指定された文書を入手せずとも、集約、タイミング、関係性、文脈から価値を引き出せる。

国務省は後に、10 個のアカウントから約 6 万通の電子メールがダウンロードされたと述べた。2023 年 9 月 28 日の記者会見で、同省は影響を受けた資料を非機密と述べ、機密メールシステムは侵害されなかったとした。CSRB のより広範な再構築では、より多くの国務省アカウントへのアクセスが特定され、アカウントアクセスのカウント方法とメッセージがダウンロードされたサブセットの違いを反映している。本稿は、当局が開示した以上のメッセージ内容を推測しない。

商務長官の公式および個人メールボックスもまた、CSRB によれば影響を受けたものの中に含まれていた。米国下院もまた影響を受けた集合の一部であり、ドン・ベーコン下院議員が含まれていた。2023 年 8 月の下院監視問い合わせは、国務省と商務省に対し、発見、影響、対応、将来のセキュリティに関する説明を求めた。これらの事実は、機微な公共部門の露出と監督上の懸念を確立するが、特定の政策決定が侵入によって変更されたことを確立しない。

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

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

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

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

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

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

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

集中は、すべての機関が Microsoft を放棄すべき、または重複したメールシステムを維持すべきという結論に自動的には至らない。移行それ自体がコストとリスクを生み、複数のプロバイダーが類似の ID 弱点を再現しうる。より強い結論は、調達と監督が共通モード ID 失敗を明示的に価格付けしなければならないということだ：鍵のセグメンテーション、プロバイダー側の異常検知、監査アクセス、証拠保存、インシデント通知、独立したテスト、終了または継続性の取り決めは、サービス要件として扱われるべきである。

CSRB の所見とそれが重要な理由

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

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

委員会はまた、具体的な反実仮想を提供した。もし手動ローテーションが完了した自動代替なしに停止されず、または経年鍵アラートが行動を強制していれば、2016 年の鍵は 2023 年も有効のままではなかっただろう。もし consumer とエンタープライズの検証が正しく分離されていれば、攻撃者のリーチははるかに狭く、エンタープライズ顧客を含まなかっただろう。もし Microsoft が自社の生成アルゴリズムに従わないトークンを検知していれば、キャンペーンはプロバイダー側でブロックまたは検知されたかもしれない。もしより強力なフォレンジック保存が存在していれば、Microsoft は鍵取得の質問に答えられたかもしれない。

これらの反実仮想は、層状安全の原則を示している。本侵入は、すべての統制が同じように破綻することを必要としなかった。いくつかの独立した統制のうちどれか一つが、エンタープライズ侵害を防止するか、または著しく短縮できたであろう：

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

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

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

Microsoft の対応

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

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

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

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

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

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

これらの対応は実質的なコミットメントである。それでもなお、独立した検証が公開されていない部分については、コミットメントおよび企業報告の進捗として記述されるべきである。CSRB は特定のアーキテクチャと統制を推奨したが、その後の完了を認証したわけではない。信頼できるクロージャ基準には、測定可能な鍵ローテーションカバレッジ、レガシーバリデータが退行された証拠、consumer およびエンタープライズ境界が閉鎖方向に失敗することを示すテスト、主要イベントを調査するのに十分な保存テレメトリ、例外が静かに持続できないことの外部保証が必要だろう。

制御能力による説明責任マップ

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

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

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

CISA、OMB、および機関調達職員は、連邦ベースラインの一部、すなわちログ要件、構成ガイダンス、契約期待、省庁間調整、より安全なデフォルトを要求するレバレッジを管理していた。彼らのインシデント後ログ対応は不公平を低減した。成熟した調達体制は、顧客がメールボックスアクセス証拠を必要とすることを確立するために危機に依存すべきではない。

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

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

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

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

本インシデントは、観測された 2016 年鍵の手法に関してのみ、運用上閉鎖されたと考えるべきである。より広範な保証問題は、いくつかの次元にわたって修復が実証されるまで開かれたままである。

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

Microsoft は、consumer およびエンタープライズ署名鍵がハードウェア保護されたシステム内で生成・使用され、デバッグ環境や一般企業環境にエクスポートできないこと、その能力に比例した頻度で自動ローテーションされること、経年またはポリシー例外が限度を超えた場合に実行可能なアラートを生成することを示せるべきである。緊急ローテーションは、2021 年の停止を招いた種類の停止を引き起こすことなく実施されるべきである。鍵セグメンテーションは、単一の鍵によって露出されるテナント、サービス、アカウントクラスの数を削減すべきである。

検証の正確性

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

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

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

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

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

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

技術開示は、バージョン履歴、信頼水準、明示的な未解決の疑問を伴うべきである。公開された仮説が証拠的支持を失った場合、訂正は迅速かつ顕在的であるべきである。プロバイダーは、不正確な根本原因説明が修正されるかどうかを監督機関が繰り返し尋ねることを必要とすべきではない。

独立した保証

企業の進捗報告は有用だが、公共部門が依存するコントロールプレーンには不十分である。連邦顧客は、秘密を露出せずにローテーション、鍵隔離、バリデータカバレッジ、アラートパフォーマンス、フォレンジック保存をテストできる保証メカニズムを必要とする。ポイントは機微なアーキテクチャの公開ではない。レガシーシステムや買収環境を含む本番全体で、表明された統制が動作しているという証拠である。

クラウド顧客と公共バイヤーのための実践的教訓

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

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

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

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

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

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

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

評価

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

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

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

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