概要
- Confluence の記録は構造的な説明責任の問題を示している。Atlassian はアドバイザリ、緩和策、修正版をリリースできるが、すべてのセルフマネージド顧客はその通知を在庫確認、ダウンタイム、アップグレード実行、フォレンジックレビュー、信頼の回復に変換しなければならなかった。
- CVE-2022-26134 は最も明確な共通モードの例である。Confluence Server およびデータセンター に影響し、認証されていないリモートコード実行を許し、公開前に悪用され、2022年6月2日に CISA の既知の悪用脆弱性カタログに登録され、修正版の公開後も多様な悪用が発生した。
- ホステッドとセルフマネージドの責任は分離されなければならなかった。Atlassian は自社の Cloud サイトは影響を受けていないと述べた一方、Server またはデータセンター を運用する顧客は実行中のインスタンスについて、ネットワーク露出、アップグレード計画、バックアップ、ログ、権限、調査、事業継続の負担を負った。
- パッチはクロージャと同じではない。対応者はメモリ内インプラント、Web シェル、ログ改ざんの試み、ランサムウェアの試み、クリプトマイニング、ボットペイロード、公開されたエクスプロイトトラフィックを観測した。修正版は1つの経路を止められても、証拠、認証情報、永続性、損なわれた信頼を未解決のままにする可能性がある。
- 説明責任のテストは、ベンダーと顧客のエコシステムが信頼できるサービスまでの時間を測定できるかどうかであり、アドバイザリ公開までの時間や最初の修正パッケージまでの時間ではない。
共通モードの露出はビジネス上の条件である
Confluence は多くの場合 Wiki やコラボレーションツールとして導入されるが、多くの組織では運用上の記憶装置となる。手順、インシデントノート、アーキテクチャの説明、ポリシーページ、プロジェクトの決定、カスタマーサポートのランブック、製品計画、他のシステムへのリンクを保存する。その役割を持つ1つの製品に活発に悪用される脆弱性が含まれる場合、リスクはソフトウェアの所有者だけに限定されない。それらのスペースの整合性と可用性に日常の作業が依存するすべてのチームに影響する。
Atlassian のConfluence セキュリティアドバイザリ 2022-06-02は、CVE-2022-26134 に関するそのリスクを公開した。このアドバイザリは、Confluence Server および Confluence データセンター における OGNL インジェクションの問題が、認証されていないリモートコード実行を許す可能性があると説明した。また、Atlassian Cloud サイトは影響を受けないとも述べた。このクラウドの区別は重要であり、運用責任を割り当てる。ホステッドサービスの顧客は、Atlassian が脆弱なサービスを運用することに依存する。セルフマネージドの顧客は、修正については Atlassian に依存するが、露出したインスタンス、変更ウィンドウ、バックアップ、ネットワーク到達可能性、権限コンテキスト、および侵害後の調査を自ら制御する。
この脆弱性は静かな理論上の欠陥ではなかった。Volexity のゼロデイ悪用レポートは、公開前の米国メモリアルデー週末に悪用が行われ、Web シェル、メモリ内の BEHINDER インプラント、Confluence に保存されたコンテンツへのアクセス、ログ改ざんの試みがあったと説明した。また、Volexity は2022年5月31日に Atlassian に通知したと述べている。Atlassian の公開対応はそのレポートの後迅速に行われたが、ベンダー側の迅速さは分散した顧客の作業負担を消し去るものではなかった。
CISA は2022年6月2日に CVE-2022-26134 を既知の悪用脆弱性カタログに追加し、対象の連邦民間機関には6月6日の期限を設定した。CISA の別の6月3日のアラートは、機関や組織に Atlassian の修正リリースを参照するよう促した。連邦の期限は民間企業に対する普遍的な法的期限ではない。しかし、「重要なパッチ」を「政府システムが直ちに対処しなければならない活発に悪用されているサービス」に変換するため、緊急性に関する強力な公的シグナルである。
共通モードの問題は、多くの組織が同時に同じ緊急事態に動くことである。Unit 42 の脅威ブリーフは、インターネットから見える可能性のある影響を受ける Confluence サーバーが19,707台、サポート終了のサーバーが1,251台と推定した。DIVD のケース記録は、約15,000の脆弱なインスタンスの運用者への通知を開始したと述べている。これらの数字は、独自の被害者や成功した侵害の確認された数ではない。露出の発見自体が大規模な運用タスクであった証拠である。
共通モード依存テストは、エコシステムがその同期されたタスクを吸収できるかどうかを問う。Atlassian は正確な範囲と修正を公開しなければならなかった。顧客はすべてのインスタンス、特に忘れられたものや外部に露出したものを特定しなければならなかった。マネージドサービスプロバイダーはアドバイザリを顧客向けに翻訳しなければならなかった。公的機関は緊急行動を優先しなければならなかった。セキュリティベンダーは検出と対応の観測を公開しなければならなかった。ビジネスオーナーは、対応を実行するために従業員が必要とするかもしれないコラボレーションプラットフォームを停止するかどうかを決定しなければならなかった。製品の欠陥は調整問題になった。
パッチクロックとサービスクロックは異なっていた
パッチタイミングは、報告からアドバイザリまで、またはアドバイザリから修正リリースまでで測定されることが多い。これはベンダーの説明責任には有用だが、顧客のサービスクロックを隠す可能性がある。顧客クロックは、警告が適切な所有者に届いたときに始まり、組織が脆弱なサービスが是正または隔離され、露出期間が調査され、復元されたサービスが使用するのに十分信頼できることを示せる場合にのみ終了する。
Atlassian のアドバイザリ更新履歴は、なぜこれらのクロックが乖離したかを示している。最初の6月2日の通知は活発な悪用を警告した。6月3日、Atlassian は緩和情報を更新し、その後サポートされているリリースブランチ全体で修正バージョンをリストした。また、顧客はローリングアップグレードを通じて修正バージョンに到達できないと警告した。この最後の点は継続性の事実であり、脚注ではない。ローリングプロセスで是正できないクラスター化された製品は、より広範なダウンタイム、緊急承認、ユーザーの混乱を必要とする可能性がある。
Atlassian の一般的なConfluence アップグレードハブおよびダウンタイムなしのアップグレードページは、通常のアップグレード作業には準備、互換性レビュー、バックアップ、クラスターの考慮、検証が含まれることを示している。緊急アドバイザリはこれらのタスクを圧縮した。顧客は、完全なアップグレードパスをたどるか、暫定的なファイル置換を適用するか、より安全な変更を計画しながらインスタンスを隔離するかを決定しなければならなかった。各オプションにはリスクが伴った：悪用可能性の継続、運用停止、互換性障害、または不完全な緩和。
バックアップはその選択を複雑にする。Atlassian のバックアップと復元のドキュメントは一般的な製品ガイダンスだが、インシデントはその目的を具体的にした。緊急是正を準備する顧客は、アップグレードが失敗した場合にデータを復元できる自信が必要だった。しかし、悪用後に取得したバックアップは、Web シェルや侵害された状態を保存する可能性があり、脆弱なバージョンへの復元は問題を再現する可能性がある。バックアップはクロージャではない。それは慎重に選択された復旧経路への1つの入力である。
米国国立標準技術研究所（NIST）は、このインシデントの直前にSP 800-40 Rev. 4およびSP 1800-31を公開した。これらのガイドは、パッチ適用を特定、優先順位付け、テスト、インストール、検証、例外処理を含むエンタープライズプロセスとして位置付けている。これらは Confluence 固有の所見ではない。「パッチが存在する」から「リスクが制御された」までの間に欠けている作業を説明している点で有用である。
Confluence の場合、検証にはいくつかの部分があった。すべてのインスタンス（テスト、古いもの、外部に露出したもの、単一プロジェクトのものを含む）は見つかったか？バージョンは修正されたか、アクセスはブロックされたか？緩和策はすべてのノードに適用されたか？サービスは不必要なホスト権限で実行されていたか？ログは改ざんや削除の前に保存されたか？接続された認証情報はローテーションされたか？ユーザーはサービスが制限されている間に避けるべきことを伝えられたか？復元されたコンテンツは信頼できるか？パッチクロックは Atlassian が修正パッケージをリリースしたときに停止する可能性がある。サービスクロックは、顧客が証拠を持っていれば、ずっと後に停止する。
これが、共通モードの脆弱性が弱い組織を不均衡に露出させる理由である。大企業は資産管理ツール、変更委員会、保存されたログ、ステージング環境、インシデント対応チームを持っている可能性がある。小規模チームは管理者1人、本番インスタンス1台、別のステージング環境がなく、ダウンタイムの許容度が限られているかもしれない。同じアドバイザリが両方に届く。説明責任は、ベンダーがすべての顧客の是正を実行できるふりをすることなく、非対称性に気づくべきである。
悪用可能性の言語は運用上の重みを持っていた
脆弱性アドバイザリの表現は広報ではない。それは、リーダーがダウンタイムを承認するかどうか、管理者が定常作業を停止するかどうか、公的機関が緊急プロセスをトリガーするかどうか、セキュリティチームがサービスを再起動する前に証拠を保存するかどうかを決定する。CVE-2022-26134 は、インターネットに面したコラボレーションプラットフォームでの認証されていないリモートコード実行が、ビジネス上の役割が明示されるまで過小評価されやすいため、異常に明確な言語を必要とした。
Atlassian のアドバイザリは、Confluence Server およびデータセンター のすべてのサポート対象バージョンが影響を受け、問題が活発に悪用されていると述べた。公開問題記録 CONFSERVER-79016は、欠陥を OGNL テンプレートインジェクションに結び付けた。NVD のCVE-2022-26134 エントリは後に CVSS 3.1 基本スコア 9.8 を反映した。スコアは大まかな手段だが、ここではスコアが運用上の現実と一致した：アカウントは不要、サービスはリモートから到達可能、ホスト上の任意のコード実行が続く可能性がある。
Atlassian のCVE-2022-26134 に関する FAQは、説明責任に関わるいくつかの点を追加した。シングルサインオンは認証前に脆弱性がトリガーされる可能性があるため悪用をブロックしないと述べた。インターネットに面していないインスタンスでもアップグレードすべきだとアドバイスした。また、Atlassian は顧客のインスタンスが侵害されたかどうかを判断できず、顧客が自らまたは専門家と調査することを推奨した。その声明は不快だが正直である。ベンダーはすべての顧客のローカルログ、メモリ状態、ファイル変更、ID 活動を所有していない。
インシデントレスポンダーはその警告の背後にある実用的な詳細を提供した。Volexity はメモリ内インプラント、ディスクベースの Web シェル、製品環境内のコンテンツテーブルへのアクセス、ログ改ざんの試みを観測した。GreyNoise の現地観測レポートは、多数の送信元アドレスが悪用を試み、多様なペイロードがあったと説明した。Cisco Talos の脅威アドバイザリは、公開された概念実証の利用可能性と活発な悪用に言及した。Sophos は後に、脆弱なサーバーにランサムウェアやその他のペイロードが到達したと報告した。これらの報告は単一の統一キャンペーンを説明するものではない。1つのエクスプロイト経路が急速に多様な運用上の脅威に多様化したことを示している。
CISA 主導の2022年の日常的に悪用された脆弱性トップに関する共同アドバイザリは後に、CVE-2022-26134 をその年の最も日常的に悪用された脆弱性の1つに含めた。この事後的な地位は、脆弱性が最初の1週間後に関係者の懸念から消えなかったことを示す点で重要である。パッチが適用されていないシステム、古いイメージから復元されたシステム、買収後に忘れられたシステムは、攻撃者にとって価値があり続ける可能性がある。
したがって、正確な悪用可能性の言語は4つの実用的な質問に答えるべきである。認証されていない攻撃者がパスに到達できるか？クラウドホステッドサービスが影響を受けるのか、それともセルフマネージドインスタンスのみか？緩和には完全なアップグレード、ファイル置換、ネットワーク隔離、シャットダウンのどれが必要か？修正の適用で調査は終了するのか、それとも顧客は悪用がすでに発生したと想定すべきか？Atlassian の公開資料はこれらの質問の多くに答え、レスポンダーエコシステムは結果を補完した。弱点はアドバイザリが述べたことだけでなかった。すべての顧客がそれに十分迅速に対応できるかどうかであった。
ホステッド対セルフマネージドの責任は明確にされなければならなかった
Confluence の記録は共有責任のケースだが、誰もがもっとうまくやるべきだという漠然とした意味ではない。責任は制御に従う。Atlassian は製品開発、アドバイザリの公開、修正版のリリース、製品固有の緩和手順、カスタマーサポート資料、クラウドとセルフマネージドの範囲の明確さを制御した。顧客は露出、インスタンスインベントリ、運用権限、バックアップ、監視、変更の実行、侵害後の調査を制御した。
Atlassian のFY22 セキュリティインシデントレポートは、CVE-2022-26134 対応を重大インシデントとして分類し、インターネットに面したインスタンスの活発な悪用を認めた。この会社作成のレポートは、Atlassian の視点からの内部重大度を確認する点で有用である。欠陥がなぜ早期に発見されなかったのか、セキュア開発テストがその後どのように変更されたのか、再発防止策が独立して検証された方法についての完全な根本原因レビューは提供していない。
Atlassian の現在のセキュリティアドバイザリ公開ポリシーおよびConfluence におけるアドバイザリアラートの資料は、現在の通知チャネルと製品セキュリティの期待がどのように形成されているかを示している。現在のポリシーは2022年5月に施行されていた正確なポリシーの証明として扱うべきではない。それでもエコシステム管理を特定するのに役立つ：顧客は信頼できるアドバイザリチャネルを必要とし、ベンダーは重大度と行動の両方を特定する顧客向け言語を必要とする。
セルフマネージドの顧客はより困難な運用負担を負っていた。Confluence Server またはデータセンター インスタンスは、ファイアウォールの背後、パブリックインターネット上、プロキシの背後、マネージドホスティングの取り決めの中、または古いインフラ上にある可能性がある。中央 IT、事業部門、プロジェクトチーム、請負業者が所有する可能性がある。現在の手順や、緊急事態が来るまでビジネスクリティカルとは誰も考えていない古いコンテンツを保持している可能性がある。ベンダーは、特にライセンス、リセラー関係、合併、ネットワーク変更が所有権を曖昧にする場合、外部からそのような展開をすべて確実に特定することはできない。
それは顧客だけがリスクを負うという意味ではない。ベンダーのアドバイザリは早期で、明確で、実行可能で、維持されなければならない。修正バージョンはサポートされているブランチで利用可能でなければならない。暫定的な緩和策は正確でなければならない。公開された回答は、活発な悪用がリスクを変える場合に、一般的な「パッチを適用」という言語の背後に隠れてはならない。Atlassian の対応は報告後迅速に動いたが、公開記録は、なぜこれほど広範囲に影響する認証されていない実行パスが存在したのか、そしてイベント後にどのような製品保証の証拠が変わったのかについて未回答のままである。
顧客にとって、説明責任の基準は残酷なまでに実用的であるべきである。公共の到達可能性を持つセルフマネージドのコラボレーションプラットフォームには、所有者、パッチチャネル、保守権限、テスト済みバックアップ、アプリケーションホストの外部で保護されたログ、エンドポイントまたはホスト監視、ネットワーク制限、侵害されたプラットフォームのみに依存しない緊急通信計画が必要である。企業がインスタンスを誰が所有し、どのように数時間以内にオフラインにするかを答えられない場合、それは脆弱性管理の問題だけではない。運用記憶依存の問題である。
顧客のクロージャにはバージョン番号だけでなく証拠が必要だった
修正された Confluence バージョンをインストールすることは必要だった。それ自体が健全性の証明書ではなかった。パッチ適用前に悪用された顧客は、コンテンツが読み取られたか改ざんされたか、Web シェルが残っていないか、認証情報が露出したか、ログが変更されたか、攻撃者作成のユーザーが存在するか、他のホストに到達されたか、復元されたコンテンツが信頼できるかを答えなければならなかった。
Volexity のアカウントは、メモリ常駐型とファイルベースの両方の活動を観測した点で重要である。単純なファイルスキャンでは1つのカテゴリを見逃す可能性がある。単純な再起動は別のカテゴリを除去しつつ、揮発性の証拠を失う可能性がある。バージョンチェックはインスタンスが修正されたと言うかもしれないが、永続性は他の場所に残っている可能性がある。Atlassian FAQは、Atlassian が各顧客のローカル状態を見ることができないため、侵害評価を適切に顧客と専門のレスポンダーに委ねた。
したがって、ログは贅沢品ではなく管理手段である。CISA のビジネスシステムでのログ使用に関するガイダンスは一般的だが、このインシデントクラスに直接語りかけている。ログが侵害されたホストにのみ存在する場合、ローテーションが速すぎる場合、またはサービス自体がログを改ざんできる場合、侵害後の信頼は脆弱になる。顧客はパッチを適用しても何が起こったのか証明できないかもしれない。証拠の欠如は運用コストになる。
英国国家サイバーセキュリティセンター（NCSC）の現在の脆弱性管理ガイダンスは、所有権、優先順位付け、デフォルトでの更新動作、例外の上級管理職承認、検証を強調している。NCSC の中小企業向け対応と復旧ガイダンスは、準備、特定、解決、報告、学習という継続性の次元を追加している。これらは Confluence の所見ではない。Confluence の顧客が洗練された企業から単純な対応モデルを必要とする小規模組織にまで及ぶため、有用である。
クロージャにはビジネス上の判断も必要だった。Confluence には Confluence の緊急事態に対応するための手順が含まれている可能性がある。ベンダーの連絡先リスト、アーキテクチャノート、継続性計画を保持している可能性がある。それをオフラインにすることは対応を遅らせる可能性がある。オンラインのままにすることは攻撃者の経路を残す可能性がある。回復力のある組織は、信頼が失われる可能性がある同じシステムの外部に緊急ランブックと連絡先パスを保存する。共通モード依存は、多くの組織が Confluence を実行していることだけではない。多くの組織が対応記憶をその内部に保存していることである。
したがって、バージョン番号は、より広範な証明に結び付けられた場合にのみ証拠となる。どのインスタンスが範囲内だったか？どのインスタンスがインターネット露出を持っていたか？どのインスタンスがパッチ適用、隔離、廃止されたか？どのインスタンスがパッチ前の活動について調査されたか？どの認証情報がローテーションされたか？どのログが保存されたか？どのビジネスオーナーが残留リスクを受け入れたか？どのユーザーがサービスが再び信頼できると伝えられたか？これらの回答がなければ、組織は製品にパッチを適用したが、必ずしも信頼できる作業面を復元したわけではない。
第二のレンズ：説明責任の問い
このインシデントに関するこれまでの報道は、しばしばパッチタイミングの非対称性、つまりベンダーの修正と顧客の是正との間のギャップに焦点を当てていた。第二のレンズはより広い：共通モード依存である。コラボレーションプラットフォームは、多くの無関係な組織内で静かに存在しながら、同期された露出を生み出す可能性がある。1つの脆弱性がどこでも同じ緊急事態を引き起こす場合、問題は、エコシステムがすべての顧客が同じ教訓を単独で再学習することなく修復を優先できるかどうかになる。
そのエコシステムの最初の要素はベンダーの証拠である。Atlassian はアドバイザリの速度だけでなく、悪用可能性の明確さ、ホステッド対セルフマネージドの範囲、ブランチサポート、緩和策の正確さ、サポートの応答性、インシデント後の保証について評価されるべきである。公開記録は Volexity の報告後の迅速な緊急対応を支持している。詳細な製品保証修復記録を公に確立してはいない。このギャップは非難ではない。証拠の境界である。
第二の要素は顧客のインベントリである。顧客は見つけられないものにパッチを適用できない。Unit 42 による公開露出推定と DIVD による通知作業は、外部者が多数のインスタンスを見ることができることを示している。外部の非営利団体が所有者が行動する前に脆弱なホストを見つけられる場合、所有者には資産所有権の問題がある。プラットフォームが仕事の中心になるほど、プラットフォームの所有者が曖昧であることは許容されにくくなる。
第三の要素は自動化である。緊急是正は、すべての管理者が完璧なタイミングでアドバイザリを読むことに依存すべきではない。組織は自動化された脆弱性インテリジェンス、資産マッピング、到達可能性評価、構成チェック、保守プレイブック、ビジネスオーナーへのエスカレーションを必要とする。自動化はすべてのトレードオフを決定できないが、公開警告から適格な行動までの時間を短縮できる。
第四の要素は継続性の設計である。Confluence は決済システムではなく知識サービスかもしれないが、知識の喪失は復旧を麻痺させる可能性がある。チームが Confluence を隔離する方法を見つけるために Confluence を必要とする場合、依存は循環する。成熟した環境は、主要なコラボレーションシステムの外部に最小限の緊急マップ、連絡先リスト、復旧プロセスを保持する。
第五の要素は、残留する未知の部分に関する透明性である。CVE-2022-26134 を通じて侵害された独自の組織の数は、どの情報源も確立していない。すべての顧客の悪用状態を確立する公開記録は存在しない。欠陥がなぜ早期に発見されなかったのか、再発がどのように防止されたのかを完全に説明する Atlassian の公開レポートは存在しない。これらの未知の部分は、確信的な前提で埋めるのではなく、述べられるべきである。
したがって、共通モードテストは「Atlassian はパッチを公開したか？」ではない。「Confluence に依存する組織の集団は、1つのベンダーアドバイザリを検証済みの修復に変換し、共有攻撃面が共有被害になる前にそれを行うことができたか？」である。2022年の記録は部分的な成功と明確な摩擦を示している。ベンダーの迅速さが重要だった。顧客の準備が重要だった。外部のレスポンダーが重要だった。次の説明責任のステップは、それらの証拠を結び付けることである。
依存関係の証拠は緊急事態の前に属する
Confluence の最も困難な教訓は、依存関係を悪用中に初めて管理することはできないということである。アドバイザリがセルフマネージドのコラボレーションサービスが認証されていないリモートコード実行に対して脆弱であると述べるとき、組織はすでに静かな計画ウィンドウを失っている。適切な所有者、インベントリ、保守ウィンドウ、バックアップ状態、緊急権限が警告の到着前に存在すべきである。そうでなければ、インシデント対応は通常の運用であるべき発見作業から始まる。
Confluence の所有者は、新しい調査を始めることなく基本的な質問に答えられるべきである。どのビジネスプロセスがスペースに依存しているか？インスタンスは Server、データセンター、Cloud のどれか？インターネットから到達可能か？どのリリースブランチか？ブランチはサポートされているか？ダウンタイムを承認できるのは誰か？どのプラグインが互換性リスクを生み出すか？バックアップはどこに保存されているか？ホストの外部でどのログが保護されているか？サービスに保存またはリンクされている ID とトークンはどれか？これらの回答が準備できていなければ、脆弱性には2つの爆発半径がある：欠陥によって作られた技術的なものと、不確実性によって作られた組織的なものである。
Atlassian のアドバイザリは、Atlassian Cloud とセルフマネージドの Confluence Server およびデータセンター を正しく分離した。その区別は、すべての顧客内部で依存関係マップをトリガーするべきだった。Cloud を使用するチームは、特定の CVE が自分のホステッドサイトに適用されないことを理解する必要があった。Server またはデータセンター を実行するチームは、即時の所有権と変更行動を必要とした。混合組織では、両方が真である可能性がある。企業は中央で Atlassian Cloud を使用しながら、事業部門、買収した会社、ラボ、請負業者が古いセルフマネージドインスタンスをまだ運用しているかもしれない。公式アーキテクチャと実際の土地が異なる場合、共通モード依存は見えにくくなる。
サポート終了のソフトウェアは特に重要である。Unit 42 の推定には、インターネットから見える可能性のある影響を受けるシステムの中にサポート終了バージョンのセットが含まれていた。サポート終了ステータスは、パッチパスが単純でない可能性があるため、説明責任を変える。顧客はもはや定期的なベンダーサポート、互換性テスト、またはサポートされているブランチアップグレードを想定できない。選択肢は緊急隔離、移行、利用可能な場合の有償延長サポート、またはサポートされていないリスクの受容になる。その選択は、真夜中の1人の管理者ではなく、悪用前にビジネスオーナーに属する。
また、外部通知が主要な資産発見方法であるべきではない。DIVD の通知作業は価値があり、公益スキャンは被害を減らすのに役立つ。しかし、外部者が数千の脆弱なインスタンスを発見した場合、その発見はより深いガバナンス問題を明らかにする：多くの運用者は、露出したコラボレーション層についてすでに十分に知っていなかった。成熟した組織は外部の警告に感謝しつつ、なぜ警告が必要だったのかを問うべきである。
依存関係の証拠には、契約とサポートの知識も含まれる。顧客はホスティングプロバイダー、リセラー、マネージドサービスプロバイダー、または内部プラットフォームチームに Confluence の運用を依存している可能性がある。Atlassian のアドバイザリを受け取る人は、パッチを適用できる人ではないかもしれない。パッチを適用できる人は、サービスを停止する権限がないかもしれない。ビジネスオーナーは、露出した実行脆弱性よりも Wiki の停止の方が安全だとは理解しないかもしれない。依存関係マップにはこれらの決定経路を含めるべきである。そうでなければ、アドバイザリは所有者を探すメッセージになる。
NIST のパッチ管理ガイドは、パッチ適用を英雄的なタスクではなく計画された能力として扱う点でここで有用である。特定、優先順位付け、入手、テスト、インストール、検証、例外管理はすべて、危機の前にデータを必要とする。Confluence の緊急事態はこれらのステップを圧縮するが、圧縮は排除ではない。無謀な変更なしに迅速に動く唯一の方法は、そのサービスに対して迅速な変更がどのように見えるかをすでにリハーサルしていることである。
共通モードのレンズは、組織がコミュニケーションについて考える方法も変える。Confluence がインシデント対応ランブック、緊急連絡先リスト、アーキテクチャ図、ベンダーサポートノートを保持している場合、制限されている同じプラットフォームがそれを制限するために必要な手順を削除する可能性がある。回復力のあるチームは、コラボレーションプラットフォームの外部に最小限の対応パケット（所有者、現在のバージョン、ネットワーク経路、バックアップ場所、緊急認証情報、主要な手順、外部連絡先）を保持する。そのパケットは華やかではない。知識プラットフォームと知識トラップの違いである。
説明責任のアーティファクトはクロージャ記録である
CVE-2022-26134 のような脆弱性の後、最も有用なアーティファクトはクロージャ記録である。プレスリリースでも、修正バージョンのスクリーンショットでも、システムがパッチ適用されたという曖昧な声明でもない。組織がアドバイザリから信頼できるサービスにどのように移行したかについての構造化された説明である。記録は、ビジネスオーナー、監査人、保険会社、または公共部門の監視機能が何が行われ、何が不確かなままかを理解できるように具体的であるべきである。
クロージャ記録は範囲から始まる。考慮されたすべての Confluence インスタンス（本番、ステージング、開発、廃止されたが到達可能なシステム、買収した企業のシステム、ホステッド契約、サポートされていないリリースを含む）をリストする。どのインスタンスが Atlassian Cloud であり、したがってこの CVE の製品範囲外であったか、どれが Server またはデータセンター であったかを記載する。どのインスタンスがインターネットに面していたか、どれが内部であったかを記載する。各インスタンスの所有者を記載する。範囲は、所有されていないインスタンスが侵害になるまで退屈なだけである。
第二の部分は行動である。範囲内の各インスタンスについて、シャットダウンされたか、インターネットからブロックされたか、修正バージョンにアップグレードされたか、Atlassian の暫定指示を通じて緩和されたか、廃止されたか、移行されたかを記録すべきである。タイミングを特定すべきである：アドバイザリが受信されたとき、アクセスが変更されたとき、修正バージョンがインストールされたとき、検証が完了したとき、ユーザーが戻ることを許可されたとき。また、なぜ例外が受け入れられたか、誰がそれを受け入れたかを記録すべきである。更新例外の上級管理職承諾は、活発な悪用が公になるとリスクがもはや純粋に技術的ではなくなるため重要である。
第三の部分は証拠の保存である。悪用が開示前に活発だった場合、組織はログ、メモリ、ファイル、接続された認証情報が重要になる可能性があると想定すべきである。クロージャ記録は、再起動やアップグレードの前にどの証拠が保存されたか、どのログが利用可能だったか、適切な場合にホストイメージやメモリキャプチャが取得されたか、どの証拠を回復できなかったかを述べるべきである。これは、すべての小規模組織が高度なフォレンジック調査を実行しなければならないという意味ではない。組織は「調べたが証拠は見つからなかった」と「調べる証拠がなかった」の違いを知るべきである。
第四の部分は侵害評価である。Volexity の報告は、悪用が Web シェル、メモリ内インプラント、コンテンツストアアクセス、ログ改ざんを伴う可能性があることを示した。Sophos、GreyNoise、Talos、Unit 42 は、後の悪用が複数のペイロードファミリーを含む可能性があることを示した。したがって、クロージャ記録は実行されたチェックを文書化すべきである：既知の Web シェルパスのファイルシステムレビュー、プロセスと永続性のチェック、アプリケーションログ、リバースシェルの指標、予期しないユーザー、発信接続、コンテンツストアアクセス、認証情報の露出、エンドポイントアラート。また、専門家の助けが使用されたか、使用されなかった理由も述べるべきである。
第五の部分は接続されたシステムのレビューである。Confluence は単独で存在することはほとんどない。ID プロバイダー、ソースコードシステム、チケッティングプラットフォーム、CI/CD ツール、チャット、ドキュメントストア、構造化コンテンツリポジトリと統合する可能性がある。Confluence ホストが侵害された場合、それらの統合で使用される認証情報はローテーションまたはレビューを必要とする可能性がある。接続された認証情報を無視する狭いパッチ記録は、攻撃者に元の脆弱性を生き残る経路を残す可能性がある。したがって、クロージャはサービスアカウント、API トークン、コンテンツストアパスワード、管理セッションを含むべきである。
第六の部分はビジネスの復旧である。ユーザーは単にサーバープロセスが実行中だからといってプラットフォームに戻るべきではない。コンテンツが無傷か、対応ウィンドウ中に行われた編集が保存されたか、添付ファイルが利用可能か、検索が機能するか、通知が信頼できるか、レビュー待ちのページやスペースがないかを知る必要がある。プラットフォームに運用手順が含まれている場合、コンテンツの整合性は可用性と同じくらい重要である。
第七の部分は学習である。クロージャ記録は、インスタンスがなぜ露出したか、なぜそのリリースブランチにあったか、アラートチャネルが適切な人に届いたか、ダウンタイム承認が遅かったか、バックアップがテストされていたか、ログが適切だったか、緊急ランブックが Confluence の外部にあったかを特定すべきである。ここで説明責任は非難から管理改善に変わる。目的はパッチを適用した人を罰することではない。次の共通モードアドバイザリをより混乱の少ないものにすることである。
そのようなクロージャにおける Atlassian の役割は、顧客が必要とする製品固有の事実（影響範囲、修正ブランチ、緩和策の有効性、悪用可能性ノート、クラウド範囲、アップグレード制約、侵害後の注意事項）を提供することである。顧客の役割は、それらの事実をローカルな証拠に変換することである。公的機関と外部のレスポンダーは、優先順位付け、観測、検出コンテキストの公開によって支援できる。これらの主体はどれも他を完全に置き換えることはできない。クロージャ記録はそれらの証拠が出会う場所である。
繰り返される Confluence の脆弱性は取締役会の質問を変えるべきである
CVE-2022-26134 は、公の記憶にある唯一の重大な Confluence 脆弱性ではない。繰り返される緊急 Confluence 是正のより広いパターンは、取締役会レベルの質問を「あの CVE にパッチを適用したか？」から「なぜこのコラボレーションレイヤーは繰り返し緊急行動を必要とし、それが発生した場合のビジネス影響をどのように制限するか？」に変えるべきである。取締役会はすべての OGNL の詳細を知る必要はない。組織が次の Confluence アドバイザリに構造的に準備ができているかどうかを知る必要がある。
その準備にはコストがかかる。Confluence を最新に保つには、ダウンタイム、プラグインレビュー、ユーザーコミュニケーション、テスト、時折のビジネス摩擦が必要になるかもしれない。インターネットアクセスを制限するには VPN、ゼロトラストアクセス、またはパートナーワークフローの変更が必要になるかもしれない。保護されたログとバックアップを維持するにはストレージとスタッフの時間がかかる。サポートされていないインスタンスを廃止するには移行労働力が必要になるかもしれない。これらのコストはインシデントの前に見えることが多いが、回避された侵害は見えない。説明責任は、リーダーがメンテナンスを任意のハウスキーピングとして扱わないように、回避されたリスクを目に見えるようにすることを意味する。
ロックインの次元も現実的である。Confluence スペースは何年もの制度的記憶を蓄積する可能性がある。ページ、権限、添付ファイル、リンク、マクロ、統合が作業に埋め込まれるため、移行は困難である。その粘着性は緊急アップグレードの決定を難しくする可能性がある。脆弱なプラグインや古いテーマは、移行が破壊的に見えるため、組織を脆弱なブランチに留まらせる可能性がある。ビジネスの便宜上、そのまま留まることがセキュリティ露出になる。成熟したガバナンスプロセスは、そのトレードオフをチケットのバックログに埋もれたままにせずに明示する。
公共部門および規制対象の顧客にとって、取締役会の質問には継続性を含めるべきである。Confluence が緊急計画、ポリシー解釈、ケースノート、インフラ文書、サービス手順をホストしている場合、セキュリティシャットダウンは公共の業務に影響を与える可能性がある。所有者は、セキュリティイベント中にどの情報が Confluence の外部で利用可能でなければならないかを知るべきである。これはサイバー衛生だけでなく、制度的記憶の継続性である。
共通モード依存テストは、広く使用されているコラボレーションプラットフォームが知識を集中させるため、繰り返される可能性が高い。Atlassian の2022年の記録からの教訓は、顧客がプラットフォームを信頼すべきではないということではない。信頼は運用上境界付けられるべきである。顧客は迅速にパッチを適用し、より迅速に隔離し、正直に調査し、プラットフォームが疑わしい場合でもコア知識に到達可能であるべきである。ベンダーは正確でタイムリーで技術的に率直なアドバイザリでその作業を容易にするべきである。エコシステムは、修正バージョンが現れた瞬間ではなく、検証済みのクロージャによって成功を測定すべきである。
調達の教訓もある。購入者はしばしばコラボレーション製品が認証、バックアップ、サポートチャネル、高可用性をサポートするかどうかを尋ねる。また、緊急セキュリティガイダンスがどのように運用者に届くか、サポートされているブランチがどの程度迅速に修正を受け取るか、ローリングアップグレードで修正バージョンに到達できない場合に何が起こるか、顧客が疑わしいインスタンスを再起動する前にどの証拠を保存すべきかを尋ねるべきである。これらの質問は、購入者をベンダーのコードの責任者にするわけではない。購入者を、次の緊急事態が発生したときに共有ツールがどのように管理されるかを知る責任者にする。
タイポグラフィに関する注記
次に何を測定すべきか
有用なインシデント後のスコアカードは、顧客認識までの時間、インベントリ確認までの時間、インターネットに面したシステムの隔離までの時間、サポートされている修正バージョンまでの時間、フォレンジック確信までの時間、ビジネスサービス復旧までの時間を測定するだろう。これらは異なるクロックである。それらを1つのパッチメトリックに統合すると、エコシステムは実際よりも制御されているように見える。
Atlassian にとって、永続的な公開証拠には、アドバイザリ記録、カスタマーサポートの改善、セキュア開発の変更、バリアント分析、製品チームが認証されていない式評価パスの再発可能性をどのように低減するかが含まれる。顧客にとって、永続的な証拠には、所有者リスト、保護されたログ、緊急ランブック、テスト済みバックアップ、認証情報ローテーション手順、活発な悪用下でコラボレーションシステムをオフラインにするためのビジネス承認が含まれる。公的機関にとって、永続的な証拠には、該当する場合の拘束力のある優先順位付け、同じリスクに直面しながら同じ権限を持たない非連邦組織のための明確なガイダンスが含まれる。
Confluence のインシデントは最終的に、コラボレーションソフトウェアがインフラになり得ることを教えている。そうなると、重大な脆弱性はもはや製品メンテナンスイベントだけではない。知識、継続性、セキュリティ証拠が、1つの欠陥がすべての依存組織を同時に即興で対応させないように十分に分散されているかどうかのテストである。