CVSSとは？脆弱性の性質と重大性を共有するためのフレームワーク

　この記事ではCVSS(Common Vulnerability Scoring System)について解説します。昨年秋にCVSS v4.0が出ておりバージョン改訂も（数年に一回ほど）されていますので、本記事ではCVSS v3.1をベースとした一般的な話に留め、v4.0に関する詳しい説明は別の記事とさせていただきます。

実践的セキュリティスクール「セキュ塾」で、この記事の執筆者でもあり「OSINT実践ガイド」の著者でもある「面和毅」が主講師を務める「脅威インテリジェンス育成コース」の2024年11月2日より開講中！こちらの講座はいつからでも受講を開始できる講座になっておりますので、ぜひチェックしてみてください！

詳細はこちらから！

CVSS(Common Vulnerability Scoring System)とは
CVSSの構造
CVSSスコアとプライオリティ
CVSSスコアの提供元とNVD(National Vulnerability Database)
実際のCVSSスコアの提示のされ方
まとめ
参考リンク
- 関連記事:

CVSS(Common Vulnerability Scoring System)とは

　皆様も「脆弱性が出た！」というニュースをIT関係のネットニュースなどで聞かれた事があると思います。その際に「CVE-2024-6387」などのCVE-IDの他に「重大性を表すスコアは8.1」みたいな書き方がされていると思います。この「重大性を表すスコア」の部分がCVSSになります。　

　CVSSは脆弱性の性質と重大性を共有するためのフレームワークです。CVSSはFIRST（Forum of Incident Response and Security Teams：1990年に米国のCERT/CC等が中心になって設立された、世界中の CSIRT同士の情報交換やインシデントレスポンス業務の協力関係を構築する目的のフォーラム）が管理母体となっていて、仕様改善等を行っています。

CVSSに関しては

CVSSは重大性を測るものであり、それ単一でリスクを測るものではない
ということが再三強調されています。あくまでも「重大性」を測るものであり、これをリスク値として扱うことはできません。v4.0でさらに強調されていますので、この点に関しては気をつけた方が良いです。

CVSSの構造

　CVSSは下記の「Metric Group」から構成されています。

Base
Temporal (v4.0ではThreat)
Environment
Supplement (v4.0で追加されたもの)

　それぞれ「ベクトル（スカラー値のように単一な数値ではないのでベクトルになります。高校の数学で習うやつです）」で表されています。下記にCVSS v3.1とv4.0の画像を転記します。

FIRST: Common Vulnerability Scoring System v3.1: Specification Document より追加。CVSS v3.1

FIRST: Common Vulnerability Scoring System version 4.0: Specification Document より引用。CVSS v4.0

これらのMetric Groupに適切な値を入れていくことでCVSSベクトルが作成され、それらからCVSSスコアが決定されます。

FIRST: Common Vulnerability Scoring System v3.1: Specification Document より追加。CVSS v3.1の場合

　このスコアの導出はかなり難しい計算式になります。そのためFIRSTではベクトルを入れることで自動的にスコアが導出されるようなWebアプリケーションを用意しています。

FIRST: Common Vulnerability Scoring System Version 3.1 Calculator。後で説明する要素を選んでいくと自動的にスコアが計算され右上に「7.2(High)」などと表示される。

Base Metric Group

　Base Metricは時間やユーザー環境等に依存しない、脆弱性固有の特性を表します。これはExploitability metrics（悪用可能性メトリック）とImpact metrics（影響メトリック）の2種類のメトリックセットで構成されます。一般的に脆弱性のスコアが公開される場合には、このBase Metric Groupのみで計算されたスコアが示されています（Base Score: 8.1など）。

Exploitability metrics （悪用可能性メトリック）

　Exploitabiility metricsは脆弱性を悪用する際の容易さと技術的な方法から成り立っています。つまり脆弱性の特性を表し、vulnerable component（脆弱なコンポーネント）とも呼ばれています。脆弱なコンポーネントは通常、ソフトウェアアプリケーション・モジュール・ドライバーやハードウェア等になります。

　Exploitabiility metricsはvulnerable componentの特性を反映するため、以下のExploitabiility metricsはvulnerable componentを基準にしてスコア付けされ、攻撃の成功につながる脆弱性の特性を反映する必要があります。

Base metricsをスコア付けする場合に気をつけなくてはならない点として、攻撃者は一般的な構成やデフォルト/組み込みの防御メカニズムなど、標的について高度な知識を持っていると想定する必要があります。たとえば、繰り返して確実に成功する脆弱性を悪用した場合、攻撃者の知識や能力に関係なく、攻撃の複雑さの値は低いと見なされます。

更に標的固有の攻撃緩和策 (カスタマイズしたFirewallフィルタなど) は後述するEnvironment metricsに反映される必要があります。標的固有の構成はCVSS Base Scoreに影響を与えてはならないため、下記のパラメータを決める時には注意しなくてはなりません（攻撃が成功するために特定の構成が必要な場合は、脆弱なコンポーネントがその構成にあると想定してスコア付けする必要があります）。

Attack Vector (AV)

　このメトリックは、脆弱性の悪用が可能な状況を反映します。このメトリックでは攻撃者が脆弱なコンポーネントを悪用するためにどこにいる必要があるのかが表されています。リモートのネットワークから悪用される脆弱性に対する攻撃者数は、物理的アクセスが必要となる脆弱性を悪用する攻撃者の数よりも大きいと想定されるため、Base Scoreが高くなります。以下が可能な値になります。

Network (N)
- 一つ以上のネットワークホップで繋がっている相手から影響を及ぼされる。いわゆる「リモートからの悪用が可能」という状態
Adjacent（隣接）(A)
- ネットワークからは攻撃できるが、プロトコルレベルで隣接しているもの（Bluetoothや802.11, LANなど）からの悪用が可能という状態。
Local (L)
- 攻撃者はローカルデバイス（端末を開いて実際にコンソール上から何かを行う）やsshなどで外部からログインしてそのターミナル上で何かをすることで悪用が可能という状態。
Physical (P)
- 攻撃者が物理的に操作する必要があるもの。例えばUSBデバイスを挿入して何かを行うことで悪用が可能、という状態。

Attack Complexity (AC)

このメトリックは、脆弱性を悪用するための条件を表しています。重要な点として、このメトリックの評価では、脆弱性を悪用するためのユーザーインタラクション（他のユーザを騙して何かを実行させる必要があるか、など）の要件は除外されます。攻撃を成功させるために特別な構成が必要な場合は、脆弱なコンポーネントがその構成をされていると仮定して、基本メトリックをスコア付けする必要があります。基本スコアは、簡単な方が大きくなるようにされています。

Low(L)
- 特に条件が存在せず、攻撃者は繰り返し脆弱なコンポーネントを攻撃出来ます。
High(H)
- 攻撃が成功するかどうかは、攻撃者が制御できない条件に依存します。つまり、攻撃を成功させるには脆弱なコンポーネントに対して準備が必要になります。例えば下記の様なものが挙げられます。
  - 攻撃を行うターゲットに関して情報（設定、シーケンス番号、共有シークレット等）の収集が必要なもの。
  - 競合状態の脆弱性などを悪用するために繰り返しエクスプロイトを実行したり、OSのセキュリティ技術を掻い潜ってエクスプロイトを実行させたりする必要があるもの。
  - 通信を傍受するためにあらかじめ準備が必要なもの（MITM: 中間者攻撃など）。

Privileges Required (PR)

このメトリックは、攻撃者が脆弱性を悪用する際にどのレベルまでの権限を持っていなければならないかを表しています。必要な権限が少ないほどBase Scoreが上がる様になっています。

None(N)
- 攻撃者は攻撃前に権限は必要がなく、攻撃を実行するために対象システムの設定やファイルにアクセスする必要はありません。
Low(L)
- 攻撃者には、一般ユーザが所有者になっている設定やファイルにのみアクセス権がある、基本的なアクセス権限が必要です。言い換えると、機密性のないリソースにアクセスできる権限があれば、攻撃者は脆弱性を悪用できます。
High(H)
- 攻撃者が脆弱性を悪用する際には、重要な（つまり管理者などの）アクセス権が必要になります。

User Interaction (UI)

このメトリックは、攻撃者以外の別のユーザの関与が脆弱性悪用に必要かを示しています。Base Scoreは、別のユーザーの関与が不要な場合に最大になります。

None(N)
- 脆弱性は別のユーザの関与なしに悪用される可能性があります。
Required(R)
- 脆弱性を悪用するには、脆弱性が悪用される前に別のユーザーが何らかのアクションを実行する必要があります。たとえば、システム管理者がアプリケーションのインストーラを走らせている間のみ悪用が可能、などです。

Scopre metrics (スコープメトリック)

　スコープメトリックは、脆弱なコンポーネントの脆弱性が、セキュリティスコープ外のコンポーネントに影響を与えるかどうかを表しています。正確に言うと

特定の主体/アクター (人間のユーザー、プロセスなど) が特定のオブジェクト (ファイル、CPU、メモリなど) にアクセス制御された方法でアクセスする場合に
アクセス制御を提供するメカニズム（アプリやOS, Sandboxなど）では、すべての主体とオブジェクトが1つのセキュリティスコープ内にあると見なされます。

　コンポーネントの脆弱性が異なるセキュリティスコープに影響を与える可能性がある場合は、スコープの変更が発生します。平たく言うと、脆弱性の影響がセキュリティ境界を侵害してセキュリティスコープ外に影響を与える場合にスコープの変更が発生します。例を挙げるとLog4Shell(CVE-2021-44228)などはスコープの変更が発生する良い例です。log4jでのログを別のロギングホストに渡している場合、ログイベントはlog4jの入っているシステムで発生しますが、コードの実行は別のシステム（ロギングホスト）で行われます。

スコープ(SC)の値は以下のどれかになります。

Unchanged (U)
- 脆弱性の悪用は、同じセキュリティ機構によって管理されているリソースにのみ影響を及ぼします。この場合、脆弱なコンポーネントと影響を受けるコンポーネントは同じであるか、両方とも同じセキュリティ機構で管理されています。
Changed (C)
- 脆弱性の悪用は、脆弱なコンポーネントを超えたリソースに影響を及ぼす可能性があります。この場合、脆弱なコンポーネントと影響を受けるコンポーネントは異なり、異なるセキュリティ機構で管理されています。

Impact metrics（影響メトリック）

　Impact metricsは悪用が成功した場合の直接的な結果を反映し、impacted component（影響を受けるコンポーネント）に対する結果を表しています。impacted componentはソフトウェアアプリケーション・ハードウェアデバイス等があります。また、ネットワークリソースもimpacted componentになる可能性があります。

Confidentiality (C)

　このメトリックは、脆弱性の悪用によって脆弱性のあるコンポーネントの情報リソースの機密性に及ぼされる影響を表します。

High(H)
- 機密性が完全に失われ、影響を受けるコンポーネント内のすべてのリソースが攻撃者に漏洩します。または、一部の制限された情報が漏洩しますが、その情報が直接的で重大な影響を及ぼすものです。たとえば脆弱性の悪用により、管理者のパスワードや WebサーバーのSecretキーを盗める場合などです。
Low(L)
- 機密性が多少失われます。一部の制限された情報が漏洩しますが、攻撃者が取得される情報を制御できなかったり、損失の量や種類が制限されるものです。つまり情報の漏洩によって影響を受けるコンポーネントに直接的な損失が発生しないものです。
None(N)
- 影響を受けるコンポーネント内で機密性が失われることはありません。

Integrity (I)

　このメトリックは、脆弱性の悪用によって脆弱性のあるコンポーネントの情報リソースの整合性に及ぼされる影響を表します。

High(H)
- 整合性が完全に失われます。たとえば攻撃者が脆弱性を悪用することで、影響を受けるコンポーネントで保護されたすべてのファイルを変更できる場合などです。または、一部のファイルのみを変更できるが、影響を受けるコンポーネントに重大な結果をもたらす場合（sudoersファイルの変更等）などです。
Low(L)
- データの変更は可能ですが、攻撃者が変更の結果を制御できなかったり、変更できるものが制限されている場合です。この場合、データの変更によりコンポーネントは重大な影響を受けません。
None(N)
- 影響を受けるコンポーネント内で整合性が失われることはありません。

Availability (A)

　このメトリックは、脆弱性の悪用によって脆弱性のあるコンポーネントの情報リソースの可用性に及ぼされる影響を表します。

High(H)
- 可用性が完全に失われ、結果として攻撃者は、影響を受けるコンポーネントのリソースへのアクセスを完全にダウンさせる事ができます。この損失は持続的 (攻撃者が攻撃を続けている間) または永続的 (攻撃が完了した後も状態が続く) のいずれかです。あるいは、攻撃者は一部の可用性を失わせられますが、可用性の損失が影響を受けるコンポーネントに深刻な結果をもたらすものです。
Low(L)
- パフォーマンスが低下したり、リソースの可用性が中断します。脆弱性を繰り返し悪用しても、攻撃者はサービスを完全に拒否状態にすることができないものです。
None(N)
- 影響を受けるコンポーネント内で可用性が失われることはありません。

Temporal Metrics

　Temporalメトリックは、エクスプロイトコードが出回っているか、パッチや迂回策の存在、脆弱性の説明に対する信頼性を測定します。

Exploit Code Maturity (E)

　このメトリックは通常、エクスプロイトの入手のし易さ、またアクティブな「実際の」エクスプロイトの現状に基づいて決められます。簡単に使用可能なエクスプロイトコードが公開されると、スキルのない攻撃者も攻撃ができるため潜在的な攻撃者の数が増え、脆弱性の深刻度が高まります。エクスプロイト公開の当初では、エクスプロイトは理論的なものに過ぎない場合もあります。

　さらに、利用可能なエクスプロイトコードが実際の攻撃コードに進化する可能性があります。深刻なケースでは、ネットワークベースのワームやウイルス、またはその他の自動化された攻撃ツールのペイロードとなって配信される可能性があります。

Not Defined (X)
- 他の値のどれかを選択するための情報が不十分であることを表しています。これを割り当てても、全体的なTemporal Scoreには影響しません。つまり、Scoreには「高」を割り当てた場合と同じ影響があります。
High(H)
- 実用的な自立コードが存在する場合や、エクスプロイトが不要 (手動トリガー) であって詳細が広く入手可能な場合です。エクスプロイトコードがあらゆる状況で機能するか、ワームやウイルスなどの自立エージェントによってアクティブに配信されています。ネットワークに接続されたシステムは、スキャンやエクスプロイトの試みに遭遇する可能性があります。エクスプロイトは信頼性が高く、広く入手可能で、使いやすい自動化ツールのレベルにまで達しています。
Functional(F)
- 実用的なエクスプロイトコードが利用可能です。このコードは、脆弱性が存在する殆どの状況で機能します。
Proof-of-Concept(P)
- PoCとしてのエクスプロイトコードが利用可能であlたり、実用的ではない攻撃のデモンストレーションがある場合です。コードや手法はすべての状況で機能するわけではなく、ベテランの攻撃者による大幅な変更が必要になる場合があります。
Unproven(U)
- エクスプロイトコードが利用できなかったり、理論上のみエクスプロイトが存在するものです。

Remediation Level (RL: 修復レベル)

　脆弱性の修復レベル(Remediation Level)は、優先順位付けの重要な要素です。通常、脆弱性が最初に公開された時点ではパッチは存在していません。公式のパッチやアップグレードが発行されるまで、迂回策やホットフィックスによって暫定的な修復が提供される場合があります。これらの各段階では、修復が最終段階になるにつれて緊急度が下がることを反映して、Temporal Scoreが下方に調整されます。

Not Defined (X)
- 他の値のどれかを選択するための情報が不十分であることを表しています。これを割り当てても、全体的なTemporal Scoreには影響しません。つまり、Scoreには「Unavailable」を割り当てた場合と同じ影響があります。
Unavailable (U)
- 解決策や迂回策が存在しないものです。
Workaround (W)
- 非公式だったり、非ベンダーのソリューションが利用可能です。また脆弱性を回避または軽減するための手順が非公式に提供されているものです。
Temporary Fix (T)
- 公式ではあるが一時的な修正プログラムが利用可能です。これには、ベンダーが一時的な修正プログラムやツール、迂回策を提供する場合が含まれています。
Official Fix (O)
- ベンダーによる完全な修正が利用可能です。ベンダーが公式パッチを発行していたり、アップグレードが利用可能なものになります。

Report Confidence (RC)

　このメトリックは、脆弱性に対する信頼度と、技術的詳細の信憑性を提供します。脆弱性の存在のみが公表されて、具体的な詳細は公表されない場合があります。

　或いは影響が望ましくないと認識されているが根本原因が不明な場合があります。

　脆弱性は後に研究によって裏付けられ、脆弱性がどこにあるのかが示唆される場合もありますが、その研究が確実でない場合があります。

　脆弱性の存在が確実にわかっている場合、脆弱性の緊急性は高くなります。このメトリックは、攻撃者が利用できる技術的知識のレベルも示しています。脆弱性がベンダーやその他の信頼できるソースによって検証されるほど、スコアは高くなります。

Not Defined (X)
- 他の値のどれかを選択するための情報が不十分であることを表しています。これを割り当てても、全体的なTemporal Scoreには影響しません。つまり、Scoreには「Confirmed」を割り当てた場合と同じ影響があります。
Confirmed (C)
- 詳細なレポートが存在するか、再現が可能な場合です。
Reasonable (R)
- 重要な部分は公開されていますが全てを完全に確認するためのソースコードにアクセスできない状態で、バグが再現可能であり、少なくとも1つの影響が検証可能であるという合理的な理由が存在する場合です。例としては、結果を再現する方法 (コードが難読化されていたり、「読者の課題として残されている」と言う記述があるもの) が付いたレポートがある場合です。
Unknown (U)
- 脆弱性が存在することを示す影響の報告がありますが、脆弱性の原因が不明であることや、脆弱性の原因・影響について異なる可能性があることが示されている場合です。例としては再現不可能なクラッシュが複数回発生しており、DoS等の可能性を示唆する報告がある場合です。

Environment Metrics

　このメトリックは、実施されている補完的/代替的なセキュリティ制御、機密性、整合性、可用性の観点から測定された、現実のユーザーの組織に対して影響を受けるIT資産の重要性に応じてCVSS スコアをカスタマイズするものです。メトリックはBase Metricsの修正であり、現実のユーザ組織のインフラに基づいて値が割り当てられます。

Security Requirements (CR, IR, AR)

　これらのメトリックにより、現実のユーザーの組織に対して影響を受けるIT資産の重要性に応じて、CVSSスコアを機密性、整合性、可用性の観点から調整できます。

　例えば資産が「可用性が最も重要であるビジネス機能をサポート」している場合には、機密性や整合性よりも可用性に高い値を割り当てることができます。各セキュリティ要件には、低、中、高の 3 つの値があります。

Not Defined (X)
- 他の値のどれかを選択するための情報が不十分であることを表しています。これを割り当てても、全体的なEnvironment Scoreには影響しません。つまり、Scoreには「Medium」を割り当てた場合と同じ影響があります。
High(H)
- 脆弱性のあるコンポーネントの[機密性 | 整合性 | 可用性] の損失が、現実の組織または組織に関連する個人 (従業員、顧客など) に壊滅的な悪影響を及ぼす可能性があります。
Medium(M)
- 脆弱性のあるコンポーネントの[機密性 | 整合性 | 可用性] の損失が、現実の組織または組織に関連する個人 (従業員、顧客など) に重大な悪影響を及ぼす可能性があります。
Low(L)
- 脆弱性のあるコンポーネントの[機密性 | 整合性 | 可用性] の損失が、現実の組織または組織に関連する個人 (従業員、顧客など) に限定的な悪影響しか及ぼさな可能性があります。

Modified Base Metrics

　これらのメトリックは、現実のユーザー環境に基づいて、個々のBase Metricsを上書きします。

　例として、脆弱なコンポーネントのデフォルト構成では、管理者権限でサービスが実行されており、攻撃により機密性・整合性・可用性への影響が高くなるが、現実のユーザ環境では同じサービスが限定的な権限で実行されている場合があります。この様な場合、変更された機密性・変更された整合性・変更された可用性をそれぞれ低にします。

　以下にそれぞれ設定できるメトリックを示します。「Modified」となっているだけで、対応する基本メトリックと同じ種類の値を取ります。

Modified Attack Vector (MAV)
Modified Attack Complexity (MAC)
Modified Privileges Required (MPR)
Modified User Interaction (MUI)
Modified Scope (MS)
Modified Confidentiality (MC)
Modified Integrity (MI)
Modified Availability (MA)

CVSSスコアとプライオリティ

　CVSSスコア（Base, Temporal, Environmentそれぞれ）とプライオリティは以下の様になります。

プライオリティ（重大度）	CVSS Score
None	0.0
Low	0.1-3.9
Medium	4.0-6.9
High	7.0-8.9
Critical	9.0-10.0

CVSSスコアの提供元とNVD(National Vulnerability Database)

　CVSSスコアは

CNA(CVE-IDをアサインする権利を持ったベンダー)が提供する
CISA-ADPが提供する
開発元ベンダー（OSSの場合には開発プロジェクト）が提供する
NIST(National Institute of Standards and Technologyの略で「米国国立標準技術研究所」)が提供するNVD(National Vulnerability Database)が調査の上提供する
セキュリティベンダーが提供する

などがあります。CNAが提供したCVSSスコアはcve.orgのCVE-IDから確認する事ができます。

https://www.cve.org/CVERecord?id=CVE-2024-6387

　NVDが提供したCVSSスコアはNVDのサイト(nvd.nist.org)から見る事ができます。

https://nvd.nist.gov/vuln/detail/CVE-2021-44228 より転記

　NIST/CNAの両方がCVSSを提供した場合には、NVD上では両方が見える形になります(CISA-ADPが提供した場合も同様です)。

https://nvd.nist.gov/vuln/detail/CVE-2023-26221 より転記

https://nvd.nist.gov/vuln/detail/CVE-2023-38831 より転記

実際のCVSSスコアの提示のされ方

　前述までの説明から分かる通り、CVSSでもBase, Temporalに関してはベンダー側で提供することが可能です。一方で、Environmentについては現実の顧客環境で大きく変化するため、顧客側の状況に合わせて値を調整する必要があります。つまり、Environmentに関してはユーザ側（或いは顧客環境をサポートするSIer等）が算出する必要があります。

　多くのベンダーではCVSSに関してはBaseのVectorとスコアしか出していません。例えば下記はRed Hatのセキュリティアラートになります。