CVSS v4.0について専門家が解説！CVSSの4つの構成要素

　この記事では昨年秋に公開されたCVSS(Common Vulnerability Scoring System) v4.0について解説します。CVSSの全体の話(v3.1ベース)については、別途こちらの解説記事をご覧ください。

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

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

hwdream.com

2024.10.24

この記事では、CVSS v4.0の解説をさせていただきます。

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

CVSS v4.0とは

　CVSS v4.0は2023年11月にリリースされました。比較的新しいため、一般的にベンダーなどから公開されるCVSSに関しては、2024年10月現在でも未だv3.1のものが多い様です。ただし、徐々に幾つかのベンダーがCVSS v4.0での情報提供を始めています。また、NVDも2024年6月にCVSS v4.0のサポートを開始した事がアナウンスされています。

　以下では、まずCVSS v4.0がどうなっているか、その構造などについて最初に触れてみます。

CVSS v4.0の構造

　CVSSの説明でも軽く触れましたが、CVSS v4.0は下記の4つのMetric Groupから構成されています。

• Base Metric Group
• Threat Metric Group(Temporal Metric Groupと呼ばれていたものの名前が変わりました）
• Environment Metric Group
• Supplemental Metric Group

Nomenclature(命名方法)

　CVSS v4.0からはNomenclature(命名方法)にも言及があります。CVSSではBase Metic GroupからBase Scoreが作成され、それにTemporalが加わった際にスコアが変化し、さらに自社環境のEnvironmentが加わるとさらにスコアが変化します。これをもっと強調するため、CVSS v4.0では生成に使用されるメトリックが伝わる様な命名法を使用しすることになりました。

Base Metric Group

　Base Metricは時間やユーザー環境等に依存しない、脆弱性固有の特性を表します。これはExploitability metrics（悪用可能性メトリック）とImpact metrics（影響メトリック）の2種類のメトリックセットで構成されます。

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

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

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

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

Attack Vecrot (AV)

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

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

Attack Complexity (AC)

　このメトリックは、攻撃者が既存のセキュリティを積極的に回避して、エクスプロイトを実行するために必要があるアクションを反映しています。ターゲットのセキュリティ設定に関係なく悪用が可能な脆弱性は、重要なカスタマイズを必要とする脆弱性よりも複雑性が低くなります。

　このメトリックは、ターゲットが使用するセキュリティの複雑さから反映されるもので、攻撃が成功するために必要な時間や試行回数とは関係ありません。

　また認証の回避は「Privileges Required」の方に含まれるため、Attack Complexityの要因とは見なされません。

• Low(L)
  • 攻撃者は脆弱性を悪用するためにターゲットのセキュリティを回避する必要はありません。特に条件が存在せず、攻撃者は繰り返し脆弱なコンポーネントを攻撃出来ます。
• High(H)
  • 攻撃が成功するかどうかは、標的のセキュリティを攻撃者が回避・迂回出来るかに依存します。これには下記のようなExploitの緩和技術なども含まれます。
    • たとえば、攻撃を成功させるためにアドレス空間ランダム化 (ASLR)やデータ実行防止 (DEP) を回避する必要があるもの。
  • 攻撃を成功させる前にターゲット固有の情報を収集する必要があるものも当てはまります。
    • たとえば、暗号チャネルを破るために秘密キーを知る必要がある場合など。

Attack Requirements (AT)

　このメトリックは、攻撃を可能にするためのターゲットの前提条件や実行条件となります。攻撃者がこの条件を克服しない限り、攻撃はたまにしか成功しないか、まったく成功しない可能性があります。

• None (N)
  • 攻撃が成功するかどうかは、ターゲットの条件に左右されません。攻撃者は特に問題なく脆弱性を悪用できると予想できます。
• Present (P)
  • 攻撃が成功するかどうかは、攻撃を可能にするシステムの特定の実行条件の存在に依存します。これには以下が含まれます
    • 脆弱性を悪用するには、競合状態を作り出して成功させる必要がある場合。
      • 攻撃を成功させるためには、単一のターゲットに対して複数回攻撃を実行する必要がある場合もあります。
    • ネットワーク インジェクション。
      • 攻撃者は、ターゲットとリソース間の論理ネットワークパス上に自分自身をインジェクションする必要があります (例: On-Path攻撃（旧MITM攻撃）を必要とする脆弱性)。

Privileges Required (PR)

　このメトリックは、脆弱性を悪用するために必要な攻撃者の権限レベルを示します。攻撃者が攻撃前に（無料トライアルアカウントなどで）特権認証情報を取得する方法は、このメトリックの範囲外です。また、攻撃の一環として自分自身に権限を付与できる場合のアカウントはPrivileges Requiredの要件にはなりません。

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

User Interaction (UI)

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

• None(N)
  • 脆弱性は別のユーザの関与なしに悪用される可能性があります。
• Passive(P)
  • 脆弱性を悪用するには、標的のユーザが不本意ながら意識せずに何らかのアクションを実行する必要があります。たとえばXSSやCSRF、システムに仕込まれた悪意のあるバイナリの実行、信頼できないネットワークを使用したアプリの実行などです。
• Active(A)
  • 脆弱性を悪用するには、標的のユーザが意識的に何らかのアクションを実行する必要があります。たとえばシステムに特定の方法でファイルをインポートする、コードを実行する前に特定のディレクトリにファイルを置く、Webアプリケーションに特定の文字列を送信する（リフレクション攻撃など）、アクションを実行する前に出てくるプロンプト（セキュリティ警告など）を閉じたりOKにする、などです。

Impact metrics（影響メトリック）

　Impact メトリックは、脆弱性の悪用に成功した場合の影響(Impact)になります。脆弱性のImpact メトリックを評価する際は、悪用の成功によるアクセスの増加や獲得した権限・その他のマイナスの結果を考慮する必要があります。

　たとえば、脆弱性を悪用する前にRead-Onlyの権限が必要な脆弱性を考えてみましょう。悪用に成功すると、攻撃者は同じレベルのRead-Only権限を維持したまま、Write(書き込み)権限を獲得します。この場合、Integrated Impact （整合性影響度）メトリックのみをスコアリングし、Confidentiality(機密性)およびAvailability(可用性)影響度メトリックは「None」に設定する必要があります。

　Impactの変化をスコアリングする場合は、最終的なImpactを使用する必要があることに注意してください。たとえば攻撃者が制限された情報への部分的なアクセスから開始し (機密性低)、脆弱性の悪用に成功した結果として機密性が完全に失われる (機密性高) 場合には、結果として得られる CVSS Baseメトリックは、「最終段階」のImpactメトリック値 (機密性高) を参照する必要があります。

　Impactメトリックの値を評価する際には、評価者は「脆弱なシステムへの影響」と、「脆弱なシステム外への影響」の両方を考慮する必要があります。これらは、「脆弱なシステムへの影響」と「後続のシステムへの影響」という2つのImpactメトリックセットによって表されます。

　この様なシステムの内外を考える場合には、評価者は対象システムのコンセプトモデルを使用する必要があります。つまり脆弱性のスコアリングの対象となる「システム」とは、「一貫した機能と一連のセキュリティポリシーを備えた環境で実行される処理ロジックのセット」として定義されます。

　脆弱性は、このようなシステムのコンポーネントに存在します。消費者の観点から目的または機能を果たすテクノロジ製品またはソリューションは、システム (サーバー、ワークステーション、コンテナ化されたサービスなど) と見なされます。

　システムがその機能を別のシステムにのみ提供する場合、または別のシステムによって排他的に使用されるように設計されている場合、それらは一緒にスコアリングの対象となるシステムと見なされます。たとえば、スマートスピーカーによってのみ使用されるデータベースは、そのスマートスピーカー システムの一部と見なされます。データベースの脆弱性がスマートスピーカーの誤動作につながる場合、データベースとそれに対応するスマートスピーカーの両方が脆弱なシステムと見なされます。

　脆弱性が脆弱なシステムの外部に影響を与えない場合、評価者は後続のシステム影響メトリックをなし (N) のままにしておく必要があります。脆弱なシステムの外部で発生するすべての影響は、後続のシステム影響セットに反映される必要があります。

　環境メトリックグループでのみ評価される場合、後続のシステム影響には、対象システムに定義されている論理システムに加えて、人間への影響も含まれる場合があります。環境メトリックグループの人間への影響のオプションについては、安全性 (S) で詳しく説明します。

Confidentiality (VC/SC)

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

Confidentiality Impact to the Vulnerable System (VC)

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

Confidentiality Impact to the Subsequent System (SC)

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

Integrity  (VI/SI)

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

Integrity Impact to the Vulnerable System (VI)

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

Integrity Impact to the Subsequent System (SI)

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

Availability (VA/SA)

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

Availability Impact to the Vulnerable System (VA)

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

Availability Impact to the Subsequent System (SA)

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

Threat Metrics (脅威メトリック)

　脅威メトリックは、脆弱性に対する悪用手法やExploitコードの現在の状態を測定します。

Exploit Maturity (E)

　このメトリックは、脆弱性が攻撃される可能性を測定するもので、悪用手法やエクスプロイトコードがどれだけ出回っているのか、またアクティブな「実際の」悪用の現状に基づいています。

　簡単に使用可能なエクスプロイトコードが公開されると、スキルのない攻撃者も攻撃ができるため潜在的な攻撃者の数が増え、脆弱性の深刻度が高まります。エクスプロイト公開の当初では、エクスプロイトは理論的なものに過ぎない場合もあります。

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

　エクスプロイトコードの状況とエクスプロイト手法の状況に関する情報に基づいて、エクスプロイトの成熟度 (E) の値を入力します。この情報は、このドキュメントでは「脅威インテリジェンス」と呼ばれます。

　運用上の推奨事項: すべての脆弱性のエクスプロイト成熟度情報を提供する脅威インテリジェンスソースは、部分的にしかカバーしていないものよりも優先されます。

　また、多くの脅威インテリジェンスは包括的ではないため、複数の脅威インテリジェンスソースを使用することをお勧めします。この情報はできるだけ頻繁に更新し、CVSS 評価への適用を自動化する必要があります。

• Not Defined (X)
  • 脅威インテリジェンスが利用できないことを示しています。これはデフォルト値で、つまり、Scoreには「Attacked」を割り当てた場合と同じ影響があります。
• Attacked
  • 利用可能な脅威情報に基づいて、次のいずれかが当てはまる必要があります。
    • この脆弱性を狙った攻撃（テストまたは成功）が報告されている。
    • 脆弱性悪用のためのキットが利用可能である（エクスプロイトツールキットなど）。
• Proof-of-Concept(P)
  • PoCとしてのエクスプロイトコードが利用可能であり、攻撃は実際には行われていない状態がこれにあたります。つまりこの場合「Attacked」の値は適用されません。
• Unreported(U)
  • 利用可能な脅威インテリジェンスに基づいて、次の各条件が満たされている必要があります。
    • 公開されているPoCのエクスプロイトコードに関する知識がない。
    • この脆弱性を悪用する試みが報告されていることを知らない。
    • 脆弱性を悪用する公開ツール等の知識がない。

Environmentl環境メトリック（Environment Metrics)

機密性、完全性、可用性の要件 (CR、IR、AR)

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

　例えば資産が「可用性が最も重要であるビジネス機能をサポート」している場合には、機密性や整合性よりも可用性に高い値を割り当てることができます。各セキュリティ要件には、低、中、高の 3 つの値があります。未定義 (X) がデフォルト値になりますがこれは高(H)のメトリクス値と同等になります。

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

Modified Base Metrics

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

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

• 例1
  • コンポーネントのデフォルト構成では、特定の機能にアクセスするために高い権限が必要になる場合があります。 ただし、現実の環境では、ユーザーを認証せずにデフォルトで管理者権限が付与される場合があります。この様な場合には、特定の環境におけるこのより深刻な状況を反映するために、必要な権限を「高」に設定し、変更された権限を「なし」に設定することができます。
• 例 2
  • 脆弱なシステムのデフォルト構成では、管理者権限でリスニングサービスを実行するように設定されている場合があり、この構成が侵害されると、攻撃者に機密性、整合性、可用性の影響がすべて「高」になる可能性があります。 しかし、現実の環境では、同じインターネット サービスが制限された権限で実行されている可能性があります。その場合、変更された機密性、変更された整合性、変更された可用性はそれぞれ「低」に設定されます。
• 例 3
  • インターネットへのアクセスもインターネットからのアクセスもない隔離されたネットワークにあるシステムとアプライアンスは、WANを介して攻撃されることはありません。これらのシステムで見つかったすべての脆弱性は、攻撃ベクトル (AV) の値が「ネットワーク」から「隣接(Adjacent)」に削減される可能性があります。

Modified Base Metrics and Safety

　システムの導入方法や導入場所によって安全性に影響が出る可能性がある場合、そのシステム内の脆弱性を悪用すると、環境メトリクスグループの安全性に影響が出る可能性があります。技術的な脆弱性の悪用 (脆弱なシステムの可用性または整合性のいずれかに影響する) が人間の安全性に影響を与える可能性がある場合、安全性の修正された後続システム影響を使用する必要があります (MSI:S/MSA/S)。

　安全性メトリクス値は、脆弱性が悪用された結果、予測どおりに負傷する可能性のある人間の安全性に関する影響を測定します。他の影響メトリクス値とは異なり、安全性は後続システム影響セットにのみ関連付けることができ、可用性および整合性メトリクスの N/L/H 影響値に加えて考慮する必要があります。

　注: 安全性が該当する場合は、可用性および整合性メトリクスに H の影響値が既に指定されている場合でも、それに加えて、安全性を明示的に割り当てる必要があります。安全への影響は、以下の表のIEC 61508 の定義を使用して、脆弱性を悪用すると、限界またはそれ以上の傷害が発生する可能性があると予測される場合に適用されます。

Modified 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)

Supplemental Metrics

　Supplemental(補足)メトリック グループと呼ばれる新しいメトリックグループでは、脆弱性の追加の外部属性を説明および測定する新しいメトリックを提供します。

　このコンテキスト情報は、現場で使用するユーザの環境ごとに異なる方法になる場合があります。どのメトリックも、最終的に計算される CVSS スコア (CVSS-BTE など) には影響しません。

　組織は、各メトリック、またはメトリックのセット/組み合わせの重要性や有効な影響を割り当てて、最終的なリスク分析への影響を大きくしたり、小さくしたり、まったく与えないようにすることができます。メトリックと値は、脆弱性自体の追加の外部特性を伝えるだけです。

Safety(S) : 安全性

　安全性(Safety: S)の提供は完全にオプションです。サプライヤとベンダーは必要に応じて、安全性を補足メトリックとして提供することも、提供しないこともできます。システムに安全性に合わせた使用または目的がある場合、そのシステム内の脆弱性を悪用することで、Supplemental(補足)メトリックグループで表すことができる安全性(Safety: S)への影響が生じる可能性があります。

　安全性メトリック値が提供されていないことは、安全性に関連する影響がないことを意味するものではありません。

• Not Defined (X)
  • メトリックは評価されていない。
• Present (P)
  • 脆弱性の結果は、IEC 61508 の結果カテゴリの「marginal」、「Critical」、「Catastrophic」の定義を満たしています。
• Negligible (N)
  • 脆弱性の結果は、IEC 61508 の結果カテゴリ「negligible」の定義を満たしています。

Automatable (AU)

　”Automatable”メトリックは、キルチェーン [Hutchins 他、2011] のステップ 1 ～ 4 に基づいて、「攻撃者は複数のターゲットにわたってこの脆弱性の悪用イベントを自動化できますか?」という質問に対する回答となります。これらのステップは、偵察、武器化、配信、および悪用です。評価された場合、メトリックは no または yes の値を取ることができます。

• Not Defined (N)
• No(N)
  • 攻撃者は、何らかの理由でこの脆弱性のために、キルチェーンの4つのステップすべてを完全に自動化することはできません。
• Yes(Y)
  • 攻撃者は、キル チェーンの 4 つのステップすべてを確実に自動化できます。これらのステップとは、偵察、武器化、配信、悪用 (たとえば、脆弱性が「ワーム化可能」) です。

Provider Urgency (U)

　現在、多くのベンダーが製品のセキュリティアドバイザリを通じて消費者に補足的な重大度評価を提供しています。プロバイダーが提供する追加の評価を組み込むための標準化された方法を容易にするために、プロバイダー緊急度と呼ばれるオプションの「パススルー」Supplemental メトリックが利用可能です。

• Not Defined(X)
  • メトリックは評価されていません。
• Red
  • プロバイダーは、この脆弱性の影響が最も緊急性が高いと評価しました。
• Amber
  • プロバイダーは、この脆弱性の影響を中程度の緊急性があると評価しました。
• Green
  • プロバイダーは、この脆弱性の影響は緊急性が低いと評価しました。
• Clear
  • プロバイダーは、この脆弱性の影響は緊急性がない (Info) と評価しました。

Recovery (R)

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

• Not Defined
  • メトリックは評価されていません。
• Automatic (A)
  • 攻撃が実行された後、システムは自動的にサービスを回復します。
• User (U)
  • 攻撃が実行された後、システムを回復するには、ユーザーによる手動介入が必要です。
• Irrecoverable (I)
  • 攻撃が実行されると、システムサービスはユーザーによって回復できなくなります。

Value Density (V)

　Value Densityは、攻撃者が1回の攻撃イベントで制御できるリソースを表します。値には、拡散と集中の 2 つの値があります。

• Not Defined
  • メトリックは評価されていません。
• Diffuse (D)
  • 脆弱なシステムには限られたリソースしかありません。つまり、攻撃者が 1 回の攻撃で制御できるリソースは比較的小さいということです。Diffuse型 (限られた) 値密度の例としては、単一の電子メール クライアントの脆弱性に対する攻撃が挙げられます。
• Concentrated (C)
  • 脆弱なシステムにはリソースが豊富にあります。経験的に、このようなシステムはユーザーではなく「システム オペレーター」が直接責任を負うことが多いです。集中した (つまり、広範囲の) 価値密度の例としては、中央の電子メール サーバーへの攻撃が挙げられます。

Vulnerability Response Effort (RE)

　Vulnerability Response Effort メトリックの目的は、インフラに導入されている製品やサービスの脆弱性の影響に対して、現場のエンジニアが初期対応を行うことがどの程度難しいかについて補足情報を提供することです。

　現場のエンジニアは、軽減策を適用したり修復をスケジュールしたりする際に、必要な労力に関するこの追加情報を考慮に入れることができます。脆弱性対応努力を計算する際には、利用可能な最速の対応を展開するために必要な労力を考慮する必要があります。

• Not Defined
  • メトリックは評価されていません。
• Low (L)
  • 脆弱性への対応に必要な労力は少ない/わずかです。例としては、ファイアウォールフィルター構成など、使用側による即時の更新、アップグレード、または交換を必要としない、より優れたドキュメント、構成の回避策、またはベンダーからのガイダンスに関するコミュニケーションが挙げられます。
• Moderate(M)
  • 脆弱性に対応するために必要なアクションには、現場に代わってある程度の労力が必要であり、実装するサービスへの影響は最小限に抑えられる可能性があります。例としては、単純なリモートアップデート、サブシステムの無効化、ドライバーアップデートなどのロータッチソフトウェア アップグレードが挙げられます。
• High(H)
  • 脆弱性に対応するために必要なアクションは重大かつ/または困難であり、スケジュールされたサービスへの影響が長引く可能性があります。この脆弱性に対する唯一の解決策には、物理​​的な交換が含まれます (たとえば、配備されたユニットは、倉庫レベルの修理または交換のためにリコールされる必要があります)。

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

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

まとめ

　CVSS v4.0では、v3.1と似ているところもありますが、一部ガラッと変わっている部分もありますので、スコアだけでなく攻撃手法などを確認する場合にはベクトルの意味もしっかりと見直しながら確認していただければと思います。

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

参考リンク

• NIST: NVD CVSS v4.0 Official Support

関連記事:

CVSSとは？脆弱性の性質と重大性を共有するためのフレームワークCWEとは？ソフトウェアの脆弱性の種類を分けるためのIDを解説CPEとは？ハードウェア／ソフトウェアなどを識別する情報を解説SCAP（セキュリティ設定共通化手順）とは？専門家が解説