EPSSやKEV Catalogを有用に使うプロジェクトが最近出てきました。
これらについて内容を確認し、どのように使えるか、同様なSSVCとどう違うかを見ていきます。
EPSSは、別途記事やインターネット上での解説を参照して下さい。
おおよそ以下のようなものです。
機会 x 脆弱性 x 資産 で示され、その中の1つを示しているKEV Catalog(Known Exploited Vulnerabilities Catalog)も、以下の通りです。
CVE_Prioritizer及びSploitScanについて、実際に動作させてみました。2024-02-29時点の情報です。
本記事末尾に、Dockerでの構築方法を残しておきます。
https://github.com/TURROKS/CVE_Prioritizer
READMEに概念等が書いてあり、CVSS/EPSS/KEV をどのように組み合わせれば良いかが、分かりやすく提示されています。
6.0 、EPSSは 0.2 としている
We have refined the prioritization thresholds based on FIRST's recommendations and our own experience.アプローチとしてはよさそうに感じました。
アプリケーションとしてみた場合は、業務で使うことはできそうだ、という感じです。
-v オプションで、判定で利用したソースが見れるのは良いですね
全体として、対象の脆弱性が少ない状況であれば、十分に判断の助けになるのではないか、と感じました。
https://github.com/xaitax/SploitScan
パッチ優先順位付けという目的はCVE_Prioritizerと同じですが、PoC Exploitも利用する点が違います。
これも、CVE_Prioritizerと同様に、アプローチとして良さそうに感じました。
def calculate_priority(cve_id, nvd_data, epss_data, poc_data, cisa_data): で利用しているCVE_PrioritizerとSploitScanでのデータの取り扱いと、同様な優先順位付け基準であるSSVC(Stakeholder-Specific Vulnerability Categorization)との違いなどを考察します。
両プロジェクトとも、脆弱性それ自体の危険度と、攻撃に利用される可能性、の2点で対応優先度をつけています。そのため、比較的大規模環境で求められる「（ 事業に対する）リスク」という観点では少し不足しているように感じるかもしれません。とはいえ、管理対象規模などを考えれば、EPSSやKEV Catalogなどを活用するという点では非常に重要であり、EPSS/KEV/CVSS/Exploitをどう考えるか、のモデルケースになると思われます。
また、KEV Catalogについては最優先の判定になるようです。
CVE_Prioritizerは、シンプルで、既存の脆弱性管理にも組み込みやすいかもしれません。CVE-IDをリストで渡すことで、管理している脆弱性の優先度を一旦丸投げすることも可能です。API-Keyにも対応しているので、多量のCVE-IDを投げてもおおよそ大丈夫かもしれません。
SploitScanは、上記CVE_Prioritizerに比べ、PoC Exploitの情報収集の点で強みがあります。しかしながら多数のCVE-IDを渡すのは、API-Keyが現時点で非対応であることや、引数でしかCVE-IDを渡せない点で、脆弱性管理している多数のCVE-IDを渡すのは難しいかもしれません。しかしながら、別途選別したCVE-IDであれば、確認のために使っていくという使い方で十分かもしれません。また、PoC Explooitが1つでもあると最優先と判定されるのは、状況により気にする必要があるかもしれません（2024-02-29時点）
SSVCは、Risk = Threat x Vulnerability x Impact に対応するように設計されています。FuturVulsで利用している Deployer Tree 等は特にそうです。前述のプロジェクトは Impact に関する部分が考慮されていないという点が、SSVCとは異なる点だといえます。
各データやプロジェクトについてRISKという観点からまとめると以下の通りです。
CISA-Coordinator Treeの場合、Exploitation（none/poc/active）でEPSSやExploit有無を利用し、Automatable（no/yes）でKill ChainのSTEP 1-4（1.Reconnaissance, 2.Weponization, 3.delivery, 4.exploitation）を利用し、Technical Impactで技術的な影響度を検討し、Mission&Well-beingで業務影響を勘案したうえで、優先度をつけます。
同様にDeployer Treeの場合は、Exploitation（none/poc/active）、Exposure(small/controlled/open)でインターネットへの暴露状態を示し、Utility（laborious/efficient/superEffective）で攻撃者にとっての便利さを示し、Human Impact（low/medium/high/veryhigh）で安全とミッション（企業活動）への影響を勘案し、優先度をつけます。
impactに関する検討がなされない点は、状況により許容できると考えられます。大規模複数環境であれば一律のactionを設定することは難しい場合も多く、Impactにより対応の濃淡を環境内でつけることができます。また、コンピュータ系サービスを主業務にしていない業態の場合、システム停止時のImpactがコンピュータ系サービスとは異なることもあります。金融等では 停止=業務停止=損害 迄かなり近いことになりますが、例えば 他の業種であれば手動オペレーションで事業へのImpactをある程度低減できる（完全にITシステムに依存しているわけではない）という場合もあります。Impactの情報を定義するということは、第三者の情報ではな自ら決定する部分も増えます。ThreatやVulnerabilityはCVSSやEPSSなどの”他者”が提供するデータで定義できますが、Impactに関連するシステムのインターネット露出度やシステムの価値などは”自ら”で決める必要があります。その場合はSSVCを適用することが困難な場合があります。
上記のように、SSVCは主にImpactに関する指標を取り込むことで、脆弱性単体ではなく「事業リスク」という観点で優先度を示しています。
良い/悪い という問題ではなく、観点が異なるということを理解しておく必要があります。
EPSSとKEV Catalogの役割は、おおよそ見当つきましたでしょうか。
事業リスクという観点で見ると、CVE_PrioritizerやSploitScanは”Treat x Vulnerability” を示すものです。自組織のシステム状況などを考慮せずに使えるため、CVSS BaseScoreだけで判断している場合は、始めるのは比較的簡単なため、これらを使ってみるのもよいかもしれません。
また、大規模環境であったりSoC/CSIRTがあるような環境であれば、SSVCを利用する方が良いと思われます。大規模ほど”早急に優先的に対応すべき脆弱性”の数は増え、早急に優先的に対応すべきものの中でも再度優先順位をつける必要がある、という状況に対応しやすいと思います。
[PR]弊社FutureVulsではSSVCの機能を実装しており、以下2点を設定するだけで容易に利用可能です（要CSIRTプラン）。
ご興味のある方は、サイトの「サポート」からご連絡ください。
[/PR]
弊社は、SSVCをサポートした FutureVuls というサービスを提供しています。もしよろしければサービスページを訪問いただけると助かります。
また、セキュリティコンサル/脆弱性対応コンサルも行っております。ある程度は無償でご相談をお受けすることはできると思いますので、ご興味があればお問い合わせフォームからご連絡ください。
よろしくお願いいたします。
以上
Ubuntu:latest のイメージ上に、各プロジェクトを展開する例を示します。
/tmp を conatiner上の /mnt/share にマウントする
/tmp よりは /home/<username>/share 等の共有用ディレクトリを用意したほうが良いvimtutor でトレーニングするのが良い可能性がある