CVSSバージョン4.0の変更点と活用可能性

  • 2023-08-07

スコアリングシステムの全体像

バージョン4.0も現行バージョン同様、脆弱性に関連するさまざまなメトリクスを評価することで、当該脆弱性の深刻度を0.0から10.0までのスコアとして算出する仕組みとなっています。メトリクスに関する現行バージョンからの主な変更点は以下の図表のとおりです。

メトリクスに関する現行バージョンからの主な変更点 の図

各メトリクスの変更点に触れる前に、スコアリングシステム全体の変更点について説明します。現行バージョンでメトリクスは、脆弱性の性質を対応する「基本評価基準」、悪用状況や対策情報の有無といった時間により変化する要素に対応する「現状評価基準」、脆弱性が存在するソフトウェアの利用環境に対応する「環境評価基準」の3つから構成されていました。バージョン4.0では近年の脅威インテリジェンスの発展および導入状況に伴い、「現状評価基準」（Temporal Metrics）の名称が「脅威評価基準」（Threat Metrics）に変更されています。また、4つ目の新たなメトリクスグループとして「補足評価基準」（Supplemental Metric Group）が追加されています。このグループは、他の3グループのメトリクスに基づいて算出されたスコアの文脈を補足することを目的としており、スコアリング自体に影響を与えません。製品ベンダーやセキュリティベンダーなどが発信している、脆弱性に関連した情報を評価・設定することで、脆弱性への対応を行う組織はスコアに加えて、これらの情報を脆弱性対応プロセスの中で活用することが可能となります。

また、現行バージョンでは「基本評価基準」に基づいてCVSSスコア（基本値）を算出した後、「現状評価基準」による評価を行うことで現状値を算出し、「環境評価基準」による評価を行うことで環境値を算出するというプロセスとなっていました。一方、バージョン4.0では、評価者が任意のメトリクスの組み合わせを利用する可能性を考慮して、利用されたメトリクスを明確化するために以下の命名方法が提供されています。

  • CVSS-B
    • 「基本評価基準」（Base Metrics）のみを利用して算出
  • CVSS-BE
    • 「基本評価基準」（Base Metrics）および「環境評価基準」（Environmental Metrics）を利用して算出
  • CVSS-BT
    • 「基本評価基準」（Base Metrics）および「脅威評価基準」（Threat Metrics）を利用した算出
  • CVSS-BTE
    • 「基本評価基準」（Base Metrics）、「脅威評価基準」（Threat Metrics）および「環境評価基準」（Environmental Metrics）を利用して算出

上記のいずれのケースでも全てのグループのメトリクスの値がスコア計算では利用され、利用していないメトリクスグループの各メトリクスの値は既定値である「未定義」として取り扱われます。そのため、どのメトリクスグループをスコアリングに利用したかを明確にするため、「CVSS-B:5.0」「CVSS-BE:8.2」といった表記が推奨されています。

基本評価基準（Base Metric Group）

このグループのメトリクスは、脆弱性攻撃の難易度や条件などに関連する、「攻撃の難易度」（Exploitability Metrics）と「攻撃時による影響」（Impact Metrics）から構成されています。それぞれの主な変更点は次のとおりです。

攻撃の実行条件（Attack Requirements）の追加

バージョン4.0から追加されたメトリクスとなり、攻撃を成立させるうえで攻撃者が解決すべき前提条件の有無を評価します。現行バージョンでも存在する「攻撃の複雑さ」（Attack Complexity）が、攻撃を緩和するための「セキュリティ対策」「制限の回避」「突破の難易度」を評価している一方で、当該メトリクスは、攻撃の実行および配置に関する条件を特定します。「攻撃の実行条件」（Attack Requirements）が取り得る値は次のとおりです。

攻撃の実行条件（Attack Requirements）
値 概要
None／なし 攻撃の成否は、システムの配置や実行条件には依存しない。攻撃者は、全てまたはほとんどのケースで脆弱性に到達し、攻撃を成功させることができる。
Present／存在する 攻撃の成否は、システムの特定の配置や実行条件により依存する。具体的には以下のケースが含まれる。
  • 競合状態（レースコンディション）に勝利するために繰り返し攻撃を試行する必要がある（確率的に攻撃が成功・失敗する）。
  • 中間者攻撃によりデータのインジェクションが可能となる脆弱性を悪用する際に、攻撃者が自身をネットワーク経路上に配置する必要がある。

具体的な例としては、競合状態（レースコンディション）に勝利するために繰り返し攻撃を試行する必要があるケース（確率的に攻撃が成功・失敗する）、中間者攻撃によりデータのインジェクションが可能となる脆弱性を悪用する際に攻撃者が自身をネットワーク経路上に配置する必要があるケースが挙げられます。

ユーザー関与レベル（User Interaction）の値の見直し

攻撃を成立させるために利用者の関与が必要か否かを評価するメトリクスです。現行バージョンでは、「要」「不要」の二値判定でしたが、バージョン4.0では「アクティブ」「パッシブ」「なし」の三値で評価を行います。「ユーザー関与レベル」（User Intraction）が取り得る値は以下のとおりです。

ユーザー関与レベル（User Interaction）
値 概要
None／なし 攻撃者は、ユーザーによるいかなる操作も必要とせず、攻撃を成立させることができる。具体的には以下のケースが含まれる。
  • リモートの攻撃者が脆弱なシステムにネットワーク経由でパケットを送信する。
  • 認証済みのローカルユーザーが特権奪取のための不正コードを実行する。
Passive／パッシブ 攻撃者が攻撃を成立させるためには、ユーザーによる限定的な関与が必要となる。ユーザーはセキュリティ機能を積極的に無効化する必要がない。具体的には以下のケースが含まれる。
  • 蓄積型XSSやCSRFなどのアクセス時に悪意のコンテンツがレンダリングされるように細工された正規サイトへのアクセス。
  • システムに仕込まれた悪意あるコードを呼び出すプログラムの実行。
  • 信頼されていない、または侵害されたネットワーク上での外部との通信。
Active／アクティブ 攻撃を成立させるためには、ユーザーが脆弱性が存在するシステム上で意識的に操作を行う、または積極的にセキュリティ機能を阻害する操作を行う必要がある。具体的には以下のケースが含まれる。
  • 脆弱性アプリケーションにデータを読み込ませる。
  • 攻撃が実行される前に特定のフォルダに、攻撃に必要となるファイルを設置する。
  • 反射型XSS、セルフXSSのように特定の文字列をサーバーに送信する。
  • ファイルのオープン・編集、デバイスの接続などに関するセキュリティ警告を無視する、受け入れる。

スコープの廃止および後続システム評価の追加

バージョン3.0で追加されたスコープ（Scope）がメトリクスから廃止され、後続システム（Subsequent System）ごとに機密性、完全性、可用性を評価するように見直しが行われました。

スコープは、脆弱性が攻撃された場合、その影響が脆弱性が存在するソフトウェア・システムの範囲に留まるのか、その周辺ソフトウェアやシステムまで拡大するのかを「変更有り」「変更なし」の二値で判断するメトリクスです。当該評価を行うためには、どこからどこまでを「脆弱性が存在するソフトウェア・システム」と捉えるのかが重要となります。バージョン4.0において、CVSSでスコアリングを行う対象は「一貫した機能を持つ環境情で実行されるコンピューティングロジックおよびセキュリティポリシーの集合体」と定義されているため、この定義において区別される範囲を、異なるソフトウェア・システム（後続システム）と見なすことができます。他方で、2つの異なるシステムの一方がもう一方を独占的に利用する場合、両者を1つのシステムと見なすことができます。

上記の考え方に基づき、脆弱性が存在するソフトウェア・システムで成立した脆弱性攻撃の影響が、後続システムの機密性、完全性、可用性に与える影響を以下のメトリクスで評価します。

後続システムの機密性への影響（Confidentiality Impact to the Subsequent System）
値 概要
High／高 脆弱性攻撃により機密性が完全に損なわれた結果、後続システムにおいても全てのリソースが攻撃者に漏洩する。または、一部の制限された情報に限定されるが、漏洩する情報が直接的で深刻な影響を与える（管理者のパスワード、ウェブサーバーの秘密鍵の漏洩など）。
Low／低 後続システム内で一定程度の機密性が損なわれる。制限された情報アクセスは得られるが、攻撃者は窃取できる情報をコントロールすることはできない、または漏洩する情報の量や種類が制限される。漏洩した情報は、後続システムに直接的で深刻な影響を与えない。
N／無視できる 後続システムにおいて機密性は損なわれない。脆弱性攻撃による機密性の影響は脆弱性を持ったソフトウェア・システムに限定される。
後続システムの完全性への影響（Integrity Impact to the Subsequent System）
値 概要
High／高 完全性が完全に失われる、または保護が完全に失われる。例えば、攻撃者は脆弱なシステムで保護されている全てのファイルを変更することができる。または、一部のファイルしか変更できないものの悪意のある変更により、脆弱なシステムに直接的で深刻な結果をもたらす。
Low／低 データの変更は可能だが、攻撃者は変更の結果をコントロールできない、または変更の量が制限される。データの変更は、脆弱なシステムに直接的で深刻な影響を与えない。
N／無視できる 後続システムにおいて完全性は損なわれない。脆弱性攻撃による完全性の影響は脆弱性を持ったソフトウェア・システムに限定される。
後続システムの可用性への影響（Availability Impact to the Subsequent System）
値 概要
High／高 可用性が完全に失われ、攻撃者が後続システムのリソースへのアクセスを完全に拒否できるようになる。この損失は持続的であり、攻撃者が攻撃を可用提供し続けている間、または攻撃が完了した後もその状態が持続する。あるいは、攻撃者は一定程度の可用性を拒否する能力を持ち、可用性の損失は後続システムに直接的で深刻な結果をもたらす。
Low／低 パフォーマンスが低下したり、リソースの利用が中断したりする。脆弱性が繰り返し悪用されたとしても、攻撃者は正当なユーザーへのサービスを完全に拒否する能力を持たない。後続システムのリソースは、常に部分的に利用可能であるか、一部の時間だけ完全に利用可能であり、全体として後続システムに直接的で深刻な影響はない。
N／無視できる 後続システムにおいて可用性は損なわれない。脆弱性攻撃による可用性の影響は脆弱性を持ったソフトウェア・システムに限定される。

脅威評価基準（Threat Metric Group）

現行バージョンでは、「現状評価基準」（Temporal Metrics）として「攻撃される可能性」「利用可能な対策レベル」「脆弱性情報の信頼性」の3つのメトリクスから構成されていましたが、バージョン4.0では「脅威評価基準」（Threat Metrics）と改名され、含まれるメトリクスも「攻撃される可能性」（Exploit Maturity）の1つに見直されています（Exploit Code Maturityから改名）。「攻撃される可能性」が取り得る値は以下のとおりです。

攻撃される可能性（Exploit Maturity）
値 概要
Not Defined／未定義 当該メトリクスが利用されていない場合の既定値。または、当該メトリクスを判定することができない。
Attacked／攻撃確認 以下のいずれかに該当
  • 脆弱性を悪用した攻撃試行、攻撃成功が報告されている。
  • 脆弱性を容易に悪用するためのツール、手法などが公開されている、または非公開だが入手可能。
Proof-of-Concept／概念実証 以下の全てに該当
  • 脆弱性攻撃の概念実証が公開されている。
  • 脆弱性悪用に関する報告は確認されていない。
  • 脆弱性を容易に悪用するためのツールなどに関する情報は確認されていない。
Unreported／未報告 以下の全てに該当
  • 脆弱性攻撃の概念実証が存在しない。
  • 脆弱性悪用に関する報告は確認されていない。
  • 脆弱性を容易に悪用するためのツールなどに関する情報は確認されていない。

環境評価基準（Environmental Metric Group）

このメトリクスグループは、現行バージョンからの大きな変更はありません。大きく2種類のメトリクスから構成されており、1つ目は脆弱性が存在するソフトウェアを利用しているシステムのユーザー環境における「機密性」「完全性」「可用性要求」を評価するものです。システムが取り扱うデータの種別や規模、攻撃を受けた際の業務影響を踏まえてユーザーが選択する必要があります。

2つ目は、サードパーティによって評価済みの「基本評価基準」（Base Metrics）について実運用環境を踏まえて再評価するものです。例えば、「ネットワーク経由で受信したデータによりサーバソフトウェアが攻撃を受ける」という脆弱性を考えた場合、通常は「基本評価基準」（Base Metrics）における攻撃元区分（Attack Vector）は「ネットワーク」として評価されています。一方自社の環境では、当該ソフトウェアはネットワークには公開しておらず、ローカルでのみ運用していた場合、攻撃元区分（Attack Vector）を「ローカル」に再評価することになります。

補足評価基準（Supplemental Metric Group）

バージョン4.0で追加されたメトリクスグループであり、スコアリングに直接影響を与えないものの、ユーザーがスコアに基づいて脆弱性対応を行ううえで有用となるコンテキスト、解釈の参考情報を評価します。

安全性（Safety）

システムに安全性に適合した利用目的が存在する場合、脆弱性攻撃による安全性への影響を評価します。なお、本メトリクスの評価は任意であり、未評価であることは「安全性に関するインパクトがないこと」を意味しない点に留意が必要です。安全性は、IEC 61508に定義されているカテゴリに基づき以下のとおり評価します。

安全性（Safety）
値 概要
Not Defined／未定義 本メトリクスは未評価。
Present／存在する 脆弱性がもたらす影響は、IEC 61508で定義されている「Marginal」「Critical」「Castrophic」のいずれかに該当する。
Negligible／無視できる 脆弱性がもたらす影響は、IEC 61508で定義されている「Negligibile」に該当する。
IEC 61508におけるカテゴリ定義
値 概要
Catastrophic 複数の人命損失
Critical 1名の人命損失
Marginal 1名または複数名の重大な負傷
Negligible 最悪でも軽傷

自動化可能性（Automatable）

サイバーキルチェーンにおける「偵察」「武器化」「デリバリー」「エクスプロイト」の一連の攻撃を自動化することが可能かどうかを評価します。

自動化可能性（Automatable）
値 概要
Not Defined／未定義 本メトリクスは未評価。
No／いいえ 攻撃者は何らかの理由で「偵察」から「エクスプロイト」までの一連の攻撃を自動化することができない。
Yes／はい 攻撃者は「偵察」から「エクスプロイト」までの一連の攻撃を自動化することができる。

供給者による緊急度（Provider Urgency）

近年、脆弱性が発見された場合、製品ベンダーなどのソフトウェア供給者がCVSSによるスコアリング結果を含むアドバイザリーを独自に発行・提供していることが多々あります。脆弱性が発見されたソフトウェアが複数の供給者を介して最終消費者に提供される場合、より最終消費者に近い供給者による緊急度を評価するために本メトリクスが提供されています。

供給者による緊急度（Provider Urgency）
値 概要
Not Defined／未定義 本メトリクスは未評価。
Red／レッド 供給者は当該脆弱性を最も緊急性が高いと評価。
Amber／アンバー 供給者は当該脆弱性を中程度の緊急性と評価。
Green／グリーン 供給者は当該脆弱性の緊急性は低いと評価。
Clear／クリア 供給者は当該脆弱性に緊急性がないと評価。

回復可能性（Recovery）

攻撃が実施された後、パフォーマンスと可能性の観点からサービスを回復するコンポーネント・ソフトウェアの回復力を評価します。

回復可能性（Recovery）
値 概要
Not Defined／未定義 本メトリクスは未評価。
Automatic／自動 攻撃が実行された後、コンポーネント・システムは自動的にサービスを回復する。
User／ユーザー 攻撃が実行された後、サービスを回復するためにはユーザーによる操作が必要。
Irrecoverable／回復不能 攻撃が実行された後、ユーザーはサービスを回復することができない。

価値密度（Value Density）

攻撃が一度成立した際に、攻撃者が獲得できるリソースの密度を評価します。

価値密度（Value Density）
値 概要
Not Defined／未定義 本メトリクスは未評価。
Diffuse／拡散 脆弱なコンポーネントを含むシステムが保有するリソースは限定的である（例：単一メールクライアントに対する攻撃）。
Concetrated／濃縮 脆弱なコンポーネントを含むシステムが保有するリソースは豊富である（例：ユーザーではなく運用管理者向けの攻撃、メールクライアントではなくメールサーバーへの攻撃）。

対応の困難度（Vulnerability Response Effort）

ユーザーが自組織で運用されているシステムに対して脆弱性の対応を行う困難の程度を評価します。ユーザーはこの評価結果に基づいて脆弱性対応の労力やスケジューリングを検討することができます。

対応の困難度（Vulnerability Response Effort）
値 概要
Not Defined／未定義 本メトリクスは未評価。
Low／低 脆弱性に対応するために必要な労力は少ない（例：設定変更、アップデートなどを必要としないベンダーからの回避策の提供）。
Moderate／中 脆弱性に対応するために最終消費者やユーザーに代わって何らかの対応が必要であり、サービス提供に最小限の影響を与える（例：リモートアップデート、サブシステムの無効化、ドライバーのアップデート）。
High／高 脆弱性に対応するために必要な措置は、重大かつ困難であり、サービスのサービスへの影響が延長される恐れがある。または、リモート対応が不可能であり、現地での物理的な交換が必要（例：特権的なドライバーの更新、UEFI BIOSの更新、故障ハードウェアの交換）。

SSVCとの比較

SSVCと比較した場合、SSVCが決定木に基づいて具体的な判断を導出するアプローチであるのに対して、CVSSはスコアリングシステムであるため、スコアの解釈・判断が必要である点は従来から変わりがありません（「SSVC（Stakeholder-Specific Vulnerability Categorization）を活用した脆弱性管理」参照）。一方で「補足評価基準」（Supplemental Group）の中には「安全性」（Safety）、「自動化可能性」（Automatable）、「価値密度」（Value Density）といったSSVCでも決定木の中で利用されているメトリクスが採用されており、上記のとおりスコアの解釈に柔軟性を持たせる方針が伺えます。ただ、これらのメトリクスの利用は任意となっているため、ユーザー目線ではどの程度サードパーティによる評価が行われ、情報として供給されるか、自組織での評価を迅速に実施できるかどうかが活用のポイントになると考えられます。

今後の展望

冒頭記載のとおり2023年10月にCVSSバージョン4.0がリリースされる予定です。リリース後は政府関連組織、セキュリティベンダーなどにおいて利用が始まり、現行バージョンと並行運用しながら段階的な移行が進むと考えられます。ユーザー企業の立場としては、スコアリングに用いられるメトリクスが見直されたものの、提供される最終アウトプットは0.0から10.0までのスコアであるため、既存の脆弱性対応プロセスに大きな影響はないと考えられます。一方で、CVSSバージョン4.0、SSVCといった近年の評価システムでは、利用者が脆弱性対応の要否、緊急性を判断するための新たなメトリクスが形式化されています。こうした動向を踏まえると、自組織の意思決定に影響する要素を棚卸し、脆弱性管理プロセスを自組織にとってより合理的なものに改善していくことが重要になると考えられます。

執筆者

村上 純一

パートナー, PwCコンサルティング合同会社

Email

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
{{contentList.loadingText}}
{{contentList.viewAllLabel}}

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
{{contentList.loadingText}}
{{contentList.viewAllLabel}}

本ページに関するお問い合わせ

フォーム

関連サービス