概要
- ProxyLogon は、Microsoft が緊急パッチを迅速に公開できたものの、露出した Exchange Server インスタンスが悪用後に発見、更新、調査、クリーンアップ、監視されたことを証明できるのはサーバー所有者だけであり、長期的な修復説明責任テストとなった。
- Microsoft の MSRC リソース「Exchange Server 向けの複数のセキュリティ更新プログラムのリリース」、および Microsoft Security の投稿「HAFNIUM による Exchange Server 標的攻撃」は、ベンダー通知と初期の属性記録の基盤となる。
- CISA の緊急指令21-02、CISA の2021年3月の警告、およびAA21-062A 勧告は、これが製品サポートイベントだけでなく、公共部門の継続性の問題であることを示している。
- 4つの脆弱性記録、CVE-2021-26855、CVE-2021-26857、CVE-2021-26858、CVE-2021-27065は、防御担当者がこのチェーンをエントリと持続性の両方のリスクとして扱わなければならなかった理由を説明している。
- DOJ の裁判所承認のウェブシェル除去作戦は、異常な残留リスクを示している。政府の行動により一部のサーバーから選択的な悪意のあるウェブシェルが削除されたが、パッチ適用、調査、資格情報のレビュー、およびより広範なクリーンアップは依然としてサーバー所有者に属していた。
緊急パッチは即時の修復を生み出さない
Exchange Server の緊急事態は、おなじみの約束から始まった。更新プログラムをインストールせよ。Microsoft の MSRC の投稿「Exchange Server 向けの複数のセキュリティ更新プログラムのリリース」は、影響を受けるオンプレミスの Exchange Server バージョンにパッチを当てるよう顧客に指示した。Microsoft のセキュリティ投稿「HAFNIUM による Exchange Server 標的攻撃」は、オンプレミスの Exchange Server の悪用について説明し、CVE-2021-26855、CVE-2021-26857、CVE-2021-26858、CVE-2021-27065 をリストアップし、Exchange Online は影響を受けないと述べた。これらは必要かつ緊急のベンダー通信であった。
しかし、説明責任の問題はパッチが出荷された瞬間に始まった。パッチの可用性はベンダーの行動であり、修復はエコシステムの結果である。オンプレミスの Exchange Server の場合、所有者はサーバーの存在を知り、露出を知り、バージョンを把握し、必要な累積更新プログラムをインストールし、セキュリティ更新プログラムを適用し、悪用の有無を確認し、アーティファクトを削除し、メールと資格情報の露見をレビューし、持続性を監視し、リスクを伝達する必要がある。そのプロセスはリリース日をはるかに超えて延びる可能性がある。
ProxyLogon はしたがって、脆弱性の開示の話だけではない。それは長期的な修復の話である。オンプレミスのメールサーバーはしばしば古く、ビジネスクリティカルであり、カスタマイズされており、セキュリティスタッフが不均等な組織によって運用されている。公的機関、学校、小規模企業、非営利団体、自治体、マネージドサービス事業者は、Exchange に依存しながらも迅速なインシデント対応能力を欠いている可能性がある。そのような環境での緊急パッチはボタンではない。それは運用キャンペーンである。
Microsoft Exchange チームの投稿「Released: March 2021 Exchange Server Security Updates」は、サポート対象バージョンと累積更新状態のインストールコンテキストを提供した。このコンテキストは重要である。なぜなら、一部の組織は単純な更新から安全になるわけではなかったからである。彼らはまずサービス状態を理解しなければならなかった。更新パスが複雑になればなるほど、クリティカルウィンドウの間に脆弱なサーバーが露出したままになる可能性が高くなる。
教訓は、Microsoft だけがすべてのサーバーにパッチを当てることができたということではない。それはできなかった。教訓は、広く展開されたオンプレミス製品を持つベンダーには、明確な更新パス、緩和策、検出スクリプト、対応者向けガイダンス、顧客コミュニケーション、そして後でパッチ未適用の長期的サーバーが見えにくくなる製品変更を通じて、緊急修復を実現可能にする説明責任があるということである。
ProxyLogon はエントリ、コード実行、永続化を結合した
脆弱性チェーンは、初期アクセスからコード実行とファイル書き込みに移行できるため危険であった。NIST の NVD 記録（CVE-2021-26855、CVE-2021-26857、CVE-2021-26858、CVE-2021-27065）は、脆弱性ファミリーを公開記録に文書化している。Microsoft の対応者向けガイダンス「オンプレミスの Exchange Server 脆弱性の調査と修復のための対応者向けガイダンス」は、脆弱性がどのように連鎖され、ウェブシェルがどのように埋め込まれ、対応者がパッチ適用を超えて調査する必要がある理由を説明している。
この最後の点が説明責任記録の中心である。ウェブシェルが存在すると、脆弱性にパッチを当ててもウェブシェルは削除されない。攻撃者がメールを読んだりツールをステージングしたりした場合、パッチを当てても何が持ち出されたかは特定できない。資格情報が露見した可能性がある場合、パッチを当ててもローテーションされない。サーバーが足場として使用された場合、パッチを当てても環境の残りがクリーンであることは証明されない。
これが緊急緩和ガイダンスが重要な理由である。Microsoft の MSRC ページ「Exchange Server の脆弱性の緩和（2021年3月）」は、検出と緩和のリソースを提供した。NSA の勧告 PDF「Microsoft Exchange Server の脆弱性を緩和する」は、連邦の技術的ガイダンスを提供した。CISA のAA21-062A 勧告は、緩和、検出、修復の指示を提供した。これらの記録は、期待される順序を示している：パッチ適用、調査、クリーンアップ、監視。
セキュリティ企業のレポートは実践的な観察を追加した。Volexity の活発な悪用レポートは、公開パッチリリース前に観測された悪用とウェブシェル活動について説明した。Palo Alto Networks Unit 42のExchange Server 脆弱性分析と Tenable の脆弱性解説は、防御担当者がチェーンを理解するのに役立った。Mandiant の古いコンテキスト「China Chopper still active」は、ウェブシェルの持続性が長期的である理由を説明するのに役立つ。これらは普遍的な被害者記録ではないが、実践的な対応問題を支持している。
説明責任のある修復の質問は単純である：更新後、各組織は残存するウェブシェル、アクティブな持続性、露見した資格情報パス、未調査のメールボックスアクセスがないことを証明できるか？できない場合、サーバーはパッチが当てられたが完全には修復されていない。
公的機関は通常の調達よりも迅速に行動する必要があった
CISA の緊急指令21-02「Mitigate Microsoft Exchange On-Premises Product Vulnerabilities」は、連邦民事執行機関に対し、影響を受けるシステムを特定し、直ちに切断または更新し、状況を報告することを要求した。CISA の3月3日の警告は、指令を発表し、脆弱性について警告した。この連邦の行動は、Exchange インシデントがどれほど迅速に公共部門の継続性問題になったかを示している。
政府のメールは単なる一般的なアプリケーションではない。それは有権者とのコミュニケーション、政策業務、調査、調達、公衆衛生の調整、学校運営、緊急管理を運ぶ。オンプレミスの Exchange サーバーが侵害された場合、被害には機密性、運用上の信頼、継続性が含まれる可能性がある。ウェブシェルが既に存在する可能性があるときに、機関は通常のメンテナンスウィンドウを待つわけにはいかない。
緊急指令はまた、インベントリの運用負担を明らかにする。遵守するために、機関は Exchange サーバーがどこに存在するかを知らなければならなかった。シャドーIT、レガシー環境、テストインスタンス、忘れられたサーバーは、そのような瞬間に負債となる。最初の質問は「パッチを当てられるか？」ではなく、「パッチを必要とするすべてのシステムを把握しているか？」である。公共部門の説明責任は、緊急時にそのインベントリが最新であることに依存する。
後日、CISA の既知の悪用された脆弱性カタログの CVE-2021-26855 エントリは、この脆弱性をより広範な連邦修復規律に組み込んだ。KEV の扱いは、機関が悪用された脆弱性を通常のバックログとして扱う可能性を減らすのに役立つ。しかし、カタログはサーバーをクリーンにできない。それは緊急性を設定する。機関は依然として運用能力を必要とする。
公共部門の教訓は連邦機関よりも広い。州・地方政府、学校、公衆衛生機関、公共契約業者は、しばしば古いオンプレミスのメールを運用している。彼らは小規模なチームと遅い調達を持つ可能性がある。緊急 Exchange パッチは、資産管理、ロギング、インシデント対応リテーナー、マネージドサービス契約、バックアップ手順のギャップを露呈させる可能性がある。ProxyLogon はそれらのギャップを公共リスクの質問に変えた。
タイポグラフィに関する注記
FBI のウェブシェル除去は残留物の異常さを示した
長期的リスクの最も顕著な公的証拠は、2021年4月の司法省の裁判所承認の Microsoft Exchange Server の悪用を妨害する取り組みの発表であり、「DOJ announces court-authorized effort」として公開された。発表によると、FBI は米国内の数百の脆弱なコンピュータからウェブシェルをコピーし除去した。FBI のPrivate Industry Notificationは、作戦と継続的なガイダンスを説明した。
この作戦は狭く真剣に読まれるべきである。サーバーにパッチを当てたわけではない。可能なすべてのアーティファクトを除去したわけではない。環境がクリーンであると判断したわけではない。特定のシステムから裁判所承認の作戦で選択されたウェブシェルを除去した。その制限がまさにこの作戦が重要である理由である。悪用の残留物は、法執行機関が民間システムからアーティファクトを除去する権限を求めたほど深刻でありながら、修復負担の残りは依然として所有者に残されていた。
この行動は痛ましい現実を露呈した：一部のサーバー所有者は自分自身でウェブシェルを除去していなかった。彼らは侵害されたことに気づいていなかったかもしれない。スキル、ツール、時間、認識が不足していたかもしれない。パッチを当てたがクリーンアップしなかったかもしれない。インシデント対応チームを持たない小規模組織であったかもしれない。ウェブシェルの残留物は、ソフトウェアの緊急事態を異常な政府の妨害行動に変えた。
説明責任にとって、DOJ の作戦は同時に2つの点を指摘している。第一に、民間のクリーンアップの失敗が継続的なリスクを生み出すとき、公的当局が介入することがある。第二に、その介入行動は、サーバー所有者やベンダーエコシステムがより良い修復経路を構築する責任を免除するものではない。そのような作戦の必要性は、パッチガイダンス、緩和ツール、通知、マネージドサービスサポートがすべての脆弱な環境に迅速に届かなかったことを示唆している。
長期的修復の基準には、パッチ適用とアーティファクト除去がリンクされているという証拠を含めるべきである。サーバー所有者は、既知のウェブシェルパスがチェックされていなければ、更新プログラムをインストールした後にインシデントをクローズしたと見なすべきではない。マネージドサービスプロバイダーは、侵害評価も対応されない限り、顧客環境をパッチ済みとして扱うべきではない。ベンダーは、パッチ適用とクリーンアップの違いが明白になるように緊急ガイダンスを設計すべきである。
小規模組織はエンタープライズ級の対応要求を引き継いだ
ProxyLogon は特に中小規模組織にとって困難であった。なぜなら、Exchange Server はエンタープライズ規模で専門的にスタッフが配置されていなくても、ミッションクリティカルである可能性があるからである。小さな法律事務所、地方自治体の事務所、学校、診療所、製造業者、非営利団体は、何年も前にインストールされ、ワークフローと統合され、小さな IT プロバイダーによって管理されているために、オンプレミスの Exchange に依存している可能性がある。緊急悪用が発生すると、その組織は突然エンタープライズ級の対応を必要とする。
それはサーバーを特定し、露出を判断し、更新を適用し、検出スクリプトを実行し、IIS ログをレビューし、疑わしいファイルを検査し、メールボックスアクセスを評価し、資格情報をローテーションし、持続性を監視し、ユーザーに伝達し、場合によっては外部の支援を雇わなければならない。それは小規模チームにとって大きな作業負荷である。セキュリティ自動化のトピックは、ツールとスクリプトが手動の負担を軽減できるため、ここで重要である。ただし、それらが明確で安全かつ到達可能である場合に限る。
Microsoft の緩和および対応者向けガイダンスは、そのようなツールを提供しようとした。Exchange チームの四半期更新投稿「Released: March 2021 Quarterly Exchange Updates」も、より広範なサービスコンテキストを指摘した。後日、Microsoft は「Exchange Server 2021年9月累積更新プログラムの新しいセキュリティ機能」という投稿で Exchange 緊急緩和サービスを導入した。この後の機能は重要である。なぜなら、それは製品レベルの長期的問題への対応を示しているからである：組み込みの緩和策は、即時のパッチ適用が困難な場合に時間を稼ぐことができる。
緊急緩和はパッチ適用の代替ではなく、後の機能が2021年のすべての環境が修復されたことを証明するものではない。しかし、それは現実を認識している。一部の Exchange 運用者は即座にパッチを当てない。勧告を見逃す者もいる。サポートされていないバージョンを使用している者もいる。累積更新プログラムをインストールするのに時間を必要とする者もいる。長いオンプレミスのテールを持つ製品には、顧客が追いつく間に害を減らすメカニズムが必要である。
小規模組織の説明責任は共有されている。運用者は、サポートされていない露出したメールサーバーを無期限に実行すべきではない。マネージドサービスプロバイダーは、顧客のサーバーを迅速にインベントリしパッチを当てるべきである。ベンダーは、緊急ガイダンスを非専門家にも理解可能にすべきである。公的機関は明確な警告を発すべきである。保険会社と監査人は、リスクの高いインターネット向けサービスが把握され、インシデント対応計画でカバーされているという証拠を要求すべきである。ProxyLogon は、誰も単独で長いテールを運ぶことはできないことを示した。
スキャンデータは露見の特定に役立ったが、露見と侵害は同じではない
露見の測定は対応の主要な部分となった。Shadowserver のMicrosoft Exchange Server 脆弱性プロジェクトは、スキャンと脆弱性露見のコンテキストを提供した。そのようなプロジェクトは、防御担当者や公的機関がインターネット向けリスクの長いテールを見るのに役立つ。パッチと勧告の後に露出した人口が減少するかどうかを示すことができる。
しかし、露見は侵害と同じではない。スキャンは、Exchange Server が到達可能であるか、特定の応答プロファイルを持つことを示唆できる。それは必ずしも正確なバージョン、成功した悪用、ウェブシェルの存在、データ窃取、またはクリーンアップを証明できない。逆に、サーバーは侵害後にパッチが当てられても調査が必要な場合がある。露見マップはトリアージツールであり、最終的な記録ではない。
この区別は公的なコミュニケーションにとって重要である。何千もの露出または脆弱なサーバーに関する見出しは行動を促進できるが、カテゴリを曖昧にする可能性もある。サーバー所有者は、自分たちが露出しているか、脆弱か、悪用されたか、パッチ済みか、クリーンか、監視中かを知る必要がある。各状態は異なる行動を意味する。クリーンなインベントリはそれらの状態を別々に追跡すべきである。
政府とベンダーのメッセージはこれを強化すべきである。「更新プログラムを適用する」は1つのアクションに過ぎない。「検出と修復の手順を実行する」は別のアクションである。「ウィンドウ中に露出した場合は侵害を想定する」は一部のコンテキストで適切かもしれないが、その想定も具体的な調査に変わらなければならない。長期的問題は部分的に分類問題である：あまりにも多くの組織が1つのタスクを完了しただけでサーバーを安全とマークする。
したがって、修復記録には状態遷移の証拠を含めるべきである。サーバーはいつ発見されたか？いつ隔離または更新されたか？指標は見つかったか？ウェブシェルは除去されたか？資格情報はローテーションされたか？メールアクセスは評価されたか？監視は強化されたか？誰がクロージャを検証したか？それらのタイムスタンプがなければ、組織はインシデント記録ではなくパッチイベントを持っている。
メールサーバーは継続性と機密性の両方のシステムである
Exchange Server は、コミュニケーションプラットフォームであると同時に、機密履歴のリポジトリでもある。侵害されたメールサーバーは、メッセージ、添付ファイル、連絡先、カレンダー、法的議論、調達記録、公的機関の対応、メールで送信された資格情報、パスワードリセットフロー、内部ビジネス計画を露呈させる可能性がある。また、組織が業務、インシデント対応、ベンダー、顧客、公的なコミュニケーションを調整するためにメールを使用するため、継続性にも影響を与える。
この二重の役割は修復をより複雑にする。ファイルサーバーが侵害された場合、組織はファイルに焦点を当てるかもしれない。メールサーバーが侵害された場合、組織はどのメールボックスがアクセスされたか、どのメッセージに資格情報や機密データが含まれていたか、どの外部連絡先が影響を受けたか、攻撃者がサーバーを使用してメールを送信したりピボットしたりできるかどうかを尋ねなければならない。サーバーはアーカイブであり、ライブコントロールチャネルでもある。
Microsoft の対応者向けガイダンスと CISA の勧告は、パッチ適用だけでなく調査と修復に焦点を当てることでこれを認識した。FBI の作戦も持続性の問題を反映している。メールサーバー上のウェブシェルは継続的なアクセス経路である。パッチ後でも、除去されなければ使用可能である。除去後でも、組織は攻撃者が除去前に何をしたかを尋ねなければならない。
公共部門の継続性にとって、メールの役割はさらに鋭い。機関はメールを使用してサービス、緊急対応、契約、給付、学校、裁判所、健康を調整する。メールシステムが疑わしい場合、通常業務は遅くなる。スタッフは会話を代替チャネルに移すかもしれないが、それは記録管理とセキュリティの問題を生み出す可能性がある。侵害されたメールサーバーは、即時的および遅延的なガバナンスコストの両方を生み出す可能性がある。
説明責任のある修復記録には、機密性と継続性を含めるべきである。組織は安全なメール利用を回復したか？潜在的に露出したメールボックスを特定したか？証拠を保存したか？必要な場合に関係者に通知したか？メールを通過した可能性のある資格情報をリセットしたか？なりすましや横方向の移動を監視したか？次のメール緊急事態に備えて代替チャネルを持つように継続性計画を更新したか？
ベンダーの修復は3月以降も続いた
Microsoft の後の Exchange 作業は重要である。なぜなら、ProxyLogon は2021年3月で終わらない製品メンテナンス問題を露呈したからである。Exchange 緊急緩和サービスは、Microsoft の2021年9月の累積更新投稿で説明され、特定の条件下で自動的に一時的な緩和を適用するように設計された。Microsoft の後のExchange Server ロードマップ更新は、サービス方向について議論を続けた。
これらの後のソースは、すべての ProxyLogon 侵害がクリーンアップされたという証明として扱われるべきではない。それらは製品ガバナンスの証拠である。Microsoft がオンプレミスのインストールベースでより自動化された保護の必要性を認識したことを示している。その認識は重要である。なぜなら、オンプレミス製品は不均等に老朽化するからである。顧客は累積更新を遅らせる。一部の環境は最新の管理から隔離されている。他のものは露出しているが監視が不十分である。緊急緩和機能は、ラグの間にリスクを軽減できる。
それでも、自動化された緩和には限界がある。サポートされている累積更新を必要とする場合がある。サポートされていないバージョンには適用されない場合がある。互換性の懸念を生み出す場合がある。特定のパスの露出を減らしても、すべてのリスクを排除しない場合がある。既存のウェブシェルを削除しない場合がある。顧客は依然としてパッチ適用、調査、クリーンアップを必要とする。自動化は長いテールを助けるが、説明責任を排除しない。
ベンダーの永続的な義務は、修復経路をより短く明確にすることである。緊急パッチは幅広い顧客がインストール可能であるべきである。パッチが即座にインストールできない場合には緩和策が利用可能であるべきである。検出ガイダンスは簡単に実行および解釈できるべきである。サポートチャネルはリスクの高い顧客を優先すべきである。ドキュメントは、再構築がクリーンアップよりも安全である場合を説明すべきである。長いテール製品は、サポートされていない露出を減らすライフサイクルとアップグレードパスを持つべきである。
ProxyLogon はまた、クラウド移行が唯一の答えではない理由を示している。Microsoft は Exchange Online はこれらの脆弱性の影響を受けないと述べ、多くの組織は露出したメールサーバーを実行しないようにクラウドホスト型メールを使用している。しかし、多くの組織はハイブリッド、規制、コスト、レガシー、または運用上の理由からオンプレミスの Exchange をまだ実行している。説明責任の質問は、残りのオンプレミス人口をどう統治するかであり、単に全員に移行を促すことではない。
マネージドサービスプロバイダーが修復チェーンの一部となった
多くの小規模組織は Exchange を単独で管理していない。彼らはマネージドサービスプロバイダー、地元の IT 企業、ホスティングプロバイダー、またはコンサルタントに依存している。ProxyLogon の間、それらのプロバイダーは修復チェーンの一部となった。彼らは顧客のインベントリを追跡し、更新を適用し、検出を実行し、リスクを伝達し、証拠を保存し、疑わしい侵害をエスカレーションする必要があった。1つのプロバイダーが多くの Exchange サーバーを管理している場合、その応答速度は多くの組織に影響を与えた。
契約は危機の前にこの緊急時の役割を定義すべきである。プロバイダーはメンテナンスウィンドウを待たずに緊急パッチを適用する権限を持っているか？ベンダーの勧告を監視しているか？侵害評価を実行しているか、それとも更新のみをインストールしているか？ログを保持しているか？悪用の疑いがある場合に顧客に通知しているか？サイバー保険を持っているか？インシデント対応者をいつ呼び込むかを知っているか？ProxyLogon はそれらの契約条件を運用上の事実に変えた。
顧客にも義務がある。どのプロバイダーが Exchange を管理しているか、どのバージョンが実行されているか、サーバーが露出しているか、バックアップがどのように機能するか、ログがどのように保持されるか、緊急時の決定を誰が行うかを知るべきである。アウトソーシングは資産認識の必要性を排除しない。小規模企業は技術的ステップを自分で実行しなくても、それらが実行されたという証拠を要求できるべきである。
公的機関と保険会社は、より明確な証拠を要求することで支援できる。クリティカルな悪用された脆弱性の後、高リスクシステムにとって「パッチを当てた」だけでは十分ではない。証拠には、日付、バージョン、検出結果、アーティファクトレビュー、資格情報対策、監視を含めるべきである。マネージドサービス顧客にとって、その証拠は顧客が保持できる形式で提供されるべきである。そうでなければ、次の監査または侵害通知は記憶から始まる。
ProxyLogon の長いテールは部分的に市場の問題であった：多くの小規模組織は、必ずしもインシデント対応を含まない地元プロバイダーからのサービスとしてメール運用を購入した。緊急悪用はその区別を崩壊させる。プロバイダーがサーバーを管理する場合、侵害評価の準備ができているか、迅速に取得する経路を持っている必要がある。
最終的な尺度は検証可能な修復である
ProxyLogon からの最も強い説明責任の教訓は、修復が検証可能でなければならないということである。サーバー所有者は、脆弱性通知からインベントリ発見、パッチインストール、緩和、侵害評価、クリーンアップ、資格情報レビュー、監視までのタイムラインを示せるべきである。ベンダーは、そのタイムラインの難易度をどのように減らしたかを示せるべきである。公的機関は、露出した人口が減少しているかどうか、重要な機関が遵守しているかどうかを確認できるべきである。
検証可能な修復は、すべてのログやフォレンジック詳細の公開リリースを必要としない。それは、組織、その取締役会、顧客、監査人、規制当局が何が行われたかを理解するのに十分な記録を必要とする。小規模組織では、その記録はマネージドサービスのレポートであるかもしれない。連邦機関では、指令の遵守証拠であるかもしれない。大企業では、インシデント対応ケースファイルであるかもしれない。形式は異なってもよい。証拠のカテゴリは異なるべきではない。
ProxyLogon は Microsoft のパッチイベントとしてのみ記憶されるべきではない。それはインストールベースのテストであった：誰が自分の Exchange サーバーを知っていたか、誰が迅速に更新できたか、誰がウェブシェルを見つけられたか、誰がメールの露出を評価できたか、誰が小規模組織を保護できたか、誰が緊急事態の後にクロージャを証明できたか。DOJ のウェブシェル除去作戦は、長いテールが現実であったことの鮮やかな兆候として残っている。
公的な教訓は同様に実用的である。インターネット向けオンプレミスシステムにとって、パッチ適用は最低限である。説明責任記録はパッチ適用から始まり、検出、クリーンアップ、資格情報ローテーション、ユーザー通知、後の製品改善を通じて続く。それらのステップが証明されなければ、緊急パッチは劇場になる：見える行動が目に見えない残留物を残すかもしれない。
Microsoft の後の緩和機能、CISA の指令と勧告、連邦法執行機関の行動、セキュリティコミュニティのレポート、地元運用者の義務はすべて同じ結論を指している。パッチから安全への道は長い。Exchange に依存する組織は、その道が実際に旅されたという証拠を必要とする。
クロージャにはパッチ適用とは異なるチェックリストが必要である
Microsoft MSRC の対応者向けガイダンス「オンプレミスの Exchange Server 脆弱性の調査と修復」は、防御担当者が更新プログラムのインストールだけでなく、ウェブシェルやその他のアーティファクトを検索する必要があることを明確にしている。その区別は、影響を受けるすべての組織内で2つの別々のチェックリストを生み出すべきであった。最初のチェックリストはパッチ適用である：バージョンの特定、前提条件の満たし、更新プログラムのインストール、ビルドの確認。2つ目はクロージャである：侵害の検索、アーティファクトの除去、資格情報のローテーション、メールボックスアクセスのレビュー、証拠の保存、再侵入の監視、通知が必要かどうかの決定。
組織はしばしば最初のチェックリストを好む。なぜなら、それは目に見えるフィニッシュラインがあるからである。サーバーにはパッチがあるか、ないかのどちらかである。2つ目のチェックリストはより厄介である。それは、攻撃者がパッチの前に存在していたか、ログが十分に遡るか、ウェブシェルが除去されたか、他の持続性が残っているか、メールボックスがアクセスされたか、横方向の移動が発生したかを尋ねる。その作業には、小規模組織が持っていないスキルが必要になる場合がある。
CISA のAA21-062A 勧告と NSA の緩和勧告は、防御担当者向けにその2つ目のチェックリストを定義するのに役立った。問題はガイダンスの欠如ではない。それは運用上の採用である。ガイダンスはサーバーを所有する人に届き、実行可能なほど理解可能であり、組織のツールと権限に適合しなければならない。
マネージドサービスプロバイダーは、クロージャチェックリストを顧客レポートに変えるべきである。レポートは単に「Exchange を更新しました」と言うべきではない。どのサーバーが更新されたか、いつ、どのバージョンから、どの検出手順が実行されたか、ウェブシェルが見つかったか、何が除去されたか、資格情報がローテーションされたか、バックアップがチェックされたか、どの監視が残っているかを述べるべきである。そのレポートは、保険会社、監査人、規制当局、影響を受けるユーザーが何が起こったかを尋ねたときの顧客の証拠となる。
大規模組織にとって、クロージャはリスクガバナンスにフィードすべきである。Exchange が露出していた場合、リーダーは公的な通知後どのくらい脆弱なままだったか、侵害が見つかったか、どのビジネスユニットがサーバーを使用していたか、機密メールボックスが影響を受けたか、より迅速な修復を妨げたものを知るべきである。答えが「サーバーの存在を知らなかった」なら、修復問題は資産管理である。答えが「知っていたがパッチを当てられなかった」なら、問題はサービス準備である。答えが「パッチを当てたが調査しなかった」なら、問題はインシデント対応の成熟度である。
サポート終了および遅延サーバーはコミュニティリスクである
ProxyLogon は、サポート終了または遅延しているオンプレミスサーバーに関するコミュニティリスク問題を露呈した。ある組織の露出した Exchange サーバーは、発射台、スパムソース、データ窃取の標的、または広範な侵入の足場になる可能性がある。害は局所的に始まるかもしれないが、侵害されたメールインフラは通信相手、パートナー、顧客、および通信への信頼に影響を与える可能性がある。だからこそ、長期的パッチ適用は所有者だけの私的リスクではない。
Microsoft の Exchange チームの2021年3月のセキュリティ更新と後の四半期 Exchange 更新に関するガイダンスは、サービス問題を指摘している。一部の顧客はサポートされている累積更新を実行しており、迅速に行動できた。他の顧客は追いつかなければならなかった。一部はサポートされていないバージョンを実行していたかもしれない。サービスギャップが長ければ長いほど、緊急修復は難しくなる。
後の2021年9月で説明された Exchange 緊急緩和サービスは、このコミュニティリスクへの1つの答えであった。一時的な緩和は、顧客が完全な更新を準備する間、露出を減らすことができる。しかし、一時的な緩和は、顧客が機能を受け取れるバージョンを使用していることと、組織が緩和モデルを受け入れることに依存する。それは放棄されたまたはサポートされていないすべてのサーバーを保護できない。
公的機関は、露出測定と通知を使用して支援できる。Shadowserver のExchange 脆弱性スキャンプロジェクトは、外部測定が行動を必要とする可能性のある人口を特定する方法を示している。そのような測定は慎重なコミュニケーションと組み合わせるべきである：露出データは侵害の証明ではないが、国やセクターの対応者が勧告を見逃す可能性のある所有者にリーチするのに役立つ。
コミュニティリスクの教訓は、インストールベースが継続的なケアを必要とするということである。ベンダーは摩擦を減らす更新パスを設計すべきである。顧客はサーバーをサポート状態に保つべきである。マネージドサービスプロバイダーはインベントリを維持すべきである。政府とセクター団体は露出した組織に警告すべきである。保険会社と監査人は、目に見えないインターネット向けメールインフラを罰則すべきである。長いテールは、各アクターが遅延サーバーを共有リスクとして扱うときにのみ縮小する。
メールボックスの露見はサーバー侵害よりも説明が難しい
ウェブシェルは目に見えるアーティファクトである。メールボックスの露見は説明が難しい場合がある。侵害された Exchange サーバーは、メッセージ、添付ファイル、アドレス帳、カレンダーアイテム、管理機能へのアクセスを許す可能性がある。しかし、どのメールボックスコンテンツが読まれたかを正確に判断することは、特にロギングが不完全であったり、攻撃者がサーバーレベルアクセスを使用した場合、困難である。これは、技術的なクリーンアップ後の通知と信頼の問題を生み出す。
Microsoft の初期のHAFNIUM 投稿と MSRC のExchange Server リソースセンターは、緊急更新と観測された悪用に焦点を当てた。影響を受ける組織にとって、次の質問はしばしばより困難であった：攻撃者はどのメールに到達したか？その答えは二値ではないかもしれない。一部の組織は明確なアクセス証拠を見つけられる。他の組織はサーバー侵害とアーティファクトの存在からリスクを推測することしかできない。
その不確実性は公的なコミュニケーションの一部であるべきである。組織が正確なメールボックスアクセスを判断できない場合、どの証拠があるか、何が欠けているか、どの保護措置が合理的かを述べるべきである。ユーザーはパスワードをリセットし、機密添付ファイルをレビューし、標的型フィッシングに注意し、一時的に通信をより安全なチャネルに移動する必要があるかもしれない。パートナーはウィンドウ中に送信されたメッセージを信頼しない必要があるかもしれない。法務および記録チームは調査資料を保存する必要があるかもしれない。
継続性の側面も説明を必要とする。メールが調査のためにオフラインにされた場合、どの代替チャネルが信頼できるか？メールがオンラインのままサーバーがクリーンアップされる場合、どの制限が適用されるか？公的機関が住民と通信する場合、どうやって信頼を失わないようにするか？これらの質問は運用上のものであり、純粋に技術的なものではない。
ProxyLogon はメールボックスの信頼を修復カテゴリにした。パッチが当てられたサーバーでも、ユーザーは古い会話が読まれたかどうか、新しいメッセージを信頼できるかどうかを疑問に思うかもしれない。最も強力な修復記録は、インフラストラクチャのステータスと通信の信頼ステータスの両方を説明すべきである。それがメールインシデントが真にクローズされる方法である。
パッチの緊急性は所有者の発見によって支えられるべきである
緊急パッチは、誰がシステムを所有しているかを誰かが知っていることを前提としている。ProxyLogon はその前提がどれほど脆弱であるかを露呈した。組織は、本番 Exchange サーバー、ハイブリッドサーバー、テストシステム、廃止されたがまだ実行中のホスト、請負業者管理のメールサーバー、忘れられたインターネット向けエンドポイントを持っている可能性がある。パッチ勧告はセキュリティチームに届くが、脆弱なサーバーはビジネスユニット、地方事務所、古いマネージドサービスプロバイダー、または明確に指名された人物がいないところに所有されている可能性がある。
だからこそ、CISA の緊急指令21-02はインストールだけでなく特定と報告から始まった。連邦機関にとって、オンプレミスの Exchange がどこに存在するかを知ることはそれ自体が緊急行動の一部であった。同じ規律が政府外にも適用される。資産インベントリは管理リストではなく、大規模悪用イベントにおける最初の制御である。
所有者の発見には、技術的所有者とビジネス所有者を含めるべきである。技術所有者はパッチを適用したりプロバイダーに電話したりできる。ビジネス所有者は、サーバーが法的メールボックス、公共サービス、経営陣のコミュニケーション、学生アカウント、臨床業務、またはアーカイブアクセスをサポートしているかどうかを理解している。両方がなければ、対応チームはマシンにパッチを当てても、露出のビジネスへの影響を見逃すかもしれない。
所有者記録には権限も含めるべきである。侵害が疑われる場合、誰がサーバーを切断できるか？誰が緊急ダウンタイムを承認できるか？誰が外部対応に資金を使えるか？誰がユーザーに通知できるか？誰がクリーンアップではなく再構築を決定できるか？ProxyLogon はそれらの決定を数日に圧縮した。事前に権限を割り当てていなかった組織は、攻撃者が既に動いている間に交渉しなければならなかった。
ベンダーと政府のガイダンスは、所有権が欠けている場合には限界がある。Microsoft のExchange Server リソースセンター、CISA の警告、セキュリティ企業のレポートは、防御担当者に何が重要かを伝えることができた。それらはすべての放置されたサーバーに名前を付けることはできなかった。それは依然として顧客の義務であり、小規模組織にとってはしばしば最も重要な義務である。
したがって、永続的な修復は所有者テスト済みのインベントリである。少なくとも定期的に、組織はすべてのインターネット向けメールシステムに指名された所有者、サポートされているバージョン、更新パス、バックアップ計画、ロギング計画、インシデント権限、ビジネス影響ラベルがあることを証明すべきである。次の緊急パッチが到着したとき、最初の1時間を誰がサーバーを所有しているかを尋ねることに費やすべきではない。
再構築の決定は計画の一部であるべき
侵害された Exchange サーバーのクリーンアップは困難である可能性がある。ウェブシェル、疑わしいプロセス、または不確かなログが存在する場合、防御担当者は除去で十分か、既知の良好なメディアからの再構築がより安全かを決定しなければならないかもしれない。その決定は、ビジネス許容度、バックアップ品質、証拠の必要性、封じ込めに対する組織の自信に依存する。それは悪用後に即興で行われるべきではない。
DOJ のウェブシェル除去作戦は、アーティファクト除去の限界を示している。既知のウェブシェルを除去することは1つのアクセス経路を減らす。それはサーバーが他の点で信頼できることを証明しない。FBI の通知は、サーバー所有者が修復を継続する必要性を強調した。それが再構築の質問を公的な形にしたものである：システムを再び信頼するのに十分な証拠のレベルは何か？
組織は事前に再構築のトリガーを設定すべきである。例えば、確認されたウェブシェルと不十分なログは再構築を必要とするかもしれない。横方向の移動の証拠はより広範な環境対応を必要とするかもしれない。サポートされていないバージョンステータスは修復ではなく移行を必要とするかもしれない。機密メールボックスの露見は復元前の法的レビューを必要とするかもしれない。これらのトリガーは、技術チームがアドホックな経営陣の議論を待たずに断固として行動するのに役立つ。
再構築計画はまた、バックアップの現実を露呈する。クリーンな再構築には、既知の良好なインストールメディア、構成ドキュメント、メールデータ保護、テスト済みの復元、ワイプ前にフォレンジック証拠を保存する方法が必要である。小規模組織は、インシデント中にバックアップは存在するが復元手順が不確かであることを発見することが多い。ProxyLogon は、緊急パッチとディザスタリカバリが関連していることを示した；安全に再構築できないサーバーはクローズがより困難になる。
説明責任の基準は、すべての侵害されたサーバーが常に再構築されなければならないということではない。それは、組織がいつ再構築がより安全な経路かを知り、それを行う手段を持っているべきであるということである。クリーンアップの決定が希望ではなく証拠のしきい値によって統治されるとき、長期的修復はより強力になる。