Atlassian Confluence、パッチタイミングが共通モード依存性の試金石に

サマリー

• Confluence の記録は構造的な説明責任の問題を示している。Atlassian はアドバイザリ、緩和策、修正バージョンをリリースできたが、全ての自己管理顧客はその通知を資産棚卸、ダウンタイム、アップグレード実行、フォレンジックレビュー、信頼回復に変換しなければならなかった。
• CVE-2022-26134 は最も明確な共通モードの例である。なぜなら、Confluence Server および データセンター に影響し、認証不要のリモートコード実行を許し、公開前に悪用され、2022年6月2日に CISA の既知の悪用された脆弱性カタログに登録され、修正バージョン登場後も多様な悪用が生じたからである。
• ホスト型と自己管理の責任を分離する必要があった。Atlassian は同社の Cloud サイトは影響を受けないと述べたが、Server または データセンター を運用する顧客は、ネットワーク露出、アップグレード計画、バックアップ、ログ、権限、調査、事業継続といった稼働インスタンスの負担を負った。
• パッチは閉鎖とイコールではない。対応者は、メモリ常駐型インプラント、Web シェル、ログ改ざん試行、ランサムウェア試行、暗号通貨採掘、ボットペイロード、公的なエクスプロイトトラフィックを観測した。修正バージョンはある経路を遮断できても、証拠、資格情報、永続性、そして損なわれた信頼は未解決のまま残った。
• 説明責任のテストは、ベンダー・顧客エコシステムが、アドバイザリ発行までの時間や初回修正パッケージまでの時間ではなく、信頼できるサービス回復までの時間を測定できるかどうかである。

共通モード露出は事業上の条件である

Confluence はしばしば Wiki やコラボレーションツールとして導入されるが、多くの組織ではそれは運営上の記憶装置となる。手順書、インシデントノート、アーキテクチャ説明、ポリシーページ、プロジェクト決定、カスタマーサポート手順、製品計画、他のシステムへのリンクを保存する。そのような役割を担う製品に悪用可能な脆弱性が存在する場合、リスクはソフトウェア所有者に限定されない。それは、これらのスペースの完全性と可用性に日常業務が依存するすべてのチームに及ぶ。

Atlassian のConfluence セキュリティアドバイザリ 2022-06-02は、CVE-2022-26134 に関するそのリスクを公開した。アドバイザリには、Confluence Server および Confluence データセンター における OGNL インジェクションの問題が記載され、認証不要のリモートコード実行が可能になるとした。また、Atlassian Cloud サイトは影響を受けないとも述べていた。このクラウドの区別は重要である。なぜなら、それによって運用責任が割り当てられるからだ。ホスト型サービスの顧客は、脆弱なサービスの運用を Atlassian に依存している。自己管理の顧客は修正を Atlassian に依存しているが、露出したインスタンス、変更ウィンドウ、バックアップ、ネットワーク到達可能性、特権コンテキスト、悪用後の調査を自ら管理する。

この脆弱性は静かな理論上の欠陥ではなかった。Volexity のゼロデイ悪用レポートは、公開前の2022年の米国メモリアルデーの週末に悪用が行われたことを記述しており、Web シェル、メモリ常駐型の BEHINDER インプラント、Confluence に保存されたコンテンツへのアクセス、ログ改ざん試行などが含まれていた。また、Volexity は2022年5月31日に Atlassian に通知したことも報告している。Atlassian の公開対応はその報告後迅速に動いたが、ベンダー側の迅速さは分散した顧客の作業負荷を消し去るものではなかった。

CISA は2022年6月2日、CVE-2022-26134 を既知の悪用された脆弱性カタログに追加し、対象となる連邦文民機関に対して6月6日までの対応期限を設定した。CISA の別途の2022年6月3日のアラートは、機関や組織を Atlassian の修正バージョンに向けた。連邦政府の期限は普遍的な民間部門の法的期限ではないが、それでも紧急性を強く示す公開シグナルである。なぜなら「重要なパッチ」を「政府システムが即座に対処しなければならない積極的に悪用されているサービス」に変換するからだ。

共通モードの問題は、同時に同じ緊急事態を経験する組織の数である。Unit 42の脅威速報は、インターネットから可視の影響を受けうる Confluence サーバー19,707台とサポート終了サーバー1,251台を推定した。DIVD のケース記録は、約15,000の脆弱なインスタンスのオペレーターへの通知を開始したと述べている。これらの数値は、固有の被害者又は成功した侵害の検証数ではない。それらは、露出の発見自体が大規模な運用タスクであったという証拠である。

共通モード依存性テストは、エコシステムがその同期的なタスクを吸収できるかどうかを問う。Atlassian は正確な範囲と修正を発行しなければならなかった。顧客はすべてのインスタンス、特に忘れ去られたり外部に露出したものを特定しなければならなかった。マネージドサービスプロバイダーは顧客向けにアドバイザリを変換しなければならなかった。公共機関は緊急対応を優先しなければならなかった。セキュリティベンダーは検出と対応の観測を公開しなければならなかった。事業所有者は、従業員が対応に必要とするかもしれないコラボレーションプラットフォームを停止するかどうかを決断しなければならなかった。製品の欠陥は調整問題となった。

パッチクロックとサービス復旧クロックは異なる

パッチタイミングは、報告からアドバイザリまで、あるいはアドバイザリから修正リリースまでで測定されることが多い。これはベンダーの説明責任には有益であるが、顧客側のサービス復旧クロックを隠してしまう可能性がある。顧客クロックは、警告が適切な所有者に届いた時点から始まり、組織が脆弱なサービスが修正または隔離され、露出期間が調査され、復旧したサービスが使用できるほど信頼できることを示せる時点で終わる。

Atlassian のアドバイザリ更新履歴は、なぜこれらのクロックが分岐したかを示している。2022年6月2日の初回通知は活発な悪用について警告した。6月3日には、Atlassian は緩和情報を更新し、サポートリリースライン全体の修正バージョンを一覧にした。また、顧客がローリングアップグレードを通じて修正バージョンに到達できないことも警告した。最後の点は連続性の事実であり、脚注ではない。ローリングプロセスで修正できないクラスター化された製品は、より広範なダウンタイム、緊急承認、ユーザー中断を必要とする可能性がある。

Atlassian の一般的なConfluence アップグレードハブおよびダウンタイムなしのアップグレードページは、通常のアップグレード作業には準備、互換性レビュー、バックアップ、クラスタ考慮事項、検証が含まれることを示している。緊急アドバイザリはこれらのタスクを圧縮した。顧客は、完全なアップグレードパスに従うか、暫定的なファイル置き換えを適用するか、あるいはより安全な変更を計画しつつインスタンスを隔離するかを決断しなければならなかった。各選択肢はリスクを伴った：継続的な悪用可能性、運用上の停止、互換性の失敗、不完全な緩和。

バックアップはその選択を複雑にする。Atlassian のバックアップと復元ドキュメントは一般的な製品ガイダンスだが、インシデントによってその目的が具体化された。緊急修正を準備する顧客は、アップグレードが失敗した場合にデータを復旧できるという確信が必要だった。しかし、悪用後に取得したバックアップは Web シェルや侵害状態を保存している可能性があり、脆弱なバージョンへの復元は問題を再現する可能性がある。バックアップは終結ではない。それは注意深く選ばれた復旧パスへの一つの入力である。

国立標準技術研究所（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 は後にランサムウェアやその他のペイロードが脆弱なサーバーに到達したことを報告した。これらの報告は一様なキャンペーンを記述するものではない。それらは、一つの悪用経路がいかに迅速に多様な運用上の脅威に拡散したかを示す。

CISA 主導の2022年上位定常悪用脆弱性共同勧告は後に CVE-2022-26134 をその年の最も定常的に悪用された脆弱性の一つとして含めた。この回顧的ステータスは重要である。それは脆弱性が最初の週の後も防御者の懸念から消えなかったことを示している。パッチ未適用のまま放置され、古いイメージから復元され、買収後に忘れ去られたシステムは、攻撃者にとって依然として価値を持ちうるからだ。

したがって、正確な悪用可能性の文言は4つの実用的質問に応えるべきである。認証されていない攻撃者が経路に到達できるか？クラウドホスト型サービスが影響を受けるのか、自己管理インスタンスだけか？緩和には完全なアップグレード、ファイル置き換え、ネットワーク隔離、またはシャットダウンが必要か？修正を適用すれば調査は終わるのか、それとも顧客は悪用が既に発生したと想定しなければならないのか？Atlassian の公開資料はこれらの質問の多くに答え、対応者エコシステムが結果を埋めた。弱点はアドバイザリが何を言ったかだけではなかった。それは、すべての顧客が十分迅速にそれに基づいて行動できたかどうかであった。

ホスト型対自己管理の責任は明示的でなければならない

Confluence の記録は共有責任の事例だが、誰もがより良くすべきだという漠然とした意味ではない。責任は管理に従う。Atlassian は、製品開発、アドバイザリ発行、修正バージョンリリース、製品固有の緩和手順、顧客サポート資料、クラウド対自己管理の範囲の明確性を管理していた。顧客は、露出、インスタンス在庫、運用特権、バックアップ、監視、変更実行、悪用後調査を管理していた。

Atlassian のFY22 セキュリティインシデント報告書は、CVE-2022-26134 対応を重大インシデントに分類し、インターネットに面したインスタンスの活発な悪用を認めた。この会社作成の報告書は、Atlassian の観点から内部の深刻度を確認するため有用である。それは、欠陥がなぜ早期に逃れたか、セキュア開発テストがその後どのように変わったか、再発防止管理がどのように独立に検証されたかを説明する完全な根本原因レビューを提供していない。

Atlassian の現在のセキュリティアドバイザリ発行ポリシーとConfluence のアドバイザリアラート資料は、今日の通知チャネルと製品セキュリティ期待がどのように枠組みされているかを示している。現在のポリシーは2022年5月に有効だった正確なポリシーの証明として扱うべきではないが、それでもエコシステム管理を特定するのに役立つ：顧客は信頼できるアドバイザリチャネルを必要とし、ベンダーは深刻度と行動の両方を特定する顧客向け言語を必要とする。

自己管理顧客がより困難な運用負荷を負った。Confluence Server または データセンター インスタンスは、ファイアウォールの背後、パブリックインターネット上、プロキシの背後、マネージドホスティング契約内、古いインフラ上に存在しうる。それは中央 IT、ビジネスユニット、プロジェクトチーム、またはコントラクターによって所有されうる。それは現在の手順書か、誰もビジネスクリティカルだとは思わない、緊急事態が発生するまでは、古い内容を保持しているかもしれない。ベンダーは外部からそのような各デプロイメントを、特にライセンス、リセラー関係、合併、ネットワーク変更が所有権を不明瞭にする場合、信頼性をもって特定できない。

それは顧客だけがリスクを負うことを意味しない。ベンダーのアドバイザリは早期で、明確で、実行可能で、維持されなければならない。修正バージョンはサポート対象ブランチで利用可能でなければならない。暫定的緩和は正確でなければならない。公開回答は、活発な悪用がリスクを変えるときに一般的な「パッチを適用せよ」という言葉の背後に隠れることを避けなければならない。Atlassian の対応は報告後迅速に動いたが、公開記録は、なぜこれほど広く影響を与える認証不要の実行パスが存在したのか、イベント後にどの製品保証の証拠が変わったのかを未回答のままにしている。

顧客にとって、説明責任の基準は残酷なまでに実用的であるべきだ。公衆到達可能な自己管理コラボレーションプラットフォームには、所有者、パッチチャネル、保守権限、テスト済みバックアップ、アプリケーションホスト外で保護されたログ、エンドポイントまたはホスト監視、ネットワーク制限、侵害されたプラットフォームだけに依存しない緊急通信計画がなければならない。もし企業が、そのインスタンスを誰が所有し、どうやって数時間以内にオフラインにするのかに答えられなければ、それは脆弱性管理の問題だけではない。それは運営記憶依存性の問題を抱えているのだ。

顧客の終結にはバージョン番号だけでなく証拠が必要

修正された Confluence バージョンをインストールすることは必要だった。それだけでは、クリーンビルオブヘルスではなかった。パッチ適用前に悪用された顧客は、コンテンツが読み取られたり改ざんされたか、Web シェルが残っているか、資格情報が公開されたか、ログが変更されたか、攻撃者が作成したユーザーが存在するか、他のホストに到達したか、復元されたコンテンツを信頼できるかどうかを回答しなければならなかった。

Volexity の説明はここで重要である。なぜなら、メモリ常駐とファイルベースの活動の両方を観測したからだ。単純なファイルスキャンでは片方のカテゴリを見逃す可能性がある。単純な再起動では、揮発性の証拠を失いながら別のものを取り除く可能性がある。バージョンチェックはインスタンスが修正されたと言えるが、永続性が他の場所に残るかもしれない。Atlassian の FAQは、侵害評価を顧客と専門対応者に適切に委ねた。なぜなら、Atlassian は各顧客の局所状態を見ることができなかったからだ。

したがって、ログは贅沢ではなく管理策である。CISA のビジネスシステムでのログ取得活用に関するガイダンスは一般的だが、このインシデントクラスに直接関係する。ログが侵害されたホスト上にしか存在せず、あまりに速くローテーションされるか、サービス自体がそれらを変更可能なら、悪用後の確信は脆弱になる。顧客はパッチを適用しても、何が起きたかを証明できないかもしれない。証拠の欠如は運用上のコストとなる。

英国国家サイバーセキュリティセンター（NCSC）の現在の脆弱性管理ガイダンスは、所有権、優先順位付け、デフォルトでの更新動作、上級者による例外の受け入れ、検証を強調している。NCSC の中小企業向け対応と復旧ガイダンスは、準備、特定、解決、報告、学習という継続性の次元を追加する。これらは Confluence の調査結果ではない。それらが有用なのは、Confluence 顧客が洗練された企業から、シンプルな対応モデルを必要とする小規模組織まで多様だったからである。

終結にはビジネス判断も必要だった。Confluence には Confluence の緊急事態に対応するための指示が含まれているかもしれない。ベンダー連絡先リスト、アーキテクチャメモ、継続性計画を保持しているかもしれない。それをオフラインにすると対応が遅れる可能性がある。オンラインにしておくと攻撃者の経路を残す可能性がある。レジリエントな組織は、緊急ランクブックと連絡先パスを、信頼が損なわれる可能性がある同じシステムの外側に保管する。共通モード依存性は、単に多くの組織が Confluence を実行していることだけではない。それは、多くの組織がその中に自分たちの対応メモリを保存していることだ。

バージョン番号はしたがって、より広範な証拠に付随する場合にのみ証拠となる。どのインスタンスが対象範囲か？どれがインターネット露出していたか？どれがパッチ適用、隔離、廃止されたか？どれがパッチ前の活動について調査されたか？どの資格情報がローテーションされたか？どのログが保存されたか？どのビジネス所有者が残余リスクを受け入れたか？どのユーザーがサービスが再び信頼できると伝えられたか？これらの答えがなければ、組織は製品にパッチを当てたかもしれないが、必ずしも信頼できる作業面を復元したとは言えない。

第二のレンズの説明責任問題

このインシデントの以前の報道は、しばしばパッチ時間の非対称性、ベンダーの修正と顧客の修復の間のギャップに焦点を当てていた。第二のレンズはより広い：共通モード依存性である。コラボレーションプラットフォームは、無関係な多くの組織の中に静かに存在しながら、同期化された露出を作り出すことができる。一つの脆弱性がどこでも同じ緊急事態を引き起こすとき、問題はエコシステムが、各顧客が単独で同じ教訓を再学習することなく修復を優先できるかどうかになる。

そのエコシステムの第一の要素はベンダーの証拠である。Atlassian は、アドバイザリの速度だけでなく、悪用可能性の明確性、ホスト型対自己管理の範囲、ブランチサポート、緩和精度、サポート応答性、そしてインシデント後の保証に基づいて評価されるべきである。公開記録は、Volexity の報告後の迅速な緊急対応を支持している。それは、詳細な製品保証修復記録を公的に確立していない。そのギャップは告発ではない。それは証拠の境界である。

第二の要素は顧客の在庫である。顧客は見つけられないものにパッチを当てられない。Unit 42による公開露出の推定と DIVD による通知作業は、部外者が多数のインスタンスを可視化できたことを示している。もし外部の非営利団体が所有者が行動する前に脆弱なホストを見つけられるなら、所有者には資産所有の問題がある。プラットフォームが業務の中核になるほど、そのプラットフォームの所有者が曖昧であることは受容しがたくなる。

第三の要素は自動化である。緊急修復は、すべての管理者が完璧な瞬間にアドバイザリを読むことに依存すべきではない。組織は、自動化された脆弱性インテリジェンス、資産マッピング、到達可能性評価、構成チェック、保守プレイブック、事業所有者へのエスカレーションが必要である。自動化はすべてのトレードオフを決定できないが、公的警告と適格な行動の間の時間を短縮できる。

第四の要素は継続性設計である。Confluence は支払いシステムではなく知識サービスかもしれないが、知識の喪失は復旧を麻痺させかねない。もしチームが Confluence を隔離する方法を発見するために Confluence が必要なら、依存性は循環的である。成熟した環境は、最低限の緊急マップ、連絡先リスト、復旧プロセスを主要なコラボレーションシステムの外に保持する。

第五の要素は残余の不明点に関する透明性である。CVE-2022-26134 を通じて何件の固有の組織が侵害されたかを確立する情報源はない。公開記録は各顧客の悪用状態を確立していない。Atlassian の公開報告書は、なぜ欠陥がより早期に逃れたか、または再発がどのように防止されたかを完全に説明していない。これらの不明点は、自信に満ちた仮定で埋めるのではなく、明示されるべきである。

したがって、共通モードテストは「Atlassian はパッチを発行したか？」ではない。それは「Confluence に依存する組織の集団は、共有された攻撃面が共有された害に変わる前に、一つのベンダーアドバイザリを検証された修復に変換できたか？」である。2022年の記録は部分的な成功と明確な摩擦を示している。ベンダーの速度は重要だった。顧客の準備態勢は重要だった。外部対応者は重要だった。次の説明責任ステップは、彼らの証拠を結びつけることである。

依存性の証拠は緊急事態の前に存在すべきである

Confluence の最も困難な教訓は、依存性は悪用時に初めて統治し始めることはできないということだ。アドバイザリが、自己管理コラボレーションサービスが認証不要のリモートコード実行に対して脆弱であると述べるとき、組織は既に静かな計画のウィンドウを失っている。適切な所有者、在庫、保守ウィンドウ、バックアップ状態、緊急権限は、警告が到着する前に存在すべきである。さもなければ、インシデント対応は、本来なら通常の運用であるべきだった発見作業から始まる。

Confluence 所有者は、新たな調査を始めることなく基本的な質問に答えられるべきだ。どのビジネスプロセスがスペースに依存しているか？インスタンスは Server、データセンター、Cloud か？インターネットから到達可能か？どのリリースブランチ上か？ブランチはサポートされているか？誰がダウンタイムを承認できるか？どのプラグインが互換性リスクを生じるか？バックアップはどこに保存されているか？どのログがホスト外で保護されているか？どの ID とトークンがサービスに保存され、またはリンクされているか？これらの答えが準備されていなければ、脆弱性は二つの爆風半径を持つ：欠陥によって作られた技術的なものと、不確実性によって作られた組織的なもの。

Atlassian のアドバイザリは、Atlassian Cloud を自己管理型の Confluence Server および データセンター から正しく分離した。その区別はすべての顧客の内部で依存性マップをトリガーすべきだった。Cloud を使用しているチームは、特定の CVE が彼らのホストサイトに適用されないことを理解する必要があった。Server または データセンター を実行しているチームは、即時の所有権と変更アクションを必要とした。混在組織では、両方が真実でありえた。ある企業は Atlassian Cloud を中央で使用しつつ、ビジネスユニット、買収された会社、研究室、またはコントラクターがまだ古い自己管理インスタンスを運用している可能性がある。共通モード依存性は、公式のアーキテクチャと実際の不動産が異なる場合に見えにくくなる。

サポート終了ソフトウェアは特に重要である。Unit 42による、インターネット可視の影響を受ける可能性のあるシステムの推定には、サポート終了バージョンのセットが含まれていた。サポート終了ステータスは説明責任を変える。なぜなら、パッチパスが単純でないかもしれないからだ。顧客はもはや定常的なベンダーサポート、互換性テスト、サポート対象ブランチアップグレードを想定できない。選択肢は緊急隔離、移行、利用可能な場合の有償延長サポート、またはサポート対象外リスクの受け入れとなる。その選択は、悪用前に事業所有者が行うべきであり、深夜の一人の管理者が行うべきではない。

外部からの通知もまた、主要な資産発見方法であるべきではない。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年の記録からの教訓は、顧客がプラットフォームを不信に思うべきだということではない。それは、信頼は運用的に境界づけられるべきだということである。顧客は迅速にパッチを当て、より速く隔離し、正直に調査し、プラットフォームが疑わしい場合でも中核知識に到達可能に保つべきだ。ベンダーは、正確でタイムリーで技術的に率直なアドバイザリでその作業を容易にすべきだ。エコシステムは、修正バージョンが現れた瞬間ではなく、検証された終結によって成功を測定すべきである。

調達の教訓もある。購入者はしばしば、コラボレーション製品が認証、バックアップ、サポートチャネル、高可用性をサポートするかどうかを尋ねる。彼らはまた、緊急セキュリティガイダンスがどのようにオペレーターに届くか、サポート対象ブランチがどれほど早く修正を受け取るか、修正バージョンにローリングアップグレードで到達できない場合に何が起こるか、疑わしいインスタンスを再起動する前に顧客がどの証拠を保存すべきかも尋ねるべきだ。これらの質問は購入者をベンダーのコードに責任を持たせるものではない。それは購入者を、次の緊急事態が来たときに共有ツールがどのように統治されるかを知る責任を持たせるものだ。

タイポグラフィに関する注記

タイポグラフィは、書かれた言語を読みやすく、判読可能で、視覚的に魅力的にするために文字を配置するアートとテクニックである。それには、書体、ポイントサイズ、行長、行間隔、文字間隔の選択が含まれる。

• タイポグラフィは、15世紀にヨハネス・グーテンベルクが可動活字を発明したことに始まる。
• 主要な要素には、フォント選択、カーニング、トラッキング、リーディングが含まれる。
• 良いタイポグラフィは可読性を高め、デザインにムードやトーンを伝える。

次に測定すべきこと

有用なインシデント後スコアカードは、顧客の認識までの時間、在庫確認までの時間、インターネットに面するシステムの隔離までの時間、サポート対象の修正バージョンまでの時間、フォレンジック確信までの時間、ビジネスサービス復旧までの時間を測定するだろう。これらは異なるクロックである。それらを一つのパッチメトリックに統合すると、エコシステムは実際よりも制御されているように見える。

Atlassian にとって、持続的な公開証拠には、アドバイザリ記録、顧客サポート改善、セキュア開発の変更、バリアント分析、そして製品チームが認証不要の式評価パスが再発する可能性を低減する方法が含まれるだろう。顧客にとって、持続的な証拠には、所有者リスト、保護されたログ、緊急ランクブック、テスト済みバックアップ、資格情報ローテーション手順、活発な悪用下でコラボレーションシステムをオフラインにするためのビジネス承認が含まれるだろう。公共機関にとって、持続的な証拠には、適用可能な場合の拘束力のある優先順位付けと、同じリスクに直面するが同じ権限を持たない非連邦組織への明確なガイダンスが含まれるだろう。

Confluence インシデントは最終的に、コラボレーションソフトウェアがインフラストラクチャになりうることを教えている。一旦そうなれば、クリティカルな脆弱性はもはや単なる製品保守イベントではない。それは、知識、継続性、セキュリティ証拠が、一つの欠陥がすべての依存組織を同時に即興させないほど十分に分散されているかどうかのテストである。