Microsoft Storm-0558 はトークン危害への運用管理を公共の説明責任テストとした

要約

• Storm-0558 は、Microsoft のコンシューマー署名鍵と検証の失敗を利用してエンタープライズ Exchange Online メールにアクセスした。これにより、危害の運用管理は主にプロバイダー側の責務となった。顧客は Microsoft の鍵をローテーションしたり、Microsoft のトークンバリデーターにパッチを当てたり、Microsoft の内部署名環境を検査したりすることはできなかったためである。
• 信頼の失敗後、最も重要な公共の説明責任テストは、Microsoft が偽造トークンの経路を迅速に特定し、トークンの更新を停止し、鍵の受け入れをブロックし、署名素材を交換し、顧客ログを拡張し、何が不明なままかを説明できるかどうかであった。
• サイバーセーフティレビューボード（CSRB）は後に、このインシデントは防止可能であったと結論付け、Microsoft のセキュリティ文化、鍵管理、検証管理、ログアクセス、および初期の鍵取得説明の修正を批判した。Microsoft は CSRB の所見を受け入れ、Secure Future Initiative の取り組みを発表したが、実施の証拠の多くはプロバイダー報告によるものである。
• 未解決の取得経路は重要である。Microsoft のクラッシュダンプ仮説は、影響を受けた鍵を含むクラッシュダンプが見つからなかったという同社の発表により、主要な仮説に絞り込まれた。したがって、説明責任は証明された管理の失敗と残存する不確実性に基づき、完全に証明された盗難チェーンにはよらない。

エビデンスマップ

トークン危害はプロバイダー管理の障害モード

Storm-0558 は、最も劇的な対象物である 2016 年に作成された Microsoft のコンシューマー署名鍵を通じて説明されることが多い。その鍵は重要だった。秘密署名鍵があれば、検証ルールが失敗した場合にサービスが受け入れる可能性のあるトークンをアクターが作成できる。しかし、説明責任のテストは鍵の盗難よりも大きい。鍵が信頼されていた期間、サービスがトークンの発行者とスコープをどのように検証したか、更新経路がどのように動作したか、不可能なトークンの組み合わせが検出されたかどうか、顧客がメールボックスアクセスの証拠を確認できたかどうかが含まれる。これらの管理は圧倒的に Microsoft にあった。

これが、危害に対する運用管理が中心的なレンズである理由である。顧客はアカウントを強化し、多要素認証を要求し、特権を削減し、ログを監視し、迅速に対応できる。しかし、Microsoft の内部署名鍵をローテーションすることはできない。Exchange Online のサーバー側検証コードを変更することはできない。すべての内部トークン発行経路を見ることはできない。Microsoft の内部クラッシュダンプや署名環境のログを保存することはできない。クラウドプロバイダーの信頼インフラが失敗した場合、顧客が最初の危害を防ぐ能力は著しく制限される。

CISA-FBI 勧告は、この配分を例外的に明確にした。勧告は、この活動の軽減策は影響を受けたインフラがクラウドベースであるため Microsoft の責任であると述べた。その一文は重要である。顧客が検出や対応に役割を果たさなかったという意味ではない。国務省の検出は極めて重要だった。決定的な封じ込め措置はプロバイダー側（偽造経路の受け入れ停止、鍵のブロック、署名素材の交換、証拠の拡張）であったことを意味する。それが危害に対する運用管理である。

この出来事は通常のメールボックス侵害ではなかった。Storm-0558 はすべての標的のパスワードをフィッシングする必要はなかった。クラウド ID の信頼決定を悪用した。そのため、被害組織を超えて危害が公になる。政府、規制対象企業、一般市民は、プロバイダーの ID プレーンを共有インフラとして依存している。プロバイダー管理のトークン境界が失敗した場合、説明責任を顧客の設定に還元することはできない。

公開記録には正確さも必要である。このインシデントは主に機密性と信頼された通信の障害であり、Exchange Online の可用性の停止ではなかった。メールは機能し続けた。危害は、メッセージへの静かなアクセスと、サービスの ID 境界が維持されたという信頼の喪失であった。公共部門の継続性にはこの種の危害が含まれる。外交官のメールボックスは到達可能でありながら、その内容が漏洩する可能性がある。

鍵取得の物語は未解決のまま

Microsoft の 2023 年 9 月の鍵取得に関する投稿は、当初詳細なクラッシュダンプ説明を提供していた。それは 2021 年 4 月のコンシューマー署名システムのクラッシュ、企業デバッグ環境に移動したクラッシュダンプ、鍵素材を見逃した資格情報スキャン、その後のエンジニアアカウントの侵害を説明していた。その説明は公開された根本原因の物語となった。2024 年 3 月、Microsoft は主張を狭める修正を追加した。影響を受けた鍵を含むクラッシュダンプは見つからず、クラッシュダンプルートは依然として主要な仮説であり、証明された事実ではないと述べた。

CSRB はその不確実性を中心に据えた。CSRB は、Microsoft が多くの仮説を調査したが、Storm-0558 がどのように、いつ 2016 年の MSA 秘密鍵を取得したかは依然として不明であると報告した。この未解決の経路は付記ではない。取得経路が不明であれば、プロバイダーは同じ経路が完全に閉鎖されたことを公に証明できない。鍵管理を強化し、署名システムを分離し、ログを改善し、ローテーションを自動化し、将来の爆発半径を減らすことができる。これらは実際の管理策である。しかし、それらは遡及的に盗難チェーンを確立するものではない。

したがって、説明責任は 2 つのカテゴリに基づくべきである。第一のカテゴリは、証明された、または強く裏付けられた障害である: 古い鍵が信頼され続けた、検証がコンシューマーとエンタープライズの境界を越えて失敗した、拡張ログが顧客に広く利用可能でなかった、Microsoft の初期の公開説明が取得経路の確実性を過大評価していた。第二のカテゴリは残存する不確実性である: 鍵が正確にどのように Microsoft の管理から離れたか、関連する機密素材が露出されたかどうか、完全な内部証拠の追跡が存在したかどうか。

この区別は衒学的ではない。顧客は根本原因の説明を使用して、是正措置が障害に一致するかを判断する。クラッシュダンプ経路が証明されれば、クラッシュダンプ処理と企業デバッグアクセスが直接の閉鎖点となる。経路が不明であれば、是正措置はより広範（鍵の分離、ローテーション、インベントリ、ログ、トークン検証、最小特権、開発者環境管理、独立した挑戦）でなければならない。経路が未解決の場合、公共の保証負担はより大きい。

Microsoft の修正もタイミングのために説明責任の記録の一部となった。CSRB は、Microsoft が 9 月の説明が不正確であることを公開修正前の 3 月に認識していたと報告した。プロバイダーはインシデント説明において善意の誤りを犯す可能性がある。誤りを発見した後の義務は、迅速かつ明白に修正することである。クラウド信頼インフラにおいて、不正確な根本原因の説明は、顧客に中心的な危害経路が閉鎖されたかどうかについて誤解を与える可能性がある。

危害管理は検証と鍵の措置から始まった

公開された軽減策の順序は、封じ込めが単一のスイッチではなかったことを示している。Microsoft は、OWA が GetAccessTokenForResource によって発行されたトークンを更新のために受け入れるのを停止し、取得された MSA 鍵によって署名されたトークンの OWA での使用をブロックし、鍵を交換し、インシデント中に有効だった MSA 署名鍵を失効させ、強化されたシステムから新しい鍵を発行し、影響を受けたコンシューマー顧客に対して以前に発行されたトークンが使用されるのを防ぐために使用をブロックしたと述べた。これは段階的な危害管理プログラムであった。

その順序はトークン危害を示している。偽造トークンキャンペーンは、更新動作、キャッシュされたメタデータ、ダウンストリームサービス、以前に発行されたトークン、コンシューマーとエンタープライズの信頼境界を通じて持続する可能性がある。プロバイダーは、誤った信頼決定が生き残るすべての場所を見つけなければならない。1 つの経路をブロックしても、将来のミントは止められても、既存のトークンが有用なままになる可能性がある。鍵をローテーションしても、サービスが鍵やトークンをキャッシュする場合、すべてのアーティファクトを即座に無効にできない可能性がある。更新エンドポイントは、閉鎖されなければ危害を拡大する可能性がある。

顧客はこの順序を理解する必要がある。それは調査に影響を与えるからである。鍵交換前にアクセスされたメールボックスは、経路が後で閉鎖されてもレビューが必要な場合がある。あるサービスに受け入れられたが別のサービスには受け入れられなかったトークンは、範囲を狭めることができる。更新経路はアクセスの期間を変える。したがって、公開開示は、問題が軽減されたことだけでなく、どの信頼決定が変更され、どの残存顧客証拠が関連するままかを説明すべきである。

Microsoft の技術報告書は、多くのインシデント開示よりも明確な軽減策の順序を提供した。それは強みである。公開上の制限は、顧客が依然としてサービス側の証明を Microsoft に依存しなければならなかったことである。彼らはすべての内部検証変更や鍵失効の影響を独立して検証できなかった。それがクラウド信頼インフラの性質である。それは、正確でテスト可能で修正された説明を公開するプロバイダーの負担を増大させる。

このインシデントはまた、鍵の経過年数が暗号衛生だけでなく運用リスクとして重要である理由を示している。意図されたライフサイクルを超えて信頼され続ける長期有効な鍵は、攻撃者により大きな価値目標とより長い潜在的な有用性の窓を与える。CSRB は、Microsoft のコンシューマー署名鍵のローテーションが手動になり、停止の懸念後に中断され、自動化された代替が完了しなかったことを発見した。これは可用性とセキュリティのトレードオフであり、その延期されたコストは機密性インシデントに現れた。危害に対する運用管理には、停止の恐れがセキュリティライフサイクルを凍結させないように、鍵ロールオーバーを十分に退屈なものにすることが含まれる。

ログは公共の説明責任の要であった

国務省は、拡張メールボックスアクセスログを通じて不審な活動を検出した。その事実がインシデントを変えた。それは、プロバイダーが軽減策を管理していても、顧客が重要なシグナルを提供できることを示した。また、ライセンス問題を暴露した。当時、CISA-FBI 勧告は MailItemsAccessed 監査イベントの重要性を強調し、関連するログがより高い階層のライセンスに結びついていることを指摘していた。CISA は後に、追加費用なしで重要なログを拡大するという Microsoft のコミットメントを公に賞賛した。

ログは顧客機能だけではない。それは危害管理インフラである。顧客がメールボックスアイテムのアクセスを見ることができなければ、プロバイダー発のトークン障害の悪用を確実に検出できない。ログの保持期間が短すぎれば、事後の発見は存在するものに制限される。重要なイベントがプレミアム機能として価格設定されていれば、下位顧客は最もプロバイダーの説明責任を必要とするときに弱い証拠しか持てない可能性がある。

Microsoft の 2023 年 7 月のログ発表は、詳細なメールアクセスログと 30 以上の他の監査イベントへの標準顧客のアクセスを拡大し、デフォルトの Audit Standard 保持を 90 日から 180 日に増やすことを約束した。CISA、OMB、ONCD、および Microsoft は後に、連邦政府機関向けの拡張ログを発表し、自動有効化と 180 日のデフォルト保持を実現した。これらの変更は、証拠を有料アドオンからベースラインのセキュリティ期待に向けて移動させたため、実質的であった。

説明責任の教訓は 1 つのログタイプを超える。クラウドプロバイダーは、プロバイダー側の管理障害を検出するために必要なログを、サービスの安全層の一部として扱うべきである。顧客は、プロバイダーの鍵や検証の欠陥が悪用されたことを発見するために、プレミアムな可視性を購入する必要があるべきではない。プロバイダーは高度な分析、ストレージ、管理された検出に対して料金を請求できる。しかし、顧客データへのアクセスを再構築するために必要な生のセキュリティイベントは、ベースラインに近づけるべきである。

このインシデントはまた、検出がプロバイダーが障害を理解する前に顧客から来る可能性があることを示した。国務省は異常を確認した。Microsoft が調査し、偽造トークン経路を特定した。その順序は、顧客が警報を発するのに十分なログと、それをエスカレーションするのに十分なチャネルを持っている場合にのみ健全である。国務省の拡張ログと調査がなければ、公開タイムラインはさらに悪化していた可能性がある。プロバイダー管理の軽減策は、顧客の検出成功を消し去るものではない。

公共部門の継続性には信頼された通信が含まれる

影響を受けたアカウントには、公共部門および政府関連のメールボックスが含まれていた。国務省は後に、約 60,000 件のメールが 10 のアカウントからダウンロードされ、侵害されたシステムは非機密であり、機密メールはハッキングされなかったと述べた。CSRB は、世界中で 22 の組織と 500 以上の個人が影響を受けたと特定した。これらの詳細は危害を慎重に枠付けている: 政府メールの可用性の崩壊ではなく、公開記録はメッセージの内容を開示していない。それでも深刻な信頼された通信の障害であった。

現代の公共部門の業務は、外交、商取引、政策、スケジューリング、交渉、行政調整のためにクラウドメールに依存している。機密性の喪失は、サービスがオンラインのままであっても行動を変える可能性がある。当局者は通信が読まれたと想定する必要があるかもしれず、情報源や計画が保護される必要があるかもしれず、将来の通信は異なるチャネルに移動するかもしれない。サービスは運用コストを課すためにダウンする必要はなかった。

それが、Storm-0558 がサイバーセキュリティだけでなく公共部門の継続性に属する理由である。継続性はしばしば可用性（機関は運用を継続できるか）を通じて定義される。より成熟したモデルには信頼された運用（機関は敵対者の可視性なしに意図された公共機能のためにサービスを使用し続けられるか）が含まれる。技術的には機能するが敵対者に静かに読み取られるメールボックスは、劣化したインフラである。

政府が依存する顧客であるため、公共の説明責任の問題はより鋭くなる。彼らは調達要件を設定し、ログを要求し、監視を実施し、理論的にはワークロードを移動できる。実際には、中核的な ID と通信のために少数のクラウドプロバイダーに依存している。その依存は、プロバイダーの是正措置が単なるカスタマーサービスではなく、公共インフラの修復であることを意味する。

議会の書簡、公聴会、CSRB レビューはこの依存を反映していた。それらは裁判所の判断や規制上の責任を見つけ出したわけではないが、プロバイダーのセキュリティ文化、鍵管理、ログの選択を公の視野に入れた。それは公共機関によって使用される共有クラウド ID インフラの障害に適切である。

セキュリティ文化は運用管理となった

CSRB の報告書は 1 つのコード欠陥に限定されなかった。それは Microsoft のセキュリティ文化を批判し、回避可能な障害の連鎖を説明した。その枠組みは重要である。なぜなら、署名鍵ライフサイクル、トークン検証、ログのデフォルト、企業ネットワークの侵害、根本原因の修正、顧客の可視性は孤立したバグではなく、組織の優先順位、エンジニアリングシステム、リスク受容、ガバナンスの結果であるからである。

セキュリティ文化は漠然と聞こえるかもしれない。このインシデントでは具体的な形があった。手動の鍵ローテーションプロセスが停止の懸念後に中断され、自動化された代替が完了しなかった。検証の仮定がコンシューマーとエンタープライズの境界を越えた。プレミアムログが顧客の可視性を制限した。初期の公開説明は、Microsoft が修正が必要であることを知った後も長い間確信を持ちすぎていた。これらは態度ではなく、運用上の決定と管理状態である。

Microsoft は Secure Future Initiative とその後の拡大で対応した。同社は自動鍵管理、ハードウェアセキュリティモジュール、機密コンピューティング、標準 ID SDK、状態検証、鍵の分割、拡張ログ、ガバナンスの変更、副 CISO、業績評価の変更、経営陣の報酬リンクを説明した。Brad Smith の議会証言は CSRB によって提起されたすべての問題を受け入れ、推奨事項の実施に向けたステップを説明した。

これらのコミットメントは重要である。しかし、それらはここでレビューされた公開情報源では主にプロバイダー報告によるものである。したがって、説明責任の基準は、発表されたプログラムと独立して検証された運用効果を区別すべきである。顧客と政府は、鍵がインベントリ化され、ローテーションされ、分離され、緊急ロールオーバーが可能であること、検証ライブラリが発行者とスコープの境界を強制すること、サービスが標準検証をバイパスできないこと、ログが保持され利用可能であること、根本原因の修正が証拠の変更時に迅速に公開されることの証拠を望むべきである。

プロバイダーの自己報告は無用ではない。それは多くのクラウド管理が最初に可視化される方法である。しかし、防止可能な信頼インフラ障害の後、自己報告は測定可能な保証に成熟すべきである。一般市民はすべての内部詳細を必要としない。インシデント後に命名された管理が運用され、テストされ、統治されていることを知るのに十分な証拠を必要とする。

トークン検証は退屈で、集中化され、バイパスが困難でなければならない

1 つの技術的教訓は、トークン検証がすべてのサービスチームが独立してすべての境界条件を記憶することに依存すべきではないということである。Microsoft のインシデント後の説明は、共通のメタデータエンドポイントと、影響を受けた経路で発行者またはスコープを正しく検証できなかったことを説明した。現代の ID システムは複雑であるが、その複雑さこそが、検証を適切に保守されたライブラリと強化されたサービスパターンに集中化すべき理由である。

Microsoft の現在の ID ドキュメントは、発行者、対象者、署名鍵、ディスカバリメタデータ、アクセストークン、鍵ロールオーバーなどの概念を説明している。これらのドキュメントは顧客向けの参照であり、2023 年のコード状態の証明ではない。それでもなお、制御論理を示している: 有効な署名だけでは十分ではない。トークンが異なる ID レルム、対象者、テナント、またはサービスのために発行された場合、認証コンテキストが異なる。

プロバイダーの仕事は、安全な経路を容易な経路にすることである。サービスが ID トークンを受け入れる必要がある場合、発行者、対象者、テナント、スコープ、鍵の出所、メタデータ更新ルールを強制する標準ライブラリを使用すべきである。逸脱はまれであり、レビューされ、ログに記録され、テストされるべきである。緊急時の鍵ロールオーバーはリハーサルされるべきである。サービスはデフォルトで不可能な組み合わせを拒否するべきである。監視は、署名鍵、発行者、リソース、テナントの関係が意味をなさないトークンを検出するべきである。

プロバイダーの検証が退屈になれば、顧客は利益を得る。彼らは各 Microsoft サービスチームがトークン検証を正しく実装したかどうかを尋ねる必要はない。中央の ID 管理と独立した保証に依存できるべきである。Storm-0558 インシデントは、全体的であるべき境界が、欠陥が重要になるほどサービス固有になった場合に何が起こるかを示した。

この教訓は Microsoft を超える。すべての大規模クラウドプロバイダーは、製品、テナント、ID レルム、API を横断するトークンインフラを運用している。集中化された検証、自動化された鍵ライフサイクル、顧客可視の証拠は共通の安全要件である。障害が政府メールに影響を与えたため、インシデントはこれらの要件を公開した。

残存する不確実性が保証負担を変える

一部のインシデントは正確な根本原因と正確な閉鎖で終了する。Storm-0558 は、少なくとも公開記録ではそうではない。鍵取得経路は未解決のままである。CSRB は、Microsoft が鍵がどのように、いつ取得されたかを判断できなかったと報告した。この不確実性は是正措置を妨げない。それは保証負担を変える。

盗難経路が不明な場合、プロバイダーはより広範な可能性のある障害を想定しなければならない。鍵素材は運用エラーを通じて署名環境から流出した可能性がある。企業侵害を通じて露出した可能性がある。生き残ったログに捕捉されなかったプロセスによって誤って扱われた可能性がある。答えは証拠を超えて公に推測することではない。答えは、生成、保存、使用、ローテーション、廃棄、ログ、デバッグ、バックアップ、インシデント対応、特権アクセスという完全なライフサイクルを強化することである。

残存する不確実性は顧客の信頼にも影響する。顧客はすべての事実が回復可能ではないことを受け入れられる。彼らは曖昧な閉鎖を受け入れられるべきではない。プロバイダーは何が不明なままか、どの証拠が欠けていたか、不確実性にもかかわらずどの管理が強化されたか、将来の証拠がどのように保存されるかを述べるべきである。透明な未知は、後で修正しなければならない過信した説明よりも信頼を築くことができる。

CSRB プロセスは、証明された事実と仮説を公に区別することを強制することで、その透明性を生み出すのに役立った。また、証拠が主にプロバイダー内にあるクラウドインシデントに対する独立レビューの価値を示した。顧客は Microsoft の署名環境の完全な独自調査を実施できない。独立した官民レビューは裁判所ではないが、プロバイダー管理の事実を公共の説明責任に十分可視化できる。

将来の保証は継続的であるべきである。大規模インシデント後の 1 回限りの報告は有用であるが、鍵ライフサイクルとトークン検証は継続的な管理である。政府とエンタープライズ顧客は、緊急鍵ロールオーバーテスト、検証ライブラリの採用、ログカバレッジ、根本原因修正プロセスの定期的な証拠を要求すべきである。管理障害は静的ではなかった。保証も静的であってはならない。

証拠の非対称性が顧客の上限を定義した

Storm-0558 はまた、顧客側調査の厳しい上限を暴露した。顧客はメールボックス監査イベントを検査し、不審なアクセスを相関させ、テナントログを保存し、Microsoft にエスカレーションできた。しかし、署名環境を検査したり、すべての内部 Microsoft 鍵信頼決定をリストしたり、鍵が他のサービスに対して使用されたかどうかを証明したり、アクターがクラッシュダンプ、企業侵害、または他の経路を通じて鍵を取得したかどうかを判断したりすることはできなかった。最も重要な証拠はプロバイダー内にあった。

その非対称性はクラウドサービスに固有のものであるが、障害がプロバイダーの ID インフラに関係する場合に深刻になる。通常のアカウント侵害では、顧客はユーザーデバイス、フィッシングメッセージ、MFA プロンプト、条件付きアクセスポリシー、ローカルログをレビューできるかもしれない。Storm-0558 では、決定的な問題は、なぜ Microsoft サービスが偽造トークンを受け入れたか、アクターが Microsoft 管理の署名素材をどのように取得したかであった。その問題は顧客の手の届かないところにあった。

したがって、プロバイダーの証拠義務は、顧客の可視性が低下するにつれて増加する。Microsoft は内部システムを調査し、利用可能な証拠を保存し、ギャップを説明し、公開主張を修正し、顧客向けログをよりアクセスしやすくしなければならなかった。顧客は Microsoft を内部の半分の説明に対して信頼しなければならなかった。CSRB レビューは、プロバイダー保持の事実に独立した公開精査をもたらすことでその信頼ギャップを減らしたが、すべての未知を排除しなかった。Microsoft と他の参加者が再構築できるものを報告できた。存在しないログを作り出すことはできなかった。

証拠の非対称性は設計インプットであるべきである。クラウドプロバイダーは、ゆっくりと発見される ID 悪用の調査をサポートするのに十分な期間、セキュリティ関連の内部ログを保存すべきである。鍵管理記録、署名システムアクセスログ、デバッグ環境管理、緊急ローテーション記録を維持すべきである。プロバイダー発の信頼アーティファクトの悪用を検出するのに十分なテナントログを顧客に提供すべきである。ログが欠落しているか保持期間が切れている場合、制限を公開すべきである。証拠の制限についての沈黙は、顧客に自信または隠蔽を想定させる。どちらも有用ではない。

顧客は、調達とリスクレビューに証拠期待を書き込むことで対応できる。デフォルトでどの監査イベントが含まれるか、プロバイダー側のログがどのくらい保持されるか、プロバイダー管理の障害後にどのインシデントサマリーが共有されるか、大規模な信頼インシデントに対して独立レビューが利用可能かどうかを尋ねるべきである。答えは顧客に完全な内部アクセスを与えることは決してない。しかし、プロバイダーが証拠を製品の一部として扱うかどうかを確立できる。

緊急鍵ロールオーバーは継続性の能力である

鍵ロールオーバーはしばしば暗号メンテナンスタスクとして議論される。Storm-0558 はそれが継続性の能力でもあることを示した。署名鍵が疑われるか、または確認された侵害の場合、プロバイダーは許容できない規模で正当な認証を壊さずに鍵をローテーションまたは失効させなければならない。つまり、アプリケーション、サービス、メタデータエンドポイント、キャッシュ、クライアント、検証ライブラリは鍵の変更に耐えなければならない。ロールオーバー経路が脆弱であれば、セキュリティチームは躊躇したり、遅延したり、古い鍵を必要な期間よりも長く信頼し続けたりする可能性がある。

CSRB のコンシューマー署名鍵ローテーションに関する議論はこの点を具体的にしている。Microsoft は停止の懸念後に手動ローテーションを中断し、自動化された代替を完了していなかった。その決定は即座の可用性リスクを減らしたかもしれないが、古い鍵を信頼されたままにした。より深い障害は単に鍵の経過年数ではなかった。ルーチンと緊急の両方の変更を処理できる安全で自動化された測定可能なロールオーバー経路の欠如であった。

現在の Microsoft 署名鍵ロールオーバーガイダンスは、鍵変更のプログラムによる処理、メタデータ更新、標準ライブラリを強調している。同じエンジニアリング原則がプロバイダー内にも適用される。サービスは鍵の変更を期待し、検証ライブラリは安全に更新され、緊急ロールオーバーは現実的な条件下でテストされるべきである。ローテーションが停止トリガーとして恐れられれば、システムはセキュリティ管理を可用性リスクに変換している。成熟したインフラはローテーションを実行するのに十分に日常的なものにする。

緊急ロールオーバーには顧客コミュニケーションの要素もある。プロバイダーが侵害の疑い後に鍵をローテーションする場合、顧客はアプリケーションや統合にアクションが必要かどうか、トークンキャッシュが影響を受けるかどうか、認証障害が予想されるかどうか、古いトークンが有効なままかどうかを知る必要がある場合がある。Storm-0558 の間、Microsoft は影響を受けた Exchange Online 経路を管理していたが、より広い原則はクラウド ID 全体にわたる。鍵の安全性と顧客の継続性は結合されている。

これが、鍵管理が回復力のメトリックとして報告されるべき理由である。プロバイダーは、集計レベルで、鍵がインベントリ化され、所有者が割り当てられ、スケジュールどおりにローテーションされ、ハードウェア支援の管理によって保護され、緊急訓練の対象となり、経過年数やポリシー逸脱について監視されているかどうかを開示できる。顧客は成熟度を評価するために秘密鍵素材を必要としない。鍵が忘れられた信頼アンカーになることが許されていない証拠を必要とする。

ベースラインログが不確実性の支払い者を変えた

Microsoft のログ拡大以前、最も有用なメールボックスアクセス証拠はすべての顧客に等しく利用可能ではなかった。それは製品パッケージングの詳細以上のものである。それは不確実性を配分する。関連するログのない顧客は、侵害を想定し、外部調査により多く費やし、弱い結論を受け入れなければならないかもしれない。ログのある顧客は、不審なアクセスを特定し、範囲を狭め、証拠をもってエスカレーションできる。

国務省は異常なメールボックスアクセスを検出するために必要な拡張ログを持っていた。その成功は、優れたテレメトリーが何ができるかを示した。また、公平性の問題を提起した: プロバイダー発の ID 障害を検出する能力がライセンス階層に依存する理由。CISA の公開声明は、重要なログは追加費用なしで利用可能であるべきであると述べ、製品決定を説明責任の問題に変えた。

したがって、Microsoft の Audit Standard イベントと保持期間の拡大へのコミットメントは単なるカスタマーサクセスのジェスチャーではなかった。それは危害配分モデルを変えた。ベースライン顧客がより多くのログを受け取れば、プロバイダー管理が失敗した場合に検出とスコーピングに参加できる。連邦政府機関が自動有効化とより長い保持を受ければ、事後再構築への依存が減る。より多くのログは鍵の侵害を防がない。それらは顧客が盲目でいられる期間を短縮する。

ログは法的および運用上の確実性にも影響する。どのメールアイテムがアクセスされたかを証明できる組織は、通知、内部是正措置、外交対応、または事業継続措置を調整できる。ログのない組織は、より広い人口を可能性のある影響を受けた者として扱わなければならないかもしれない。その意味で、ログは二次的な危害を減らす。それらは攻撃者を見つけるのに役立つだけでなく、過度に広範な不確実性を避けるのに役立つ。

ベースライン基準は明確であるべきである: 顧客データへの不正アクセスを検出するために必要なイベント、特に根本原因がプロバイダー管理のインフラにある可能性がある場合、サービスの一部として含まれるべきである。高度な相関、管理された検出、長期アーカイブ、分析はプレミアム提供のままにできる。顧客データにアクセスされたかどうかを知るために必要な最小限の証拠は、高級機能であってはならない。

プロバイダーの修正はインシデント対応の一部である

Storm-0558 はまた、公開修正を運用上の説明責任の一部とした。Microsoft は初期インシデント通知、技術分析、そして鍵取得調査の投稿を公開した。9 月の投稿は詳細な説明を提供したが、後に狭めなければならなかった。2024 年 3 月の修正は単に歴史的な脚注を編集したわけではない。それは顧客が根本原因について責任を持って信じられるものを変えた。

インシデント対応はしばしば公開コミュニケーションを技術的修復から分離して扱う。クラウド信頼インシデントでは、それらはリンクされている。プロバイダーの閉鎖を信頼するかどうかを決定する顧客は、どの管理が失敗したかの正確な説明を必要とする。取得経路がクラッシュダンプとして説明されれば、顧客はクラッシュダンプとデバッグ環境の管理が問題を閉鎖することを期待する。取得経路が不明であれば、顧客はより広範な鍵ライフサイクルの強化とより強力な証拠保存を期待する。言葉が保証需要を決定する。

したがって、修正は迅速で、可視的で、明示的であるべきである。プロバイダーは、変更された根本原因の確信度を、何が変わったか、なぜかを明確に述べずにバージョン管理された投稿に埋めるべきではない。Microsoft は 2024 年 3 月の更新を追加し、CSRB は後に修正のタイミングと重要性を議論した。説明責任の教訓は、根本原因の確信度自体が開示された事実であるということである。確信度が「これが起こった」から「これが依然として主要な仮説である」に低下した場合、顧客は知る必要がある。

この基準はプロバイダーと顧客の両方を保護する。正直な修正は、公開記録が誤った説明の周りで固まるのを防ぐ。それは是正措置が適切に拡大することを可能にする。それはプロバイダーが証拠を物語の便宜から区別する意思があることを示す。高い信頼のクラウドインフラでは、その区別はサービスの信頼性の一部である。

共有責任には管理面マップが必要

Storm-0558 は曖昧な共有責任の言葉に対する有用な解毒剤である。「共有責任」というフレーズは、管理面を特定しなければ霧になる可能性がある。このインシデントでは、Microsoft が鍵ライフサイクル、トークン検証、サービス側軽減策、ベースラインログの可用性、内部証拠保存、ほとんどの根本原因の証明を管理した。顧客はテナント監視、インシデントエスカレーション、メールボックスレビュー、アカウント衛生、ポリシー構成を管理した。政府は調達圧力、監視、公開レビューメカニズムを管理した。これらの役割は異なる。

管理面マップは 2 つの悪い議論を防ぐ。最初の悪い議論は、顧客が独自のクラウドセキュリティに責任があり、したがってインシデントを防ぐべきだったというものである。それは失敗する。なぜなら、顧客は Microsoft のサービスが Microsoft 管理の素材で署名された偽造トークンを受け入れるのを防げなかったからである。2 番目の悪い議論は、プロバイダーが根本原因を管理したため、顧客には意味のある役割がなかったというものである。それも失敗する。なぜなら、国務省の検出、顧客ログ、エスカレーションが公開対応を実質的に変えたからである。

より良いモデルは 4 つの質問をする。誰がこのクラスの障害を防げたか？誰が最初に検出できたか？誰が封じ込められたか？誰が範囲を証明できたか？Storm-0558 では、Microsoft が最も強い防止と封じ込めの管理を持っていた。顧客（この場合は国務省）は、拡張メールボックスログを所有し使用したため、重要な検出役割を持っていた。範囲の証明は共有されたが非対称だった: 顧客はログが存在すればテナントを検査でき、Microsoft はプロバイダー側の信頼と鍵の証拠を説明しなければならなかった。

調達はそのマップを反映すべきである。クラウドメールと ID を購入する顧客は、稼働時間とコンプライアンス認証だけでなく、鍵ロールオーバー、トークン検証、発行者境界テスト、デフォルト監査イベント、プロバイダー側ログ保持、インシデント修正ポリシー、独立レビューオプションについて尋ねるべきである。これらは難解な管理ではない。プロバイダーの信頼ファブリックが失敗したときに何が起こるかを決定する管理である。

公共機関は、その依存が市場基準を形成できるため、追加の義務がある。政府顧客が重要なログがベースラインであるべきと主張するとき、プロバイダーはより広い人口向けに提供を変更する可能性がある。Storm-0558 後のログ拡大は、公共の説明責任がデフォルトのセキュリティ態勢を改善できることを示している。課題は、その改善をインシデント主導ではなく体系的なものにすることである。

説明責任テスト

Microsoft Storm-0558 は、トークン危害に対する運用管理を公共の説明責任テストにした。なぜなら、決定的な管理は Microsoft のクラウド内にあったからである。顧客は独自のメールボックスを検出、エスカレーション、調査できたが、Microsoft だけが鍵を交換し、検証を修正し、トークン更新動作を変更し、ベースラインログを拡大し、内部証拠ギャップを説明できた。

より良い基準はプロバイダー検証可能な危害管理である。クラウド ID プロバイダーは、すべてのアクティブな署名鍵を知り、自動化されたテスト済みの経路を通じて鍵をローテーションし、標準ライブラリを通じてトークン検証を強制し、不可能なトークン使用を検出し、遡及分析に十分な期間証拠を保存し、プロバイダー発の管理障害を検出するために必要なベースラインログを顧客に提供すべきである。根本原因の仮説が変更された場合、プロバイダーは迅速に記録を修正すべきである。

未解決の鍵取得経路は教訓の一部であり、隠蔽すべき恥辱ではない。クラウド顧客は、プロバイダーが危害のクラス全体が削減されていることを証明すれば、正直な不確実性とともに生きることができる。最も特権的な障害が顧客が被害を発見した後にのみ説明される信頼システムとともに安全に生きることはできない。