【翻訳】CVSS v3.1 UserGuide - SIOS SECURITY BLOG

こんにちは。SIOS OSSエバンジェリスト/セキュリティ担当の面和毅です。

やや古くなってしまいましたが、2019年の6月にCVSS 3.1がリリースされました。既に脆弱性情報(CVE)に紐付いて、Red Hat等からはCVSS 3.1での情報も出てきていますので、こちらでCVSS v3.1 UserGuideの拙訳を行いたいと思います。用語に関しては、共通脆弱性評価システムCVSS v3概説 (IPA)も参考にさせていただいてます。

2020/02/11: 3.6までの翻訳が終わりました。

2020/02/13: 3.11までの翻訳が終わりました。

Common Vulnerability Scoring System v3.1: User Guide

オリジナル原文：CVSS v3.1 User Guide (FIRST)

Common Vulnerability Scoring System（CVSS）は、ソフトウェア脆弱性の性質と重大性を共有するためのオープンフレームワークです。 CVSSは、Base(基本評価基準), Temporal(現状評価基準), Environment(環境評価基準)の3つのメトリックグループで構成されます。 Baseのグループは、時間とともにユーザー環境全体で変化しない本質的な脆弱性の性質を表し、Temporalグループは時間に伴い変化する脆弱性の性質を反映し、Environmentalグループはユーザーの固有の環境での脆弱性の特性を表します。Baseメトリックは、Temporal及びEnvironmentメトリックのスコアにより変更される、0から10の範囲のスコアを生成します。CVSSスコアはまた、スコアを導出するために使用される値による圧縮テキスト表現であるベクトル文字列としても表されます。このドキュメントでは、CVSSバージョン3.1の公式仕様を提供します。

最新のCVSSリソースはhttps://www.first.org/cvss/で見る事ができます。

CVSSは、米国を拠点とする非営利組織であるFIRST.Org、Inc.（FIRST）が所有および管理しており、その使命は世界中のコンピューターセキュリティインシデント対応チームを支援することです。FIRSTは、CVSSおよびこのドキュメントを定期的に更新する権利を保有しています。FIRSTはCVSSのすべての権利と利益を所有していますが、以下の条件に従って、CVSSを自由に使用できるように公開しています。CVSSを使用または実装するために、FIRSTのメンバーシップは必要ありませんが、FIRSTはCVSSを使用する個人または団体が適切な帰属を提供することを要求します。該当する場合、CVSSはFIRSTが所有し許可を得て使用します。さらにFIRSTの使用条件としては、スコアを発行する個人または組織がこのドキュメントで説明するガイドラインに準拠し、スコアとスコアベクトルの両方を提供して、他のユーザーがスコアの導出方法を理解できるようにすることを要求しています。

1. Introduction

このガイドは共通脆弱性評価システム CVSS(Common Vulnerability Scoring System) version 3.1の仕様文書となり、CVSS version 3.0からの明白な変更やスコアリングの案内、スコアリングの指標なども盛り込んだものになっています。

2004年の最初のリリース以来、CVSSは広く採用されています。 2007年9月、CVSS v2.0は、Payment Card Industry Data Security Standard（PCI DSS）の一部として採用されました。PCI DSSに準拠するには、クレジットカードを処理する販売業者は、コンピュータシステムにCVSSスコア4.0以上の脆弱性がないことを証明する必要があります。2007年、国立標準技術研究所(NIST)はCVSS v2.0をSecurity Content Automation Protocol (SCAP)に含めるました。2016年3月、CVSS v3.0は、脆弱性スコアリングの標準(ITU-T X.1521)に準拠しました。

2. CVSS Version 3.1での変更点

CVSSバージョン3.0と3.1の変更点は、新しいメトリックやメトリック値を導入せずに、既存の計算式に大きな変更を加えることなく、既存の標準を明確にして改善することに焦点を当てています。重要な変更点を以下に説明します。

2.1. CVSSは重大性を測るものであり、それ単一でリスクを測るものでは無い

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

包括的なリスクの評価がより適切な状況で、CVSS Baseスコアが使用されているという懸念が上がっています。CVSS v3.1仕様書では、CVSSBaseスコアは、時間とユーザ環境全体で一定の、脆弱性の固有の特性のみを表すことを明確にしています。CVSS Baseスコアは、環境の分析に関係した補足がされており、CVSS Temporal メトリック氏及びEnvironment メトリックによって変化する属性からも補足されていなくてはなりません。より適切には、単なるCVSS Baseスコアよりも、多くの要因を考慮出来る包括的リスク評価システムを採用する必要があります。このようなシステムは通常、CVSSの範囲外となる露出度や脅威等の要因も考慮します。

2.2. 攻撃元区分(Attackベクタ)の変更と修正

CVSS v3.0は、Open Systems Interconnection（OSI）モデルへを参照して、攻撃ベクトル(AV)のメトリック値を説明していました。技術的には正確ですが、この表現は一般的なCVSS 提供者や仕様者には馴染みのない可能性があるため、表現が変わっています。

攻撃元区分(Attackベクタ(AV))のメトリック値である”隣接(A)”の使用はCVSS v3.0で定義されたように制限されています。論理的に隣接しているか、または信頼されたネットワーク(MPLS、VPNなど)に対する攻撃元区分(攻撃ベクトル)のあいまいさは、これらの”制限されたアクセスの”ネットワークを含むように、隣接の定義を拡張することで対処されています。

セクション3.6には、リソースがファイアウォールの内側のみにある場合の、修正された攻撃元区分(攻撃ベクトル)の環境メトリックの使い方に関する新しいガイダンスが含まれています。

2.3. スコアリングガイダンスの変更

CVSSの仕様書およびユーザーガイドは、CVSSアナリストがスコアを提供する際に、色々な状況では定常的に防御できるような、以前はあいまいであると考えられていた状況でのスコアを作成する際に役立つ補足ガイダンスを用いて更新されました。新しいスコアリングガイダンスのサンプルを以下に示します。

2.3.1 スコアリングは詳細な知識を前提とするべきである

CVSS仕様書は、Baseメトリックのスコアを付ける際に、「攻撃者がターゲットとなるシステムに対して、一般的な設定とデフォルトの防御メカニズム（すなわちビルトインのファイアウォール、呼び出し制限、トラフィックポリシなどを含む）の高度な知識を持っている」と仮定しなくてはならない、と言うことが明白になるように更新されています。

CVSS v3.1仕様書のセクション2.1により詳細な情報が載っています。

2.3.2 獲得された特権に基づくスコア

脆弱性のImpactメトリックのスコアを付ける際に、アクセスの増加、権限獲得、あるいはその他の悪用の成功の結果となるネガティブな結果を考慮しなくてはならない事を明確にするために、仕様書のセクション2.3に追加のテキストが付け加えられました。

CVSSのアナリストは、影響のスコアを付ける際に、攻撃者が脆弱性を悪用する前に持っている権限を考慮し、それらを悪用後の権限と比較する必要があります。権限の変更は、Impact メトリック、つまり機密性、整合性、可用性に反映されます。

最後に、Impactメトリックで差分の変化のスコアを付ける際には、最終的なImpactを使用する必要があります。

2.3.3 脆弱性のある構成を想定する

CVSS v3.0の攻撃の複雑さの説明では、「特定のシステム構成の存在」を考慮しています。このテキストはCVSS v3.1から削除されました。攻撃を成功させるために特定の構成が必要な場合、妥当な構成であれば、脆弱なコンポーネントがその構成内にあると想定してスコアを付ける必要があります。不合理な構成とは、たとえばセキュリティ機能を無効にするなど、意図的にターゲットを脆弱な状態にしたり、ドキュメント化された構成ガイダンスと競合するような構成を取った場合です。

2.3.4 範囲の説明の言い換え

仕様書の範囲の説明は、脆弱なコンポーネントと影響を受けるコンポーネントの概念とともに、より明確になるように書き直されました。ユーザーガイドのセクション3.5に、追加情報といくつかの例が含まれています。

2.3.5 ソフトウェアライブラリの脆弱性のスコア付け

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

2.3.6 複数のCVSS Baseスコア

新しいガイダンスでは、複数の製品バージョン、プラットフォーム、およびオペレーティングシステムに影響する脆弱性に対して、複数のCVSS Baseスコアを明示的に生成できます。詳細については、セクション3.8を参照してください。

2.3.7 Environment セキュリティ要件のメトリックを使用するためのガイダンス

環境評価基準(Environment Metric)グループには、機密性要件(CR)、整合性要件(IR)、可用性要件(AR)の3つのセキュリティ要件メトリックが含まれています。セクション3.11に、これらのメトリックの使用方法を説明する新しいガイダンスと例が含まれています。

2.4. 攻撃元区分(Attackベクタ)のスコア付けのガイダンス

攻撃元区分(Attackベクタ)のスコア付けの新しいガイダンスはセクション3.10で提供されています。

2.5. CVSS拡張フレームワーク

セクション3.9では、CVSSを拡張して標準のBase、Temporal、及びEnvironmentメトリックを保持しながら、追加のメトリックおよびメトリックグループを含める標準的な方法を定義しています。追加のメトリックにより、プライバシー、安全性、自動車、ヘルスケアなどの業界セクターが、CVSS標準外の要因のスコアを付ける事ができます。

2.6. 式の変更

Base, Temporal, Environmentのスコアの計算式は次のように変更されました。

2.6.1. 一般的な式の再構成

式は再構成されて明確になり、様々な目的でImpact サブスコアを定義することで生じるあいまいさを削除しています。これらは純粋に明白にしているだけであり、スコア付けには変更はありません。

2.6.2. 切り上げ式の再定義

CVSS v3.0の「Round up」関数はRoundupに名前が変更され、浮動小数点の曖昧さによって異なるスコアを生成する可能性を最小限にするために、より正確に定義されました。これは異なる言語やハードウェアプラットフォーム間の浮動小数点演算の違いが原因で発生する可能性があります。仕様書の付録Aでは、問題の詳細を説明し、解決策を提案しています。

この再定義により発生する可能性のあるスコアの違いの例として、FIRSTのWebサイトにある参照JavaScript CVSS計算機のCVSS v3.1バージョンは、v3.0とは異なる方法で以下の脆弱性をスコアリングします。

Baseスコアが2.5, 5.0, 10.0で攻撃される可能性(Exploit Code Maturity)がHigh(容易に攻撃可能)、利用可能な対策のレベル(RL：Remediation Level)が無し(U)、脆弱性情報の信頼性(RC：Report Confidence)が未確認(U)の場合にはCVSS v3.1は3.0のときよりも0.1低く出てきます。例えば、次のメトリックコンビネーションはTemporalスコアがCVSS v3.0では4.7ですが、CVSS v3.1では4.6になります:
```
CVSS:3.1/AV:P/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:H/E:H/RL:U/RC:U
```
メトリックの一部の組み合わせでは、環境評価基準(Environment)スコアがCVSS v3.1でスコア付した際にv3.0と異なる値となる事があります。これはRoundupの再定義と、次のセクションで説明するModifiedImpactの式の変更によるものです。CVSS v3.1では7%のメトリック組み合わせがv3.0よりも0.1高くなり、1%未満が0.1低く出てきます。環境評価基準(Environment)スコアの差分が0.1を超えることはありません。
CVSS式のその他の実装では、CVSS v3.1式の変更により修正する予定の問題から、CVSS v3.0とv3.1の間で異なるスコアが見られる場合があります。

2.6.3. 環境評価基準(Environmentメトリック)グループのModifiedImpact式の変更

CVSS v3.0では、環境メトリックの特定のセットには、セキュリティ要件または変更されたImpactメトリックの値を、より高いEnvironmentスコアを生成する値に変更すると、スコアが低くなるという直感に反した状態があります。この問題は、緩和策後のスコープ
(MS：Modified Scope)が変更され、少なくとも1つのセキュリティ要求度(Security Metrics)が高い場合に発生します。例として、次の脆弱性の環境評価基準(Environment)スコアは5.6です。


CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:U/RL:T/RC:U/CR:L/IR:L/AR:H/MAV:P/MAC:H/MPR:H/MUI:R/MS:C/MC:L/MI:H/MA:H

緩和策後の機密性への影響(MC：Modified Confidentiality Impact)がLowからHighになると結果として環境評価基準スコアは等しいか高くなりそうですが、実際には5.5に下がります。


CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:U/RL:T/RC:U/CR:L/IR:L/AR:H/MAV:P/MAC:H/MPR:H/MUI:R/MS:C/MC:H/MI:H/MA:H

根本の原因は、Modified Scopeが変更されたときに使用されるModifiedImpact式の一部にあり、具体的にはterm 3.25×（MISS-0.02）15です。 MISSは修正された影響サブスコアです。これにより、最高の環境スコアが低下しますが、低い環境スコアとそれほど大きな違いはありません。ただし、MISSの可能な最高値に達すると、このtermはサブ数式の最初のtermよりも速く増加し、MISSが増加するにつれてサブ数式の値が減少します。

CVSS v3.0とv3.1の間で異なる環境評価基準(Environment)スコアをもたらすメトリックセットを最小限に抑える為に、さまざまな潜在的な修正が検討されました。 MISSに定数を掛けることでMISSの効果を減らすことができましたが、外部指数を15から13に減らした同様のアプローチよりも多くのスコアを変更しました。CVSSv3.1で新しく追加されたMISS定数の値は、問題となるすべてのインスタンスを修正する最大値であり、最大値であることは影響を受けないスコアへの変更が最も少ないことを意味しています。

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

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

3. Scoring Guide

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

脆弱性のImpactをいつスコアリングするかを理解するには、分析者は攻撃者が達成できると確信している最終的な影響について、合理的に影響を制限する必要があります。この影響による可用性はExploitabilityサブスコアが最低値となるものから支持されるべきですが、脆弱性の説明から詳細を含めることもできます。たとえば、次の2つの脆弱性を考えてみましょう。

脆弱性1は、リモートで、非認証の攻撃者が些細な、改変されたリクエストをWebサーバに送ることで、Webサーバがroot(administrator)アカウントのパスワードをプレーンテキストでさらけ出すという脆弱性です。アナリストは、Exploitabilityサブスコアメトリックと、攻撃者が脆弱性を悪用するために、改変されたリクエストをWebサーバに送るというアクセスを持っているという、脆弱性の説明のみを知っています。Impactはそれで終わるべきです。攻撃者はこれらの資格情報を使用して、後で管理者としてコードを実行できる可能性がありますが、攻撃者がログインプロンプト、またはこれらの資格情報を使用してコマンドを実行するためのアクセスがあるかどうかはわかりません。このパスワードにアクセス出来るようになるということからは、機密性のみが直接的に深刻に失われるということを意味しています。


Base Score: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

脆弱性2は、ローカルで、低い権限のユーザが些細な、改変されたリクエストをOSに送ることでroot(administrator)アカウントのパスワードをプレーンテキストでさらけ出すという脆弱性です。アナリストは、Exploitabilityサブスコアメトリックと、攻撃者が脆弱性を悪用するために、OSにアクセス出来、ローカルにログイン出来、低い権限を持っているという脆弱性の説明のみを知っています。このパスワードへにアクセス出来るようになるということは直接的に、気密性／完全製／可用性に対する深刻な喪失を意味しています。何故ならば、アナリストはroot/administratorアカウントとしてコマンドを実行できるという合理的な問題があるからです(攻撃者は彼らのアカウントからログアウトできてrootとしてログインできるという仮定を行っています)。


Base Score: 7.8 CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

3.2. 機密性／完全性に対する可用性のImpact

機密性と整合性のメトリックは、サービスで使用される”データ”に影響を与えるImpactを指しています。たとえば、悪意を持って変更されたWebコンテンツや、盗まれたシステムファイルなどです。可用性Impactメトリックは、サービスの”操作”を指しています。つまり可用性メトリックは、データの可用性ではなく、サービス自体のパフォーマンスと操作を表しています。攻撃者がディレクトリ内のすべてのWebファイルを変更または削除できるような、Web, mail, DNSなどのインターネットサービスの脆弱性を考えてみて下さい。 Impactは完全性のみに影響し、可用性には影響しません。たまたま、変更されたコンテンツを提供しているだけです。

3.3. リモートの攻撃者によるローカルの脆弱性利用

ガイダンスでは、CVSS v3.0でNetworkとAdjacentの攻撃ベクタメトリックに関する値の定義を明確にすることにより、ローカル攻撃に関して改善がされました。具体的には、アナリストは脆弱性がネットワークスタックにバインドされている場合にのみ、NetworkまたはAdjacentに対してスコアを付けます。（USBドライブなどを介してローカルに入ってくるなどの）悪意のあるコンテンツをダウンロードしたり、受信するためにユーザーの操作を必要とする脆弱性
は、ローカルとしてスコア付けする必要があります。

3.4. Vulnerability Chaining(脆弱性のチェイン)

CVSSは個別の脆弱性をクラス分けして評価するように設定されています。しかしながら、ホストやアプリケーションを侵害する一つの攻撃の過程で、複数の脆弱性が悪用されるような状況に対応することで、脆弱性アナリストコミュニティの要望をサポートすることは重要です。この方法での複数の脆弱性のスコアリングは、Vulnerability Chaining(脆弱性のチェイン)と呼ばれます。これは正式なメトリックではありませんが、これらの種類の攻撃をスコアリングする際のアナリスト向けのガイダンスとして含まれています。

脆弱性のチェインをスコアリングする場合、どの脆弱性が組み合わされてスコアが形成されるかを特定するのはアナリストの責任です。アナリストは明確な脆弱性とそのスコアを、チェインスコアに加えてリスト化する必要があります。例えば、これはWebページに投稿された脆弱性開示内で渡される場合があります。

さらに、アナリストは、スコアリングされる脆弱性と連鎖する可能性がある、他のタイプの脆弱性を含むことが出来ます。特に、アナリストは、しばしば連鎖するような脆弱性の一般的なタイプ（またはクラス）をリストしたり、必須条件の詳細な説明を提供したりする事が出来ます。たとえば、特定の種類のSQLインジェクションの脆弱性がクロスサイトスクリプティング（XSS）攻撃の前兆だったり、特定の種類のバッファオーバーフローがローカル権限を付与するなどの説明です。脆弱性の一般的なタイプまたはクラスをリストする事で、攻撃者に新しいエクスプロイトの可能性を知らせることなく、他のユーザーに警告するための必要最小限の情報を提供出来ます。

あるいは、アナリストは、ITシステムを悪用するためにスコア付されている脆弱性に連鎖している(あるいはそう思われる)関連する脆弱性の完全なリストを(CVE IDまたはCWEとして機械的に可読および解析可能なリストの形式で)特定することが出来ます。他の前提条件が満たされた後にのみ脆弱性が悪用される可能性がある場合(最初に別の脆弱性を悪用するなど)、最も影響のあるImpactサブスコアメトリックのスコアメトリックとスコアリングにより、2つ以上のCVSSスコアを組み合わせて、最小制限のエクスプロイト可能性サブスコアを付けて脆弱性のチェーンを記述することは許容されます。次の例では、Exploitability、Scope、Impactサブスコアを使用してチェーンを記述しています。

脆弱性Aは、CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H とします。悪用するにはローカルで低い権限のユーザが必要です。

脆弱性Bは、CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L とします。特権のないリモートの攻撃者は、ローカルユーザが対話して攻撃を完了した場合、システム上で低い影響を及ぼすコードの実行が出来ます。

AとBによるチェーンCはB->Aと記述されます。

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HはBのExploitabilityとAのImpactを組み合わせたもので、両方のケースでスコープは変更されません。AのImpactはBを悪用してローカルユーザとしてコードを実行できるようになる場合、Aを実行するための前提条件を満たしています。

3.5. スコープ(Scope), 脆弱想定範囲(Vulnerable Component), 影響想定範囲(Impacted Component)

あるセキュリティ機構によって管理されたコンポーネントの脆弱性が、別のセキュリティ機構が管理するリソースに影響を与えることができる場合、スコープの変更が発生します。これは通常、脆弱なコンポーネントと影響を受けるコンポーネントが、異なるセキュリティ機構によって管理された、(物理的又は論理的に)異なるシステムの一部である場合、或いはセキュリティ上の理由で脆弱なコンポーネントと影響を受けるコンポーネントを論理的に分離するために人工的な境界が作成されている場合（サンドボックスでプロセスを実行する場合など）に発生します。セキュリティ境界メカニズムが分離しているコンポーネントが脆弱性によって阻害され、これが脆弱性想定範囲のセキュリティスコープ外のインパクトを与える場合、スコープの変更が発生します。この場合、セキュリティ境界が期待どおりに機能すると想定すると、コンポーネントのみに制限された脆弱性はその範囲外の影響を引き起こさないため、通常セキュリティ境界を実装または制御するコンポーネントに脆弱性が存在します。

次の脆弱性の例では、スコープのスコアリングのさまざまな側面を見る事ができます：

仮想マシン上の攻撃者が、ホストOS上のファイルの読み込み／削除が可能な脆弱性(自分自身の仮想マシンだったとしても)はスコープ変更と考えられます。この例では、２つの分離されたセキュリティ権威があります：一つは仮想マシンとそのユーザに対してのアクセス制御を決定して執行するところであり、他方は仮想マシンが実行されているホストシステム上でアクセス制御を決定して失効している所です。
マイクロプロセッサの特権レベル感でのセキュリティ境界違反はCVSSを用いて脆弱性のスコアリングをする際に考慮されるべきです。低い特権レベルで動作しているユーザ空間プログラムのケーパビリティは通常、OSの管理者権限で動作している場合であっても、どのような指示を実行できるかや、どのようなレジスタが書き込み可能であるかが制限されています。低い特権レベルで動作しているプログラムが任意のコードを高い特権レベルで実行できるような脆弱性は、スコープの変更として考えるべきです。
CVSSを用いて脆弱性をスコアリングする場合には、マイクロプロセッサに統合されたセキュアエンクレーブ間のセキュリティ境界と、OSカーネル自身を含むその他のOSプロセスを考慮する必要があります。他のプロセスがセキュアエンクレーブ内のデータやコードの機密性、整合性、可用性にインパクトを与える脆弱性の場合は、スコープの変更として考えるべきです。
スコープの変更は、Webアプリケーションの脆弱性がユーザークライアント（Webブラウザーなど）に影響を与える場合に発生します。この種の一般的な脆弱性には、クロスサイトスクリプティングとURLリダイレクトが含まれます。この脆弱性はWebアプリケーションにありますが、被害者のユーザーのWebブラウザーのデータ/動作に影響があり、これらは異なるセキュリティスコープ内にあります。
分散環境では、攻撃の成功が他のコンポーネントに影響を与える場合、異なるセキュリティ機構のコンポーネントに接続、保護、または認証サービスを提供するコンポーネントの脆弱性を、スコープの変更としてスコアリングする必要があります。たとえば、ルーター、ファイアウォール、認証マネージャーなど、1つ以上のダウンストリームコンポーネントの主な可用性に影響するコンポーネントの脆弱性は、スコープの変更としてスコアリングする必要があります。ただし、攻撃の成功がまったく影響を与えない場合、または別のセキュリティコンポーネントにほとんど影響を与えない場合、脆弱性はスコープ変更なしとしてスコアリングする必要があります。たとえば、フォールトトレランスが、攻撃の成功が異なるセキュリティコンポーネントに影響しないことを意味する場合、より大きなフォールトトレラントトポロジの一部として展開するように設計されたコンポーネントの脆弱性は、変更されたスコープでスコアリングされるべきではありません。脆弱なコンポーネントによって提供される追加サービスへの影響は、範囲の変更ではなく、二次的な影響と見なされます。
被害者が悪意のあるPDFドキュメントを開いた際に、攻撃者に同じOS上の他のファイルを危険に晒すことが出来るようなPDFリーダの脆弱性は、スコープ変更はありません。これは、PDFリーダがOSとは別のセキュリティ機構とみなされる認証機能を持っていないことを前提としています。
WebアプリケーションのSQLインジェクション脆弱性は、通常Webアプリケーションと影響を受けるSQLデータベース間で資格情報が共有されているため、同じセキュリティスコープの一部であると仮定して、スコープの変更とは見なされません。
WebサーバーまたはSSHサーバーをクラッシュさせる脆弱性は、影響が影響を受けるサーバーによって提供されるサービスに限定されるため、スコープの変更とは見なされません。ユーザーへの影響は二次的なものであり、ユーザーはコンポーネントと見なされないため、スコープの変更とは見なされません。
攻撃者がアプリケーションの通常の機能の下で動作し、セキュリティ境界に違反していないため、ファイルシステムがいっぱいになるなど、攻撃者が共有システムリソースを使い果たすことを許可する脆弱性は、スコープの変更とは見なされません。
アプリケーションの脆弱性を悪用して、ユーザーが複数のセキュリティスコープで他のコンポーネントと共有されているリソース（システムファイルなどのオペレーティングシステムリソース）へのアクセスを制限できるようにすることで、攻撃者はアクセスできないはずのリソースにアクセスできます。信頼境界を越えた有効なパスが既に存在するため、スコープの変更はありません。
攻撃者がセキュリティスコープ外のリソースに影響を与えることができる独自のセキュリティ機関を実装するアプリケーションの脆弱性は、スコープの変更としてスコア付けされます。これは、複数のセキュリティスコープ（他のオペレーティングシステムのリソースなど）で他のコンポーネントと共有される高レベルのセキュリティ機関によって管理されるリソースにアクセスするための機能をユーザーが提供しないことを前提としています。 1つの例は、ユーザーがWebアプリケーションのインストールパスの下でのみWebページとファイルを読み取りおよび変更でき、これらのパスを超えて対話する機能をユーザーに提供しないWebアプリケーションです。悪意のあるユーザーがこのアプリケーションに関係のないオペレーティングシステムファイルにアクセスできるようにするこのアプリケーションの脆弱性は、スコープの変更と見なされます。

3.6. ファイアウォールに保護されているコンポーネントの脆弱性

脆弱性で攻撃ベクタがネットワークだとスコアリングされ、アナリストが脆弱性のあるコンポーネトがインターネットから利用不可能な安全なネットワークにデプロイされていると高く信頼してる場合、Modified Attack Vector(修正された攻撃ベクタ)は隣接としてスコアリングされ、CVSS v3.1スコアは減らされます。

例： MySQL Stored SQL Injection (CVE‑2013‑0375)


Base Score: 6.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Environmental Score: 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N/MAV:A

3.7. ソフトウェアライブラリ中の脆弱性のスコアリング

ライブラリ中の脆弱性の影響をスコアリングする場合、取り入れられているプログラムや実装とは独立して、アナリストはしばしばどのライブラリが使用されているかを考慮する方法が無い状態に直面します。ライブラリを使用している特定の製品はどのようにライブラリを使用しているかを指定してCVSSスコアを生成する必要がありますが、ライブラリ自身のスコアリングには前提条件があります。アナリストは合理的なワーストケースの導入シナリオを考慮してスコアリングする必要があります。可能であれば、CVSS情報にはこれらの仮定の詳細を記す必要があります。

例えば、イメージ変換を行うライブラリがネットワーク越しの信頼できないソースからのイメージを許可するプログラムによって使用されたとします。合理的なワーストケースでは、イメージの有効性チェックを行わずにライブラリに引き渡してしまうかもしれません。その場合、アナリストはライブラリの脆弱性を入力データに関連付けてAttack Vector(AV)のネットワーク(N)を仮定するべきですが、この仮定を脆弱性のサマリーで説明するべきです。ライブラリが一般的な権限で動作する場合、組み込まれた実装では低い影響となりますし、高い権限で動作する場合には、影響は増加するためアナリストはライブラリの脆弱性をスコアリングする際に高い権限を仮定する必要があります。

影響を受けるライブラリを使用した特定の実装の脆弱性をスコアリングする場合、その特定の実装についてスコアを再計算する必要があります。たとえば、実装が前の例で述べた脆弱なライブラリを組み込み、ローカルファイルでのみ動作する場合、Attack Vector(AV)はローカル（L）になります。このライブラリを組込む実装が障害のある機能を呼び出さないか、その脆弱性を引き起こすモードをサポートしない場合、脆弱性を悪用するインターフェースまたはAttack Vectorはありません。したがって、組み込まれたライブラリの脆弱性はその実装に影響を与えず、与えられた実装のスコアは0になります。

3.8. 複数のCVSSベーススコア

複数の製品バージョン、プラットフォーム、および/またオペレーティングシステムに脆弱性が存在することは一般的です。状況によっては、Base metricsは製品のバージョン、プラットフォーム、オペレーティングシステムによって異なる場合があります。たとえば、架空のベンダーの脆弱性は、同じベンダーが製造した複数のオペレーティングシステムに適用されます。レガシーのオペレーティングシステムでのこの脆弱性の攻撃の複雑さ(AC)は低(L)です。しかしながら、新しいオペレーティングシステムには、攻撃の複雑さを高(H)に変更できる、新しい固有の保護機能があります。この違いにより、最終的には2つのオペレーティングシステムで同じ脆弱性のベーススコアが異なります。

それぞれが特定の製品バージョン、プラットフォーム、および/また、スコアに関連するオペレーティングシステムの概要を説明する追加の言語を持っている場合には、単一の脆弱性に対して複数のベーススコアをスコア付けして公開することが許容されます。スタンダードな形式を使用して、影響を受ける各製品バージョン、プラットフォーム、および/またオペレーティングシステムに対しての、（事前に計算されたベーススコアだけでなく）全てのBase Score属性が提供される必要があります。複数のベーススコアが適用可能であるが、単一のスコアのみが提供される状況では、最も高い値のベーススコアを使用する必要があります。

3.9. CVSS拡張フレームワーク

CVSSのコア基盤を活用して追加のスコアリング作業を行う場合があります。たとえば、CVSS BaseとEnvironmentalメトリックの組み合わせを重ね合わせてプライバシーへの影響を引き出すことにより、CVSSにプライバシーを組み込むという提案がCVSS Special Interest Group（SIG）に提示されました。

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

3.9.1. ガイドライン

既存のCVSSベース、時間、または環境メトリックの式、定数、または定義は変更しません。既存のアイテムの変更が必要な場合は、新しい名前で新しいメトリックグループを作成し、必要に応じて作業します。
新しいメトリックは既存のメトリックグループに追加するのではなく、新しいメトリックグループに追加する必要があります。新しいメトリックグループは、既存のメトリックグループに基づくことができます。
新しいメトリクスは、Exploit可能サブスコアなど、標準のサブ形式に基づいて作成できますが、これらは変更、削除、または標準の将来の改訂で置き換えられる可能性があり、また絶対値に依存しない必要があります。
新しいメトリックグループはオプションでスコアを持つことができます。その場合、スコアは0.0から10.0の間である必要があり、10.0が最も深刻になります。Base/Temporalスコアが最終スコアを生成するためにベーススコアを調整する方法と同様に、スコアはBaseスコアおよび/またEnvironment/Temporalスコアの調整に基づいている必要があります。
CVSS SIGは拡張機能を公式には承認していませんが、IETF1と同様にコンサルティングbodyとして機能しています。CVSS SIGは革新を歓迎し、奨励していますが、提案されているすべての拡張機能の一貫性を維持することに関心があります。
検証された拡張機能のリストは、IANA2と同様に、first.org Webサイトにリストされます。
- 必須フィールド: 名前、説明、外部の信頼できるWebページ
- オプションのフィールド: JSONスキーマ、XMLスキーマ、JavaScript Calculator

3.9.2. 提案されたベクトル文字列形式

CVSS拡張ベクトル文字列は分けられてリストされるべきで、以下のようなフォーマットで使用されます;


CVSS:3.1/AV:x/AC:x/PR:x/UI:x/S:x/C:x/I:x/A:x
EXT:1.0/NEW1:VAL1/NEW2:VAL2

ここで

EXT:n.nはユニークな拡張IDでmajor.minorバージョン番号

Newnはそれぞれの新しいメトリックにたいしてユニークな拡張属性

VALnはそれぞれの新しいメトリック値に対するユニークな属性値

となります。

3.10. Attack Vectorの考慮事項

Attackベクトルをスコアリングする場合、攻撃がネットワーク経由で開始されなくても、攻撃が成功するためにネットワーク接続が必要な場合は、(必要に応じて)隣接(Adjant)またはネットワーク(Network)を使用します。たとえば、ローカルの攻撃者は、脆弱で特権のあるローカルプログラムをだまして、攻撃者が選択したネットワーク経由でサーバーに機密データを送信させることができます。機密データを収集するにはネットワーク接続が必要なので、これはネットワーク(Network)のAttack Vectorでスコア付けされます。

悪意のあるデータが1つのコンポーネントによってネットワーク経由で受信され、脆弱性を持つ別のコンポーネントに渡される際の脆弱性は、ローカル(Local)のAttack Vectorでスコアリングされる必要があります。例としては、悪意のあるオフィスドキュメントをダウンロードしてディスクに保存し、保存されたファイルを読むために脆弱なオフィスアプリケーションを起動する、Webブラウザーがあります。

脆弱な機能が悪意のあるデータを受信するコンポーネントの一部である場合、Attack Vectorはネットワーク(Network)としてスコアリングされる必要があります。例えば、悪意のあるデータを受信したときにトリガーされる、ブラウザー自体やブラウザーのプラグイン、または拡張機能に脆弱性があるWebブラウザーです。

3.11. セキュリティ要件

セキュリティ要件のメトリックは、Environmentメトリックグループの一部であり、変更されたEnvironmentメトリックがEnvironmentスコア全体に与える重みを変更します。このセクションでは、特定の環境の特性に基づいて適切なメトリック値を選択するためのガイダンスを提供します。例は概念を説明するために簡略化されています。

3.11.1. 機密性要件(CR: Confidentiality Requirement)

システムの機密性要件は、ターゲットシステムで実行されているユーザーやアプリケーションによって保存または使用されるデータの分類レベルに基づいている必要があります。機密性要件を確立するためには、このデバイスに保存されているデータの暗号化も考慮する必要があります。この属性を評価する際に、消費または処理されずにデバイス（スイッチやファイアウォールなど）を通過するデータは考慮に入れないでください。以下が例になります。

注：データの量は属性の値に影響を与える可能性がありますが、保存または使用されるデータの分類（つまり、タイプ）ほどの影響はありません。

最高レベルで分類されたデータを保存するデバイスでは、この属性の評価を”高”にする必要があります。ただし、機密データが保存時に暗号化されている場合、この属性の評価は”中”になります。
非公開として分類されたデータを保存するが、最高レベルよりも高くないデバイスは、この属性を”中”と評価する必要があります。ただし、機密データが保管時に暗号化されている場合、この属性は”低”と評価されます。
パブリックに共有できるデータを保存するデバイスは、この属性を”低”と評価する必要があります。
ルーター、スイッチ、ファイアウォールなどのネットワーク機器は、ルーティングテーブルなどのセンシティブな情報のため、一般的に”中”と評価されます。
暗号化せずにログインクレデンシャルを保存するシステムでは、この属性を”高”と評価する必要があります。これには、スクリプトまたはソースコードに埋め込まれたサービスアカウントと資格情報が含まれます。

3.11.2. 整合性要件(IR: Integrity Requirement)

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

金融取引データおよび/または個人を特定できる情報（PII）を含むデバイスは、高と評価される必要があります。
ビジネスまたはリスク管理の決定を行うために直接使用されるデータを含むデバイスは、最低でも中で評価される必要があります。決定の重大度が増すにつれて、整合性要件の評価も増加します。
健康の判断に直接使用されるデータを含むデバイスは、高と評価されるべきです。
ルーターやスイッチなどのネットワーク機器は、転送テーブルなどの情報のセンシティブな情報を厳しく制限するため、一般に少なくとも中と評価されます。
ファイアウォールは、ルールセットの機密性により、高と評価される必要があります。

3.11.3. 可用性要件(AR: Availability Requirement)

システムの可用性要件は、稼働時間要件と、デバイスまたはデバイスによって提供されるアプリケーションの冗長性に基づいている必要があります。冗長クラスタの一部であるデバイスの可用性要件は低くなります。以下が例になります。

回復要件が24時間未満と評価されている、完全な容量の冗長性がないデバイスは、高と評価される必要があります。
1〜5日間の回復要件で評価される、完全な容量の冗長性のないデバイスは、中と評価される必要があります。
5日以上の回復要件があるデバイスは、低と評価される必要があります。
クラスタ化されたデバイスおよび/または完全な容量の冗長性を備えたデバイスは、低と評価される必要があります。
レギュレーションの要件に基づいて迅速な応答時間がトランザクションに要求されるデバイスは、高と評価される必要があります。

[参考]

CVSS v3.1 User Guide (FIRST)

共通脆弱性評価システムCVSS v3概説 (IPA)

セキュリティ系連載案内

OSSセキュリティ技術の会による日経Linuxでの連載「IoT時代の最新SELinux入門」がITPro上で読めるようになりました。技術の会代表で第一人者である中村さん等による、最新のSELinuxの情報やコマンド類等も更新されているのでお薦めです。
OSSセキュリティ技術の会によるThinkITでの連載「開発者のためのセキュリティ実践講座」がThinkIT上で開始しました。技術の会の中の人間で、最新の代表的なOSSセキュリティ技術を紹介していきます。
OSSセキュリティ技術の会により、ThinkITでLinuxSecuritySummit 2018のレポートが紹介されています。
OSSセキュリティ技術の会の面により、@ITで「OSS脆弱性ウォッチ」が連載されています。
OSSセキュリティ技術の会の面により、@ITで「OpenSCAPで脆弱性対策はどう変わる？」が連載されています。
OSSセキュリティ技術の会のメンバーにより、@ITで「Berkeley Packet Filter（BPF）入門」が連載されています。