脅威の調査

パッチ適用の優先順位付け: フレームワークとツールの分析 – パート 2: 代替フレームワーク

修復の優先順位付けを支援するために設計されたツールやフレームワークに関する 2 部構成シリーズの後半では、CVSS に代わるフレームワークをいくつかご紹介します。

** 本記事は、Prioritizing patching: A deep dive into frameworks and tools – Part 2: Alternative frameworks の翻訳です。最新の情報は英語記事をご覧ください。**

このシリーズのパート 1 では、CVSS とその仕組みについて詳細を確認し、CVSS にはいくつかの利点がある一方、優先順位付けの唯一の手段として使用するようには設計されていないと結論づけました。本記事では、修復の優先順位付けに用いることのできるいくつかの代替ツールやシステム、それらの使用方法、および長所と短所を取り上げます。

Exploit Prediction Scoring System (エクスプロイト予測スコアリングシステム: EPSS)

Black Hat USA 2019 で初めて発表された EPSS は、(CVSSと同じく) FIRST Special Interest Group (SIG) によって管理されています。Black Hat の講演に添付されたホワイトペーパーに記載されているように、EPSS の作成者は、CVSS フレームワークのギャップを解消することを目的としています。つまり、過去のデータに基づいた悪用の可能性予測です。

元々、EPSS はロジスティック回帰を使用していました。いくつかの独立変数がその結果に与える影響を考慮することによって、結果が 2 つの値のどちらを取るかという可能性を測定する統計的手法です。たとえば、もし私がロジスティック回帰を使って、はい/いいえのどちらかの事象が発生する可能性 (たとえば、ある人が私の製品を購入するかどうか) を算出したい場合、過去の顧客および見込み顧客のマーケティングデータの大規模なサンプルを収集する必要があります。独立変数としては年齢、性別、給与、可処分所得、職業、地域、競合製品をすでに所持しているかどうか、などが考えられます。従属変数は、その人物が製品を購入したかどうかです。

ロジスティック回帰モデルは、どの変数が結果に有意に寄与するか、その寄与がプラスかマイナスかを教えてくれます。したがって、たとえば「年齢 < 30」、「給与 > 50,000 ドル」という値は結果に正の相関があり、「競合製品をすでに所有 = true」は予想通り負の相関がある、ということがわかります。それぞれの値の変数への寄与を計量することで、新しいデータをモデルに学習させ、任意の人がその製品を買いたいと思う可能性についての知見を得られます。ロジスティック回帰モデルの予測精度を測定することも (偽陽性または偽陰性が発生するかもしれないため) 重要で、測定にはROC (受信者操作特性) 曲線を用いることができます。

EPSS の制作者は 25,000 件以上の脆弱性 (2016~2018 年) を分析し、影響を受けたベンダー、エクスプロイトコードが実環境に存在するかどうか (Exploit-DB または Metasploit や Canvas のようなエクスプロイトフレームワークのいずれか)、公開された CVE エントリの参照数など、関係の深い 16 件の独立変数を抽出しました。これらは独立変数であり、従属変数は脆弱性が実際に悪用されたかどうかです (Proofpoint、Fortinet、AlienVault、GreyNoise のデータに基づきます)。

EPSS の制作者は、攻撃に使用されたエクスプロイトの存在が、モデルに対して最もプラスに寄与していることを発見しました。さらに、Microsoft が影響を受けたベンダーであること (Microsoft が開発・リリースする製品の数や人気、攻撃者に狙われた歴史があるためだと考えられます)、概念実証コードの存在、Adobe が影響を受けたベンダーであること、が続きました。

興味深いことに、EPSS の制作者は、Google と Apple が被害を受けたベンダーであることなど、負の相関関係もいくつか指摘しています。Google 製品に多くの脆弱性があり、その中で悪用されたものが比較的少ないこと、Apple がクローズドなプラットフォームであり、攻撃者が歴史的に標的にしてこなかったことが原因ではないかと推測されています。脆弱性の固有の特性 (すなわち、CVSS スコアに反映される情報) は、結果にほとんど影響を与えないようです。しかし、リモートコード実行の脆弱性は、たとえばローカルメモリ破壊の脆弱性に比べて悪用可能性が高くなっています。

EPSS は元々スプレッドシートで実装されていました。このスプレッドシートは、与えられた脆弱性が今後 12 か月以内に悪用される可能性の推定値を算出するものでした。その後の EPSS のアップデートにより洗練された機械学習モデルによる集中型アーキテクチャが採用され、機能セットが拡張 (公開脆弱性リスト、Twitter / X での言及、攻撃的なセキュリティツールへの組み込み、ベンダーの市場シェアやインストールベースと悪用活動の相関関係、脆弱性の年齢などの変数を含む) され、12 か月ではなく 30 日の期間内で悪用される可能性を推定するようになりました。

図 1: EPSS Data and Statistics ページのスクリーンショット。画像がキャプチャされた時点での過去 48 時間の EPSS スコア上位を示します。EPSS は、これらの CVE の多くが最終的に悪用されるとは結論づけていないことに注意してください。

v1.0 ではシンプルなオンライン計算機が利用可能ですが、最新バージョンを使用するには、EPSS Data and Statistics ページから逐次 CSV ファイルをダウンロードするか、API を使用する必要があります。EPSS スコアは、CVSS スコアを優先する National Vulnerability Database (NVD) には表示されませんが、VulnDB のような他の脆弱性データベースでは利用可能です。

本シリーズのパート 1 で述べたように、CVSS スコアは歴史的に、信頼できる悪用予測因子ではありませんでした。そのため、EPSS は原理的に自然な補完物のように思われます。つまり、影響度を評価するCVSS に対し、悪用の可能性を示す EPSS が相補的に働くということです。たとえば、CVSS ベーススコアが 9.8 である一方、EPSS スコアが 0.8% の脆弱性があるとしましょう (つまり、悪用されると深刻ですが、今後 30 日以内に悪用される可能性は 1% 未満だということです)。一方、別のバグは CVSS ベーススコアが 6.3 とかなり低い一方、EPSS スコアが 89.9% だとします。このような場合は、後者の脆弱性に優先的に対処した方がよいでしょう。

(EPSS の制作者も指摘しているように) CVSS スコアと EPSS スコアを掛け合わせる意味はありません。理論的には「重大度*脅威」の値が得られるとしても、CVSS スコアはあくまでただの順位付けであることを忘れないでください。EPSS は CVSS とは異なる情報を伝えるものであり、この 2 つは統合して考慮すべきですが、その性質は異なるものだと、EPSS の制作者は述べています。

では、EPSS は CVSS の「理想のパートナー」なのでしょうか。そうかもしれません。EVSS は CVSS のように無料で使え、有用な洞察を提供してくれます。一方でいくつかの注意点があります。

EPSS は実際に何を測定しているのか?

EPSS は、ある脆弱性が一般的に悪用される可能性を示す可能性スコアを提供します。EPSS は、特定の組織が標的にされる可能性や、悪用が成功した場合の影響、あるいは悪用が (たとえば) ワームやランサムウェアのツールキットに組み込まれる可能性を測定するものではなく、またそのようなことを意図したものでもありません。EPSS が予測する結果は 2 値データ (悪用が発生するかしないかのどちらか。実際には悪用が発生するか、発生したかどうかわからないかなので、より微妙です) であり、したがって EPSS スコアが指し示すのは、次の 30 日以内に悪用が発生する可能性のみです。この 30 日間という期間についても関連して言及しておきます。EPSS スコアは時間的データに依存しているため、設計上、再計算されるべきです。1 つの EPSS スコアはある瞬間のスナップショットであり、不変の指標ではありません。

EPSS は「事前脅威」ツール

EPSS は予測型のプロアクティブなシステムです。必要な情報がすべて利用可能な場合、任意の CVE について関連する脆弱性が今後 30 日以内に悪用される可能性を生成します。その脆弱性がまだ悪用されていなければ、EPSS スコアを考慮して優先順位を付けられます。EPSS は予測値であるため、 脆弱性がすでに積極的に悪用されている場合、EPSS スコアは何の意味ももちません。先ほどのロジスティック回帰の例に戻りますと、あなたが 6 週間前にすでに製品を購入していた場合、あなたのデータをモデルに投入し、あなたに製品を販売しようとすることにはほとんど意味がありません。当然のことですが、それでも心に留めておく意味はあります。すでに悪用されている脆弱性については、EPSS スコアは優先順位付けの決定に何の価値も発揮できません。

透明性の欠如

理由は異なりますが、EPSS は透明性に関して CVSS と同様の問題を抱えています。EPSS は機械学習モデルであり、その基礎となるコードとデータは、一般人はおろか、FIRST SIG のほとんどのメンバーもアクセスできません。EPSS のメンテナンス担当者は、「透明性を向上させることが私たちの目標の 1 つです」と言う一方で、「データ協定の一環として、データの非共有を要請されてきた複数のお客様がいるため、データを共有できません。モデルやコードについて、EPSS をサポートするためのインフラには多くの複雑な側面があります」と述べています。

前提条件と制約

カーネギーメロン大学ソフトウェア工学研究所の研究者である Jonathan Spring 氏は、EPSS はいくつかの仮定に依存しているため、想像されるほど普遍的な適用ができないことを指摘しています。EPSS の Web サイトは、このシステムが「ソフトウェアの脆弱性が悪用される可能性 (確率)」を推定するものだと主張しています。しかし、この主張はある程度一般化されたものです。たとえば、EPSS では「ソフトウェアの脆弱性」は公表されている CVE を指しますが、ソフトウェアベンダーやバグ報奨金管理者によっては、優先順位付けに CVE をまったく使わない場合もあります。Spring 氏が指摘しているように、特定の問題に対して CVE がまだ公表されていない (つまり、ベンダーが公表前に研究者と修正について調整している) ためかもしれませんし、脆弱性と言うよりは設定ミスの問題であり、そもそも CVE 番号が付与されないためかもしれません。

同様に、「悪用された」は、EPSS とそのパートナーが観察・記録できた悪用の試みを意味し、「実環境」は EPSS らによる観察の範囲を意味します。リンク先の論文の著者は、観察範囲の大部分が IDS シグネチャに依存しているため、境界デバイスに対するネットワークベースの攻撃に偏りがあることにも言及しています。

数値出力

CVSS と同様、EPSS は数値を出力します。また、CVSS と同様、リスクは単一の数値には落とし込めないことをユーザーは認識すべきです。CVSS と EPSS のスコアを直接かけ合わせる試みにも意味はありません。そうではなく、ユーザーはスコアの解釈に影響を及ぼすであろうコンテキストやシステムの問題点を意識しながら、数値スコアを考慮に入れるべきです。また、CVSS と同様、EPSS スコアは独立した数値であり、公式な推奨事項や解釈の手引きは提供されていません。

考えられる今後の課題

EPSS の制作者は、攻撃者がシステムに適応する可能性があることを指摘しています。たとえば、一部の組織があまり優先しないであろうという理由で、EPSS スコアの低い脆弱性を悪用する攻撃者が出現するかもしれません。また、EPSS は機械学習を利用していることから、攻撃者が将来、入力データ (ソーシャルメディアでの言及や GitHub リポジトリなど) を操作して特定の脆弱性に過剰なスコアを計上させ、EPSS スコアを敵対的に操作しようとする可能性も指摘しています。

Stakeholder-specific Vulnerability Categorization (ステークホルダー別脆弱性分類: SSVC)

カーネギーメロン大学のソフトウェア工学研究所 (SEI) が 2019 年に CISA と共同で作成した SSVC は、出力として数値スコアを一切生成しないという点で、CVSS や EPSS とは完全に異なっています。SSVC は数値を生成する代わりに、(機械学習的な意味ではなく伝統的な、論理的な意味での) 決定木モデルを採用しています。SSVC は、制作者も認識している CVSS と EPSS の 2 つの主要な問題点の解消を目的としています。1 つ目は、推奨事項や判断ポイントを提供せず、数値スコアの解釈をユーザーにゆだねていること、2 つ目は、CVSS と EPSS のいずれも、ステークホルダーではなく脆弱性を計算式の中心に置いていること、です。

SSVC のホワイトペーパーによると、このフレームワークは、いくつかの枝に沿って意思決定木を辿ることで、優先順位付けに関する意思決定を行うことを意図しています。たとえば、脆弱性管理の観点からは、まずエクスプロイトに関する質問に答えます。攻撃活動や概念実証、活発に悪用されている証拠があるかどうか、などです。これらの回答は、インターネットへの公開度 (小規模、制御下、オープン) 、キルチェーンが自動化可能かどうか、「価値密度」(悪用に成功した後に攻撃者が獲得するリソース) に関する決定に寄与します。最後に、安全への影響と業務への影響に関する 2 つの質問に回答します。結果である決定木の「葉」は、延期、予定、期間外、即時という 4 つからなります。

図 2: SSVC デモサイトに掲載された決定木の例

有益なことに、SSVC の最新版には、パッチ供給者、調整者、トリアージ/公開担当者 (新しい脆弱性のトリアージと公開に関する決定のため) など、他の役割もいくつか対象としており、役割によって、決定木の質問と決定結果は異なります。たとえば、トリアージ担当者に対する決定木では、可能な結果は辞退、追跡、および調整です。また、ラベルと重み付けは、組織の優先事項や業界に応じてカスタマイズできるように設計されています

決定木の結果は JSON または PDF にエクスポートできます。前回の CVSS に関する分析レポートでも登場したベクトル文字列も結果に記載されます。特筆すべきは、このベクトル文字列がタイムスタンプを含んでいることです。 SSVC の結果の一部は、コンテキストに応じて再計算されることを意図しているためです。SSVC のホワイトペーパーの制作者は、たとえば「エクスプロイトの状態」という判断項目に依存するスコアは急速に変化する可能性があるため、1 日に 1 回再計算することを推奨しています。一方、技術的影響など他の判断項目は静的だとしています。

その名が示すように、SSVC は数値スコアではなく、ステークホルダー固有の問題と意思決定に基づく結果を強調することによって、ステークホルダーを意思決定の中心に置こうとしています。SSVC の長所の 1 つは、CVE がない脆弱性や設定ミスにフレームワークを適用できることであり、もう 1 つは、異なるセクターや業界のステークホルダーが、それぞれのニーズに合わせてフレームワークを適用できることです。また、一度定義を理解すれば、使い方はかなり簡単です (こちらからお試しいただけます)。

私たちの知る限り、SSVC の有効性についての独立した実証研究は存在せず、SSVC の制作者によって行われた小さなパイロット研究があるだけです。また、このフレームワークはいくつかの点で、詳細よりも単純さを好みます。たとえば、CVSS には攻撃の複雑さを評価する指標がありますが、SSVC には悪用の容易さや頻度、あるいはそれに類するものについて同等の判断項目はありません。判断項目は悪用が発生したかどうか、概念実証が存在するかどうかのみです。

そして、おそらくは意思決定木が複雑になりすぎるのを避けるために、SSVC 決定木のどの質問にもデフォルトで「不明」の選択肢はありません。「不明」を選択する代わりに、ユーザーは過去のイベントに基づいて「合理的な推測」を行うように求められます。場合によっては、この仕様は最終的な決定を歪めるかもしれません。特に、組織がコントロールできない判断項目 (脆弱性が積極的に悪用されているかどうかなど) に関しては、アナリストは「推測」を嫌がり、慎重すぎる回答をするかもしれません。

とはいえ、SSVC が数値スコアを避けているのは悪いことではなく (欠点だと考えるユーザーもいるかもしれませんが)、他にもいくつかの有利な要素があります。カスタマイズできるように設計されていること、完全にオープンソースであること、最終的な出力として明確な推奨事項を提供することです。本記事で言及するほとんどのツールやフレームワークと同様に、堅実なアプローチは、他のものと組み合わせることでしょう。EPSS と CVSS の詳細 (および後述する KEV Catalog) を適用可能な場合にカスタマイズされた SSVC 決定木に入力することで、どの脆弱性に優先順位をつけるべきかの合理的な示唆が得られるでしょう。

Known Exploited Vulnerabilities (KEV: 既知の悪用された脆弱性) Catalog

米国サイバーセキュリティ・社会基盤安全保障庁 (CISA) が運営する KEV Catalog は、攻撃者がアクティブに悪用していることが分かっている CVE を継続的に更新するリストです。2024 年 12 月現在、このリストには 1,238 件の脆弱性が掲載されており、CVE 番号、ベンダー、製品、簡単な説明、実施すべき対策 (および期限、後ほど説明します)、メモ欄 (多くの場合、ベンダーのアドバイザリへのリンクを含みます) などの詳細が記載されています。

CISA による拘束力のある運用指令 22-01 によると、「連邦政府、行政府、省庁」は、KEV Catalog の該当する脆弱性を一定の期間内 (2021 年以前に割り当てられた CVE 番号 については 6 か月、それ以外のものについては 2 週間) に、その他の措置とともに是正することが求められています。CISA が KEV Catalog を作成する正当な理由は、前回の記事で指摘したことと似ています。悪用される脆弱性はごく一部であり、攻撃者はエクスプロイトの開発・展開には重大度評価を利用していないと考えられるためです。そのため、CISA は「組織は実際の攻撃では使用されないであろう何千件もの脆弱性対策に集中するよりも (中略) 悪用された既知の脆弱性を最優先で是正すべきです」と主張しています。

KEV Catalog は定期的に更新されるものではなく、CISA が以下のような一定の基準を満たす脆弱性を認識してから 24 時間以内に更新されます。

  • CVE 番号が存在する
  • 「この脆弱性が実環境でアクティブに悪用されているという信頼できる証拠がある」
  • 「脆弱性に対する明確な改善策がある」

CISA によると、悪用が試行段階なのか実際に成功しているのかにかかわらず、悪用が活発に行われていることを示す証拠は CISA のチームによるオープンソースの調査のほか、「セキュリティベンダー、研究者、パートナーからの直接の情報」、「米国政府や国際的なパートナーからの情報」、「サードパーティのサブスクリプションサービスを通じた情報」から得られるとのことです。スキャン活動や概念実証の存在だけでは、脆弱性を KEV Catalog に追加するには不十分であることに注意してください。

完全開示: ソフォスは、KEV Catalog を発行している CISA の一部である JCDC のメンバーです。

図 3: KEV Catalog のエントリの一部

KEV Catalog は主に米国連邦政府機関を対象としていますが、多くの民間企業も優先順位付けのためにこのリストを採用しています。これはある意味当然のことです。KEV Catalog は、CSV または JSON 形式の、シンプルで管理しやすいアクティブな脅威のコレクションを提供するため、CISA が提案するように優先順位付けのために脆弱性管理プログラムに簡単に取り込めます。極めて重要なことに、組織は KEV Calatog だけに頼るのではなく、他の情報源も考慮に入れるべきであると CISA は明言しています。

EPSS と同様、KEV Catalog の結果は 2 値データです。脆弱性がリストに載っていれば、その脆弱性は悪用されたことがあるということです。載っていなければ、そうではありません (より正確には、悪用が確認されていません)。しかし、KEV Catalog が提供しないコンテキスト情報も多くあり、中には優先順位付けをする上で組織の助けになり得る情報も含まれます。特に今後リストの項目が増え続け、扱いづらくなるに従い、その傾向は強まる可能性があります。(実際にそうなるでしょう。脆弱性がリストから削除される理由は 1 つしかありません。ベンダーのアップデートが「脆弱性そのものよりも大きな影響を与える予期せぬ問題」を引き起こした場合です。)

たとえば、KEV Catalog には悪用された回数が詳細に記載されていません。脆弱性が悪用されたのは一度だけなのでしょうか、それとも数回、あるいは数千回なのでしょうか。また、優先順位付けのための有用なデータ項目となり得る、影響を受けた業界や地域に関する情報も提供されません。また、脆弱性を悪用している攻撃者のカテゴリ (ランサムウェアの攻撃者以外) や、脆弱性が最後に悪用された時期も不明です。EPSS に関する議論と同様に、何を脆弱性だとみなすかや、データの透明性にも問題があります。前者について、一部のステークホルダーにとってはあまり有用ではないかもしれませんが、KEV Catalog のエントリには CVE が必要です。後者については、KEV Catalog の観察範囲は CISA のパートナーが観察できる範囲に限られており、そのデータは閲覧したり裏付けを取ったりすることはできません。しかし、アクティブに悪用されていると思われる脆弱性の精選されたリストは、多くの組織にとって有用である可能性が高く、修正に関する意思決定の基礎となる追加情報を提供します。

これらの異なるツールやフレームワークのいくつかを組み合わせることで、リスクをより深く理解し、より多くの情報に基づいた優先順位付けを行えることを、お分かりいただけたのではないでしょうか。CVSS は、脆弱性固有の特性に基づいて脆弱性の重大度を示します。KEV Catalog は、すでに攻撃者により悪用された脆弱性を示します。EPSS は、攻撃者が将来脆弱性を悪用する可能性を示します。SSVC は、カスタマイズされたステークホルダー固有の意思決定木内でこれらの情報の一部を考慮に入れることによって、優先順位付けに関する意思決定を支援します。

CVSS、EPSS、SSVC、KEV Catalog の 4 つはある意味「大物」です。次に、あまり知られていないツールやフレームワークと、それらがどのように併用できるかに目を向けてみましょう。(CWECWSSCWRAF などのスキームは、脆弱性や優先順位付けよりも弱点に特化しているため、ここでは取り上げません。)

その他のフレームワークとツール

ベンダー別スキーム

いくつかの営利団体が、優先順位付けを支援するために設計された有料の脆弱性ランキングサービスやツールを提供しています。その中には、独自のモデルによって生成された EPSS のような予測データや、クローズドソースのデータと組み合わせた EPSS スコアを含むものもあります。また、CVSS を使用し、独自のスコアリングシステム、脅威インテリジェンス、脆弱性インテリジェンス、 および/または顧客の資産やインフラストラクチャに関する情報とスコアを組み合わせたものもあります。これらの結果は、たとえば CVSS や EPSS 単独と比較して、リスクのより完全な全体像把握と優先順位付けのためのより良い指針となるかもしれませんが、多くは一般公開されていないため、十分に評価・査定されていません。

製品ベンダーの中には、独自のシステムを考案し、そのスコアを公開しているところもあります。Microsoft は自社製品の脆弱性に関して、CVSS と同様に脆弱性の重要度の目安となるセキュリティアップデートの重要度評価システム (Microsoft は、この評価は「その脆弱性が悪用された場合の理論上最悪の結果」に基づいていると述べています) と、脆弱性が悪用される可能性を評価することを目的とした「Microsoft の悪用可能性指数」の 2 つのシステムを持っています。これらのシステムは統計モデルではなく、Microsoft による脆弱性の分析、脆弱性を悪用することの難しさ、過去の悪用傾向に基づいているようですが、事実かどうかを確認するのに十分な情報は提供されていません。

Red Hat もまた、4 つの可能なレーティングと、算出された CVSS ベーススコアで構成された Severity Ratings システムを持っています。Microsoft のシステムと同様、このシステムは自社製品の脆弱性にのみ関係し、スコアの算出に用いる項目および算出方法は不透明です。

CVE Trends (サービス終了) と代替サービス

X が API の使用を制限しているため、本記事執筆時点では更新を停止していますが、CVE Trends は X、Reddit、GitHub、NVD からスクレイピングされた情報をクラウドソース化したダッシュボードです。データに基づき、その時点で最も話題になっている 10 件の脆弱性が表示されていました。

図 4: CVE Trends のダッシュボード

上記のスクリーンショットに示すように、ダッシュボードには CVSS と EPSS のスコア、CVE 情報、ツイートおよび Reddit への投稿のサンプル、「公開」日、過去数日間 (または 24 時間) のアクティビティの測定結果が記載されています。

CVE Trends は、セキュリティコミュニティにおける「今月人気の」 CVE についての知見を得るのに役立つかもしれませんし、新しい脆弱性について素早く知るのにも役立つかもしれません。しかし、新しい、影響の大きい脆弱性以外の優先順位付けにはあまり役立ちませんでした。CVE Trends は、一度に 10 件の脆弱性のみを示しています。そのうちのいくつか (Log4j など) は、スクリーンショットでも確認できるように、当時すでに古いものでしたが、広く流行し、大きな影響を与えていたため、言及され続けていました。

前述の通り、CVE Trends は 2023 年半ばから活動を休止しています。本記事執筆時点で、このサイトへの訪問者には次のようなメッセージが表示されます。このメッセージは、制作者の Twitter フィードの最後のメッセージにもなっています。

図 5: CVE Trends のお別れメッセージ/ツイート

X が API の使用制限を緩和するかどうか、あるいは CVE Trends の制作者である Simon J. Bell 氏がサイトの機能を回復するために他の選択肢を模索するかどうかは不明です。

Bell 氏の Web サイトが閉鎖された後、Intruder という会社がこのツールの独自バージョンを開発しました。本記事執筆時点ではベータ版で、同じく「CVE Trends」と呼ばれています。このツールは、ソーシャルメディアの活動に基づいて、0〜100 の「話題度」を表示する機能を備えています。

SOCRadar も「CVE Radar」と呼ばれる同種のサービスを維持しており、ダッシュボードにてツイート数、ニュースレポート、脆弱性関連リポジトリの詳細を提供しています。感動的なのは、Simon Bell 氏による CVE Trends の仕事を (Intruder 社が About ページで行っているように) メインページで認めていることです。CVE Radar と Intruder 社による CVE Trends はどちらも関連するツイートのテキストを有効に組み込んでおり、特定の脆弱性に関するソーシャルメディア上での言及のダイジェストを一目で確認できます。X からのユーザーの流出を考えると、いずれかのツールの開発者が他のソーシャルメディアプラットフォームを取り入れるつもりなのかどうかは不明です。

CVEMap

2024 年半ばに導入された CVEMap は、ProjectDiscovery による比較的新しいコマンドラインインターフェースツールで、CVSS スコア、EPSS スコア、脆弱性の年齢、KEV Catalog のエントリ、概念実証のデータなど、CVE エコシステムのいくつかの側面を統合することを目的としています。CVEMap は、あくまで統合ツールであるため、新しい情報やスコアを提供したり促進したりする機能は備えていません。しかし、脆弱性に関するさまざまな情報源をシンプルなインターフェースにまとめ、製品やベンダーなどによるフィルタリングも可能にしていることから、複数の情報源に基づいて優先順位を決定する手段を求めている防御者にとって有用だと考えられます。

Bug Alert

Bug Alert は、インシデント対応者に存在する特定のギャップを解決するように設計されたサービスです。Bug Alert は、重大で影響力の大きい脆弱性 (金曜日の午後や祝日の直前に発生するような脆弱性) を、セキュリティ勧告や CVE 番号の公表を待つことなく、電子メール、SMS、電話通知によってできるだけ早くユーザーに知らせることを目的としています。コミュニティ主導の取り組みであり、研究者が新しい脆弱性の通知を GitHub リポジトリへのプルリクエストとして提出することに依存しています。Bug Alert の制作者が現在も保守を続けているかどうかは不明です。本記事執筆時点では、Github リポジトリでの最後の活動は 2023 年 10 月となっています。

CVE Trends と同様、Bug Alert は痒いところに手が届くシステムかもしれませんが、一般的な優先順位付けに使用するようには設計されていません。

vPrioritizer

vPrioritizer は、オープンソースのフレームワークであり、資産単位または脆弱性単位でコンテキスト化されたリスクを評価・理解できるように設計されています。そのため、資産管理と優先順位付けを統合できます。vPriortizer は、CVSS スコアと「コミュニティ分析」および脆弱性スキャナの結果を併用することで統合を実現しています。悲しいことに、2019 年に SSVC のホワイトペーパーで言及され、2020 年に Black Hat USA Arsenal で発表されたものであるにもかかわらず、vPrioritizer の開発者がまだプロジェクトを維持しているかどうかは不明です。本記事執筆時点で、GitHub リポジトリへの最後のコミットは 2020 年 10 月です。

Vulntology

Vulntology (「脆弱性」と「オントロジー」の合成語) は、脆弱性を、どのように悪用される可能性があるか、悪用された場合の潜在的な影響、および脆弱性の緩和要因に従って特徴付ける NIST 主導の取り組みです。脆弱性の説明記述 (ベンダーによる勧告やセキュリティ情報など) の標準化、その種の記述をより詳細にすること、脆弱性情報の言語の壁を越えた簡単な共有などを目的として出発しました。「vulntology に即した表現」の例は、こちらで入手できます

図 6: Vulntology の提案する作業の説明図(プロジェクトの GitHub リポジトリより引用)

したがって、Vulntology はスコアリングのフレームワークでもなければ、意思決定木でもありません。その代わりに、Vulntology は共通言語への小さな一歩であり、広く採用されるようになれば、脆弱性管理に関して重要な価値を持つようになる可能性があります。脆弱性を記述するための標準化されたアプローチは、複数のベンダーのセキュリティ勧告、脆弱性インテリジェンスフィード、その他の情報源を評価する際に、確かに役立つでしょう。本記事で言及しているのは、脆弱性の優先順位付けに影響を与える可能性があるためです。長期的なものにはなりますが、脆弱性管理の分野における問題を解決しようとするものです。このプロジェクトの Github への最後のコミットは、2023 年春です。

犯罪市場データ

最後に、犯罪市場のデータと、優先順位付けのためにデータをどのように活用するかという今後の研究について簡単に触れておきます。2014 年にトレント大学の研究者たちが、CVSS スコアが悪用の優れた予測因子であるかどうかについての研究を行いました。彼らは、CVSS スコアは悪用の割合とは一致しないと結論付けましたが、「犯罪市場で販売されているエクスプロイトに対応した修復が最大のリスク低減をもたらす」とも結論付けました。現在でも同じことが言えるかどうかを調べるのは、興味深い研究テーマでしょう。2014 年以降、エクスプロイト市場の規模は拡大しており、エクスプロイトのマーケティングと販売に特化した大規模な地下経済が存在しています。

図 7: 犯罪フォーラムで Windows のローカル権限昇格エクスプロイトを販売するユーザー

犯罪市場におけるエクスプロイトの存在だけでなく、価格、関心の高さ、顧客からのフィードバックを確認することは、優先順位付けの試みに利用できる、さらに有用なデータ項目になるでしょう。

もちろん、こうした犯罪市場へのアクセスやデータのスクレイピングが困難であるという課題が存在します。その多くは登録不可で、他ユーザーからの紹介、金銭の支払い、攻撃者としての評判によってのみアクセスできるためです。また、地下市場の規模が拡大するにつれて、かつてほど多元化されていることも間違いありません。有名なフォーラムは商品を宣伝する最初の場所として機能するかもしれませんが、価格を含む重要な情報の多くは、興味を持つ潜在的な買い手がプライベートメッセージを通じてのみ入手できることもあり、実際の交渉や販売はしばしば、Jabber、Tox、Telegramのような「帯域外」のチャネルで行われます。優先順位付けのための実現可能なデータソースとなり得るかどうかを判断するためには、この問題に関するさらなる研究が必要です。

組み合わせとカスタマイズが鍵

CVSS、EPSS、SSVC、KEV Catalog に加え、他のツールやフレームワークについても簡単に説明しましたが、すべての優先順位付けの問題を解決する魔法のようなソリューション、あるいは魔法の組み合わせは当然ながら見つかりませんでした。しかし、ほとんどの場合、単一のフレームワークを使うよりも、組み合わせて用いる方が好ましいと考えられます。より多くのデータ項目は、より多くの情報に基づいた知見を意味し開発者による技術的な努力の賜物かもしれませんが、私たちが議論してきたほとんどのツールとフレームワークの出力結果は、自動化された方法で簡単に取り込まれるように設計されています (そして、CVEMap のようなツールは、すでにこの大変な作業のいくつかを行っています)。

結果を併用するだけでなく、カスタマイズも極めて重要です。見落とされがちですが、優先順位付けは脆弱性やエクスプロイトだけの問題ではありません。もちろん、問題の大きな部分を占めてはいますが、重要なのは、修復の観点から見ると、脆弱性は単独では存在しないということです。その固有の特性を考慮することは、状況によっては役に立つかもしれませんが、本当に重要な項目は、その脆弱性があなたにどのような影響を与えうるかということだけです。

さらに、組織ごとに優先順位付けの方法は異なり、その組織の業務内容、仕事の進め方、予算やリソースの状況、リスク選好度に依存します。

多くの場合、フレームワークの評価という観点からは、単一で画一的なスコアや勧告は論理的な意味を持ちません。修復に優先順位を付けようとする個々の組織から見るとなおさらです。すべてはコンテキスト次第です。そのため、どのようなツールやフレームワークを使うにしても、スコアやランキングではなく、自らの組織を計算式の中心に置いてください。組織の規模や構造によっては、部門や部署ごとに優先順位を付けたり、文脈を整理したりするなどの調整を、より詳細なレベルで実行できます。いずれにせよ、できる限りカスタマイズを行い、どれだけ著名で人気のあるフレームワークであっても、その結果はあくまで目安に過ぎないことを忘れないでください。

CVSS や SSVC のようないくつかのシステムでは、出力結果をカスタマイズして調整するためのオプションが組み込まれています。EPSS や KEV Catalog のような他のシステムでは、カスタマイズはあまり重要ではありませんが、その情報を他のツールやフレームワークと統合し、可能な限り全体像を確認することで、結果にコンテキストを追加することができるでしょう。

もちろん、優先順位付けは、本記事で取り上げたツールだけに留まりません。本シリーズでツールに焦点を当てたのは、ツールが脆弱性管理の興味深い構成要素であるからです。しかし、優先順位付けの決定に反映されるべき情報は、理想的には脅威インテリジェンス、弱点、セキュリティポスチャ、管理策、リスク評価、侵入テストやセキュリティ監査の結果など、他のさまざまな情報源から得られます。

前回の記事で指摘したことの繰り返しになりますが、ソフォスがこれらのツールやフレームワークの欠点を指摘してきたのは、決してツールの開発者や彼らの努力を否定するためではありません。ソフォスは公正で公平な評価を心がけてきました。これらのようなフレームワークを作るのは大変な作業であり、熟考と綿密な計画を必要とします。使うためにあるのですから、意味のある時に、意味のある場所で使うべきです。ソフォスは、安全で十分な情報に基づき、効果的な方法で優先順位付けを行うのに本シリーズが役立つことを願っています。