FutureVuls Blog

EPSS (Exploit Prediction Scoring System) 徹底解説 ~相互運用からデータソース、機械学習モデルまで~

本記事は 2024年3月24日に開催された VulnCon 2024の講演
EPSS: Challenges and Opportunities Going Forward + EPSS AMAを内容を元に、EPSS (Exploit Prediction Scoring System) について、詳しく解説することを目標としています。

EPSS は「脆弱性が近い将来(30日以内などの指定期間)に攻撃される確率」を予測し、スコアとして公開する仕組みです。
近年、継続的な脆弱性管理が重要となる中で、「本当に攻撃される確率」にフォーカスした新しいアプローチとして注目を集めています。

本記事では、EPSS の現状を解説しつつ、以下のようなポイントをできるだけ詳細に取り上げます。

  • EPSS の目的と特徴、CVSS や他スコアとの違い
  • データパートナーの役割やデータソースの課題・バイアス
  • 機械学習モデル(XGBoost 等)の詳細とスコア更新プロセス
  • 「確率」「パーセンタイル」 をどう使い分けるか
  • カバレッジ(Coverage)・効率(Efficiency)の意味とグラフ解釈
  • 既存の標準化 (CVSS, SSVC, KEV 等) との相互運用性の問題
  • スコアの変動タイミングと実運用での注意点
  • 今後の標準化の展望 (ITU-T など)
  • Q&A で言及された「利用者が抱える疑問点」とその回答例

これから EPSS を導入してみたい企業のセキュリティ担当者、あるいは既に PoC や一部運用を始めている方にとって、最新動向が把握できるようまとめました。ぜひご参照ください。


1. EPSS とは何か

新しい脆弱性管理の視点

EPSS (Exploit Prediction Scoring System) は、脆弱性管理において「今後攻撃されるリスク」を定量化するスコアリング手法です。

  • 従来の CVSS は「脆弱性の技術的深刻度」を示す指標
  • EPSS は「攻撃される可能性(Exploitation Probability)」に特化

EPSS は約 4 年前から構想され、3 年前よりスコアを オープンデータ として公開(0:24)。SIG (Special Interest Group) と呼ばれるコミュニティが支えており、世界中の データパートナー から攻撃データを収集して日々モデルを更新しています。

攻撃確率を具体的に数値化

  • EPSS が生成する確率は 0~1(または 0~100%)の値で、「この脆弱性が 30 日以内に攻撃される確率」 を表現
  • 約 23 万件 の脆弱性 (CVE) に対して一括でスコアを付与し、FIRST.org などからダウンロード可能

参考: 1:02~1:20 付近で「EPSS はデータ・ユーザー・SIG の三要素が揃わないと成り立たない」と強調。


2. EPSS の特徴と従来スコアとの違い

CVSS, SSVC, ベンダー独自スコアとの比較

CVSS との違い

  • CVSS: 脆弱性そのものの技術的/環境的な深刻度 (攻撃成立時の被害規模) を評価
  • EPSS: 「攻撃が発生する可能性の大きさ」を評価

「CVSS 9.0 以上の脆弱性 = 攻撃されやすい」ではない点が注目されています。
EPSS は「本当に攻撃される可能性が高いもの」を浮き上がらせる際に有用とされます。

SSVC (Stakeholder-Specific Vulnerability Categorization)

  • SSVC: 「緊急修正」「後回し」「監視する」など、ステークホルダー視点での優先度判断を支援
  • EPSS が算出する「攻撃発生確率」を SSVC の意思決定要素に統合すれば、より効果的な優先度付けができる

ベンダー独自スコア

  • Qualys、Tenable、Rapid7 など多くの企業が独自の脆弱性リスクスコアを提供
  • ただし多くの場合は「ブラックボックス」であり、明確な確率は提供されないケースが多い

動画参考: 1:26~3:03 で「複数スコアの相互運用が課題」と強調。

EPSS 導入の意義

  • 「修正工数が限られている」 企業において、確率が高いものを優先的に潰す 判断材料として非常に有用
  • 統計・機械学習を駆使し、「実際の攻撃発生データ」に基づいてスコアリングするのが大きな特徴

3. データパートナー・データソースの重要性

EPSS が提供するスコアの正確性は、いかに多様な攻撃データを集められるか に依存します。動画では以下の課題が議論されています。

  1. データのバイアス
    • 特定ベンダー製品が多い環境や、一部の IDS 署名だけで集めた情報に偏る危険
    • 1:08 付近で「EPSS は収集データが無ければ成り立たない」と明言
  1. 検知されない脆弱性が多い
    • 23 万超の脆弱性 (CVE) 全てに対してシグネチャを持つ IDS は存在しない
    • 「署名が無い脆弱性」は検知されていないため、EPSS の学習データにも現れにくい
  1. CVE ID が付与されていない脆弱性の扱い
    • EPSS は CVE ID をキーとしているため、未割り当て脆弱性は基本的にスコープ外
    • 13:03 付近で「非CVE管理の脆弱性は識別が難しい」と言及
  1. 「本当に攻撃されていない」ことを証明しづらい
    • ログが無いだけで攻撃が行われていないかどうか確証は得にくい
    • 12:13~12:46 付近で、「ゼロを証明する難しさ」を指摘

データパートナーの募集

  • SIG では、あらゆる形での攻撃データ提供を歓迎 (IDS/IPS ログ, honeypot, マルウェア解析ログ など)
  • 個人情報や企業名は含まず、「どの脆弱性がいつ攻撃されたか」 だけで十分
  • 9:04~11:01 で「より多くのデータソースが必要」と明示的に呼びかけ

4. 機械学習モデルの仕組みとスコア更新

EPSS のモデルは主に XGBoost を使用しており、1,400 を超える特徴量(変数)を活用して学習しています。

  • CVE 情報: 例) CVSS ベーススコア、攻撃元がリモートかローカルか、ユーザー権限要否など
  • 参照 (Reference) 数: その脆弱性に関するブログやアドバイザリ、GitHub リポジトリ数
    • 45:26 辺りで「単純に“参照数”が重要な予測因子になる」と語られる
  • ExploitDB / Metasploit の有無
  • Shodan のスキャン状況 など、様々な要素を組み合わせて総合評価

スコア更新のプロセス

  1. 学習データの収集: ベンダーやパートナーの攻撃ログ + 公開情報 (CVE, PoC など)
  2. モデルへの取り込み: XGBoost などの機械学習で予測モデルを構築
  3. スコア計算・公開: “30 日以内に攻撃される確率” を各 CVE に割り当て
  4. 日次・週次の更新: データ量や都合によって更新頻度を調整
  5. 大規模リリース (v1 → v2 → v3 …)
    • 主要アルゴリズムや特徴量が変わる際、メジャーバージョン が上がり大きくスコアが変動する

モデルバージョンアップのタイミング

  • 38:03~40:10 付近で v1, v2, v3 の精度比較が紹介
    slide
  • SIG はボランティアベースで活動しており、モデルが古くなると精度が下がるためアップデートは必須だが、時期は不定期

5. 確率・パーセンタイル・カバレッジ・効率

EPSS が提供する指標のうち、特に重要とされる概念を整理します。

1 確率 (Probability)

  • 「今後30日以内に攻撃される確率」を 0~1 (もしくは 0~100%) で表示
  • 例: 0.3270.469 などの数値
  • 微妙な差を直感しづらいため、パーセンタイル情報も併用

2 パーセンタイル (Percentile)

  • 脆弱性をスコア順に並べた際の順位情報
  • 例: パーセンタイル 95% → EPSS 全体で上位 5% に位置づけ
  • 3:03~5:00 で「確率だけでは分かりにくいので、パーセンタイルが補助する」と解説

3 カバレッジ (Coverage) / 効率 (Efficiency, Precision)

30:01~31:28 辺りで詳しい図解が示されます。

  • Coverage:

    • 実際に攻撃された脆弱性のうち、「優先的に修正対象としたもの」がどのくらい含まれるか
    • 攻撃されるものをどれだけ捉えられたか
  • Efficiency (Precision):

    • 「優先的に修正対象とした脆弱性」のうち、実際に攻撃が確認されたものの割合
    • 修正工数をどの程度効率的に投入できたかを示す

具体例

  • CVSS 7 以上を全部修正 する場合:Coverage は高いが、Efficiency が低くなりがち
  • 下の図の赤枠がCVSS 7以上のもの
    • 攻撃カバー率(Coverage)
      • 81.9%:CVSSスコア「7以上」の脆弱性を対象にすると、実際に攻撃に利用される脆弱性の 81.9% をカバーできる。攻撃リスクの広範囲を含む点は評価できる。
    • 効率性(Efficiency)
      • 57.4%:全脆弱性のうち、57.4%がCVSSスコア「7以上」と分類されている。高スコアの割合が多いため、対応対象が膨大になる傾向がある。
      • 3.9%:CVSSスコア「7以上」の脆弱性の中で、実際に攻撃に利用されるものは 3.9% に過ぎない。攻撃に使われない脆弱性も多く含まれるため、リソースの集中には非効率的。

slide

  • EPSS で 0.5 以上に絞る 場合:Coverage をある程度確保しつつ、Efficiency も向上可能
  • 下の図の赤線がEPSS v3のもの。EPSSスコア「0.5」を見てみると、
    • 攻撃カバー率(Coverage)
      • 約63%:EPSSスコアが「0.5」以上の脆弱性を対象にすることで、実際に攻撃に利用される脆弱性の 63% をカバー可能。
    • 効率性(Efficiency)
      • 85%:EPSSスコア「0.5」以上の脆弱性のみを対象とした場合、全体の脆弱性の中で、攻撃に使われるものを 85% の精度で特定可能。
  • 組織が対応すべきと判断するしきい値は、該当組織のリスクに対する考え方や対応能力によって調整する必要あり。

slide


6. 相互運用性と導入上の課題

既存の業界標準・ベンダースコアとの組み合わせ

  • CVSS と組み合わせる際:EPSS は「攻撃リスク」、CVSS は「影響度」で役割分担
  • SSVC と合わせると、優先度判断がさらに柔軟化
  • ベンダースコア (Qualys, Tenable 等) も存在し、どれをどう組み合わせるかが実務上の大きな課題

スコア変動への備え

  • モデルアップデート時(v2→v3 など)には、スコアが大幅に変動 することがある
  • 企業内のチケット管理や IT 資産管理に EPSS スコアを組み込んでいる場合は注意が必要
  • 1:20:32~1:21:20 辺りの Q&A でも言及あり

閾値設定の難しさ

  • EPSS スコアが 0.30.35 の違いをどう扱うか
  • パーセンタイルも活用しつつ、組織のリスク許容度に合わせたルール作りが必要

7. 標準化への取り組み (ITU-T 等)

EPSS は ITU-T での標準化を目指し、さまざまな国際フォーラムで議論されています。

  • 16:06~17:20 付近で「Geneva の国際会議に参加し、CVSS 同様の立ち位置を狙いたい」との発言
  • 一方で「EPSS は特定のコミュニティ独自の技術であり、国際標準として認められるか課題」という指摘もあり

標準化によって、各種セキュリティツールへの標準搭載や業界全体での浸透が期待されますが、まだ道半ばです。


8. EPSS 導入のメリットと注意点

メリット

  1. 攻撃可能性を考慮した優先度付け
    • リソースが限られる中、確率が高い脆弱性を重点修正できる
  1. データドリブンな脆弱性管理
    • 各種ログや PoC、ハニーポット観測など、実際の攻撃情報に基づく
  1. CVSS/SSVC 等との組み合わせ
    • 攻撃確率に加えて「深刻度」「ビジネス影響度」を統合し、多面的に評価可能

注意点

  1. EPSS スコアだけでは完結しない
    • 自社インフラの重要度やコンプライアンス要件など、独自リスク評価も必要
  1. モデルの変動リスク
    • バージョンが変わるとスコアの付け方が大きく変わり得る
    • 運用フローやツールへの影響を考慮
  1. データソースのバイアス
    • 特定企業や製品群に偏ったデータで学習されている可能性を排除できない
  1. CVE 未割り当ての脆弱性は非対象
    • 実際には存在するが EPSS ではスコアが付かないケースがある

9. Q&A で語られた主な疑問点と回答例

動画後半(42:01 以降)や全体の Q&A では、以下のような質問が寄せられました。その一部をまとめます。

Q1. 「KEV や他のリストで ‘既に攻撃されている’ とされているなら、EPSS は常に 100% で良いのでは?」

  • 回答要旨:
    • EPSS は「今後 30 日以内に攻撃される確率」を指標にしており、過去に攻撃があったからといって、同じ頻度で継続的に攻撃されるとは限らない
    • KEV などは「既に攻撃された事実」を示すが、攻撃が沈静化する場合もある

Q2. 「モデルをどの程度の頻度で更新するのか? どれくらい精度が落ちると ‘次のバージョン’ に移行するのか?」

  • 回答要旨:
    • SIG はボランティアベースのため明確な更新頻度は設定されていない
    • ただし継続的なデータモニタリングで精度が落ちたと判断すれば大きなアップデートを行う
    • 1:15:59 付近 で詳しいやり取りがある

Q3. 「EPSS の内部ロジックがブラックボックスに感じる。オープンソース化の予定は?」

  • 回答要旨:
    • 現状 XGBoost で学習させており、特徴量が 1,400 以上ある
    • 公開しても複雑すぎて再現が難しく、有益な透明性を得られるとは限らない
    • 1:02:00 頃の議論 で「ロジックは公開しても ‘コード眺めても意味がない’ という可能性が高い」と述べられている

Q4. 「自社環境固有の要素(例: インターネット露出状況)を加味したいが、どうすれば?」

  • 回答要旨:
    • EPSS はグローバルな確率を提供する仕組みであり、各社のアセット価値やネットワーク構成までは考慮していない
    • したがって、EPSS スコア + 自社インフラのリスク評価 を組み合わせるのがベストプラクティス
    • 1:02:45 頃 付近でも「最終的には組織自身の判断が必要」と回答

10. FutureVulsの例

FutureVulsの画面上で EPSS を確認できます。SSVCに加えて、EPSSを活用した脆弱性管理が可能となります。

EPSS

詳細は公式ヘルプ>トリアージを参照してくだい。


11. まとめ

EPSS は、脆弱性管理において 「実際に攻撃されるか否か」 という視点を加える画期的な仕組みです。CVSS と組み合わせることで、「技術的な深刻度」と「攻撃発生の可能性」を両面から検討できるようになります。

しかし、

  • データソースのバイアス
  • モデル更新時のスコア変動
  • CVE 未割り当ての脆弱性が対象外になる問題
  • 組織固有のリスク評価との統合

といった課題もあり、EPSS 単独で完結するものではない ことに留意が必要です。SIG の取り組みや、ITU-T への標準化アプローチなど、今後の進展に注目が集まっています。


参考リンク


脆弱性情報の自動集約・EPSSやSSVCによる優先度付けに役立つSaaSを開発・提供しています。EPSSを使った意思決定プロセスを用いて、継続的かつ効率的に脆弱性管理を進めたい方は公式サイトもぜひご覧ください!

お問い合わせはこちら