共通脆弱性評価システム

共通脆弱性評価システム

略語	CVSS
状態	アクティブ
初版	2005年2月 ( 2005-02 )
最新バージョン	4.0
組織	インシデント対応およびセキュリティチームのフォーラム
ドメイン	情報セキュリティ
Webサイト	詳しくはこちら

共通脆弱性評価システム( CVSS ) は、コンピューティング システムの脆弱性の重大度を評価するための技術標準です。スコアは、エクスプロイトの容易さと影響を概算するいくつかの指標を使用した式に基づいて計算されます。スコアの範囲は 0 から 10 で、10 が最も重大です。重大度の判断には CVSS 基本スコアのみを使用する人が多いですが、緩和策の可用性と組織内で脆弱なシステムがどの程度広がっているかをそれぞれ考慮する時間スコアと環境スコアも存在します。

CVSSの現在のバージョン（CVSSv4.0）は2023年11月にリリースされました。^[1]

CVSSはパッチ管理の優先順位付けの方法として使用されることを意図したものではないが、そのように使用されている。^[2]

2003年から2004年にかけての国家インフラ諮問委員会（NIAC）による研究の結果、2005年2月にCVSSバージョン1（CVSSv1）が発表され、^[3]「ソフトウェアの脆弱性に対するオープンで普遍的な標準の重大度評価を提供するように設計」されることが目標とされました。この最初の草案は、ピアレビューや他の組織によるレビューの対象ではありませんでした。2005年4月、NIACは、将来の開発のためにCVSSの管理者として、インシデント対応およびセキュリティチームのフォーラム（FIRST）を選択しました。^{[4] [5]}

CVSSv1を本番環境で使用しているベンダーからのフィードバックでは、「CVSSの初期ドラフトには重大な問題がある」ことが示唆されました。CVSSバージョン2（CVSSv2）の作業は2005年4月に開始され、最終仕様は2007年6月に発表されました。^[6]

さらなるフィードバックの結果、2012年にCVSSバージョン3 ^[7]の作業が開始され、2015年6月にCVSSv3.0がリリースされました。^{[8] [3]}

CVSS 評価では、次の 3 つの懸念領域を測定します。

1. 脆弱性に固有の性質に関する基本指標
2. 脆弱性の存続期間中に変化する特性の時間的指標、および
3. 特定の実装または環境に依存する脆弱性の環境メトリック。

これらのメトリック グループごとに数値スコアが生成されます。ベクター文字列 (CVSSv2 では単に「ベクター」) は、すべてのメトリックの値をテキスト ブロックとして表します。

CVSSv2の完全なドキュメントはFIRSTから入手できます。^[9]以下に概要を示します。

アクセス ベクトル (AV) は、脆弱性がどのように悪用される可能性があるかを示します。

アクセス複雑度 (AC) メトリックは、発見された脆弱性を悪用することがどれだけ容易か困難かを表します。

認証 (Au) メトリックは、攻撃者がターゲットを悪用するために認証する必要がある回数を表します。これには、(たとえば) アクセスを取得するためのネットワークへの認証は含まれません。ローカルで悪用可能な脆弱性の場合、最初のアクセス後にさらに認証が必要な場合のみ、この値を Single または Multiple に設定する必要があります。

機密性 (C) メトリックは、システムによって処理されるデータの機密性への影響を説明します。

整合性 (I) メトリックは、悪用されたシステムの整合性への影響を説明します。

可用性 (A) メトリックは、対象システムの可用性への影響を表します。ネットワーク帯域幅、プロセッサ サイクル、メモリ、またはその他のリソースを消費する攻撃は、システムの可用性に影響を与えます。

これら 6 つのメトリックは、脆弱性の悪用可能性と影響のサブスコアを計算するために使用されます。これらのサブスコアは、全体の基本スコアを計算するために使用されます。

${\displaystyle {\textsf {悪用可能性}}=20\times {\textsf {アクセスベクトル}}\times {\textsf {アクセス複雑度}}\times {\textsf {認証}}}$

${\displaystyle {\textsf {インパクト}}=10.41\times (1-(1-{\textsf {ConfImpact}})\times (1-{\textsf {IntegImpact}})\times (1-{\textsf {AvailImpact}}))}$

${\displaystyle f({\textsf {影響}})={\begin{cases}0,&{\text{if }}{\textsf {影響}}{\text{ = 0}}\\1.176,&{\text{otherwise }}\end{cases}}}$

${\displaystyle {\textsf {BaseScore}}={\textsf {roundTo1Decimal}}(((0.6\times {\textsf {Impact}})+(0.4\times {\textsf {Exploitability}})-1.5)\times f({\textsf {Impact}}))}$

メトリックは連結され、脆弱性の CVSS ベクトルが生成されます。

バッファ オーバーフローの脆弱性は、Web サーバー ソフトウェアに影響を及ぼし、リモート ユーザーがシステムを部分的に制御してシャットダウンする機能などを取得できるようになります。

この場合、悪用可能性のサブスコアは 10、影響のサブスコアは 8.5 となり、全体の基本スコアは 9.0 になります。この場合の基本スコアのベクトルは、AV:N/AC:L/Au:N/C:P/I:P/A:C となります。スコアとベクトルは通常、受信者が脆弱性の性質を完全に理解し、必要に応じて独自の環境スコアを計算できるようにするために一緒に提示されます。

時間的メトリックの値は、脆弱性の存続期間中、エクスプロイトが開発、公開、自動化され、緩和策や修正が利用可能になるにつれて変化します。

エクスプロイト可能性 (E) メトリックは、エクスプロイト手法または自動化されたエクスプロイト コードの現在の状態を表します。

脆弱性の修復レベル (RL) により、緩和策や公式の修正が利用可能になると、脆弱性の一時スコアが下がります。

脆弱性のレポート信頼度 (RC) は、脆弱性の存在に対する信頼度と、脆弱性の技術的詳細の信憑性を測定します。

これら 3 つのメトリックは、すでに計算されている基本スコアと組み合わせて使用​​され、脆弱性とその関連ベクトルの一時スコアを生成します。

時間スコアを計算するために使用される式は次のとおりです。

${\displaystyle {\textsf {TemporalScore}}={\textsf {roundTo1Decimal}}({\textsf {BaseScore}}\times {\textsf {Exploitability}}\times {\textsf {RemediationLevel}}\times {\textsf {ReportConfidence}})}$

上記の例を続けると、ベンダーが最初に概念実証コードをメーリング リストに投稿して脆弱性を知らされた場合、初期の時間スコアは以下に示す値を使用して計算されます。

この場合、時間スコアは 7.3 となり、時間ベクトルは E:P/RL:U/RC:UC (または完全なベクトルは AV:N/AC:L/Au:N/C:P/I:P/A:C/E:P/RL:U/RC:UC) になります。

ベンダーが脆弱性を確認した場合、スコアは8.1に上がり、時間ベクトルはE:P/RL:U/RC:Cになります。

ベンダーからの一時的な修正によりスコアは 7.3 (E:P/RL:T/RC:C) まで下がりますが、公式の修正によりスコアはさらに 7.0 (E:P/RL:O/RC:C) まで下がります。影響を受けるすべてのシステムが修正またはパッチ適用されていると確信することはできないため、ベンダーの対応に基づいて一時的なスコアが特定のレベル以下に下がることはなく、脆弱性に対する自動エクスプロイトが開発されるとスコアが上がる可能性があります。

環境メトリックは、基本スコアと現在の一時スコアを使用して、脆弱な製品またはソフトウェアの展開方法のコンテキストにおける脆弱性の重大度を評価します。この尺度は、通常、影響を受ける当事者によって主観的に計算されます。

付随的損害の可能性 (CDP) メトリックは、脆弱性が悪用された場合に、機器 (および人命) などの物理的資産に対する潜在的な損失または影響、または影響を受ける組織への財務的影響を測定します。

ターゲット分布 (TD) メトリックは、環境内の脆弱なシステムの割合を測定します。

さらに 3 つのメトリックにより、機密性 (CR)、整合性 (IR)、可用性 (AR) に関する特定のセキュリティ要件が評価され、ユーザーの環境に応じて環境スコアを微調整できます。

5 つの環境メトリックは、以前に評価された基本メトリックおよび時間メトリックと組み合わせて使用​​され、環境スコアを計算し、関連する環境ベクトルを生成します。

${\displaystyle {\textsf {AdjustedImpact}}=\min(10,10.41\times (1-(1-{\textsf {ConfImpact}}\times {\textsf {ConfReq}})\times (1-{\textsf {IntegImpact}}\times {\textsf {IntegReq}})\times (1-{\textsf {AvailImpact}}\times {\textsf {AvailReq}})))}$

${\displaystyle {\textsf {AdjustedTemporal}}={\textsf {TemporalScore}}{\text{ }}{\textsf {BaseScore}}{\text{s }}{\textsf {Impact}}{\text{ サブ方程式を使用して再計算し、 }}{\textsf {AdjustedImpact}}{\text{ 方程式に置き換えます}}}$

${\displaystyle {\textsf {EnvironmentalScore}}={\textsf {roundTo1Decimal}}(({\textsf {AdjustedTemporal}}+(10-{\textsf {AdjustedTemporal}})\times {\textsf {Collat​​eralDamagePotential}})\times {\textsf {TargetDistribution}})}$

前述の脆弱な Web サーバーが銀行によってオンライン バンキング サービスの提供に使用されており、ベンダーから一時的な修正が利用可能である場合、環境スコアは次のように評価されます。

この場合、環境スコアは 8.2、環境ベクトルは CDP:MH/TD:H/CR:H/IR:H/AR:L となります。このスコアは 7.0 ～ 10.0 の範囲内であるため、影響を受ける銀行のビジネスの観点からは重大な脆弱性となります。

いくつかのベンダーや組織は CVSSv2 に対する不満を表明しました。

オープンソース脆弱性データベースを管理するリスクベースドセキュリティとオープンセキュリティ財団は、 CVSSv2の欠点と欠陥に関する公開書簡をFIRSTに共同で発表しました。^[10]著者らは、いくつかの指標の粒度が不十分であり、その結果CVSSベクトルとスコアが異なるタイプとリスクプロファイルの脆弱性を適切に区別できないと指摘しました。CVSSスコアリングシステムでは、脆弱性の正確な影響について過度の知識が必要であるとも指摘されました。

オラクルは、公式CVSS仕様における部分的と完全の間の説明における認識されたギャップを埋めるために、機密性、整合性、可用性の新しいメトリック値「部分的+」を導入しました。^[11]

これらの批判に対処するため、2012年にCVSSバージョン3の開発が開始されました。最終仕様はCVSSv3.0と名付けられ、2015年6月にリリースされました。仕様書に加えて、ユーザーガイドと例のドキュメントもリリースされました。^[12]

いくつかの評価基準が変更、追加、削除されました。数値式は、既存の0～10のスコア範囲を維持しながら、新しい評価基準を組み込むように更新されました。なし（0）、低（0.1～3.9）、中（4.0～6.9）、高（7.0～8.9）、重大（9.0～10.0）^[13]のテキストによる重大度評価が定義されました。これは、CVSSv2でNVDが定義したカテゴリに似ていますが、その標準には含まれていませんでした。^[14]

ベース ベクトルでは、ユーザー インタラクション (UI) と必要な権限 (PR) という新しいメトリックが追加され、悪用されるためにユーザー インタラクションまたはユーザーまたは管理者の権限を必要とする脆弱性を区別しやすくなりました。以前は、これらの概念は CVSSv2 のアクセス ベクトル メトリックの一部でした。UI は None または Required の値を取ることができます。ユーザーとしてログインする必要のない攻撃は、より深刻であると見なされます。PR は None、Low、または High の値を取ることができます。同様に、必要な権限が少ない攻撃はより深刻です。

また、ベース ベクトルには、どの脆弱性が悪用され、システムまたはネットワークの他の部分を攻撃するために使用される可能性があるかを明確にするために設計された新しいスコープ (S) メトリックが導入されました。これらの新しいメトリックにより、ベース ベクトルは、評価される脆弱性の種類をより明確に表現できます。

機密性、整合性、可用性 (C、I、A) メトリックが更新され、CVSSv2 の「なし」、「部分的」、「完全」ではなく、「なし」、「低」、「高」で構成されるスコアになりました。これにより、脆弱性が CIA メトリックに与える影響をより柔軟に判断できるようになります。

アクセス権限が別のメトリックに移動されたことを明確にするため、アクセスの複雑さは攻撃の複雑さ (AC) に名前が変更されました。このメトリックは、この脆弱性の悪用がどの程度再現可能であるかを示します。攻撃者が完全なタイミングやその他の状況 (ユーザー操作以外、これも別のメトリック) を必要とし、将来の試行で簡単に再現できない場合、AC は高くなります。

攻撃ベクトル (AV) には、実行するためにデバイスまたはシステムへの物理的なアクセスを必要とする脆弱性を表すために、新しいメトリック値である物理 (P) が含まれるようになりました。

時間的メトリックは CVSSv2 から基本的に変更されていません。

CVSSv2 の環境メトリックは完全に削除され、基本的に 2 番目の基本スコア (修正ベクトルと呼ばれる) に置き換えられました。修正ベースは、世界全体と比較した組織または企業内の差異を反映することを目的としています。特定の環境に対する機密性、整合性、可用性の重要性を捉える新しいメトリックが追加されました。

2015年9月のブログ投稿で、CERTコーディネーションセンターは、モノのインターネットなどの新興技術システムの脆弱性のスコアリングに使用するCVSSv2とCVSSv3.0の限界について説明しました。^[15]

CVSS のマイナー アップデートが 2019 年 6 月 17 日にリリースされました。CVSSv3.1 の目標は、新しいメトリックやメトリック値を導入することなく、既存の CVSSv3.0 標準を明確化して改善し、スコアリング プロバイダーとスコアリング コンシューマーの両方が新しい標準をスムーズに導入できるようにすることです。CVSS 標準を改善する際、使いやすさが主な考慮事項でした。CVSSv3.1 で行われるいくつかの変更は、CVSSv3.0 で導入された概念の明確さを改善し、それによって標準の全体的な使いやすさを向上させることです。

FIRST は、業界の専門家からの意見を取り入れて、CVSS を継続的に強化および改良し、過去 15 年以上にわたって開発されている脆弱性、製品、プラットフォームにますます適用できるようにしてきました。CVSS の主な目的は、さまざまな構成員にわたって脆弱性の重大度をスコアリングする決定論的かつ反復可能な方法を提供し、CVSS の消費者がこのスコアを、特定の環境とリスク許容度に固有のリスク、修復、および軽減のより大規模な意思決定マトリックスへの入力として使用できるようにすることです。

CVSSv3.1 仕様の更新には、攻撃ベクトル、必要な権限、範囲、セキュリティ要件などの既存の基本メトリックの定義と説明の明確化が含まれます。CVSS 拡張フレームワークと呼ばれる CVSS を拡張する新しい標準方法も定義され、スコアリング プロバイダーは、公式の基本メトリック、時間的メトリック、環境メトリックを保持しながら、追加のメトリックとメトリック グループを含めることができます。追加のメトリックにより、プライバシー、安全性、自動車、医療などの業界セクターは、コア CVSS 標準外の要素をスコアリングできます。最後に、CVSS 用語集が拡張され、CVSSv3.1 ドキュメント全体で使用されるすべての用語をカバーするように改良されました。

バージョン4.0は2023年11月に正式にリリースされ、^[1] FIRSTで入手可能です。^{[16]いくつかの明確化の中で、最も注目すべき変更点は、}攻撃の複雑さの指標を補完する新しい基本指標である攻撃要件です。これは、脆弱性を悪用するためにターゲット側でどのような条件が必要かを評価します。さらに、影響の指標は、脆弱なシステム自体への影響と後続のシステムへの影響に分割されています（これは、以前のバージョンの範囲の指標に代わるものです）。

基本メトリックは次のようになります。

• 攻撃ベクトル (AV):どの (物理的な) 方法で脆弱性を悪用できますか? [N]ネットワーク、[A]隣接(直接接続に限定)、[I]対話(SSH またはキーボード経由など)、[P]物理的(ハードウェアの操作または監視など)。
• 攻撃の複雑さ (AC):攻撃者が回避しなければならないさらなる対抗手段はありますか? また、回避するのはどの程度難しいですか? [ L]低い、または[H]高い(例: データ実行防止)。
• 攻撃要件 (AT):攻撃者が影響を与えることができない攻撃に必要な条件はありますか? [N]なし、または[P]存在(例: 競合状態に勝つ必要がある、またはシステムが特定の状態にある)。
• 必要な権限 (PR):ターゲット システムで何らかの権限が必要ですか? [N] なし (認証されていない)、[L] 低(通常のユーザー)、[H] 高(管理者アクセス)。
• ユーザーインタラクション (UI):システムの (正当な) ユーザーは、攻撃を可能にするために何かを行う必要がありますか? [N] なし、[P] 受動的(例: 悪意のある Web サイトに誤ってアクセスする)、[A] 能動的(例: 悪意のある Office マクロを実行する)。
• 脆弱なシステムの機密性の影響 (VC): [N] なし、[L] 低、[H] 高。
• 脆弱なシステム整合性への影響 (VI): [N] なし、[L] 低、[H] 高。
• 脆弱なシステム可用性への影響 (VA): [N] なし、[L] 低、[H] 高。
• 後続のシステム機密性の影響 (SC): [N] なし、[L] 低、[H] 高。
• 後続のシステム整合性への影響 (SI): [N] なし、[L] 低、[H] 高。
• 後続のシステム可用性への影響 (SA): [N] なし、[L] 低、[H] 高。

これらの基本メトリックに加えて、エクスプロイトの公開可能性、環境固有のスレッド モデリング、システム回復などに関するオプションのメトリックがあります。

オンライン ウェブ ショップでSQL インジェクションが発生したと仮定します。オンライン ショップ ソフトウェアのデータベース ユーザーは、データベースへの読み取りアクセス権のみを持っています。さらに、インジェクションは、登録済みの顧客のみが閲覧できるショップのビューで発生します。CVSS 4.0 の基本ベクトルは次のとおりです。

• AV:N脆弱性はウェブ上で引き起こされる可能性がある
• AC:Lは、スクリプトを介して SQL インジェクションを確実に悪用される可能性があります (オンライン ショップに対策がない場合)。
• AT:Nは、攻撃が特定のシステム条件に依存しないため
• PR:L攻撃者は通常のユーザーとして認証される必要があるが、管理者権限は必要ない
• 他のユーザーが関与していないため、UI:N
• VC:H攻撃者はデータベース内のすべてのテーブルを読み取ることができる
• VI:N攻撃者は書き込み権限を持たないため
• VA:L攻撃者がデータベースに対して長いクエリを実行し、一時的にデータベースの速度が低下したり、応答しなくなったりする可能性があるため
• SC:N (以降のシステムについては詳しい情報はありません)
• SI:N (以降のシステムについては詳しい情報はありません)
• SA:L注文管理や物流に関わる他のシステムも、応答しないデータベースの影響を受けることが予想されます。

この結果、ベクトルAV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:Lが生成される。

CVSS のバージョンは、次のような幅広い組織や企業で、脆弱性の重大度を定量化する主な方法として採用されています。

• 国家脆弱性データベース（NVD）^[17]
• オープンソース脆弱性データベース（OSVDB）^[18]
• CERTコーディネーションセンター^[19]は、特にCVSSv2ベース、時間的、環境的メトリクスを活用している。

• 共通脆弱性一覧(CWE)
• 共通脆弱性識別子(CVE)
• 共通攻撃パターンの列挙と分類(CAPEC)

• インシデント対応およびセキュリティチームフォーラム (FIRST) CVSS サイト
• 国家脆弱性データベース (NVD) CVSS サイト
• 共通脆弱性評価システム v2 計算機