【翻訳】CVSS v3.1 UserGuide (逐次更新中)

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

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


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を実行するための前提条件を満たしています。



セキュリティ系連載案内


OSSに関するお困りごとは サイオス OSSよろず相談室まで

サイオスOSSよろず相談室 では、OSSを利用する中で発生する問題に対し、長年培ってきた技術力・サポート力をもって企業のOSS活用を強力に支援します。Red Hat Enterprise Linux のほか、CentOS をご利用されている環境でのサポートも提供いたします。

前へ

sudoの脆弱性(CVE-2019-14287)が「ALL」が含まれる時だけ発生した理由