【翻訳】CVSS v4.0ユーザガイド

ここでは、2023年11月にリリースされたCVSS v.4.0のユーザガイドの翻訳を載せています。5章（用語集）、および６章（スコアリングルーブリック）に関しては、原文を参照してください。

1. イントロダクション

このガイドは、CVSS ver 4.0の仕様文書を補足するもので、CVSS ver 3.1 からの重要な変更、追加のスコアリングガイダンス、スコアリングの評価基準などの追加情報が含まれています。

2. CVSS ver 4.0 での変更点

CVSS ver 3.xから4.0への変更では、既存のスタンダードの明確化と改善に重点を置いています。

2.1 CVSSの命名法

CVSS Scoreの数値は、計算に使用されるメトリックに基づいて非常に異なる意味を持ちます。優先順位付けに関しては、CVSS Scoreの数値の有用性は、そのScoreを生成するために利用されたCVSSメトリクスに直接比例します。したがって、CVSS Scoreの数値は、生成に使用されるメトリックを伝える命名法を使用して列挙する必要があります。

CVSS の命名法使用される CVSS メトリクス
CVSS-BBase metrics（ベースメトリクス）
CVSS-BEBase and Environmental metrics（ベースと環境メトリクス）
CVSS-BTBase and Threat metrics（ベースと脅威メトリクス）
CVSS-BTEBase, Threat, Environmental metrics（ベース、脅威、環境メトリクス）

その他の注意事項：

  • この命名法は、CVSS Scoreの数値が表示または伝達される場合には常に使用する必要があります。
  • 環境(Environment)および脅威(Threat)メトリクスの適用は、CVSSを使用するユーザ側の責任です。製品メンテナーなどの評価プロバイダーや、National Vulnerability Database (NVD)などのその他の公的/民間団体は、通常CVSS-Bとなるベーススコアのみを提供します。
  • スコアを生成する際に環境メトリクスが使用される場合には、命名法に「E」を含めることが適切です。
  • スコアを生成する際に脅威メトリクスが使用される場合には、命名法に「T」を含めることが適切です。
  • CVSS v4.0 では、最終スコア(final score)の計算では、ベース(Base)・脅威・環境メトリックが常に考慮されます。 明示的に脅威／環境メトリックが選択されていない場合でも、デフォルト (“Not Defined : 未定義“) の値を使用した完全なスコアが得られます。 この命名法により、提供されるCVSS Scoreの数値でどのメトリックが考慮されたかが明示的かつ明確になります。

2.2 CVSS Baseスコア (CVSS-B) はリスクではなく重大度を測定

　CVSSの仕様が更新され、CVSS Base (CVSS-B)スコアは脆弱性の重大度を測定するように設計されており、リスク評価に単独で使用すべきではないという事実がより強調され明確化されました。

　CVSS v4.0仕様ドキュメントでは、CVSS Baseスコアは脆弱性の本質的な特性のみを表し、脅威に関連する要因や脆弱なシステムが存在する環境には依存しないと明確に記載されています。

　CVSS Baseスコアは、環境の分析 (環境メトリクス) と、時間の経過とともに変化する可能性のある属性 (脅威メトリクス) で補足する必要があります。

　自動化ツールなどを採用して環境メトリクスと脅威メトリクスを包括的に利用している組織の場合、結果として得られる CVSS-BTE スコアは「リスク」にはるかに近いと考えられます。

2.3 評価ガイダンスの変更

　CVSS 仕様ドキュメントとユーザー ガイドは、以前は曖昧だと考えられていた様々な状況にわたって、CVSSアナリストが一貫性と防御可能かどうかの結果を表すスコアを生成できるように、ガイダンスを追加して更新されました。 新しい評価ガイダンスのサンプルを以下に示します。

2.3.1 スコープ(Scope)の削除

　スコープの概念は、脆弱なシステム (VC／VI／VA) と後続のシステム (SC／SI／SA) の概念に置き換えられました。 詳細については、セクション3.7を参照してください。

2.3.2 ソフトウェア ライブラリ (および類似のもの) の脆弱性の評価

　新しいガイダンスでは、ライブラリの脆弱性の影響を評価する方法について説明しています。 詳細については、セクション3.9を参照してください。

2.3.3 複数のCVSS Base (CVSS-B) スコア

　ガイダンスでは、複数の製品バージョン・プラットフォーム・OSに影響を与える脆弱性に対して複数のCVSS Baseスコアを生成することを明示的に許可しています。 詳細については、セクション3.10を参照してください。

2.3.4 環境セキュリティ要件メトリクスの使用方法のガイダンス

　環境メトリクスには、脆弱なシステムの機密性要件 (CR)・脆弱なシステムの完全性要件 (IR)・脆弱なシステムの可用性要件 (AR) の3つのセキュリティ要件メトリクスが含まれています。 セクション3.14には、これらの指標の使用方法を説明する新しいガイダンスと例が含まれています。

2.4 サプリメンタルメトリクスの使用方法のガイダンス

　新しいサプリメンタルメトリクスのそれぞれを評価するためのガイダンスは、セクション4.0に記載されています。

2.4.1 新たなBase メトリック: Attack Requirements（攻撃の要件）

　CVSS v3.1では、”Low(低)”および”High(高)”のAttack Complexity(AC: 攻撃の複雑度) の値は、”High”の複雑さの定義で現在暗黙的に含まれている条件の大きな違いを反映していません。 たとえば、ASLRや暗号化などのセキュリティ手法を回避するには、競合状態を悪用する攻撃を繰り返すよりも、客観的に見てはるかに高いエクスプロイトの複雑さが必要です。しかし、CVSS v3.1ではどちらの条件も最終的な重大度スコアに対して同じだけの”ペナルティ”をもたらしています。

　この問題に対処するために、CVSS v4.0ではACの定義を”Attack Complexity”(攻撃の複雑さ：AC)と”Attack Requirements” (攻撃の要件：AT)の2つの指標に分割しています。これらの指標はそれぞれ次の内容を伝えます。

  • Attack Complexity(攻撃の複雑さ:AC) – 防御技術やセキュリティ強化技術を回避するために必要なエクスプロイト作成技術の複雑さを反映します。 （防御策）
  • Attack Requirements(攻撃の要件:AT) – 攻撃を可能にする脆弱なコンポーネントの前提条件を反映します。

2.4.2 更新されたBaseメトリック: User Interaction（ユーザの関与）

　User Interaction（ユーザの関与）のBaseメトリックが更新され、脆弱なコンポーネントとユーザー関与の関係を考慮する際の粒度がさらに向上しました。詳細は次のとおりです。

  • None (N): 脆弱なシステムは、攻撃者以外のユーザー(人間)による介入なしに悪用される可能性があります。
  • Passive(P): この脆弱性の悪用に成功するには、脆弱性のあるコンポーネントと攻撃者のペイロードの間に、標的となったユーザによる限られた関与が必要です。 この関与は無自覚なものとみなされ、脆弱性のあるコンポーネントに組み込まれている保護を、ユーザーが積極的に無効にする必要はありません。
  • Active(A): この脆弱性の悪用に成功するには、ユーザーが脆弱性のあるコンポーネントおよび攻撃者のペイロードに対して特定の意識的な操作を実行したり、あるいは脆弱性を悪用するためにユーザーの操作によって積極的に保護メカニズムを破壊する必要があります。

2.4.3 Temporal(現状値)メトリックグループがThreat(脅威)メトリックグループへ名称変更

Temporal(現状値)メトリックグループにいくつかの変更が加えられました。

  • Temporal(現状値)メトリックグループはThreat(脅威)メトリックグループへと名称変更されました。
  • Remediation Level(利用可能な対策のレベル: O)とReport Confidence(脆弱性情報の信頼性:C)は廃止されました。
  • Exploit Code Maturity(攻撃される可能性)はExploit Maturity(悪用される可能性)に変更されました。
  • 脅威メトリック値のImpact(インパクト)が強化されました。

Threatメトリックグループは、脅威インテリジェンスを使用してCVSS-BTEスコアを下げることにより、「合理的な最悪のケース」の基本スコアを調整し、多くのCVSS (Base)スコアが高すぎるという懸念に対処します。

2.5 CVSS拡張フレームワーク

　セクション3.11では、公式のBase・脅威・環境メトリクスを保持しながら、追加のメトリクスとメトリクスグループを含めるようにCVSSを拡張する標準的な方法を定義します。 指標を追加することで、プライバシー業界や自動車などの業界でCVSS標準外の要素を評価できるようになります。

2.6 新しいスコアリングシステムの開発

　CVSS v4.0 のスコアリングシステムの開発は、次のような大まかな手順(ステップ)で行われました。 各ステップについては、以下でさらに詳しく説明します。

  1. メトリックグループを使用して、1,500万のCVSS-BTEベクトルを270の同値集合に分類しました。
  2. 専門家に依頼して各同値集合を表すベクトルを比較してもらいました。
  3. 専門家の比較データを使用して、最も重大度の低いベクトルから最も重大度の高いベクトルの順序を計算しました。
  4. CVSS v3.xの定性的な重大度スコアと互換性を持たせるために、ベクトルの順序付けにおいてどのベクトルグループが定性的な重大度スコアを表すかを決定するため、専門家の意見を求めました。
  5. 各定性的重大度内のベクトルグループを、その内の利用可能なスコアに圧縮しました (例えば重大の場合は9.0～10.0、高の場合は7.0～8.9など)。
  6. メトリック値の変更によってスコアが変更されるように、ベクトルグループ内のスコアを調整する小さなスコア変更係数を作成しました。 その目的は、スコアの変化が上記ステップ2で専門家による比較データから収集されたベクトルグループのランキングを超えないようにするためです。

これら6つの各ステップの詳細は次のとおりです。

2.6.1 メトリックグループを使用して、1,500万のCVSS-BTEベクトルを270の同値集合に分類

　このステップは、いくつかの設計要件を満たすのに役立ちます。

1つ目は、101個のCVSSスコア(0.0～10.0で0.1刻み)があることです。

2つ目は、ボランティアでCVSS Special Interest Group (SIG)に専門家が提供できる時間をそれほど使わずにスコアリングシステムを作成することです。これが最初の要件を満たすのにどのように役立つかはわかりやすいと思います。1,500万のオプションと101の可能なスコアがある場合、それらの多くはスコアを共有する必要があるため、考えられるすべてのベクトルを何らかの方法でグループ化する必要があります。このステップによってシステムへの専門家の労力がどのように削減されるかはわかりにくいですが、ステップ2でより明確になります。

　基本的な考え方は、1,500万個のベクトルは、専門家が達成可能な時間内にすべてを個別にランク付けするには多すぎるということです。これはどの並べ替えアルゴリズムでも、並べ替えられる要素の数に比例した数の比較が行われるため当てはまります。通常、作業はリストサイズよりも速い順序で増加します(計算用語では、nlog(n)のオーダーです。並べ替えアルゴリズム-Wikipediaを参照)。スコアリングシステム設計への影響は、CVSSベクトル空間全体についてスマートな入力を取得したい場合、専門アナリストから収集したデータを構造化して使用するのに役立つ、それに関するいくつかのルールを考える必要があることです。

2.6.2 専門家に依頼して各同値集合を表すベクトルを比較してもらう

　比較する項目の総数が 1,500 万から 270 に減少したため、専門家に各要素を他の要素と比較して、メトリク グループ ベースの定性的なベクトルのセットの重大度を完全に順序付けるように依頼することが可能になりました。 これは魅力的なアイデアです。SIG は、CVSS ベクトル空間からサンプリングすることなく、関係するすべての SIG メンバーからの入力に基づいて、再現可能かつプライベートな方法で、考えられるすべての BTE ベクトルのスコアを定義できるからです。 つまり、メトリクスグループベースの定性セットのメンバーシップとそれらのセットの相対的な重大度に基づいて、考えられる各ベクトルのスコアを生成できます。

2.6.3 専門家の比較データを使用して、最も重大度の低いベクトルから最も重大度の高いベクトルの順序を計算する

　「専門家比較データ」は、メトリックグループベースのベクトルセットが競合していてベクトルセットを「最高」から「最悪」までランク付けしたいと考える際に使用されます。これらの「専門家比較データ」をランキングに変換するためのアルゴリズムは、チェスの試合の結果 (比較) を取得してチェスプレイヤーを最高から最低までランク付けするために使用されるアルゴリズムと同じです。 このアルゴリズムの名前は Elo (イロレーティング – Wikipedia) です。 アルゴリズムによる出力は、「ポイント」と呼ばれる「生の」スコアのセットです。 それぞれのベクトル セットのポイントスコアの解釈は、例えばあるベクトルセットのスコアが別のベクトルセットより100ポイント高い場合、そのスコアの差により、専門家は一定の割合の時間でより高いスコアのベクトルセットを「より厳しい(severe)」と評価すると予測されます。 チェスの例えで言えば、一定の確率で試合に勝つことになります。

　ポイントスコアの差が大きいほど、スコアの高いベクトルがより深刻であると評価される可能性が高くなります。 イロレーティングアルゴリズムを正確に構成して実行する方法については、重要な詳細があります；しかしながら、SIG（CVSS Special Interest Group ）主導のフィードバックプロセスを通じて、構成の詳細は同様の値セットをどれだけカバーするかに収束する傾向があることがわかりました。

　従ってイロレーティングアルゴリズムの出力は安定しており「多様な専門家の意見による入力値」から「単一の重大度順になっているメトリックグループベースのベクトルセット」への信頼できる変換を表していると考えられます。

2.6.4 CVSS v3.xの定性的な重大度スコアと互換性を持たせるために、ベクトルの順序付けにおいてどのベクトルグループが定性的な重大度スコアを表すかを決定するため、専門家の意見を求める。

　270の”メトリックグループベースのベクトルセット”を0.0〜10.0のスコアにマッピングする前に、SIG はCVSS v3スコアとの下位互換性を上げたいと考えていました。 これを行うために、SIGは、どの”メトリックグループベースのベクトルセット”が定性的な重大度(Severity)セットとしての境界を定義するかを決定したいと考えていました。

　ステップ3の出力は、ベクトルセットの全体的な順序付けでした。定性的な重大度の境界を決定する際には、SIG はステップ3で出力されてきた順序付けを変更しませんでした。むしろSIGでは、どの CVSS v4-Bのベクトルセットが重大と高、高と中、中と低の間の境界を表すかを決定したいと考えていました。 これは30名を超えるメンバーからなる CVSS SIGからの意見で決定されました。5人のメンバーが、ベクトルセットの順序付けにおける3つの境界をマークするという形で意見を提供しました。 次にSIG は、5人のSIGメンバーの選択の平均として境界を定義しました。

2.6.5 各定性的重大度内のベクトルグループを、その内の利用可能なスコアに圧縮 (例えば重大の場合は9.0～10.0、高の場合は7.0～8.9など)

　CVSS v3との下位互換性を維持する2番目の部分は、各定性的重大度のスコア範囲を同じに保つことでした。 全体の順序付け (ステップ3) と定性的重大度境界 (ステップ4) の結果、各定性的重大度のスコアにおけるメトリックグループベースのベクトルセットの数は次のようになりました。 各ベクトルセットには異なる数のCVSS v4.0 BTEベクトルがあることに注意してください。

ただし、SIGは考えられるCVSS v4.0 BTEベクトルの総数をカウントすることが、CVSS v4 BTEスコアのかたまりを評価する適切な方法であるとは考えていません。たとえば2023年4月の時点では、プログラムの開始以来現在までのCVE IDの総数は 200,000未満です。仮に1,500万のCVSS v4 BTEスコアが可能だとしても、CVE IDの数はベクトルよりもはるかに少ないため、殆どがCVE IDに割り当てられることはありません。CVSS v4 BTEスコアの分布をより適切に評価するには、実際のCVE IDの評価でベクトルの文字列が実際に何回繰り返されるかを経験的に評価する必要があります。

スコアリングシステムの作成の特徴として、CVSS v4.0スコアリングシステムは、定性的重大度スコア (重大、高、中、低) ごとに作成された4つのスコアリングシステムとして作成され、0.0 の特別なケースとして”None”も作成されました。各定性的重大度スコアには、異なる数のメトリックグループベースのベクトルセットと異なる数の利用可能なスコアが含まれます。 Critical・High・Medium・Lowのそれぞれの要件を満たすスコアリングシステムの作成には、同じアルゴリズムが使用されます。 そのアルゴリズムは凝集型階層クラスタリング (階層クラスタリング – Wikipedia) で、同じCVSS v4 BTEスコアを共有するベクトル セットのElo-pointスコア間の差も最小になるようにします。

2.6.6 メトリック値の変更によってスコアが変更されるように、ベクトルグループ内のスコアを調整する小さなスコア変更係数を作成しました。

ステップ5の結果は、CVSS v4.0スコアリングシステムのオプションです。 メトリック値の変更によって CVSS v4 BTE スコアが少なくとも 0.1 変化するという要件を満たすために、SIGでは、メトリックグループ内のベースベクトルセットメトリック値の変更に基づいて、スコアに小さな変化を作成する追加の手順を追加しました。

ベクトルセットは完全に順序付けされていますが、ベクトルセットの特に小さな違いはElo-ポイントスコアで、結果として得られる順序付けに同意しない多くの専門家がいました。ベクトルセット内のメトリック値に基づいて小さな変更を提供する事で、ベクトルセット内のほんの少しだけ深刻なメトリック文字列を、近くにあるほんの少しだけ深刻なメトリックグループベースのベクトルセットからの、ほんの少しだけ深刻度が低いメトリック文字列とオーバーラップさせることができます。 これらの小さな変化は、たとえ専門家の意見によるランク付けが可能になるほど重要かつ顕著に同値であるとしても、同値セット内のすべてのベクトルが同一ではないという事実を説明しています。

これらの小さな調整の背後にある基本的な直感は、CVSSメトリック値が各メトリック内で順序付けされているということです。たとえばAV:NはAV:Aよりも深刻で、AV:AはAV:Lよりも深刻で、AV:LはAV:P よりも深刻です。 他のすべてのメトリクスにも同様の順序があります。

したがって、この順序に基づいてCVSS v4 BTEスコアの変更をアルゴリズム的に定義することは妥当です。専門家の意見は、質的に重要な相違点の大局的な順序を分類するために使用されました。 メトリックグループベースの同値セットの変化に顕著ではないメトリック値の小さな変化は、専門家が1つのベクトルが別のベクトルよりも厳しいものとして評価する可能性を示すEloポイントの差の解釈と一致するスコアの小さな変化を表すために使用できます。

2.7 ベクトル文字列内のバージョン識別子の更新

ベクター文字列が更新され、CVSS:3.1ではなくCVSS:4.0で始まるようになりました。 ベクトル文字列にはその他の変更は加えられていませんが、CVSS v4.0には一部のメトリック値の定義と式が変更されているため、CVSSのバージョンを正確に示すことが重要です。

3. 評価（Assessment）ガイド

以下に、CVSS v4.0を用いて脆弱性を評価する際のユーザ向けの推奨事項をいくつか示します。

3.1 脆弱性スキャンの結果を資産管理と統合する

脆弱性スキャンソリューションの結果を資産データで強化することを強くお勧めします。多くの場合、資産管理データはデータベースに保存され、脆弱性スキャンデータと簡単に統合できます。このステップにより、脆弱性管理チームが環境メトリックグループを利用して、結果として得られるCVSSスコアの品質を向上できるだけでなく、特定された脆弱性の修復を担当するエンジニアが、より多くの情報を自由に使えるようになります。

たとえば、脆弱性スキャンは100台のサーバーに対して実行されます。スキャン結果には、ホスト名・脆弱性・CVSS Base(CVSS-B)スコアが含まれます。資産管理データベースには、すべてのサーバーのレコードが含まれており、各サーバーには資産クラス、機密性要件、完全性要件、可用性要件、および公開(インターネットまたは内部向け)の値が含まれています。自動化を使用してこの情報が統合されると、環境要因を考慮したCVSS-BEスコアが得られます。さらに、資産クラスおよび同様の情報を使用して、脆弱性を適切なエンジニアに伝えて修復させることができます。

3.2 脆弱性スキャンの結果を脅威インテリジェンスと統合する

おそらく、CVSS評価の結果を改善するための最も重要な側面の1つは、脅威データの適用とエクスプロイト成熟度(E)指標の使用です。過去にどの脆弱性が悪用されたかを知ることは、結果のスコアに大きな影響を与えるはずです。

脆弱性のエクスプロイト成熟度に関する脅威インテリジェンスを提供できる情報源は数多くあります。これらのソースの多くは無料で公開されており、その他有料によっても提供されています。

これらのソースはどれも完璧ではないことを理解することが重要であり、脆弱性データを強化するために使用される情報の包括性と忠実性を向上させるために、脅威インテリジェンスの複数のソースを収集することを強くお勧めします。

脅威インテリジェンスの適用は、自動化を使用して脆弱性スキャンデータと照合する必要があります。その結果、評価対象の脆弱性に適用する優先度がより正確に測定されます。

3.3 Exploit ライフサイクルでのCVSSスコアリング

脆弱性の影響をいつ評価するかを理解するとき、アナリストは、攻撃者が達成できると確信できる合理的な最終結果に影響を限定する必要があります。たとえば、次の 2 つの脆弱性について考えてみましょう。

脆弱性1では、リモートの認証されていない攻撃者が、Webサーバーに細工された簡単なリクエストを送信することで、Webサーバーにroot(管理者)アカウントの平文パスワードを開示させる可能性があります。アナリストは脆弱性の説明から、攻撃者が脆弱性を悪用するために細工したリクエストをWebサーバーに送信するアクセス権を持っていることしか知りません。影響はそこで止まるはずです；攻撃者はこれらの資格情報を使用して、後で管理者としてコードを実行できる可能性がありますが、攻撃者がログインプロンプトにアクセスしたり、これらの資格情報を使用してコマンドを実行する方法を持っているかどうかは不明です。このパスワードへのアクセスが可能であることにより、機密性が直接的かつ重大に失われることになります。

CVSS-B Score: 8.8 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N)

脆弱性2では、ローカルの権限の低いユーザーが、悪意のある細工されたリクエストをOSに送信し、root(管理者)アカウントの平文パスワードを開示させる可能性があります。アナリストは脆弱性の説明から、攻撃者がOSにアクセスし、ローカルの低特権の攻撃者としてログインできることを知りました。このパスワードへのアクセスを取得すると、機密性、完全性、および可用性が直接かつ重大に失われることになります。これは、アナリストがroot/管理者アカウントとして合理的にコマンドを発行できるためです(攻撃者が自分のアカウントからログアウトし、rootとして再度ログインできると仮定します)。

CVSS-B Score: 8.5 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)

3.4 機密性（Confidentiality）と完全性（ Integrity）へのインパクト vs 可用性（Availability）へのインパクト

　機密性と完全性のメトリクスは、サービスで使用されるデータに影響を与える影響を指します。例えば、悪意を持って変更されたWebコンテンツや盗まれたシステムファイルなどです。可用性への影響メトリックは、サービスの運用を指します。つまり、可用性メトリクスは、データの可用性ではなく、サービス自体のパフォーマンスと運用を表します。Web・メール・DNSなどのインターネットサービスに脆弱性があり、攻撃者がディレクトリ内のすべてのWebファイルを変更または削除できると考えてください。Webサービス自体はまだ機能しており、たまたま変更されたコンテンツを提供していることになるため「可用性ではなく整合性に対しての影響がある」となります。

3.5 リモートの攻撃者による「ローカルの脆弱性」の悪用

　ローカル攻撃に関するガイダンスは、ネットワークの定義と攻撃ベクトルメトリックの隣接値を明確にすることで改善されました。 具体的には、アナリストは脆弱性がネットワークスタックにバインドされている場合にのみ、ネットワークまたは隣接を評価する必要があります。 悪意のあるコンテンツをダウンロードまたは受信するためにユーザーの操作が必要な脆弱性 (ローカルに配信される可能性もある) は、ローカルとして評価される必要があります。

3.6 脆弱性連鎖（Vulnerability Chaining）

　CVSSは個々の脆弱性を分類して評価するように設計されています。しかし、脆弱性分析コミュニティのニーズをサポートするために、単一の攻撃の過程で複数の脆弱性が悪用されてホストやアプリケーションが侵害される状況の評価に対応することが重要です。このように複数の脆弱性を評価することを「脆弱性連鎖」と呼びます。これは正式な指標ではありませんが、この種の攻撃を評価する際のアナリストへのガイダンスとして含まれていることに注意してください。

　一連の脆弱性を評価する場合、どの脆弱性が組み合わされて連鎖的なスコアが形成されるかを特定するのはアナリストの責任です。アナリストは個別の脆弱性とその結果のスコアを、連鎖した結果のスコアとともにリストする必要があります。たとえば、Webページに掲載する脆弱性開示通知内で伝達する場合があります。

　更にアナリストは、評価対象の脆弱性と連鎖する可能性のある他のタイプの関連脆弱性を含めることもあります。具体的には、アナリストは多くの場合連鎖している関連する脆弱性の一般的なタイプ(またはクラス)をリストしたり、存在する必要がある前提条件の詳細な説明を提供したりする場合があります。たとえば、特定の種類のSQLインジェクションの脆弱性がクロスサイトスクリプティング(XSS)攻撃の前兆であることや、特定の種類のバッファオーバーフローによってローカル権限がどのように付与されるかを説明することができます。脆弱性の一般的なタイプまたはクラスをリストすると、攻撃者に新たな悪用の機会を知らせる可能性がなく、他のユーザーに警告するために必要な最小限の情報が提供されます。

　あるいは、アナリストは、1つまたは複数の脆弱性に連鎖していることが知られている(または連鎖している可能性が非常に高い)特定の関連脆弱性の完全なリストを(機械読み取り可能で解析可能なCVEIDまたはCWEとしての脆弱性リストの形式で)特定することもできます。ITシステムを悪用するために、連鎖的な脆弱性のさらなる評価が行われています。他の前提条件が満たされた後にのみ脆弱性が悪用される場合(最初に別の脆弱性を悪用する場合など)のイベントでは、２つ以上のCVSSスコアを結合して最も制限の少ない悪用可能性メトリクスを評価し、最も影響力のあるインパクト指標が何かを評価することが許されます。次の例では、悪用可能性と影響の評価を使用してチェーンを説明します。

・脆弱性Aは下記になり、悪用するには権限の低いローカル ユーザーが必要です。

CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

・脆弱性Bは下記になり、権限のないリモート攻撃者がシステム上でコードを実行できる（攻撃による影響度はLow）になります。

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

・与えられたA,Bから下記のようなチェーンC(B->A)が出来上がります。これはBの悪用可能性とAの影響を組み合わせたものです。Bを悪用し、そこからローカル ユーザーとしてコードを実行できれば、脆弱性Aによる影響を引き起こすための前提条件を満たしていることになります。

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

3.7 脆弱なシステムと後続(Subsequent)システム

　CVSS4.0の仕様では、脆弱なシステムと後続(Subsequent)システムの概念が導入されています。脆弱なシステムへの影響と後続のシステムへの影響を区別する方法を理解するために、CVSS3.1から借用したいくつかの例を見てみましょう。

  1. 仮想マシンの脆弱性により、攻撃者がホストOS(おそらくは独自の仮想マシンでも)上のファイルの読み取りや削除を可能にする場合は、後続システム(ホストOS)と脆弱なシステム(仮想マシン)となります。
  2. CVSS を使用して脆弱性を評価する場合は、マイクロプロセッサ特権レベル間のセキュリティ境界違反を考慮する必要があります。 より低い特権レベルで実行されるユーザー空間プログラムの機能は、OSの管理者特権で実行されている場合でも実行できる命令や書き込みできるレジスタに制限があります。 低い特権レベルで実行されているプログラムが突破され、高い特権レベルで任意のコードを実行できる脆弱性は、脆弱なシステム (マイクロプロセッサ) への影響であるとみなされる必要があります。
  3. CVSSを使用して脆弱性を評価する場合、マイクロプロセッサに統合されたセキュアエンクレーブと、OSのカーネルを含む残りのプロセスとの間のセキュリティ境界を考慮する必要があります。他のプロセスがセキュアエンクレーブ内のデータまたはコードの機密性、整合性、または可用性に影響を与えることを可能にする脆弱性は、脆弱なシステム(エクスプロイトが発生するセキュアエンクレーブ)だけでなく、後続のシステム(脆弱なシステムのセキュリティ境界の外側での攻撃の影響を受けたセキュアエングレーブ)にも影響を与えます。
  4. Webアプリケーションの脆弱性がユーザークライアント(Webブラウザなど)に影響を与える場合、ユーザークライアントは後続システムになります。このタイプの一般的な脆弱性には、クロスサイトスクリプティングやURLリダイレクトなどがあります。この脆弱性はWebアプリケーションにありますが、被害ユーザーのWebブラウザのデータ/動作に影響があります。
  5. 分散環境では、別のセキュリティドメイン内のコンポーネントに接続・保護・認証のサービスを提供するコンポーネントの脆弱性では、攻撃が成功して他のコンポーネントに影響を与える場合に後続システムの評価を含める必要があります。たとえば、ルーター・ファイアウォール・認証マネージャーなどのコンポーネントの脆弱性は、1つ以上の下流コンポーネントの主要な可用性に影響を及ぼし、後続システムに影響を与える可能性があります。ただし攻撃が成功しても、他のコンポーネントにまったく影響を与えないか極僅かな影響しか与えない場合、その脆弱性は後続システムに影響を与えないと評価される必要があります。さらに、大規模なフォールトトレラントトポロジの一部として導入されるコンポーネントの脆弱性は、「フォールトトレランス」により攻撃の成功による他のコンポーネントへの影響がない場合には後続システムへの影響を評価すべきではありません。脆弱なシステムによって提供される追加サービスへの影響は二次的な影響とみなされ、後続システムへの影響とは見なされません。
  6. シンプルなPDFリーダーの脆弱性により、被害者が悪意のあるPDFドキュメントを開いたときにOS上の他のファイルを侵害する可能性がある場合には、後続システムには影響がないと評価されています。これは、PDFリーダーが基盤となるOSとは別個のセキュリティドメインとみなされる認証機能を持たないことを前提としています。
  7. WebアプリケーションとSQLデータベースの間で資格情報が共有されており、それらが同じセキュリティスコープの一部であると考えられる場合には、WebアプリケーションのSQLインジェクションの脆弱性は後続システムに影響を与えるとは考えられません。
  8. WebサーバーまたはSSHサーバーをクラッシュさせる脆弱性は、影響を受けるサーバーが提供するサービスにのみ影響が限定されるため、後続システムへの影響とはみなされません。ユーザーへの影響は二次的なものであり、ユーザーは後続システムの構成要素とはみなされないため、後続システムへの影響とはみなされません。
  9. ファイルシステムをいっぱいにする様な攻撃者がシステムリソースを使い果たすことを可能にする脆弱性は、後続システムに影響を与えるものとして考慮されるべきではありません。攻撃者は依然としてアプリケーションの通常の機能に従って動作しており、セキュリティ境界を突破していません。
  10. ユーザのアクセスを複数のセキュリティスコープにわたって他のコンポーネントと共有されているリソースに対して制限する様な(例えばSystemファイルの様なOSリソース)アプリケーションの脆弱性では、悪用により攻撃者がアクセスできないはずのリソースにアクセスできます。この場合、信頼境界を越える有効なパスがすでに存在すると考えられるため、後続システムへの影響は無いと考えられます。
  11. 独自のセキュリティドメイン実装のアプリケーションに、攻撃者がセキュリティスコープ外のリソースに影響を与えることが可能になる様な脆弱性がある場合は、後続システムへの影響があると評価される必要があります。これはアプリケーションが、複数のセキュリティスコープにわたる他のコンポーネントと共有される上位レベルのセキュリティドメインによって管理されるリソース(たとえば、基礎となるオペレーティングシステムのリソース)にアクセスするための機能をユーザーが提供しないことを前提としています。例えばユーザーがWebアプリケーションのインストールパス内でのみWebページとファイルの読み取りと変更を許可し、ユーザーがこれらのパスを超えて対話できる機能を提供しないWebアプリケーションが挙げられます。このアプリケーションの脆弱性によって悪意のあるユーザーがOSファイルにアクセスできるようになる場合は、後続システムに影響が及ぶと考えられます。

3.8 ファイアウォールにより保護された脆弱性のあるシステム

　脆弱性が攻撃ベクトル(AV)のネットワーク(N)で評価されていて、脆弱なシステムがインターネットから利用できない安全なネットワークに展開されているとアナリストが確信している場合には、修正攻撃ベクトル(Modified Access Vector: MAV)は隣接(Adjacent)として評価される可能性があります。結果としては、重要度のスコアが減少します。

　例えば、MySQL の SQL Injection (CVE-2013-0375)は

CVSS-B Score: 5.1 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N)

が、下記の様に変化します。

CVSS-BE Score: 4.9 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/MAV:A)

3.9 ソフトウェアライブラリ（あるいは類するもの）の脆弱性の評価

　ライブラリの脆弱性の影響を評価する場合、採用しているプログラムや実装には関係無く、アナリストはライブラリの使用方法を考慮に入れることができない場合がよくあります。ライブラリを使用する特定の製品は、ライブラリの使用方法に沿ったCVSSスコアを生成する必要がありますが、ライブラリ自体を評価するには仮定を行う必要があります。アナリストは合理的な最悪のシナリオを考慮する必要があり、可能であればCVSS情報で仮定を詳しく説明する必要があります。

　例えば画像変換を実行するライブラリは、ネットワーク経由で信頼できないソースから画像を受け入れるプログラムによって使用されるのが合理的です。合理的な最悪のケースでは、画像の有効性をチェックせずにライブラリに画像を渡すことになります。したがって、受信データに関連するライブラリの脆弱性を評価するアナリストは、攻撃ベクトル(AV)中でネットワーク(N)を想定する必要がありますが、この想定を脆弱性の概要で説明する必要があります。ライブラリが通常の権限で実行されて埋め込み実装への影響が少ないか、高い権限で実行されて影響が増大する可能性がある場合、アナリストはライブラリの脆弱性を評価する際に高い権限を想定する必要があります。

　影響を受けるライブラリを使用して特定の実装の脆弱性を評価する場合、その特定の実装に対してのメトリック値を再評価する必要があります。たとえば、実装に脆弱なシステム(この場合は前の例で説明したライブラリ)が組み込まれているがローカルファイルでのみ動作する場合、攻撃ベクトル(AV)はローカル(L)になります。このライブラリを組み込む実装が問題のある関数を呼び出さない場合や、その脆弱性を引き起こすモードをサポートしない場合には、その脆弱性を悪用するためのインターフェイスや攻撃ベクトルは存在しません。したがって、組み込みライブラリの脆弱性はその実装には影響せず、その結果、特定の実装の重大度スコアは0になります。

3.10 複数のCVSS Base (CVSS-B)スコア

　脆弱性が複数の製品バージョン・プラットフォーム・OSに存在するのは一般的です。状況によっては製品バージョン・プラットフォーム・OSが異なると、ベースメトリクスが異なる場合があります。たとえば同じベンダーが製造した複数のOSに適用される脆弱性があるとします。従来のOSにおけるこの脆弱性の攻撃複雑度(AC)は低(L)です。ただし新しいOSには攻撃の複雑度を高(H)に変更する新しい保護機能が備わっていたとします。この差異によって、最終的に2つのOS上の同じ脆弱性に対するCVSS-Bスコアが異なることになります。

　単一の脆弱性でCVSS-B スコアに関連する特定の製品バージョン・プラットフォーム・OSを説明する文言が含まれる場合、単一の脆弱性に対して複数のCVSS-B スコアを公開することが認められます。(CVSS-B スコアだけでなく)すべてのCVSS-B メトリクスの値は、標準形式を使用して影響を受ける製品バージョン・プラットフォーム・OSごとに指定する必要があります。複数のCVSS-B スコアが適用可能であるが、提供されるのが1つだけである状況では、最も高いCVSS-B スコアを使用する必要があります。

3.11 CVSS 拡張フレームワーク

　追加のスコアリング作業のためにCVSSのコア基盤を活用する機会があります。たとえばCVSS Special　Interest Group(SIG)にCVSSベースと環境メトリクスを組み合わせてプライバシーへの影響を導き出すという提案が来ました。

　以下のガイドラインでは、公式のBaseメトリック、脅威メトリック、および環境メトリックを保持しながら、追加のメトリックとメトリックグループを含めるようにCVSSを拡張する標準的な方法を定義します。追加の指標により、プライバシー、安全性、自動車、ヘルスケアなどの業界セクターは、CVSS　標準の範囲外の要素をスコアリングできるようになります。

3.11.1 ガイドライン

  • 既存のCVSS Base／Threat(脅威)／Environment(環境)メトリクスの式や定数、定義等を変更してはなりません。既存の項目を変更する必要がある場合は、新しい名前で新しいメトリックグループを作成し、必要に応じて作業します。
  • 新しいメトリックを既存のメトリックグループに追加はできませんが、新しいメトリックグループには追加する必要があります。新しいメトリックグループは、既存のメトリックグループに基づきます。
  • 新しいメトリックグループは、必要に応じて結果のスコアに影響を与えることができます。該当する場合、結果のスコアは0.0～10.0（最も深刻）の間になる必要があります。結果として得られるスコアは、必要に応じてCVSS-B・CVSS-BT・CVSS-BE・CVSS-BTEスコアを調整したことに基づいている必要があります。
  • CVSS SIGは拡張を正式に承認しませんが、IETF1と同様にコンサルティング機関として機能します。CVSS SIGはイノベーションを歓迎し奨励しますが、提案されたすべての拡張機能にわたって一貫性を維持することに関心を持っています。
  • 検証された拡張機能のリストは、IANAと同様に、first.org Web サイトに掲載されます。
    • 必須のフィールド: Name, Description, 外部の権威あるウェブサイト
    • オプションのフィールド：JSON Schema, XML Schema, JavaScript Calculator

3.11.2 推奨されるベクトル文字列フォーマット

CVSS拡張ベクトル文字列は下記のように区別してリストされる必要があります：

CVSS:4.0/AV:x/AC:x/AT:x/PR:x/UI:x/VC:x/VI:x/VA:x/SC:x/SI:x/SA:x
EXT:1.0/NEW1:VAL1/NEW2:VAL2

ここで

  • EXT:n.nはユニークな拡張識別子でmajor.minorがバージョン番号になります。
  • NEWn は新しいメトリック毎のユニークな拡張属性になります。
  • VALnは新しいメトリックのための属性の値になります。

3.12 攻撃ベクトル(Attack Vector)に関する考察事項

　攻撃ベクトルをスコアリングするときは、攻撃を成功させるためにネットワーク接続が必要な場合は、攻撃がネットワーク経由で開始されない場合でも[隣接]またはネットワークを使用します。例えばローカルの攻撃者は、特権を持っていて脆弱性があるローカルプログラムを使って、別のサーバーにネットワーク経由で機密データを送信させることができる可能性があります。機密データを収集するにはネットワーク接続が必要であるため、これはネットワークの攻撃ベクトルでスコア付けされます。

　悪意のあるデータがあるシステムからネットワーク経由で受信され、別の脆弱性があるシステムに渡される場合には、ローカルの攻撃ベクトルでスコア付けされる必要があります。例としては、Webブラウザが悪意のあるオフィスドキュメントをダウンロードしてディスクに保存し、脆弱なシステム(この場合はドキュメント処理アプリケーション)が起動されて保存されたファイルを読み取る場合などです。

　脆弱なシステムに悪意のあるデータを受信する機能が含まれている場合、攻撃ベクトルはネットワークとしてスコア付けされる必要があります。例としてはWebブラウザ自体やプラグイン・拡張機能等に、悪意のあるデータを受信するとトリガーされる脆弱性がある場合等です。

3.13 否認防止（Non-Repudiation）は完全性（Integrity）の一部です

　NISTによると、否認防止(Non-Repudiation)とは「特定のアクションを実行した個人が、そのことを否認出来ないようにすること」です。システムユーザーが、ユーザー自身の権限内でクリティカルな行為を行った後にその行為を拒否していた場合に、否認による影響を考える必要があります。

　システムに複数の管理者がいるとします。1人の管理者が悪意のある攻撃者に対してシステムのバックドアへのアクセスを許可したとします。このインシデントが特定された状態で、ログが記録されていなかったため、誰がやったかを特定する方法が無いとします。悪意のある管理者は、自分の権限を超えることは何もしていません。このケースは、CWE-778 : 不十分なログが、否認防止への影響、したがって整合性の影響を引き起こす弱点となります(例:CVE-2019-8124)。

　同様に、水平方向への権限昇格の脆弱性の場合、悪意のあるユーザーは通常自分の能力を超えて何かを行うことができません。C・I・Aに対する影響は「None」になります。ただし、攻撃者は同じ権限を持つ別のユーザーになりすましてシステム内で悪意のあるアクションを実行することができ、否認防止への影響、ひいては整合性の影響をもたらします(例:CVE-2017-6785)。

　脆弱性によって潜在的に否認防止への影響が引き起こされると、直ちにシステムの完全性に影響が及びます。

3.14 セキュリティ要件

　このセクションでは、特定の環境の特性に基づいて適切なメトリック値を選択するためのガイダンスを提供します。 概念を説明するために簡略化されたサンプルを用いています。

3.14.1 Confidentiality Requirement (機密保持の要件：CR)

　システムの機密性要件は、ターゲットシステム上のユーザーやアプリケーションによって保存・使用されるデータの分類に基づきます。機密性要件を確立する際には、このデバイスに保存されているデータの暗号化も考慮する必要があります。この属性を評価する際には、処理されずにデバイス(スイッチやファイアウォールなど)を通過するデータは考慮すべきではありません。以下の例を参照してください。

注:データの量は属性の値に影響を与える可能性がありますが、使用または保存されるデータの分類(つまり、タイプ)ほど大きな影響を与えることはありません。

  1. 最高レベルに分類されたデータを保存するデバイスは、属性を「高」と評価する必要があります。 ただし機密データが保管時に暗号化されている場合、属性が「中」となる可能性があります。
  2. 非公開として分類されているが最高レベルほどではないデータを保存するデバイスは、属性を「中」と評価する必要があります。ただし機密データが保管時に暗号化されている場合、属性は「低」となる可能性があります。
  3. 一般に共有されている様なデータを保存するデバイスは、属性を「低」と評価する必要があります。
  4. ルーター・スイッチ・ファイアウォールなどのネットワーク機器は、ルーティングテーブルなどの情報の機密性を厳密に考慮して、通常は「中」と評価されます。
  5. ログイン認証情報を暗号化せずに保存するシステムは、属性を「高」と評価する必要があります。これにはスクリプトやソースコードに埋め込まれたアカウント／資格情報が含まれます。

3.14.2 Integrity Requirement (整合性の要件：IR)

　システムの整合性要件は、システムが使用または保存するデータの正確さに重点を置いています。この属性を評価する際、処理されずにデバイス(スイッチやファイアウォールなど)を通過するデータは考慮すべきではありません。この属性では、保存するデータに対しての暗号化を考慮する必要はありません。以下の例を参照してください。

  1. 金銭取引のデータや、個人を特定できる情報(PII)が含まれるデバイスは、「高」と評価される必要があります。
  2. ビジネスまたはリスク管理の意思決定の為に使用されるデータを含んだデバイスは、最低でも「中」と評価される必要があります。決定の重大さが増すにつれて、整合性要件の評価も増加する必要があります。
  3. 健康に関する決定に使用されるデータを含むデバイスは「高」と評価される必要があります。
  4. ルーターやスイッチなどのネットワーク機器は、転送テーブルなどの情報の機密性を厳密に考慮して、通常は少なくとも「中」と評価されます。
  5. ルールセットの機密性により、ファイアウォールは「高」と評価される必要があります。

3.14.3 Availability Requirement (可用性の要件：AR)

　システムの可用性要件は、デバイスやデバイス上のアプリケーションの稼働時間要件と冗長性に基づく必要があります。クラスタリングの一部であるデバイスの可用性要件は低くなります。以下の例を参照してください。

  1. キャパシティの冗長性がなく、回復要件が24時間未満と評価されるデバイスは「高」と評価される必要があります。
  2. 1～5日の回復要件があるとされる、キャパシティの冗長性が無いデバイスは「中」と評価される必要があります。
  3. 回復要件が5日を超えるデバイスは、「低」と評価される必要があります。
  4. クラスタ化されたデバイスやキャパシティの冗長性を備えたデバイスは「低」と評価される必要があります。
  5. 規制要件に基づくトランザクション目的で、迅速な応答時間が要求されるデバイスは「高」と評価される必要があります。

4. Supplemental Metrics(補足メトリック)

　補足メトリックグループと呼ばれる新しいメトリックグループにより、脆弱性の追加の外部属性を記述したり測定する新しいメトリックを提供します。補足メトリックグループ内の各メトリックの使用法はスコアの使用者によって決定されます。このコンテキスト情報は、使用者の環境ごとに異なる方法で使用される可能性があります。

　仕様の範囲内では、どのメトリクスも最終的に計算されるCVSSスコア(例:CVSS-BTE)に影響を及ぼしません。その後、組織は各指標の重要性や効果的な影響、または指標のセット／組み合わせを割り当ててます。これは最終的なリスク分析に多大な影響を与えたり、或いは全く与えなかったりすることがあります。メトリクスと値は、脆弱性自体の追加の外部特性を伝えるだけです。

4.1 Safety(安全性)

　システムの使用目的が安全性を考慮している場合、そのシステムでの脆弱性の悪用により安全性に影響が生じる可能性がありますが、これは補足メトリックグループで表すことができます。

安全性を含むすべての補足指標は完全にオプションであることに注意してください。サプライヤーやベンダーは必要に応じて、追加したい補足メトリックをケースバイケースで選択できます。安全性メトリック値が提供されていないからといって、安全性に関する影響が存在しないかもしれないことを意味していません。

4.2 Automatable(自動化可能)

　キルチェーンのステップを確実に自動化できない理由の例としては、次のようなものがあります。

  1. 脆弱性のあるシステムが検索できないか、ネットワーク上に膨大な数がある場合
  2. 兵器化（Weaponization）に当たって、ターゲットごとに人間が関わる必要がある場合
  3. デリバリー(Delivery)に当たって、展開されているネットワーク上の設定でBlockされている場合
  4. エクスプロイトが信頼できなかったり、悪用防止技術がデフォルトで有効になっている場合; ASLRは悪用防止ツールの一例です。

これらは説明のために提供された理由の例であり、キルチェーンステップが自動化できない理由の完全なリストではありません。

「Yes」のヒューリスティックの1つとして、脆弱性により認証されていないリモートコード実行またはコマンドインジェクションが行われる場合、期待される応答は「Yes」です。アナリストは、ヒューリスティックのみに依存するのではなく、4つのステップすべてを自動化できるという議論や実証を提供する必要があります。

自動化可能の定義は、特定のステークホルダーの脆弱性分類(バージョン2)における意思決定ポイントの定義と実質的に同じです。

4.3 プロバイダー緊急度

　現在多くのベンダーが、製品のセキュリティ勧告を通じてユーザに重大度評価を提供しています。また、CVSSv3.x仕様文書からの定性的重大度評価をアドバイザリで公開するベンダーもあります。

　プロバイダーが提供する追加の評価を容易に組み込むために、プロバイダー緊急度と呼ばれるオプションの「パススルー」補足メトリックを採用することが提案されています。

4.4 リカバリー

　リカバリー（回復）とは、攻撃が実行された後にパフォーマンスと可用性の観点からサービスを回復するためのコンポーネント/システムの回復力を表します。 回復の値には次のものが含まれます。

  • 自動(A):コンポーネント/システムは、攻撃が実行された後にサービスを自動的に回復します。
  • ユーザー(U):コンポーネント/システムは、攻撃が実行された後、サービスを回復するためにユーザーによる手動介入を必要とします。
  • 回復不能(I):コンポーネント/システムサービスは、攻撃が実行された後、ユーザーによって回復できなくなります。

4.5 価値の密度

以下は、このメトリクスに対して拡散メトリクス値または集中メトリクス値をどう選択するかについての例です。

拡散:拡散価値を持つシステムの例としては、電子メールアカウント・消費者向け銀行アカウント・一般的な携帯電話・ユーザーが所有して維持するコンピューティングリソース等が挙げられます。(「ユーザー」とは、システムまたはコンポーネントの保守以外の専門的業務を行う人を指します。「システムオペレーター」は、システムの適切な運用または保守に専門的に責任を負う人を指します。)

集中:ヒューリスティック的に、このようなシステムは多くの場合、ユーザーではなく「システムオペレーター」が直接責任を負います。(「ユーザー」とは、システムやコンポーネントの保守以外の専門的業務を行う人を指します。「システムオペレーター」は、システムの適切な運用または保守に専門的に責任を負う人を指します)。集中価値の例としては、システム・Kerberosサーバー・ログインページをホストするWebサーバー・クラウドサービスプロバイダー・データベース等があります。ただし脆弱なシステム上のリソースの有用性と独自性は、価値密度にも影響します。たとえば、暗号化されたモバイルメッセージングプラットフォームには価値が集中している可能性があります。これは、各電話のメッセージング履歴に特に大量のデータがあるためではなく、法執行機関にとって独自の価値があるためです。

価値密度の定義は、ステークホルダー固有の脆弱性分類(バージョン2)における同じ名前による意思決定ポイントの定義と実質的に同じであることを目的としています。

4.6 脆弱性対応への取り組み

　脆弱性対応努力指標の目的は、インフラに展開されている製品およびサービスの脆弱性の影響に対してユーザーが初期対応を行うことがいかに難しいかについて、補足情報を提供することです。ユーザーは緩和策を適用したり修復をスケジュールしたりするときに、必要な労力に関するこの追加情報を考慮に入れることができます。

脆弱性対応工数を計算するときは、利用可能な最も迅速な対応を展開するために必要な工数を考慮する必要があります。

5. 用語集

用語集以下は、原文を参照してください。

タイトルとURLをコピーしました