CVSS v4.0 主な変更点とよくある質問
2023年11月にCVSS v4.0が公開されました。前回のバージョンCVSS v3.1は2019年6月に公開されたため、4年ぶりの更新となります。
今回は、CVSS v3.1にどのような課題があったのか、それらを改善したCVSS v4.0の主な変更点をメインに紹介したいと思います。
（文字数が多くなってしまったので各章毎にまとめのスライド画像を載せています。そちらをご確認頂くことで概要の把握ができます。）
CVSS 年表
2023年11月にCVSS v4.0がリリースされました。CVSSがこれまでどのような経緯があったのか概要を紹介します。
2005年以前
- 各ベンダーが互換性のない評価システムを利用
- NIAC (National Infrastructure Advisory Council) がソフトウェアやプラットフォーム間で脆弱性の評価を標準化する必要性を認識
2005年2月 CVSS v1リリース
- 業界で広く採用されることを目的にリリースするも、事前にレビューをあまり受けていなかったために多くの批判を受ける
- メトリクスの定義が曖昧でスコアリングとスコアの解釈が難しい問題があった
- 2005年4月にNIACがFIRSTをCVSSの管理者として選定
2007年6月 CVSS v2リリース
- CVSS-SIGの10数名が、2006年から2007年にかけて数百もの実際の脆弱性でテスト
- 矛盾を減らし、粒度を増やし、当時の多種多様な脆弱性をより正確に反映するように改善した
2015年6月 CVSS v3リリース
- 1つのソフトウェアに存在する脆弱性が他のソフトウェアに影響を与えることを表現する「スコープ」の追加
- 用語の更新（アクセス -> 攻撃）、必要な特権レベルの導入、なし/部分的/全面的 → なし/低/高へ変更
2019年6月 CVSS v3.1リリース
- 新しいメトリクスなどの変更はなく、概念の明確さの改善、Roundupの処理の定義
- CVSS拡張フレームワークの追加
- 「CVSSは脆弱性の深刻度を測定するためのもので、単独でリスクを評価すべきではない」ことの強調
2023年11月 CVSS v4.0リリース
- CVSSは基本値 (Base Score) だけでないことをよりわかりやすくCVSS-Bなど命名法の変更
- 基本評価基準の改善、Scoreの廃止など
- IoT/ICS/医療機器領域に対応するためにSafetyの追加
- 補足評価基準 (Supplemental Metrics) の追加
- スコアリング方法の変更
CVSS v3.1での課題
改善されリリースされたCVSS v3.1ですが、以下のような課題がありました。
- CVSSの基本値がリスク分析で主に利用されている
- リアルタイムでの脅威と捕捉的な影響情報の詳細が表現できていない
- ITシステムにしか適用できない
- 健康、人的安全、産業制御システムにあまり適さない
- ベンダーが公開する脆弱性の深刻度が「High」「Critical」（スコア7.0以上）のものが多い
- 脆弱性を性質を表現するための粒度が荒い
- 現状評価基準 (Temporal Metrics) がCVSSのスコアに効果的に影響していない
- CVSSのスコアの計算が複雑で直感に反している
CVSS v4.0 変更点の概要
CVSS v3.1での課題を解決するためにCVSS v4.0では以下のような変更が入りました。
「CVSS-BTE」等の表記の追加
- 依然としてCVSSの基本値だけが利用され、基本値をリスク判断の材料とされていることへ対応
- 基本評価基準によるスコアの場合は「CVSS-B」など表記するように変更
基本評価基準の変更
- 「攻撃条件の複雑さ (AC:Attack Complexity) 」の改善
- 「ユーザ関与レベル (UI：User Interaction) 」の改善
- 「スコープ (S：Scope) 」の廃止
現状評価基準から脅威評価基準に変更
- 名称変更に加えて「利用可能な対策のレベル」と「脆弱性情報の信頼性」が廃止
- 簡素化され、CVSS-BTの評価が楽に
IoT/ICS/医療機器領域に対応するために「Safety」の追加
- これまでは、脆弱性によるITシステムへの影響のみを考慮
- 脆弱性が悪用された結果、人体に被害が発生した場合の影響を考慮できなかった問題に対応
補足評価基準の追加
- 脆弱性の特性を追加で表現し伝えられるようになった
- 補足評価基準の評価結果はスコアには影響を与えない
スコアリング方法の変更
- これまではCVSSのスコアの計算が複雑で直感に反しているという意見があったことへ対応
以降、それぞれどのような変更があったのか詳しく紹介します。
「CVSS-BTE」等の表記の追加
CVSS v3.1でも「CVSSは脆弱性の深刻度を測定するためのもので、単独でリスクを評価すべきではない」ことを強調する変更がありましたが、依然としてCVSSの基本値だけが利用され、基本値をリスク判断の材料とする流れは変わっていないように思います。
CVSS v4.0では、CVSSのスコアを表示する時にどの基準が使われているのかを以下のように表記するように改善されました。
- CVSS-B:基本評価基準
- CVSS-BE:基本と環境評価基準
- CVSS-BT:基本と脅威評価基準
- CVSS-BTE:基本と脅威と環境評価基準
このように表記されることで、使われているスコアが基本評価基準で算出されているのか、脅威評価基準まで含めているのかすぐにわかりますし、あくまで自分たちが利用しているのは基本評価基準のみであることもわかりやすくなったと思います。
このような命名法の変更以外にも、小さな変更ですがドキュメント内で基本値だけでなく、脅威評価基準、環境評価基準を使うことを更に強調するように変更されています。
v3.1
Scoring the Temporal and Environmental metrics is not required, but is recommended for more precise scores.
（日本語訳）時間的および環境的メトリクスのスコアリングは必須ではありませんが、より正確なスコアを得るために推奨されます。
v4.0
Assessment of the Threat and Environmental metrics is not required, but is highly recommended for more meaningful results.
（日本語訳）脅威と環境のメトリクスの評価は必須ではありませんが、より有意義な結果を得るために強く推奨されます。
変更点ではなくCVSS v3.1でも書かれていることですが、基本値は時間の経過とともに変化しない本質的な特性に従って脆弱性の重大度を反映し、さまざまな展開環境にわたる 「reasonable worst-case（合理的な最悪の場合）」 での影響を想定してスコアがつけられています。
そのため、CVSS-Bは他のCVSS-BT、CVSS-BTE等と比較して高い値になりやすくなっています。
ユーザーガイドにも書かれていますが、脅威インテリジェンスを利用しCVSS-BTEスコアを下げることで「合理的な最悪の場合」の基本値を調整し、多くのCVSS-Bが高くなりすぎてしまうという懸念に対処できます。
基本評価基準の変更
「攻撃条件の複雑さ (AC:Attack Complexity) 」の改善
「攻撃条件の複雑さ」が改善され、「攻撃条件の複雑さ」と新規追加の「攻撃の前提条件 (AT:Attack Requirements） 」に分割されました。
これまでの「攻撃条件の複雑さ」では、ASLRや暗号などの攻撃への緩和策の回避が必要な脆弱性とレースコンディションの脆弱性の場合、攻撃条件の複雑度が大きく異なりますが、同じ「高」に設定されてしまう問題がありました。
CVSS v4.0では、「攻撃条件の複雑さ」はASLRなどの緩和策を回避する条件があることや攻撃を成功させる前にターゲット固有のシークレットを収集することが必要などの条件があるかどうかが判断基準になります。
「攻撃の前提条件」では、レースコンディションや中間者攻撃などが必要な場合、デフォルトの設定ではなく、特定の設定・モジュールが有効化されている場合に影響を受けるなどが判断基準になります。
また、Attack RequirementsなのにARではなく、ATと略されているのはすでに環境評価基準にAvailability Requirements (AR) があるからです。
CVSS v4.0でこれまでの脆弱性を評価した例が公開され、そこでどのような場合に該当するのか詳しく確認できます。
https://www.first.org/cvss/v4.0/examples
「ユーザ関与レベル (UI：User Interaction) 」の改善
「ユーザ関与レベル」は、要/不要で評価されていましたが、アクティブ/パッシブ/不要で評価できるように改善され、より粒度が細かくなりました。
例としては、クロスサイトスクリプティング (XSS) の脆弱性の場合を紹介します。
リフレクション（反射型）クロスサイトスクリプティングでは、被害者が特定のリンクをクリックする必要があり、リンクをクリックする前にリンクを確認する機会がある（意識的な決定が行われる）と判断されるため、アクティブとなります。
一方、ストアド（蓄積型/持続型）クロスサイトスクリプティングでは、標準的な閲覧動作の中で悪用を引き起こす可能性があり、悪用される前に回避・認識する機会がない（意識的な決定がない）ため、パッシブとなります。
粒度が細かくなることで、脆弱性の特性を正しくスコアに反映でき、CVSSの評価結果を見ることでどんな脆弱性なのかを判断できるようになります。
「スコープ (S：Scope)」の廃止、脆弱なシステムへのインパクトと後続システムへのインパクトへ
「スコープ」では、脆弱なコンポーネントの脆弱性がセキュリティのスコープを超えて影響を与えるかどうかで評価されていました。
しかし、スコープという概念がわかりにくく、理解されていなかったために、脆弱性を評価する人毎に評価結果が変わってしまう問題を抱えていました。
FIRSTCON23というカンファレンスの発表資料の中でも「スコープはCVSSのメトリクスの中で最も愛されず、理解されなかったものかもしれない」と書かれています。
CVSS v4.0では、「スコープ」を廃止し、脆弱なシステムの機密性 (VC) ・完全性 (VI) ・可用性（VA）、後続システムの機密性 (SC)・完全性 (SI) ・可用性 (SA) で評価できるように改善されました。
「脆弱なシステム」と「後続システム」の境界線はどうなるのでしょうか。
FAQに書かれていますが、以下のような分け方になるようです。
大きなアプリケーションの特定のサービスに脆弱性が存在し、そのサービス自体では自立できない、サービスの集合体（アプリケーション）がそのサービスの存在が不可欠な場合、「脆弱なシステム」の範囲はアプリケーションになります。
一方、脆弱性のあるサービスがアプリケーションから分離でき、そのサービスがアプリケーションにとって不可欠でない場合、影響範囲はアプリケーションではなく、脆弱性のあるサービスになります。
サービスの脆弱性が、アプリケーションに影響を与える場合、アプリケーションが「後続システム」に含まれることになります。
現状評価基準から脅威評価基準に変更
現状評価基準 (Temporal Metrics) から脅威評価基準 (Threat Metrics) に名称が変更され、また「利用可能な対策のレベル (RL:Remediation Level) 」と「脆弱性情報の信頼性 (RC:Report Confidence) 」が廃止されました。
また 「攻撃される可能性 (E:Exploit Code Maturity) 」から「攻撃の成熟度 (E:Exploit Maturity) 」に名称が変更されました。
「コード」という言葉がなくなったことによって、コードの存在有無に関わらず、悪用が観測されているのかどうかといった情報も含まれることがわかりやすくなりました。
また、これまで
容易に攻撃可能 (H:High) /攻撃可能 (F:Functional) /実証可能 (P:Proof-of-Concept) /未実証 (U:Unproven)
の4つの分類でしたが、
攻撃されている (A:Attacked) /実証可能 (P:Proof-of-Concept) /未報告 (U:Unreported)
の3つになりました。
脅威評価基準がかなり簡素化されたため、CVSS-BTを評価することが楽になりました。
ドキュメント上でも以下のような文章が追加され、CVSS-BTを消費者側でを評価することが強調されています。
It is the responsibility of the CVSS consumer to populate the values of Exploit Maturity (E) based on information regarding the availability of exploitation code/processes and the state of exploitation techniques.
（日本語訳）攻撃コード/プロセスの可用性および悪用技術の状態に関する情報に基づいて、攻撃の成熟度 (E) の値を設定するのは、CVSSコンシューマーの責任です。
IoT/ICS/医療機器領域に対応するために「Safety」の追加
CVSS v3.1では、脆弱性によるITシステムへの影響を考慮したものになっているため、脆弱性が悪用された結果、人体に被害が発生した場合の影響を考慮できませんでした。
例として、インスリン管理システムで、攻撃者によってインスリン投与の制御ができる可能性がある脆弱性CVE-2020-10627があります。
安全性 (Safety) を考慮するために、CVSS v4.0では環境評価基準の「変更後の後続システムの完全性 (MSI:Modified Subsequent System Integrity) 」と「変更後の後続システムの可用性 (MSA:Modified Subsequent System Availability) 」では 高/低/無視できる に加えて、安全性 (S:Safety) をメトリクスの値として選択することができるようになりました。
加えて、新しい評価基準として追加された補足評価基準 (Supplemental Metrics) の中でも安全性 (Safety) というメトリクスで評価できるようになりました。
補足評価基準の追加
これまでは、基本評価基準、現状評価基準、環境評価基準の3つの評価基準があり、評価した結果はスコアに影響を与えました。
CVSS v4.0では、新しく補足評価基準 (Supplemental Metrics) が追加され、該当の脆弱性の特性を追加で表現し、利用者へ伝えられるようになりました。
補足評価基準は、安全性 (S:Safety) 、攻撃の自動化 (AU:Automatable) 、プロバイダー緊急度 (U:Provider Urgency) 、リカバリー (R:Recovery) 、値密度 (V:Value Density) 、脆弱性対応困難性 (RE:Vulnerability Response Effort) の6つのメトリクスがあり、このメトリクスは最終的なスコアには影響を与えません。
脆弱性情報の利用者側で、補足評価基準で共有された情報を参考にリスク分析を強化するために利用できます。
補足評価基準の各メトリクスの情報は、ベンダー側から任意で提供され、どのメトリクスを提供するのかもベンダー側で決められます。
たとえば、DoSの脆弱性があった場合、DoSによってサービスが停止するが、すぐに回復する脆弱性なのか (Automatic) 、管理者が再起動するまで回復しない脆弱性なのか (User)、回復させることが困難な脆弱性なのか (Irrecoverable) といった特性があると思います。
すぐに回復するDoS、回復が困難なDoS、どちらであってもCVSS-Bの可用性の評価では「高」として同じになりますが、特性を知ることで脆弱性対応の判断が変わる可能性があります。
このように、スコアには影響を与えないが、脆弱性の対応判断に影響を与える可能性のある情報を補足評価基準で得られます。
スコアリング方法の変更
これまでは、CVSSのスコアの計算が複雑で直感に反しているという意見があったようです。
また、CVSS v4.0のCVSS-BTEでは約1500万のベクトルがあるため、全てのパターンを確認し、スコアに違和感がないか確認することは現実的ではありません。
CVSS v4.0では、スコアリング方法に変更が入り、ベクトルをグループ化し、まず約1500万のベクトルを270に減らし、270個を専門家が評価できるようにしました。
メトリクスを6つのEQ （Equivalence class,同値類）としてまとめ、各EQの値 (0,1,2) がスコアに影響を与えるようになっています。
EQはEQ1からEQ6まであり、EQ1が最も重要な要素となり、EQ2が次に重要な要素となっています。
EQ1は、Attack Vector (AV) 、Privileges Required (PR) 、User Interaction (UI) の3つのメトリクスをまとめたものになります。
またEQ1が0~2のどのスコアになるのかは以下のように決定します。
AV:N/PR:N/UI:Nの場合はEQ1が0（最も深刻）
AV:A/PR:N/UI:N or AV:N/PR:L/UI:N or AV:N/PR:N:/UI:Pの場合はEQ1が1
AV:P/PR:N/UI:N or AV:A/PR:L/UI:Pの場合はEQ1が2（最も深刻ではない）
このように複数のメトリクスをEQとしてまとめ、どのような場合に深刻なのかどうかでスコアを決め、最終的にEQ1~EQ6のスコアからCVSSのスコアが決定するようになりました。
スコアリングに関して詳しく知りたい方は以下のドキュメント、GitHubのリポジトリをご確認ください。
https://www.first.org/cvss/v4.0/specification-document#CVSS-v4-0-Scoring
https://www.first.org/cvss/v4.0/user-guide#New-Scoring-System-Development
https://github.com/FIRSTdotorg/cvss-v4-calculator
よくある質問 (FAQ)
FIRSTよりよくある質問とその回答が公開されています。
https://www.first.org/cvss/v4.0/faq
その中から特に気になったものをピックアップして紹介します。
Q. CVSS v4.0は深刻度が「High」「Critical」に集中しすぎるスコアの問題にどのように対処しましたか?
CVSS v3.1のスコアが「High」「Critical」に集中している問題は、CVSS SIGがv4.0で解決しようとしていた問題ではありません。ベンダーが最も深刻な脆弱性の評価、発表、修正に注力するため、より多くの脆弱性が高い深刻度の脆弱性となります。
脅威と環境情報を利用して脆弱性の評価に適用し（できれば自動化し）、他の脆弱性よりも重要ではない脆弱性のスコアを下げるのは消費者の責任です。
たとえば、実際に悪用されておらず、概念実証コードが公開されていない脆弱性では、CVSS-BTEスコアが大幅に低下します。悪用された脆弱性はより高いスコアを維持し、消費者は重要なことに集中できるようになります。
Q. 「攻撃される可能性」を評価するのはプロバイダー（ベンダー）ではなく消費者の責任であるのはなぜですか？
これは、CVSS v4.0 に固有の質問ではなく、過去のすべてのバージョンに当てはまる一般的な質問です。
この責任がサプライヤー/ベンダーにある場合、すべてのサプライヤー/ベンダーは、組織がこれまでに発表したすべての脆弱性のエクスプロイトの成熟度を正確かつリアルタイムで理解する必要があります。明らかに、これは現実的ではなく、信頼性もありません。
ただし、これはまさに脅威インテリジェンスの情報源と組織が最も得意とすることです。消費者が利用できる無料のサブスクリプションベースの脅威インテリジェンスフィードが多数あり、環境内で検出された最大数の脆弱性にそのデータを適用できます。
Q. 脅威情報を適用すると結果として得られるCVSSスコアが低下するだけなのはなぜですか?
これはCVSS v4.0に限ったことではなく、過去のすべてのバージョンに当てはまるよくある質問です。一見すると、この概念は直感に反しているように見えます。
プロバイダーが公表のために脆弱性を評価するとき、彼らは仕様書に従って「合理的な最悪の場合」を想定します。
新しく発表された脆弱性の評価を行う際、プロバイダーはすべての脆弱性が悪意ある行為者によって悪用され、完全に武器化されることを想定しなければなりません。
利用可能な脅威インテリジェンスを適用し、検出された各脆弱性が攻撃の成熟度のどの位置にあるかを判断することは、利用者の責任です。悪用され、武器化されている脆弱性については、スコアは高いままです。悪用されておらず、概念実証 (POC) コードも公開されていない脆弱性については、スコアは低下し、重要性は低くなります。
Q. 「EPSS」「SSVC」はCVSSの代替品ですか?
EPSS、SSVCと呼ばれる脆弱性の優先順位付けや悪用の予測をサポートするシステムが公開されています。
EPSS：Exploit Prediction Scoring System
30日以内に悪用される可能性をデータドリブンで推測する取り組み
https://www.first.org/epss/
SSVC：Stakeholder-Specific Vulnerability Categorization
脆弱性へのアクションを決めるための優先順位付けフレームワーク
https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
https://github.com/CERTCC/SSVC
これらはいずれもCVSSに代わるものではありませんが、脆弱性対応の優先順位をより適切に評価、予測し、情報に基づいた意思決定を行うために併用できます。
まとめ
2023年11月にCVSS v4.0が公開され、多くの改善が行われました。
わかりにくかったスコープの廃止や名称を変更しシンプルになった脅威評価基準、Safetyを評価できるようにすることで医療機器など幅広く適用できるものへとなりました。
しかし、脆弱性の数が増え深刻度が高い脆弱性が増え続けている中でCVSSの基本値のみをリスク判断に使っている状態は変わっていないようです。
CVSSを評価する人、評価結果を受け取る人、追加で評価する人それぞれが正しく理解し利用する必要があります。
CVSS v4.0以外にも、EPSSやSSVCなど新たな取り組み、フレームワークも登場していますが、それぞれがどのような目的で作られたもので、どのように利用するものなのかを理解することが重要です。
例えば、EPSSがLog4Shellの時にどのようなスコアだったのかについて以下の記事がありますので興味がある方は見てみると面白いと思います。
https://www.first.org/epss/articles/log4shell
yamoryではオートトリアージ機能によりCVSSの情報だけでなく、攻撃コードの有無・悪用の観測状況（KEVカタログ）、システムの環境情報（公開サービスかどうか）を利用して脆弱性の対応優先度を自動で判別します。
yamoryでは、2023年の脆弱性セキュリティレポートを公開しております。
今年のセキュリティの傾向について知ることができますのでご興味がある方は以下のリンクよりダウンロードできます。
https://seminar.yamory.io/dl_security_report_2023
