Qlik はアナリティクスサーバーを管理ソフトウェアの信頼境界問題にした

要約

• Qlik Sense Enterprise for Windows の脆弱性は、分析プラットフォームがエッジセキュリティシステムのメンタルモデルの外側にありながらビジネスデータを集中させるため、説明責任のテストとなった。
• Qlik は公式の高重要度および重大なセキュリティ修正を発行した。NVD 記録、CISA KEV の文脈、およびセキュリティ研究者は、脆弱性セットをパッチの緊急度と露出管理に関連付けた。
• 後日、ディフェンダー報告は Qlik Sense の脆弱性の悪用を CACTUS ランサムウェアの活動に結び付け、問題を理論上のパッチノート以上のものにした。
• 説明責任は共有されている。Qlik は勧告、パッチ、緩和策、および製品ガイダンスを管理した。顧客は露出インベントリ、パッチ展開、セグメンテーション、ロギング、および侵害評価を管理した。
• 信頼できる修復記録は、パッチ適用バージョンだけでなく、どの露出したサーバーが見つかったか、どのサーバーが侵害についてチェックされたか、どのデータパスがレビューされたか、そして分析プラットフォームがベンダーリスクおよびインシデント対応ルーチンにどのように組み込まれたかを示すべきである。

分析ソフトウェアは隠れたエッジシステムになり得る

Qlik Sense Enterprise for Windows はビジネス分析プラットフォームであり、ファイアウォールや VPN アプライアンスではない。この違いは危険なメンタルモデルを生み出す可能性がある。組織は分析サーバーを、たとえネットワーク境界を越えてユーザー、パートナー、管理者から到達可能であっても、内部レポートシステムとして扱うことがある。分析サーバーが露出し、認証され、統合され、ビジネスデータに接続されている場合、それは組織の信頼境界の一部として機能する。脆弱性管理はそれに応じて扱うべきである。

Qlik の公式勧告が出発点となる。同社はQlik Sense Enterprise for Windows の高重要度セキュリティ修正、重大なセキュリティ修正、および同じ脆弱性クラスターにおける別の高重要度セキュリティ修正を公開した。これらの勧告は、顧客が迅速に解釈する必要があるバージョンと修復のガイダンスを提供した。

CVE-2023-41265、CVE-2023-41266、CVE-2023-48365の NVD 記録は、公開脆弱性カタログを提供する。NVD は全体像を語らず、ベンダーに遅れることもあるが、顧客や監査人が勧告を標準化された記録に結び付けるのに役立つ。組織が CVE、スキャナー、チケットシステム、パッチダッシュボードでトリアージすることが多いため、記録は重要である。

説明責任の問題は、勧告の発行がリスク軽減とイコールではないことである。ベンダーは修正を公開できるが、顧客は影響を受けるソフトウェアを実行しているか、露出しているか、パッチがクリーンに適用されるか、緩和策が必要か、ログが悪用を示すか、ダウンストリームデータがアクセスされたかを知らなければならない。分析プラットフォームの場合、その作業にはビジネスインテリジェンスチーム、IT 管理者、セキュリティ運用、データ所有者、マネージドサービスパートナーが関与する可能性がある。

Qlik のケースは、組織が分析サーバーが VPN、ファイアウォール、ID プロバイダー、公開 Web アプリケーションと同じ脆弱性管理インベントリにあるかどうかを問うことを強制するため有用である。そうでない場合、組織は信頼境界の盲点を持つことになる。

パッチチェーンは順序の責任を生み出す

公開 Qlik 勧告記録は複数の CVE と修正を含んでいた。これにより順序リスクが生じる。顧客は1つのパッチをインストールして問題が解決したと思い込むかもしれないが、別の関連修正が必要である。高重要度の通知を読んで後で重大な通知を見逃すかもしれない。1つの CVE を検出するスキャナーに依存するが、チェーン全体を検出しないかもしれない。テストやダウンタイムが重要な複雑な環境を更新する必要があるかもしれない。各ステップで部分的な修復の機会が生じる。

Rapid7 の緊急脅威対応 (CVE-2023-41266 および CVE-2023-41265 Qlik Sense Enterprise の脆弱性) は、防御者が脆弱性と修復パスを解釈するのに役立った。Tenable の概要 (Qlik Sense の重大な脆弱性) は、CVE を結び付け、パッチ適用を強調した。Praetorian の技術的エクスプロイト分析は、防御者が CVE ラベルだけでなくチェーンを理解する必要がある理由を示した。

ここでベンダーのコミュニケーションが重要になる。強力な勧告は、修正バージョンのリスト以上のことを行う。実用的な顧客の質問を説明する：これらのバージョンを実行している場合は、これらの手順を実行する；以前のパッチを適用した場合は、これを確認する；サーバーが露出している場合は、これを優先する；すぐにパッチを適用できない場合は、この緩和策を使用する；悪用が疑われる場合は、これらのログを収集し、これらの指標を調査する。問題がチェーンを含むほど、顧客は決定木を必要とする。

顧客には独自の順序義務がある。勧告の言葉をインベントリ、チケット、変更ウィンドウ、テスト、ロールバック計画、侵害評価に変換しなければならない。セキュリティチームが「Qlik CVE」に対して1つのチケットを開くと、運用の現実を見逃す可能性がある。より良いプロセスは、影響を受けるサーバー、露出、バージョン、パッチステータス、緩和ステータス、ログレビュー、データ所有者通知、最終検証を追跡する。

管理証拠はパッチウィンドウを生き残るべきである。数ヶ月後、監査人やインシデント対応者は、どの Qlik システムが存在したか、どのシステムが露出していたか、いつパッチが適用されたか、悪用がチェックされたか、残留リスクが受け入れられたかを見ることができるはずである。その証拠がなければ、「パッチ適用済み」は単なる主張にすぎない。

悪用によりリスクが理論から運用に変わった

CISA の既知の悪用された脆弱性カタログは、実際に悪用された脆弱性に関する一般的なリファレンスである。組織が CISA の期限に直接拘束されているかどうかに関わらず、KEV 的な思考は重要である：悪用が観測された場合、パッチの優先順位が変わる。露出、悪用可能性、積極的な使用は、通常のカレンダーベースのパッチ適用よりも優先される。

Arctic Wolf は、CACTUS ランサムウェアが Qlik Sense の脆弱性を悪用しているのを観測したと報告した。SecurityWeek はランサムウェアグループによって悪用された Qlik Sense の脆弱性をカバーし、BleepingComputer はCACTUS ランサムウェアが初期アクセスに Qlik Sense を悪用したと主張したと報じた。これらの報告は問題をパッチ衛生からインシデント準備に変えた。

悪用が可能であるか観測された場合、顧客はバージョンチェックで止まるべきではない。脆弱な期間中にサーバーが到達可能であったかどうか、Web ログが不審なリクエストを示すかどうか、サービスアカウントが悪用されたかどうか、ファイルやスケジュールタスクが変更されたかどうか、データエクスポートが発生したかどうか、横方向の移動が続いたかどうか、サーバーが機密ビジネスデータセットにアクセスしていたかどうかを問うべきである。必要なら先にパッチを適用し、しかし調査も行う。

これは分析プラットフォームにとって特に重要である。なぜなら多くのデータソースに接続することが多いからである。プラットフォームはすべてのデータを永続的に保持しないかもしれないが、資格情報、コネクタ、キャッシュ抽出、ダッシュボード、ユーザーアクセスパスを持つことがある。分析インフラを侵害した攻撃者は、初期脆弱性が「単なる」Web アプリケーションの問題であっても、ビジネスデータのマップを得る可能性がある。

したがって、悪用が観測された後の説明責任の問いは、顧客が脆弱な分析サーバーを可能な初期アクセスポイントとして扱ったかどうかである。扱わなかった場合、侵入者が入った後に組織がドアにパッチを当てた可能性がある。ベンダーのガイダンスは、顧客に侵害評価が必要であることを明示することで役立つ。

公開アプリケーションの悪用はよく知られたパターンである

MITRE ATT&CK の公開アプリケーションの悪用技術は、攻撃者が露出したアプリケーションを初期アクセスに悪用する方法を説明する。Qlik Sense は到達可能な方法で展開された場合にそのパターンに適合する。この技術は一般的である。なぜなら組織はビジネスアプリケーションをユーザーに公開する一方で、攻撃者がどのくらい迅速に脆弱なバージョンをスキャンするかを過小評価するからである。

問題は Qlik に固有ではない。VPN、ファイル転送ツール、ID サービス、Web シェル、コラボレーションプラットフォーム、管理コンソールで現れる。Qlik のケースはそのファミリーに属する。分析サーバーは境界インフラのように見えないかもしれないが、保護されたセグメントの外部からリクエストを受け入れる場合、境界リスク管理に属する。

公開アプリケーションの露出はパッチの緊急度も変える。強力な制御下の内部専用サーバーは、インターネット露出サーバーとは異なるリスクを持つ可能性がある。顧客はすべての Qlik インスタンスを均等に扱うべきではない。露出、データ感度、認証、ネットワークセグメンテーション、利用可能なログによって分類すべきである。その分類がパッチ順序と侵害評価を駆動すべきである。

ベンダーは露出ガイダンスを明示することでこれをサポートできる。どの展開モードがよりリスクが高いか？どのエンドポイントが関連するか？どのバージョンが緊急のパッチ適用を必要とするか？どのログがエクスプロイト試行を示すか？どの緩和策が一時的に露出を減らすか？どの製品構成を公衆インターネットから到達可能にしてはいけないか？顧客は具体的な回答を必要とする。なぜなら分析プラットフォームのビジネスオーナーはセキュリティ専門家ではない可能性があるからである。

公開アプリケーションのリスクはマネージドサービスパートナーにも影響する。パートナーが顧客のために Qlik をホストまたは維持する場合、パートナーはパッチ展開と時には露出を制御する。顧客はパートナーがすべてのインスタンスを見つけ、パッチを適用し、ログをチェックしたかどうかを知る必要がある。マネージド分析サービスは運用作業を移管できるが、不透明性を移管すべきではない。

データ所有者はインシデントに席を持つ必要がある

分析プラットフォームが脆弱な場合、セキュリティチームはエクスプロイトパスとサーバーの整合性に焦点を当てるかもしれない。データ所有者は、プラットフォームが見ることができるものを理解しているため、インシデントに席を持つ必要がある。侵害された分析サーバーは、収益、顧客、健康、運用、財務、サプライチェーン、セキュリティ指標、従業員データに関するダッシュボードを持つ可能性がある。リスクは接続されたデータに依存し、サーバー自体だけではない。

インシデント対応プロセスは、接続されたデータソース、サービスアカウント、キャッシュされたデータセット、エクスポートログ、ダッシュボード権限、最近のクエリアクティビティを特定すべきである。どのビジネスユニットがプラットフォームに依存しているか、データ露出通知が必要かどうかを問うべきである。データ所有者は、あるダッシュボードは無害で、別のダッシュボードは規制情報を含んでいることを知っているかもしれない。その知識がなければ、対応者はリスクを過小または過大評価する可能性がある。

同じ問題が資格情報にも適用される。分析プラットフォームはデータベース、データウェアハウス、API にクエリを実行するためにサービスアカウントを使用することが多い。分析サーバーが侵害された場合、それらの資格情報のローテーションが必要になる可能性がある。サービスアカウントが広範な読み取りアクセスを持つ場合、ブラスト半径は Qlik サーバー自体よりも大きくなり得る。したがって、分析コネクタの最小権限は脆弱性予防の一部である。

データ所有者は復旧優先順位にも参加すべきである。一部のダッシュボードは日々の運用をサポートする。他のものは四半期報告をサポートする。パッチ適用や隔離にダウンタイムが必要な場合、優先順位はビジネス影響とデータ感度を反映すべきである。セキュリティのみの決定はサーバーを迅速に隔離するかもしれない。ビジネスのみの決定はパッチ適用を遅らせるかもしれない。成熟した決定は両方を使用する。

インシデント後、組織は分析プラットフォームがデータガバナンスとセキュリティガバナンスマップに含まれているかどうかをレビューすべきである。Qlik が重要なデータへのパスである場合、重要なアプリケーションインベントリに含まれるべきである。含まれていない場合、それはガバナンスのギャップである。

パッチ管理には露出を意識した優先順位付けが必要である

NIST SP 800-40 Revision 4、エンタープライズパッチ管理計画のガイドは、一般的なパッチ管理ガイダンスを提供する。FIRST の悪用予測スコアリングシステムは悪用の確率コンテキストを提供する。これらのツールは役立つが、Qlik のケースはグローバルシグナルをローカル露出と組み合わせる必要があることを示している。CVE スコアや悪用確率は、組織の Qlik サーバーがインターネットから到達可能か、クラウンジュエルデータに接続されているか、監視されているかを知らない。

露出を意識した優先順位付けは実用的な質問をする。影響を受ける Qlik サーバーは公開されているか？パートナーネットワークから到達可能か？VPN の背後にあるか？ログは有効か？シングルサインオンを使用しているか？機密データベースに接続しているか？バックアップは利用可能か？マネージドサービスプロバイダーがパッチ適用を担当しているか？悪用がグローバルに観測されているか？緊急緩和策はあるか？

回答はアクションを駆動すべきである。ランサムウェアに悪用された脆弱性セット内の公開、脆弱、データ接続されたサーバーは緊急対応に移行すべきである。隔離された制御下のラボサーバーは依然としてパッチ適用が必要かもしれないが、露出した本番システムほど優先順位は高くない。このアプローチはパニックと自己満足の両方を回避する。

パッチ管理には証拠も必要である。パッケージがインストールされたためにクローズとマークされたチケットは弱い証拠である。より強い証拠には、バージョン検証、サービスの再起動確認、外部スキャン結果、ログレビュー、悪用チェック結果、コネクタ資格情報レビュー、ビジネスオーナーの承認が含まれる。分析ソフトウェアの場合、証拠にはデータアクセスの影響を含めるべきである。

ベンダーは明確な検出および検証手順を公開することで証拠を改善できる。顧客はどの修正バージョンをインストールするかだけでなく、露出しなくなったことを確認する方法と、侵害の兆候を探す方法を知る必要がある。勧告の品質は顧客の修復品質に直接影響する。

ランサムウェアの枠組みは経営陣の説明責任を変える

CACTUS ランサムウェアの報告は経営陣の会話を変えた。ビジネス分析の脆弱性はソフトウェアの欠陥としてフレーム化されると延期しやすい。防御者がランサムウェアの悪用を報告すると延期しにくくなる。ランサムウェアはパッチ問題をビジネス中断、データ窃取、恐喝、復旧コストに変える。

CISA のStopRansomware ガイドは一般的な準備と対応のガイダンスを提供する。Qlik に適用すると、脆弱な分析サーバーをセグメンテーション、バックアップ、ID、監視、インシデント対応、復旧計画で考慮すべきであると示唆する。脆弱な公開アプリケーションはランサムウェアイベントの最初のドミノになり得る。

したがって、経営陣の説明責任には分析資産を含めるべきである。取締役会はしばしばエンドポイント保護、メールセキュリティ、バックアップ、ID について尋ねる。また、どのビジネスアプリケーションが露出し脆弱であるか、どのアプリケーションが積極的に悪用されているか、どのアプリケーションが機密データに接続しているかも尋ねるべきである。分析プラットフォームはセキュリティ重要とブランド化されていないかもしれないが、露出とデータアクセスを通じてセキュリティ重要になり得る。

最高情報セキュリティ責任者は問題全体を単独で所有できない。分析プラットフォームオーナー、インフラチーム、データ所有者、調達、法務、事業継続リーダーはすべて役割を持つ。Qlik パッチにダウンタイムが必要な場合、ビジネスリーダーはリスクトレードオフを承認しなければならない。侵害が疑われる場合、法務とデータ所有者は通知義務を評価しなければならない。マネージドプロバイダーが責任を負う場合、調達とベンダー管理は証拠を強制しなければならない。

ランサムウェアの枠組みはコミュニケーションにも影響する。顧客や内部関係者が脆弱性がランサムウェアグループによって使用されていることを知っている場合、より明確な緊急性が必要になる可能性がある。曖昧な勧告はビジネスユニットにダウンタイムを承認させるのに十分でないかもしれない。攻撃パス、露出、潜在的な結果の具体的な説明ができる。

残留未知数と説明責任の問い

公開記録は、影響を受けたすべての Qlik 顧客、すべてのエクスプロイト試行、すべてのパッチ遅延、または Qlik の内部勧告決定プロセスを示していない。露出したすべてのサーバーが侵害されたことを証明していない。脆弱なインスタンスに接続されたすべてのデータソースを特定していない。各顧客が資格情報をローテーションしたりログをレビューしたりしたかどうかを示していない。これらのギャップは認識されるべきである。

知られていることは説明責任を定義するのに十分である。Qlik は Qlik Sense Enterprise for Windows の脆弱性に対するセキュリティ修正を公開した。公開 CVE 記録とセキュリティ研究者はエクスプロイトチェーンとパッチ要件を説明した。ディフェンダーと報道は悪用をランサムウェア活動に結び付けた。露出した Qlik Sense システムを実行している顧客は、パッチを適用し、調査し、分析サーバーが初期アクセスポイントとして放置されていないことを証明する必要があった。

説明責任の問いは、ベンダーと顧客が勧告公開を検証済みのリスク軽減に変えたかどうかである。Qlik にとって、それは明確な勧告、迅速なパッチ、緩和ガイダンス、検出サポート、およびチェーンリスクを説明する顧客コミュニケーションを意味する。顧客にとって、それは露出インベントリ、パッチ展開、侵害評価、データ所有者の関与、資格情報レビュー、監視を意味する。マネージドプロバイダーにとって、それは約束ではなく証拠を意味する。

Qlik のケースは管理ソフトウェアの信頼境界問題として記憶されるべきである。ビジネス分析プラットフォームは組織がその運用を見るのを助けるため信頼されている。プラットフォーム自体が露出し、ガバナンスが不十分な場合、その信頼は危険になる。修復は単なるバージョン番号ではない。それは分析サーバーがインベントリされ、パッチ適用され、監視され、セグメント化され、機密ビジネスデータへのパスを開くか閉じるシステムとしてレビューされる運用モデルである。

インベントリは最初の制御であり、後付けのスプレッドシートではない

多くのエンタープライズ脆弱性インシデントで最も難しい部分は、パッチをインストールすることではない。脆弱なソフトウェアが実行されているすべての場所を発見し、それらのどの場所が攻撃者に到達可能かを決定することである。Qlik Sense の展開は、中央 IT、ビジネスインテリジェンスチーム、地域オフィス、ラボ、マネージドサービス環境、パートナー向けポータル、またはリクエストに応答し続ける忘れられた仮想マシンに存在する可能性がある。インベントリが不完全であれば、その後のすべての制御は部分的に仮想的なものになる。

説明責任のあるインベントリはホスト名とバージョン以上のものを記述すべきである。所有者、環境、露出、認証パス、データ接続、サービスアカウント、バックアップ状態、ロギング状態、サポート契約、パッチウィンドウ、ビジネス依存関係を示すべきである。また、緊急ダウンタイムを承認できる者も示すべきである。脆弱な公開分析サーバーが緊急修正を必要とする場合、対応者は最初の1時間を誰が所有しているかを尋ねるのに費やすべきではない。その1時間は封じ込め、検証、コミュニケーションに属する。

ここで CISA の広範なセキュアバイデザインフレーミングが有用である。セキュアバイデザインの説明責任は、ベンダーと顧客にデフォルトリスクを減らすよう求め、すべての運用複雑性をエンドユーザーに押し付けない。Qlik にとって、これはベンダーがすべての顧客展開を知ることができるという意味ではない。製品設計、文書、インストーラーの動作、管理インターフェース、バージョンの可視性、更新ガイダンスが、顧客が脆弱なシステムを見つけて修復するのを容易にすることを意味する。顧客が露出を確立するために複数のコンソール、コミュニティ通知、チケットシステム、スキャナー出力、サーバーシェルを検索する必要がある場合、制御負荷は高い。

顧客にとって、分析インベントリは資産管理に統合され、非公式のビジネスユニットリストとして保持されるべきではない。収益ダッシュボードを生成するサーバーは、財務システムと同様に運用上重要である可能性がある。本番データに接続する場合、インベントリはデータガバナンスに接続すべきである。エンタープライズ外部から到達可能な場合、インベントリは攻撃表面管理に接続すべきである。ベンダーまたはパートナーが管理する場合、インベントリはベンダーリスク記録に接続すべきである。Qlik のエピソードは、これらのマップがインシデント中ではなく、インシデント前に会合すべき理由を示している。

インベントリは経営陣とのコミュニケーションにも影響する。取締役会や監査委員会は、「Qlik パッチが適用されています」という文から露出を判断できない。いくつのインスタンスが存在するか、いくつが脆弱であったか、いくつが公開されていたか、いくつが機密データアクセスを持っていたか、いくつがパッチ適用されたか、いくつが侵害についてチェックされたか、どの例外が残っているかを知る必要がある。これはすべてのホスト名を開示する必要はない。技術作業を説明責任のあるステータスに変換する必要がある。

検出にはアプリケーション、ID、データシグナルを含める必要がある

パッチ適用は将来の悪用リスクを減らすが、過去の悪用がなかったことを証明しない。検出は適切な層を調べる必要がある。Qlik Sense の脆弱性の場合、関連する証拠には Web サーバーログ、Qlik アプリケーションログ、Windows イベントログ、リバースプロキシログ、エンドポイントテレメトリ、サービスアカウントアクティビティ、管理者アクション、ファイルシステムの変更、不審なプロセス作成、異常なエクスポート、コネクタアクティビティ、ID プロバイダー記録が含まれる可能性がある。単一のログソースが全容を語るわけではない。

NIST のコンピュータセキュリティインシデント処理ガイドは、検出と分析をチェックボックスではなくプロセスとして扱うため、ここで有用である。インシデント対応者は指標を収集し、範囲を決定し、インシデントを分類し、影響を受けるシステムを封じ込め、証拠を保存し、イベントから学ぶ。Qlik の文脈では、そのプロセスにはビジネスデータの質問を含めるべきである。純粋なインフラ対応は、サーバーがパッチ適用され再起動されたことを確認するかもしれないが、資格情報、ダッシュボード、キャッシュ抽出、接続されたデータベースが触られたかどうかを見逃す可能性がある。

MITRE ATT&CK のアプリケーション層プロトコルと有効なアカウント技術は、分析プラットフォームのインシデントがエクスプロイトと悪用のパスをぼやけさせる理由を説明するのに役立つ。攻撃者は公開脆弱性から始め、次に正当なサービス動作、資格情報、スケジュールタスク、またはアプリケーション機能を使用して、エクスプロイトから永続的またはデータアクセスに移行する可能性がある。証拠は劇的なマルウェアイベントのように見えないかもしれない。異常なエクスポート、新しいタスク、変更されたファイル、奇妙な時間にデータベースに到達するサービスアカウント、またはまとめて見たときにのみ意味をなす Web リクエストチェーンに見えるかもしれない。

したがって、検出にはアプリケーションを理解する人々を含めるべきである。セキュリティ運用スタッフは不審なプロセスとネットワーク動作を特定できるが、Qlik 管理者はどのリクエストが正常か、どのコネクタが機密か、どのリロードタスクが重要か、どのダッシュボードが異常な権限を持つかを知っているかもしれない。データ所有者はエクスポートパターンがリスクがあるかどうかを知っているかもしれない。ID チームはシングルサインオンログが異常なセッションを示すかどうかを知っているかもしれない。協調的なレビューは一人のチケットクローズより遅いが、より信頼性が高い。

保持問題もある。ログが迅速にローテーションされる場合、顧客は悪用を判断するために必要な証拠を失う可能性がある。脆弱な期間後に知られるようになる脆弱性勧告は、関連ログがすでになくなった時点で到着する可能性がある。そのため、高価値のビジネスアプリケーションは、インシデント対応の現実に一致する保持ポリシーを必要とする。問題はすべてのログを永久に保持できるかどうかではない。深刻な勧告の後に、このシステムが露出していたか、不審にアクセスされたか、攻撃者が認証したか、データが移動したか、横方向の移動が続いたかといった可能性のある質問に組織が答えられるかどうかである。

マネージドサービスは証拠を求める顧客の義務を消さない

多くの組織は、分析プラットフォームをホスト、管理、監視、またはパッチ適用するためにパートナーに依存している。そのモデルは、パートナーがより深い専門知識を持つ場合、運用の質を向上させることができる。また、顧客が深刻な脆弱性の後に安心させるだけの文しか受け取らない場合、説明責任のギャップを生み出す可能性がある。「環境はパッチ適用されました」は有用だが、悪用が公に報告され、プラットフォームが重要なデータに接続する可能性がある場合は十分ではない。

顧客はリスクに比例した証拠を求めるべきである。低感度の内部分析サンドボックスの場合、証拠は単純でよい。顧客、財務、運用データセットに接続された露出した本番サーバーの場合、証拠には影響を受けるインスタンスのインベントリ、バージョン検証、露出評価、パッチタイミング、緩和タイミング、ログレビューの範囲、侵害評価の結果、資格情報ローテーションの決定、データ所有者の通知、残留例外を含めるべきである。プロバイダーは、説明責任のある証拠を提供するために機密内部詳細を明らかにする必要はない。

調達には役割がある。なぜなら、これらの証拠期待の多くはインシデント前に契約に含まれる必要があるからである。契約は、セキュリティ通知のタイミング、緊急パッチ権限、顧客のログへのアクセス、インシデント協力義務、証拠形式、データの返却または削除義務、重要な修正のためのサービスレベル期待を定義できる。これらの条件がなければ、顧客はインシデント中に、パートナーが環境を制御しているが、顧客が自らの規制当局、保険会社、監査人、顧客のために必要な証拠を提供する義務を負っていないことを発見する可能性がある。

ベンダーリスクチームは、一度きりのアンケート思考も避けるべきである。脆弱性の数ヶ月前に行われたアンケートは、現在の修復状態についてほとんど教えない。より良い制御はイベント駆動型である：積極的に悪用された脆弱性がサービスのソフトウェアに影響を与える場合、パートナーはインシデント固有の証明を提供する。製品、影響を受けるバージョン、展開範囲、露出、修復ステータス、調査ステータス、次のステップを特定すべきである。これは官僚的な書類ではない。これは委任された運用と保持された説明責任の間の橋渡しである。

Qlik のケースは、マネージドサービス顧客がデータアクセスのマップを必要とする理由も示している。パートナーは分析サーバーを運用するかもしれないが、接続されたデータセットの完全なビジネス意味を知らないかもしれない。顧客はデータを理解するかもしれないが、パッチウィンドウを制御しないかもしれない。インシデント中、両方の知識が必要である。それらが接続されていない場合、対応は技術的にクリーンで、実質的に不完全になる可能性がある。

パッチ後のガバナンスは運用モデルを変えるべきである

緊急パッチと調査が完了したら、組織はインシデントを運用モデルに関する証拠として扱うべきである。資産インベントリに分析プラットフォームが含まれていたか？脆弱性管理プロセスは Qlik を迅速に特定したか？スキャナーは影響を受けるバージョンを検出したか？ビジネスオーナーは緊急時の役割を知っていたか？ログは侵害評価をサポートしたか？データ所有者は参加したか？マネージドサービスプロバイダーはタイムリーな証拠を提供したか？経営陣は公的なランサムウェア報告が注意を強制する前にリスクを理解していたか？

NIST のサイバーセキュリティフレームワーク 2.0は、ガバナンス、識別、保護、検出、対応、復旧を接続するため、インシデント後のレビューを整理するのに役立つ。Qlik に適用すると、ガバナンスは誰が分析プラットフォームリスクを所有するかを問う。識別はどのシステムとデータパスが存在するかを問う。保護はセグメンテーション、アクセス制御、最小権限、パッチ適用が露出を減らすかどうかを問う。検出はログと監視が悪用を明らかにするかどうかを問う。対応は組織が封じ込めて調査できるかどうかを問う。復旧は証拠をもってサービスと信頼を回復できるかどうかを問う。

このレビューは実用的な変更を生み出すべきである。Qlik サーバーが外部攻撃表面スキャンから欠落していた場合、追加する。ビジネスインテリジェンスチームが中央 IT の外でソフトウェアをインストールしていた場合、調達と展開制御を更新する。サービスアカウントが広範なデータベースアクセスを持っていた場合、権限を減らし資格情報をローテーションする。ログが不十分だった場合、保持と集中化を変更する。パッチウィンドウがインターネット露出システムに対して遅すぎた場合、緊急例外を定義する。パートナーが十分な証拠を提供できなかった場合、契約またはガバナンスプロセスを更新する。

レビューは経営陣の報告も変えるべきである。パッチ適用された CVE の数のみを報告すると、最も重要なシステムを隠す可能性がある。経営陣は露出とビジネス重要度による脆弱性ステータスを見るべきである。機密データに接続された公開分析サーバー上の積極的に悪用された脆弱性は、低リスクの内部ツールとは異なる注意を必要とする。これは1つの CVE が道徳的に重要だからではない。リスクは脆弱性、露出、データ、制御、攻撃者の行動によって一緒に生成されるからである。

公開企業と規制対象組織はこの記録を保存すべきである。将来のインシデントがデータ露出やビジネス中断を含む場合、組織は脆弱性を知っていたことだけでなく、どのように評価して修復したかを示す必要がある。良い Qlik 修復記録は、後の質問に答えやすくする：どのシステムが影響を受けたか、誰が所有していたか、どのアクションが取られたか、どの証拠がクローズをサポートするか、残留リスクは何か。

修復基準は攻撃者のリーチからの検証済み除去である

最も有用な説明責任基準は、述べるのは簡単で証明するのは要求が厳しい：脆弱な分析サーバーは攻撃者のリーチから除去されるべきであり、顧客はその方法を知っていることを示せるべきである。攻撃者のリーチからの除去は、パッチ適用、隔離、廃止、再構成、またはその他の緩和を意味する。適切なアクションは環境に依存する。証拠には技術的検証と運用コンテキストの両方を含めるべきである。

弱い修復記録は「ベンダーパッチを適用しました」と言う。より強い記録は「6つの Qlik Sense Enterprise for Windows インスタンスを特定しました。2つはインターネットに面していました。6つすべてが影響を受けるバージョンでした。緊急パッチ適用はこれらの日付に完了しました。パッチ適用前に一時的なアクセス制限が適用されました。外部スキャンはパブリックエンドポイントが脆弱なバージョンを露出しなくなったことを確認しました。脆弱な期間のログがレビューされました。4つのシステムで悪用の指標は見つかりませんでした。2つのシステムはより深い調査が必要でした。サービスアカウントの資格情報がローテーションされました。データ所有者は接続されたデータセットをレビューしました。残留例外はこちらで追跡されています」と言う。それがアクティビティと説明責任の違いである。

その修復基準におけるベンダーの役割は、証拠を可能にすることである。勧告は正確であるべきである。修正バージョンは検証が容易であるべきである。緩和策は具体的であるべきである。検出アドバイスは使用可能であるべきである。悪用が知られている場合、顧客は侵害評価が推奨されるかどうかを理解すべきである。証拠の収集を困難にする製品制限がある場合、ベンダーはそう言い、製品を改善すべきである。顧客は曖昧な指示から信頼できる証拠を生成できない。

顧客の役割は緊急性と規律を持って行動することである。報告ダッシュボードが便利だからといってパッチを無期限に延期することはできない。誰もダウンタイムを所有したくないからといって露出したサーバーを公開したままにすることはできない。ローテーションが面倒だからといってサービスアカウントに広範なアクセスを維持することはできない。プラットフォームが機密データに接続している場合、ビジネスオーナーは無知を主張できない。Qlik のケースの要点は、分析の利便性とセキュリティ説明責任が同じシステムで出会うことである。

最終的な教訓は、Qlik が独自にリスクが高いということではない。教訓は、組織が管理ソフトウェアに依存し、露出させ、重要なデータに接続するとき、それはインフラになるということである。それが起こると、説明責任基準が上がる。ベンダーは実用的な修復を公開しサポートしなければならない。顧客はインベントリし、パッチを適用し、調査し、証明しなければならない。パートナーは作業を示さなければならない。データ所有者は対応に参加しなければならない。そうでなければ、リーダーがビジネスを見るのに役立つ分析プラットフォームが、攻撃者が最初にそれを見るシステムになる可能性がある。

顧客行動は製品リスク表面の一部である

Qlik のエピソードにおける不快な教訓の1つは、顧客行動自体がリスク表面の一部であるということである。ベンダーは正しいパッチを生成するかもしれないが、顧客は通知を理解し、インスタンスを見つけ、ダウンタイムをスケジュールし、修正をインストールし、バージョンを検証し、悪用をチェックし、必要に応じて資格情報をローテーションし、データ所有者に説明する必要がある。各ステップは失敗する可能性がある。したがって、顧客行動パスは製品リスクの外側ではない。それはベンダーコミュニケーション、製品アーキテクチャ、顧客成熟度、攻撃者のタイミングが出会う場所である。

それは重要である。なぜならソフトウェアベンダーは時々顧客行動を単純な最終マイルとして説明するからである。実際のエンタープライズでは、そのマイルは変更フリーズ、ビジネスオーナーの抵抗、パートナー契約、不完全な資産記録、古いオペレーティングシステム、週末のスタッフ制限、スキャナーの盲点、経営陣が使用するダッシュボードを壊す恐れを横断する。分析プラットフォームがビジネスに重要であるほど、パッチのステージングは慎重に行わなければならない。露出が大きいほど、防御者が慎重なステージングに費やす時間は少なくなる。その緊張は説明責任分析で可視化されるべきである。

ベンダーは、緊急行動を明白にし、プレッシャーの下で信頼できる更新パスを設計することで負担を減らすことができる。顧客は、露出したアプリケーションに緊急パッチ権限を事前承認し、ロールバック計画を維持し、ビジネスオーナーがセキュリティが通常の報告利便性をどのようにオーバーライドするかを知っているかどうかをテストすることで負担を減らすことができる。マネージドサービスプロバイダーは、顧客固有のインスタンスマップを維持し、追跡されるのを待たずにインシデント固有の修復証明を提供することで負担を減らすことができる。

測定可能な結果は「顧客は知らされた」ではない。それは「顧客は行動できた」である。小さなセキュリティチームは、3つの別々の通知を読まずにどのバージョンが影響を受けたかを理解できたか？ビジネスインテリジェンス管理者はインストールされたバージョンを検証できたか？マネージドサービス顧客はプロバイダーから証拠を得ることができたか？データ所有者は機密データが到達可能かどうかを判断できたか？経営陣はパッチ適用済み、緩和済み、調査済み、露出済みの違いを見ることができたか？これらは実用的な質問だが、勧告が実際のリスク軽減になるかどうかを決定する。

Qlik の記録について、公開事実はすべての顧客がこれらの質問にどのように答えたかを証明していない。しかし、なぜ質問が重要であるかを示している。脆弱性は開示された。研究者はエクスプロイトチェーンを説明した。ディフェンダー報告は悪用をランサムウェア活動に結び付けた。それで十分に顧客行動をガバナンス対象にする。パッチ適用された分析サーバーをクローズされたチケットとして扱う組織は、ソフトウェアタスクとは完了しているかもしれないが、必ずしも説明責任タスクと完了しているわけではない。より厳しい基準は、ビジネス、セキュリティ、データ、パートナー側がすべて何が変わったか、なぜ残留リスクが許容可能か、組織の記憶がぼやける前にそれらの判断が文書化されたかを示すことである。