Atlassian Confluence とパッチタイムの非対称性：修正リリース後のリスクの所在

要約

• CVE-2022-26134 は、自己管理型の Confluence Server および Confluence データセンター における重大な OGNL インジェクションの脆弱性でした。認証されていないリモート攻撃者が任意のコードを実行できました。Atlassian Cloud は影響を受けませんでした。Volexity は、2022年5月31日に、米国メモリアルデーの週末に発生した悪用を調査した後、このゼロデイを Atlassian に報告しました。Atlassian は6月2日にアドバイザリを公開し、6月3日に修正バージョンをリストアップしました。
• この迅速なベンダー対応によって顧客の露出が終わったわけではありません。CISA は6月2日にこの脆弱性を既知の悪用された脆弱性カタログに追加し、米国連邦民事機関に対し、インターネットトラフィックを直ちにブロックし、影響を受ける製品を6月6日までに更新または削除するよう要求しました。インターネット測定と対応報告は、広範なスキャン、複数のペイロードタイプ、ランサムウェアの試行、暗号通貨マイニング、ボット活動、メモリ内インプラント、Web シェルを示しました。
• 運用負荷は非対称でした。Atlassian は修正済みソフトウェアを中央で生成できましたが、各顧客はすべてのインスタンスとノードを特定し、バージョンを確認し、アクセスを制限し、データをバックアップし、変更をテストし、緊急ダウンタイムを受け入れ、修正または暫定緩和策を適用し、検証し、サービスを復旧する必要がありました。Atlassian のインシデント別アドバイザリは、クラスター化された顧客はローリングアップグレードとして修正バージョンをインストールできないと警告しました。そのため、小規模組織やシングルノード展開は、コラボレーションの停止と継続的な露出の直接的な選択に直面しました。
• パッチ適用は必要でしたが十分ではありませんでした。Volexity はメモリのみのインプラント、ディスクベースの Web シェル、データベースアクセス、ログの改ざんの試みを観測しました。Atlassian の FAQ は、同社が顧客のインスタンスが侵害されたかどうかを判断できないと述べ、ローカルのフォレンジック調査を推奨しました。バージョンアップグレードが成功しても脆弱性は閉じられますが、盗まれた情報、認証情報、永続化、または破棄された証拠が残る可能性があります。
• 責任は制御能力に従うべきです。Atlassian は、安全な製品開発、脆弱性調査、バックポート修正、リリース品質、通知、製品固有の検出ガイダンスを管理しました。顧客は、資産インベントリ、公開露出、運用権限、ネットワーク境界、ログ、バックアップ、変更実行、インシデント対応、継続性を管理しました。記録は、Atlassian の迅速な開示から修正への対応を支持しますが、このような広範囲に影響を与える欠陥がなぜ早期に発見されなかったかを評価するのに十分な詳細な根本原因レビューは公開されていません。また、どの程度の露出したシステムが実際に侵害されたかも確認されていません。
• 永続的な教訓は、パッチまでの時間だけでなく、信頼できるサービスまでの時間を測定することです。積極的に悪用される知識プラットフォームの場合、終了には、すべてのインスタンスが修復または隔離され、露出期間が調査され、認証情報と接続システムが対処され、継続性手順が機能し、復元されたプラットフォームに説明責任のあるビジネスオーナーがいることの証明が必要です。

1つの脆弱性、4つの時計

従来の脆弱性タイムラインには、開示とパッチという2つの端点があります。これはベンダーの対応を測定するのに有用ですが、顧客の作業を架空の瞬間に圧縮します。CVE-2022-26134 は、その欠落した時間を可視化します。

最初の時計はベンダーの時計でした。Atlassian が脆弱性を再現および評価するのに十分な情報を受け取ったときに始まりました。Volexity は5月31日に Atlassian に連絡したと述べています。Atlassian のセキュリティアドバイザリは、6月2日午後1時（太平洋時間）のリリースと、6月3日午前10時に7つの修正バージョンを追加した更新を記録しています。公的な証拠によれば、Atlassian は積極的に悪用されている重大な脆弱性を確認し、CVE を割り当て、リスクを伝達し、サポート対象ブランチ全体にバックポートを準備し、迅速に修正をリリースしました。

2番目は封じ込めと変更の時計でした。これは各顧客で別々に始まりました。警告は行動権限のある者に届かなければなりませんでした。その人物は、Confluence のデプロイメント、ノード、バージョン、外部ルート、所有者、依存関係、サポートステータスのインベントリを必要としました。影響を受ける各インスタンスは、切断、制限、アップグレード、緩和、または削除されなければなりませんでした。パッケージが利用可能になったからといって時計が止まるわけではありません。顧客が脆弱なインスタンスが残っていないことを証明できたときにのみ止まりました。

3番目はフォレンジックの時計でした。積極的な悪用は公開開示に先行していました。そのため、顧客は攻撃者が修正前に自分たちに到達したかどうかを尋ねる必要がありました。この調査は、保持されている Web、OS、エンドポイント、ID、ネットワーク、アプリケーションの証拠に依存していました。メモリ取得、ファイルシステム比較、認証情報レビュー、接続システムの調査に拡大する可能性がありました。パッチは将来の悪用可能性を変えました。インストール前の期間を書き換えることはできませんでした。

4番目は継続性の時計でした。Confluence は通常、運用手順、プロジェクト記録、内部知識、インシデントラン ブック、意思決定履歴を保持しています。データが破壊されていなくても、それを制限またはシャットダウンすると作業が損なわれる可能性がありました。復旧にはサービスの再起動以上のものが必要でした。ユーザーはプラットフォームが利用可能で、完全で、安全に使用できるという信頼を必要としていました。Wiki に Wiki を復旧するための指示が含まれている場合、セキュリティ対応は循環依存関係を露呈する可能性がありました。

これらの時計は異なる責任を割り当てます。ベンダーはすべての人にとって実行可能な修正までの時間を短縮できます。顧客のシャドウインスタンスをインベントリしたり、メンテナンスをスケジュールしたり、ログを保存したり、どのビジネスプロセスが停止に耐えられるかを決定したりすることはできません。顧客はデプロイメントを分離して強化できます。ベンダーのプライベートな開発記録を検査したり、同じ速度でサポート対象のパッチを独自に作成したりすることはできません。各当事者が制御できる時計に対して評価されると、説明責任がより明確になります。

悪用と緊急パッチのタイムライン

この一連の流れは異常に文書化されていますが、証拠には限界があります。Volexity のレポートは2つの顧客サーバーとその直接のインシデント対応を説明しています。Atlassian のアドバイザリは製品範囲と更新時間を記録しています。CISA のカタログは連邦修復期限を記録しています。インターネットテレメトリはスキャンまたは潜在的に露出したシステムを説明していますが、確認された世界的な被害者数ではありません。

NVD エントリは、この問題に CVSS 3.1 基本スコア 9.8 を割り当て、影響を受ける範囲をバージョン 1.3.0 以降から各修正ブランチまでと特定しています。また、CISA カタログのアクションと日付も再現しています。これらのバージョン範囲の広さは、多くのリリースラインで修正が必要であったことを示しています。それ自体では、欠陥がいつ導入されたか、いつ初めて実際に悪用可能になったか、誰が最初に発見したか、または Atlassian が事前に知っていたかどうかを確立するものではありません。

その区別は公正な説明責任にとって重要です。長い影響を受けるバージョン範囲は、大きな修復負担と深い製品系統を示す可能性があります。それは、意図的な隠蔽や特定のセキュア開発の失敗の証明ではありません。それらの判断には、公的記録が提供していない証拠が必要です。

CVE-2022-26134 が可能にしたこと

Atlassian は CVE-2022-26134 を、Confluence Server または データセンター インスタンス上で認証されていないユーザーが任意のコードを実行できるようにする OGNL インジェクション脆弱性と説明しました。実際には、HTTP リクエスト内の攻撃者制御の入力が式として評価され、Confluence プロセスのセキュリティコンテキストでコマンドを実行するために使用される可能性がありました。有効なユーザーアカウント、盗まれたセッション、または従業員による操作は必要ありませんでした。

そのため、深刻度は部分的にデプロイメントに依存していました。インターネット到達性により、インスタンスは広範なスキャンに対して発見可能になりました。オペレーティングアカウントは、コマンドがホスト上で何ができるかを決定しました。ネットワークアクセスと保存された認証情報は、横方向の移動を形成しました。Confluence とそのデータベース内の情報は、機密性への影響を形成しました。監視とログ保持は、悪用が後で証明できるかどうかを形成しました。

Volexity のインシデント対応分析は、その連鎖を示しています。対応者は、侵害された Confluence プロセスが root として実行されており、コマンドに完全なホスト権限を与えていることを発見しました。メモリ内の BEHINDER インプラント、China Chopper Web シェル、別のアップロードシェル、偵察、ローカル Confluence データベーステーブルへのアクセス、および Web ログの改ざんの試みを特定しました。Volexity は、Confluence を root として実行しないよう明示的に推奨しました。製品の脆弱性がエントリを可能にしました。顧客側の権限とアーキテクチャは、そのエントリが何を意味するかを拡大する可能性がありました。

メモリ内コンポーネントは、クロージャの証拠にとって特に重要です。新しく作成されたファイルのみを検索する対応者は、メモリ内に存在するインプラントを見逃す可能性があります。サービスを再起動するとそのコンポーネントが削除される可能性がありますが、ディスクに書き込まれた2番目の Web シェル、逆流出を削除したり、認証情報が秘密のままであることを証明したりはしません。Volexity はまた、インプラントとの対話に使用されるリクエストが、単独では正当なトラフィックに似ている可能性があると指摘しました。検出には、コンテキストと一連の証拠が必要であり、単一のユニバーサルシグネチャではありません。

独立した観測は、悪用の人口がどれほど急速に多様化したかを示しています。GreyNoiseは、偵察、リバースシェル、ボットネット、暗号通貨マイニング、管理ユーザー作成の試み、破壊的なコマンド、難読化のペイロードを確認しました。Cisco Talosは継続的な悪用を報告し、ネットワーク検出カバレッジを公開しました。Sophosは、自動化された後続ペイロードとランサムウェアの試行を観測しました。Unit 42は、顧客テレメトリにおいて Cerber ランサムウェアの試みに関連する悪用の成功を報告しました。

これらの観測は、1つの普遍的な攻撃にまとめるべきではありません。Volexity の最初の攻撃者、自動化された暗号通貨マイニングオペレーター、ボットネット配信者、ランサムウェアオペレーターは異なる目的を持っていました。Volexity がリストした IP アドレスを発見しなかった組織も、他の誰かによって攻撃された可能性があります。既知の送信元アドレスをブロックすることは、一時的な摩擦手段として有用でしたが、修復や調査の代わりにはなりません。

Atlassian の対応は迅速だったが、製品記録は不完全

Volexity が報告した5月31日の通知から測定すると、Atlassian は約2日でアドバイザリを公開し、翌日に修正リリースを提供しました。アドバイザリは更新履歴を保持し、影響を受ける製品に名前を付け、Cloud と自己管理型デプロイメントを分離し、修正バージョンをリストし、暫定的なファイル置換手順を提供し、ローリングアップグレードの制限について警告し、最新の長期サポートリリースに顧客を誘導しました。これらは緊急対応における重要な強みです。

速度が重要なのは、ベンダーの分析の1時間1時間が、顧客がサポート対象の修正を欠いている間に発生するためです。7つのリリースを生成することは、ソースコードの1行を変更する以上のものです。ベンダーは欠陥を特定し、修正をテストし、影響を受けるブランチを決定し、アーティファクトをビルドして署名し、リリース情報を準備し、サポートを調整し、2番目の停止や脆弱性を作成しないようにする必要があります。公開記録は、Atlassian がこれを緊急事態として扱ったという結論を支持しています。

Atlassian はまた、専用のCVE-2022-26134 FAQを公開しました。Cloud は脆弱ではなかったこと、SSO は悪用が認証されていなかったため自己管理型インスタンスを保護しなかったこと、インターネットに面していないシステムでもアップグレードすべきであること、修正バージョンのみが保護を保証できることを明らかにしました。また、顧客にファイルシステムのアーティファクトをバックアップと比較し、ローカルのセキュリティチームまたはフォレンジック専門家に関与するよう助言しました。このガイダンスは、脆弱性の修復を侵害評価から正しく分離しました。

通知はチャネルに依存していました。FAQ によると、Atlassian は重要なアドバイザリを関連する製品アラートメーリングリストに送信しました。同社の現在のセキュリティアドバイザリ公開ポリシーも同様に、公開投稿とメーリングリスト通知を説明しています。メーリングリストは大規模に情報を配布できますが、現在の運用者がメッセージを受信し、確認し、行動することを保証できません。顧客記録には、購入者または元管理者が保持されている場合があります。マネージドサービスの責任があいまいな場合があります。アドバイザリは顧客ガバナンスへの入力ですが、修復が行われたという証拠ではありません。

しかし、予防に関する公開詳細は少ないです。Atlassian のFY2022 セキュリティインシデントレポートは、CVE-2022-26134 対応の調整をレベル1インシデントとして分類し、インターネットに面したインスタンスでの積極的な悪用に言及しています。アドバイザリと公開された問題は、脆弱性と修復を説明しています。関連するコードパスの完全な根本原因分析、既存の開発またはテスト管理がそれを検出しなかった理由、その後に行われた管理変更、またはそれらの変更の独立した検証を提供していません。

その欠如は、内部レビューが行われなかったことを証明するものではありません。外部の利害関係者が、パッチ対応と同じ精度で予防的管理対応を評価できないことを意味します。強力なインシデント後記録は、少なくとも5つの質問を分離する必要があります。どのコード動作がインジェクションパスを作成したか、いつメンテナンスブランチに導入されたか、どのレビューまたはテストがそれを検出すべきだったか、なぜ検出しなかったか、そしてどの測定可能な変更が現在同等の式言語パスをテストしているか。その説明がなければ、一般は製品学習の深さよりも反応速度をより確実に評価できます。

したがって、責任に関する調査結果は混合しています。Atlassian は、迅速なトリアージ、透明なアドバイザリ更新、広範なサポート対象修正、明確な顧客ガイダンスに対して、証拠に基づく評価に値します。公開記録は、根本的なセキュア開発管理が妥当であったか、不十分であったか、またはイベント後に実質的に改善されたかを判断するのに十分ではありません。発見後の速度は重要な説明責任の証拠ですが、予防を説明する代わりにはなりません。

リリースされたパッチは、修復された顧客環境ではない

ソフトウェアベンダーはしばしば、修正が出荷されたと報告します。顧客はしばしば、インストールが成功したときにチケットをクローズとして報告します。どちらのイベントも、組織全体でリスクが終了したことを証明しません。

第一に、顧客は分母を見つける必要があります。これには、本番、ディザスタリカバリ、ステージング、テスト、開発、移行、トレーニング、買収した会社、請負業者管理、一時的に停止したインスタンスが含まれます。すべての データセンター ノードとすべてのリバースプロキシルートが含まれます。DIVD のケース記録は、アドバイザリとパッチの後も通知が続いたため、明らかです。外部研究者は、所有者が修復していないか、露出に気づいていなかった脆弱なシステムをまだ特定できました。

第二に、顧客はバージョンとサポートステータスを確立する必要があります。Atlassian の影響範囲は、サポート対象および古いリリースに及びました。Unit 42 による6月3日の1,251台のインターネット露出サポート終了サーバーの推定は、明確なガバナンス問題を表していました。サポートされていない製品には、直接的で低リスクのアップグレードパスがない場合があります。そのオペレーティングシステム、Java ランタイム、データベース、アプリ、またはカスタムテーマも古い可能性があります。1つのパッチに見えるものが、マルチコンポーネントの移行になる可能性があります。

第三に、インストールはすべての関連コンポーネントに到達する必要があります。暫定緩和策では、顧客は Confluence を停止し、特定の JAR またはクラスファイルを置き換え、正しい所有権と権限を維持し、サービスを再起動し、すべてのクラスタノードでプロセスを繰り返す必要がありました。インストールディレクトリに残された古い JAR のコピーは、意図された変更を無効にする可能性があります。したがって、運用上の証拠には、管理者の回避策が試行されたという声明だけでなく、アーティファクト ID とノードカバレッジが含まれている必要があります。

第四に、接続を再評価する必要があります。内部にあると思われるサーバーでも、VPN、パートナールート、リモートアクセスゲートウェイ、アプリケーションリンク、クラウドロードバランサー、忘れられた DNS レコード、一時的なトラブルシューティングルールを介して到達可能な場合があります。Atlassian の FAQ は、一般的なインターネットアクセスの欠如は一般的なインターネットからの攻撃を無効にするが、アクセスパスはさまざまであるため、アップグレードを推奨すると慎重に述べています。「内部」はテストする仮説であり、永続的な資産特性ではありません。

第五に、修復の検証が必要です。NIST のエンタープライズパッチ管理計画ガイドは、更新の特定、優先順位付け、取得、インストール、検証を含むプロセスを定義しています。検証は可能な限り変更アクションから独立している必要があります。新しい認証済みインベントリ、パッケージまたはファイルハッシュ検査、アプリケーションヘルスチェック、本番に害を与えない脆弱性テスト、および検証が完了するまで古いルートが閉じたままであることのネットワーク確認です。

重要な指標は、発見されたインスタンスのパッチ適用率ではありません。それは、説明責任のある環境のうち、脆弱でない、隔離された、または削除された状態にある割合です。資産インベントリが不完全な場合、100%のパッチダッシュボードは数学的に正しくても、運用上は誤りである可能性があります。分母自体に保証が必要です。

パッチはエントリを停止できても、信頼を確立できるとは限らない

Atlassian の FAQ は、フォレンジックの中心的な限界を明確に述べています。Atlassian は個々の顧客インスタンスが侵害されたかどうかを確認できませんでした。ローカルのセキュリティ担当者または専門会社の関与を推奨し、攻撃者がシステム、監査、またはアクセスログを改ざんする可能性があると警告しました。この割り当ては回避的ではありませんでした。決定的な証拠は顧客環境に存在していました。

したがって、有用な対応は2つのワークストリームを分離しました。修復ワークストリームは、インスタンスを分離し、修正バージョンまたはサポート対象の緩和策をインストールし、結果を検証することにより、新たな悪用を防止しました。インシデントワークストリームは、歴史的な露出ウィンドウを調査し、結果に対処しました。これらを並行して実行することで、フォレンジックの完全性が封じ込めに先行しなければならないという危険な仮定を回避しつつ、後の結論を可能にする十分な証拠を保持しました。

調査ウィンドウは6月2日に開始できませんでした。Volexity はすでに前の週末に悪用を確認しており、Unit 42 は5月26日という早い時期に関連インフラからのスキャンを発見しました。慎重な組織は、利用可能な最も初期の信頼できる証拠から開始し、指標、欠落したログ、または異常な動作が正当化する場合には過去に拡大するでしょう。世界的な研究日付を自身の侵害の証明として扱うことはしません。

証拠収集は、観測された手法に適合する必要がありました。関連するソースには、リバースプロキシおよび Web アクセスログ、Confluence アプリケーションログ、認証および管理イベント、エンドポイントテレメトリ、プロセス作成、可能な場合はメモリ、ファイル整合性、スケジュールされたタスク、サービス変更、アウトバウンド DNS およびネットワークトラフィック、クラウドフローログ、ID プロバイダイベント、データベースアクセス、特権認証情報の使用が含まれます。リモートまたは保護されたログは、コマンド実行を持つ攻撃者がローカルファイルを変更できるため、特に価値がありました。

中小企業向け CISA のログガイダンスは、ログを不正アクセスや削除から保護し、ポリシーに従って保持し、技術、コミュニケーション、法務、継続性にわたってインシデント役割を割り当てるようアドバイスしています。CVE-2022-26134 は、これらが接続された管理である理由を示しています。ログ保持はセキュリティ運用の費用であるだけでなく、経営陣が後で「証拠が見つからなかった」と「証拠が保持されなかった」を区別できるかどうかを決定します。

侵害が発見された場合、または合理的に除外できなかった場合、信頼できるメディアからの再構築は、未知のホストをクリーンアップするよりも安全である可能性があります。Confluence サービスが利用可能な認証情報、設定に保存されたもの、データベースに使用されたもの、管理者が保持するもの、または Wiki コンテンツで公開されたものは、ローテーションが必要になる場合があります。接続されたシステムのレビューが必要になる場合があります。バックアップは整合性と、侵害された状態を保存している可能性についてチェックする必要があります。データ露出分析では、インスタンスに含まれるものと、サービスアカウントが到達できるものを考慮する必要があります。

これが、「24時間以内にパッチ適用」と「24時間以内に復旧」が異なる主張である理由です。前者はソフトウェアの状態によって証明される可能性があります。後者は、攻撃者の活動、データの整合性、ID、接続システム、ビジネス運用に関する証拠を必要とします。組織は、安全にオフライン、脆弱にオンライン、パッチ適用済みだが信頼できない、または復旧済みで信頼できる状態になります。責任あるダッシュボードは、これらの状態を赤と緑に減らすのではなく、維持します。

緊急パッチ適用は可用性インシデントでもあった

インシデント別の Atlassian アドバイザリは、クラスターを実行している顧客はダウンタイムなしで修正バージョンにアップグレードできないと述べました。この警告は、データセンター アーキテクチャが常に重要な更新をシームレスなローリング変更に変えるという安心感を打ち砕きます。より安全なソフトウェア状態には中断が必要でした。

Atlassian の一般的なローリングアップグレードドキュメントは、ゼロダウンタイムの適格性はソースとターゲットのバージョンに依存し、マルチノード データセンター クラスターが必要であり、別のノードがオフラインの間、アクティブなノードに十分な容量がなければならないことを説明しています。バックアップ、アップグレード前チェック、ステージング環境を推奨しています。これらは健全なプラクティスですが、ゼロデイはそれらを実行するために利用可能な時間を圧縮します。

シングルノードの顧客には、トラフィックを運ぶ2番目の Confluence ノードがありませんでした。一部はユーザーの前に静的メンテナンスページまたは読み取り専用エクスポートを配置できました。他の者は準備された代替手段を持っていませんでした。自動化を構築し、アップグレードをリハーサルし、バックアップをテストし、依存関係を文書化した組織は、不確実性が少なく、より迅速に行動できました。メンテナンスを時折の技術的作業として扱った組織は、緊急時に手順を発見する必要がありました。

選択肢は抽象的な「セキュリティか可用性か」ではありませんでした。継続的な露出は、攻撃者が破壊的なコマンド、ボットソフトウェア、暗号通貨マイナー、ランサムウェアを展開していたため、可用性も脅かしました。計画されたダウンタイムは、境界のある管理された中断を課しました。封じ込められていない侵害は、より長く、予測不可能なものを生み出す可能性がありました。管理目標は、ステータスページをどんな犠牲を払っても緑に保つことではなく、信頼できるサービスへの最も損害の少ないルートを選択することでした。

Atlassian のアップグレードハブと データセンター ガイダンスは、バックアップ、互換性、設定変更、アップグレード後チェックを強調しています。バックアップと復元のドキュメントも、「バックアップを取る」が完全な継続性管理ではない理由を示しています。バックアップ方法が異なれば目的も異なり、バックアップジョブは失敗する可能性があり、復元は現在のデータを上書きする可能性があり、再起動はタスクを中断する可能性があります。有用な復旧計画は、ファイルを数えるのではなく、復元をテストします。

知識プラットフォームの場合、継続性設計にはオフラインの最小運用セットを含める必要があります。インシデント連絡先、ID およびインフラストラクチャの復旧手順、ネットワーク図、ベンダーアカウントの詳細、意思決定権限、重要な顧客手順、Confluence 自体を復元するための手順です。そのコピーは保護され、最新であり、影響を受ける ID やアプリケーションパスなしでアクセス可能でなければなりません。すべてのページをエクスポートする必要はありません。分離中に運用するために必要な小さなセットを保存することが重要です。

中小企業が不均衡な継続性負担を負う理由

脆弱性は、同じ影響を受けるバージョンを実行している多国籍企業と小企業で技術的に同一でした。対応を吸収する能力は同一ではありませんでした。

大企業は、24時間のセキュリティ運用センター、構成データベース、ステージングクラスター、インフラ自動化、リテインドインシデント対応会社、アプリケーション所有者、ダウンタイムを承認する権限のある役員を持っているかもしれません。それでも失敗する可能性はありますが、専門的な能力を持っていました。小規模組織は、1人の管理者、外部委託プロバイダー、単一の本番ノード、限られたログ保持、テスト環境なし、主に何かが壊れたときに維持される Confluence インスタンスを持っているかもしれません。

その違いは、対応キューを生み出します。同じ人物が、アドバイザリを読み、信頼性を確認し、管理者に連絡し、サーバーを見つけ、バックアップを取得し、アップグレードをテストし、ユーザーに通知し、適用し、アプリをトラブルシューティングし、ログを検査し、プロバイダーと話し、アクセスを復元する必要があるかもしれません。各ステップは個別に合理的ですが、そのシーケンスは公開された悪用ウィンドウを超える可能性があります。パッチ時間の非対称性は、部分的には専門知識と調整の非対称性です。

NCSC 中小企業向け対応および復旧ガイドは、準備、特定、解決、報告、学習を中心に構築されています。ここでの関連性は実用的です。準備は決定を危機から外に移動させます。中小企業は、重要な悪用された脆弱性に対するインターネット分離を事前承認し、サプライヤーの連絡先を最新に保ち、インシデント前にフォレンジックプロバイダーを特定し、オフラインのラン ブックを維持し、一時的な停止を受け入れることができる人を定義できます。これらの管理のいずれもエンタープライズ規模を必要としません。

NIST のパッチプラクティスガイドは、構造的な対立を直接認識しています。パッチ適用はリソース集約的であり、システムの可用性を低下させる可能性があります。インベントリ、緊急緩和、分離、テスト、追跡、検証を同じ能力の一部として扱います。中小企業にとって、これはミニチュアエンタープライズプログラムではなく、控えめだが完全な設計を示唆しています。

実行可能な中小企業の管理セットには以下が含まれます。

1. 1つの説明責任のあるレジスタ。インスタンス URL、デプロイメント場所、製品とバージョン、ライセンスとサポートステータス、管理者、ビジネスオーナー、パブリックルート、認証依存関係、データベース、バックアップ方法、プロバイダー連絡先を記録します。サービスが変更されるたびにレビューします。
2. 事前承認された緊急しきい値。アクティブな悪用と認証されていないリモートコード実行が露出したインスタンスで発生した場合、通常の変更ミーティングを待たずに即時の制限またはシャットダウンを承認する必要があります。
3. テストされたメンテナンスパス。インストールメディア、構成記録、アプリ互換性情報、バックアップ手順、簡単な検証チェックリストをすぐに利用できるようにしておきます。少なくとも1回のアップグレードと復元をリハーサルします。
4. 代替の知識チャネル。インシデント対応と重要なサービス提供に必要な少数のドキュメントの保護されたオフラインまたは別途ホストされたコピーを維持します。
5. 時計付きのプロバイダー契約。MSP がサービスを運用する場合、誰がアドバイザリを監視するか、誰が切断できるか、応答時間と通知時間、証拠保持、時間外カバレッジ、緊急作業の支払い者を定義します。
6. リモート証拠。重要なログをアプリケーションホストから離れた場所に送信し、開示前のウィンドウを調査するのに十分な履歴を保持します。それらを取得できる人を知っています。
7. 再開の決定。サービスを信頼できると宣言できる人物を指名し、必要な証拠（修正バージョン、すべてのノードカバレッジ、ヘルスチェック合格、露出レビュー、侵害評価が合意されたレベルで完了、必要に応じて認証情報が対処された）を定義します。

現在のNCSC 脆弱性管理ガイダンスは、中小企業だけでなく大規模組織も対象としています。デフォルトでの更新、アクティブな悪用対応、資産識別、更新しない決定の上級管理者による所有、検証を強調しています。Confluence イベント後に更新されましたが、永続的なガバナンスモデルを捉えています。技術チームはリスクについて助言できますが、露出したままにする決定はビジネス上の決定であり、そのように可視化されるべきです。

中小企業の制限は、包括的な言い訳になるべきではありません。過剰な権限で実行されているインターネットに面したサポートされていない Wiki は、従業員数に関係なく回避可能なリスクです。しかし、説明責任は救済策を割り当てる際に能力を認識する必要があります。ベンダーは、明確なバージョンマトリックス、機械可読なアドバイザリ、検証済みアーティファクトハッシュ、簡潔な分離手順、サポート対象ホットフィックス、検出パッケージ、プロバイダー対応のコミュニケーションにより、顧客の負担を軽減できます。マーケットプレイスとマネージドサービスパートナーは、アプリの互換性とアップグレードの所有権を明確にできます。より優れた上流設計は、より平等な下流の安全性を生み出します。

クラウド依存関係、しかしクラウド侵害なし

CVE-2022-26134 は Atlassian Cloud に影響を与えませんでした。アドバイザリと FAQ の両方が、ホストされた Cloud インスタンスは保護されており、顧客の操作は不要であると述べています。この事実は中心に保たれなければなりません。このイベントを一般的な「Confluence 侵害」と表現すると、Atlassian が脆弱ではなかったと述べているサービスを誤って含めることになります。

それでも、このイベントは2つの理由でクラウドサービス依存関係分析に属します。第一に、Atlassian はホスト型と自己管理型の両方のデリバリーにまたがる製品を持つグローバルなコラボレーションプラットフォームプロバイダーです。組織は、運用管理が異なっていても、同じベンダーエコシステム、ワークフロー、アプリマーケットプレイス、ID リンク、知識プラクティスに依存しています。第二に、Cloud と自己管理の選択自体が管理の割り当てです。

Atlassian Cloud では、ベンダーはホストされた環境を一元的にパッチ適用でき、顧客は製品バージョンのアップグレードをスケジュールする必要がありません。顧客は、その運用集中と引き換えに、いくつかのインフラ管理を放棄します。Server および データセンター では、顧客はホスティング、ネットワーク露出、メンテナンスタイミング、ログ、および多くの統合を管理しますが、実行負荷も負います。「共有責任」は固定されたパーセンテージではなく、サービスモデルによって変化します。

Atlassian の現在のConfluence セキュリティ概要は、データセンター のセキュリティは共有されており、顧客をセキュリティチェックリストに誘導すると述べています。これは方向性として正しいですが、そのフレーズは名前付きのアクションと証拠に変換された場合にのみ有用になります。ベンダーは製品コードを修正します。顧客は修正を適用し、デプロイメントを保護します。ベンダーは正確な侵害ガイダンスを提供します。顧客はローカル証拠を保持および分析します。ベンダーは顧客のサーバーがクリーンであると安全に約束できません。顧客はベンダーの開発管理が再発を防止したことを独立して証明できません。

ホスト型サービスへの移行は緊急パッチの実行を減らすことができますが、普遍的な答えではありません。規制、居住、統合、パフォーマンス、カスタマイズ、または管理要件が自己管理をサポートする場合があります。Cloud はまた、集中化とプロバイダー可用性の依存関係を生み出します。ガバナンスの問題は、どちらのモデルが道徳的に優れているかではありません。組織が選択したモデルに伴う責任に資金を提供しているかどうかです。

責任は固有の制御と証拠に従うべき

説明責任モデルは、2つの簡単な失敗を避けるべきです。1つ目は、欠陥がコードにあったため、すべてをベンダーに割り当てます。2つ目は、パッチが存在したため、公開後のすべてを顧客に割り当てます。両方とも重要な管理を消去します。

この割り当ては、顧客がベンダーからの証拠を必要とする理由も説明します。「すぐにアップグレードせよ」というアドバイザリは行動を起こすのに十分ですが、製品ガバナンスを評価するには十分ではありません。エンタープライズバイヤーと公的機関は、機密または公開のインシデント後報告、セキュア開発の変更、独立した保証、検証済みレポートからサポート対象修正までの時間を合理的に要求できます。小規模バイヤーは個別にレバレッジを持つことはほとんどないため、標準的なベンダー透明性には分配的価値があります。

ベンダーは、サポートまたはインシデント分析が開始されるときに、顧客からの証拠を必要とします。正確なバージョン、ノード数、トポロジ、ログ、タイムスタンプ、変更、プラグイン、観測された指標は、製品欠陥をデプロイメント固有の影響から区別できます。「パッチを適用した」という漠然とした主張では、どちらの側もリスクを再構築できません。

責任は共有されても、希薄化されることなく共有できます。製品の欠陥は、顧客が Confluence を root として実行していた場合でも、Atlassian の責任のままです。root 権限は、攻撃者が Atlassian のコードを通じて侵入した場合でも、顧客の責任です。遅いパッチ適用は欠陥を消しません。迅速な修正は安全でない露出を消しません。各管理は同じ損失に寄与し、それでも異なる所有者を持つことができます。

信頼できるサービス復旧のための証拠パッケージ

取締役会と中小企業の所有者にとって、最も有用なアウトプットは大きな技術レポートではありません。それは、懐疑的な読者がアラートからクロージャまでの決定を追跡できるコンパクトな証拠パッケージです。

パッケージはスコープステートメントから始める必要があります。CVE-2022-26134、影響を受ける製品ファミリー、使用された権威あるアドバイザリバージョン、組織が最初に通知を受けた日付、対応責任者を指定します。すべての既知のインスタンスとノード（非本番システムおよび停止したシステムを含む）をリストし、そのリストが DNS、ロードバランサー、クラウドアカウント、ライセンス、外部スキャン、構成記録、プロバイダーデータとどのように調整されたかを説明します。

次に封じ込め記録です。各インスタンスについて、インターネットトラフィックがブロックされたかどうかとその時期、サービスが停止されたか、アクセスが制限されたか、暫定緩和策がインストールされたか、修正リリースがデプロイされたか、システムが削除されたかを示します。運用継続期間を承認した人物と存在した補償管理を記録します。例外には有効期限とエスカレーションパスが必要です。

変更記録は、変更前のバージョン、ターゲットバージョン、バックアップ結果、互換性チェック、メンテナンス開始と終了、アーティファクトの出所、変更された各ノード、再適用された構成、エラー、ロールバック決定、変更後のヘルスチェックをキャプチャします。Atlassian が修正リリースはローリングアップグレードの対象外と警告したため、記録には計画された停止とユーザーに伝えられた内容も示す必要があります。

検証記録は、オペレーターの記憶から独立した方法から得られるべきです。現在のバージョン出力、パッケージ ID、提供された場合のチェックサム、認証済みソフトウェアインベントリ、安全な脆弱性検証、外部到達可能性テスト、古いノードやイメージがサービスに戻っていないことの確認を含めることができます。クロージャを承認する人物は、分母と結果を見ることができる必要があります。

侵害評価は、調査期間、証拠ソース、保持ギャップ、クロック同期、テストされた指標と動作、調査結果、信頼度を記載します。「悪用の証拠は見つからなかった」と「侵害されていない」を区別します。ログが妥当な攻撃ウィンドウの後に開始された場合、その制限は隠すべき脚注ではなく、経営上の事実です。侵害が見つかった場合、パッケージは封じ込め、認証情報のローテーション、接続システムのレビュー、通知、再構築、復旧の決定にリンクします。

継続性記録は、どのビジネス機能がアクセスを失ったか、どの代替手段がアクティブ化されたか、重要な手順が利用可能であったかどうか、実際のダウンタイム、復旧後に必要なデータ調整、ビジネスオーナーの承認を特定します。スタッフが運用に必要な情報にアクセスできなかった場合、技術的なアップタイムだけでは不十分です。

最後に、再発防止計画は、日付付きの改善を割り当てます。典型的なアクションには、サポートされていないリリースの排除、管理されたアクセスの背後へのサービスの移動、不要な権限での Confluence の実行防止、ログの集中化、保持期間の延長、復元のテスト、ステージングパスの維持、ベンダー連絡先の更新、MSP の義務の明確化、オフラインラン ブックの作成、選択したホスティングモデルが依然として組織の能力に適合しているかのレビューが含まれます。

このパッケージは、後知恵バイアスに対する防御でもあります。各決定時点で何が知られていたかを記録します。6月2日、顧客は積極的な悪用を知っていましたが、まだリストされた修正バージョンを持っていませんでした。直ちに隔離する決定は、6月3日以降に待つ決定とは異なる評価が可能です。優れた記録はその違いを保持します。

非対称性を隠すのではなく、暴露する指標

一般的な「平均パッチ適用時間」指標は、脆弱性レコードがツールに入力され、インストールが報告されたときに終了します。このインシデントで最も説明責任を負った部分を見逃しています。

より良いセットには以下が含まれます。

• ベンダーの報告からアドバイザリまでの時間:検証済みの外部報告から実行可能な公開警告まで、サポート対象修正までの別個の時間。
• 通知から所有者までの時間:権威ある公開から技術およびビジネス所有者による確認まで。
• インベントリ調整時間:通知からすべてのインスタンス、ノード、ルートの防御可能なリストまで。
• 封じ込めまでの時間:通知から既知のすべての露出インスタンスの隔離または効果的な緩和まで。
• 検証済み修復までの時間:通知から、説明責任のある環境が修正、隔離、または削除されたという独立した証明まで。
• 侵害判断までの時間:通知から、記載された証拠の限界を持つ文書化された結論まで。
• 信頼できる復旧までの時間:封じ込めから、安全で使用可能なサービスに対するビジネスオーナーの承認まで。
• 未勘定の環境:所有者と検証済み状態にマッピングされていない、外部で観測またはライセンスされたデプロイメント。
• 証拠カバレッジ:必要なログとテレメトリが存在する調査ウィンドウの部分。
• 継続性パフォーマンス:実際の中断、フォールバックアクティベーション時間、維持された重要な機能。

これらの測定は、ベンダーの迅速なリリースが下流の負担を隠蔽するのを防ぎ、顧客の成功したインストールが欠落した証拠を隠蔽するのを防ぎます。また、調達にも役立ちます。機械可読なアラートと優れた検出サポートを備え、数時間で確実にアップグレードできるプラットフォームは、特別な週末作業を必要とするものとは異なるライフサイクルコストを課します。

指標は、安全なダウンタイムを選択したチームを罰するために使用されるべきではありません。パフォーマンス目標が可用性に報いる一方で、認証されていない RCE が露出したままの場合、誤った行動を生み出します。計画された隔離は、代替手段が制御不能な侵害である場合、制御の成功です。品質の質問は、中断が予見され、承認され、伝達され、テストされた目標内で復旧されたかどうかです。

記録が証明することと、証明しないこと

公開記録は、いくつかの信頼性の高い調査結果を支持しています。CVE-2022-26134 は、Confluence Server および データセンター における重大な、認証されていないリモートコード実行でした。Atlassian Cloud は影響を受けませんでした。公開開示前に悪用が発生しました。Volexity は5月31日に Atlassian に通知しました。Atlassian は6月2日にアドバイザリを公開し、6月3日に修正バージョンをリリースしました。CISA は6月6日の期限でこの脆弱性を KEV に配置しました。公開悪用は急速に拡大しました。インシデント固有の修正には、ローリングアップグレードではなくダウンタイムが必要でした。パッチは顧客がすでに侵害されているかどうかを判断できませんでした。

その他の結論には抑制が必要です。記録は、脆弱な組織、成功した侵害、データ損失、または停止の検証済みの世界規模の数を提供していません。Unit 42 の19,707という数字は、確認された被害者ではなく、潜在的に影響を受けるインターネット可視サーバーを説明していました。DIVD の通知は、特定された脆弱なインスタンスを説明していましたが、必ずしも固有の企業や悪用されたホストではありませんでした。GreyNoise は、そのセンサーネットワークで見られたリクエストを測定しましたが、すべての Confluence サーバーに対する攻撃ではありませんでした。

記録はまた、Atlassian がいつ合理的に欠陥を発見できたか、なぜリリース前管理から逃れたか、特定の以前のテストが確実に発見したかどうか、またはどのような内部是正措置が完了したかを確立していません。影響を受けるバージョンの履歴は、根本原因調査の代わりにはなりません。また、顧客の迅速なパッチ適用は、パッチ前にデータがアクセスされなかったことを証明しません。

2022年に日常的に悪用された脆弱性に関する共同アドバイザリは、この脆弱性の継続的な脅威の関連性を確認しています。すべてのパッチ未適用インスタンスが侵害されたことを確立するものではありません。これらの限界についての正確さは、それ自体のための注意ではありません。それは、ヘッドラインの算術ではなく、証拠に説明責任を結び付け続けます。

説明責任の調査結果

Atlassian の CVE-2022-26134 への緊急対応は、一般が測定できる側面において実質的に強力でした。迅速な確認、迅速な警告、アクティブな悪用の表現、メンテナンスブランチ全体の修正リリース、暫定緩和策、更新ログ、Cloud のスコーピング、サポートガイダンス。最も重要な未解決のベンダー質問は、ライフサイクルのより早い段階にあります。公開記録は、予防的管理の失敗を説明していないか、インシデント後のセキュア開発の変更の深さを評価するのに十分な証拠を提供していません。

顧客は隠れた欠陥を制御できませんでしたが、コラボレーションサーバーがインターネットに面しているか、過剰な権限で実行されているか、サポートされていないままであるか、現在の所有者がいるか、耐久性のある証拠を生成するか、重要な運用知識を失うことなく停止できるかを制御しました。これらの制御は、ベンダーの欠陥が一時的な管理された中断、証明不可能な露出、またはより広範な侵害になるかどうかを決定しました。

中小企業にとって、このイベントは内部の問題だけでなく、市場設計の問題も露呈しています。パッチはすべての顧客が利用可能でしたが、安全に消費する能力は平等ではありませんでした。責任あるベンダーとパートナーエコシステムは、摩擦の少ないアップグレード、実行可能な通知、サポート対象の緩和策、検出ガイダンス、明確なサービスプロバイダーの義務を通じて、そのギャップを減らすべきです。責任ある顧客は、その管理が伴うメンテナンスとインシデント作業に予算を計上せずに、自己管理の制御を購入すべきではありません。

最終的なテストは単純です。パッチが出荷された後、次に何が起こったかを証明できるのは誰か？Atlassian は何を修正し、いつ修正をリリースしたかを証明できました。各顧客だけが、どのシステムが存在したか、いつ隔離されたか、攻撃者が侵入したかどうか、どのビジネス機能が中断されたか、なぜサービスを復元しても安全かを証明できました。リスクはその証拠のギャップに存続しました。それを埋めることが説明責任の本当の仕事です。