CVSS（共通脆弱性評価システム）3.0から3.1への変更点：OpenSCAPで脆弱性対策はどう変わる？（7）

本連載では、グローバルスタンダードになっている「SCAP」（セキュリティ設定共通化手順）およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。今回は、CVSS 3.0から3.1への変更点について。

[面和毅，OSSセキュリティ技術の会]

　OSSセキュリティ技術の会の面和毅です。本連載「OpenSCAPで脆弱性対策はどう変わる？」では、実質的にグローバルスタンダードの「SCAP（Security Content Automation Protocol：セキュリティ設定共通化手順）」、およびそれを基にシステム構成や脆弱（ぜいじゃく）性の検査を行うためのOSS（オープンソースソフトウェア）ツール「OpenSCAP」や、その周辺の技術、用語などを紹介しています。

　今回はSCAPの構成要素の一つであるCVSS（Common Vulnerability Scoring System：共通脆弱性評価システム）が、2019年6月に3.1にバージョンアップされたため、3.0からの差分を見てみます。

あらためてCVSSとは

　本連載の第1回でも説明しましたが、CVSSは脆弱性の性質と重大性を共有するためのフレームワークです。CVSSは、Base（基本評価基準）、Temporal（現状評価基準）、Environment（環境評価基準）の3つのメトリックグループで構成されています。

• Base（基本評価基準）：一般的によく知られているもの。ベンダーが公開する
• Temporal（現状評価基準）：脆弱性が公開された後の状況（Exploitコードが出回っているのかどうか、修正済みのバージョンはあるのかどうかなど）によって、時系列で変化していくもの。ベンダーが出す
• Environment（環境評価基準）：エンドユーザー側固有の環境による緩和策を加味したもの。エンドユーザー側の方で決める

　なお、CVSS 3.1の仕様およびユーザーガイドについては、それぞれ「Common Vulnerability Scoring System version 3.1: Specification Document」「Common Vulnerability Scoring System v3.1: User Guide」を参考にしてください。日本語での拙訳を「【翻訳】CVSS v3.1（目次）」として公開しているので、こちらも参照していただければと思います。

　また、今回CVSSのスコア値を計算する際には、Webで公開されているNVDのJavaScript計算機を使用していきます。

CVSS 3.0から3.1での変更点

　CVSS 3.0から3.1での変更点としては、新しい指標を導入したり、既存の計算式に大きな変更を加えたりすることはなく、既存の標準を明確にして改善することに焦点が当たっています。変更点は細かいものが多いため、代表的なものを下記にまとめました。

1. 「CVSSは重大性を測るものであり、それ単一でリスクを測るものではない」ことの強調
2. 攻撃元区分（Attackベクター）の変更と修正
3. 式の変更
4. スコアリングガイダンスの変更
5. CVSS拡張フレームワーク

　それぞれを詳しく見ていきましょう。

「CVSSは重大性を測るものであり、それ単一でリスクを測るものではない」

　こちらは、非常に重要な「CVSS」の定義に関わるものです。CVSSは場合によっては「ユーザーにとってのリスクを計るため」のものと混同され、ユーザー側からは「CVSSのBaseスコアがXXだから、われわれにとってはXXくらいのリスクがある」とそのまま捉えられてしまうきらいがあります。

　CVSS 3.0では仕様書のIntroductionで「最終的に、CVSSは優先付けられたリスクを有効にします。環境評価基準スコアが計算される際、脆弱性はそれぞれの組織にとって意味を持ち、この脆弱性によって組織にもたらされるリスクをよりよく理解するのに役立ちます」と書いてあります。つまり本来は「CVSSによってもたらされた脆弱性の重大性を用いて、ユーザー固有の環境評価基準を適用する際に、環境にどれくらいのリスクがあるかが分かる」というものですが、あまり分かりやすいとはいえない説明です。

　そこでCVSS 3.1では仕様書のIntroductionで明確に「基本（Base）スコアは、時間とともに一定であり、異なる環境全体で合理的な最悪のケースを想定した、脆弱性の重大性を反映します」としています。「脆弱性の重大性」だと明確にうたっているのです。また、仕様書からは「risk（リスク）」という単語がなくなっており、混同しにくいように気を使った形に修正されています。

攻撃元区分（Attackベクター）の変更と修正

　CVSS 3.0では攻撃元区分（Attackベクター）の用語を下記のように説明しています。

Network：脆弱性がNetworkアクセスで悪用可能という意味は、脆弱性のあるコンポーネントがネットワークスタックにバインディングされており、攻撃者のパスはOSIモデルのレイヤ3（Networkレイヤ）となることを意味しています。（略）

Adjacent（隣接）：脆弱性が隣接ネットワークアクセスから悪用可能という意味は、脆弱性のあるコンポーネントがネットワークスタックにバインディングされており、攻撃は同じ共有された物理の（すなわちBluetooth, IEEE 802.11）、或いは論理的な（すなわちローカルIPサブネット）ネットワークでは可能だが、OSIレイヤ3境界（すなわちルータ）を超えることは出来ないという事を表しています。（略）

　ネットワークを勉強した人間やセキュリティ専門家には分かりやすいのですが、CVSSを利用する「ユーザー」には少し分かりにくい表現です。そこでCVSS 3.1ではユーザーなどに分かりやすい形に表現が変わっています。

　また最近では、VPN（Virtual Private Network）やMPLS（Multi-Protocol Label Switching）などの信頼されたネットワークも「隣接したネットワーク」に含まれるので、CVSS 3.1ではそれらも「Adjacent（隣接）」の定義に含むようになっています。

Network：脆弱性のあるコンポーネントがネットワークスタックにバインディングされており、攻撃者はInternetを含む下記にリストしたオプション（Adjacent, Local, Physical）を超えた形でやってきます。（略）

Adjacent（隣接）：脆弱性のあるコンポーネントがネットワークスタックにバインディングされているが、攻撃はプロトコルレベルで論理的に近接なトポロジーに限定されています。これは攻撃が同じ共有された物理の（すなわちBluetoothやIEEE 802.11）、また論理の（すなわちローカルIPサブネット）ネットワークで実行されるか、管理ドメイン（すなわちMPLSや管理ネットワークゾーンへのセキュアVPN）から行われるということを意味しています。

　このように「Adjacent（隣接）」とネットワークの関係が分かりやすくなったため、ユーザー環境でのEnvironmentメトリックを評価するのが分かりやすくなります。

　例えば、MySQLの脆弱性（CVE-2013-0375。MySQLサーバのサーバレプリケーション処理に関する脆弱性）のBaseメトリックは、ネットワークから悪用可能なため下記のように表します。

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

　ユーザーの環境でファイアウォールの内側にMySQLサーバがあり、信頼された管理ネットワークのみしか接続されていない場合は、CVSS 3.1を見ると「Adjacent（隣接）」に「信頼された管理ネットワーク」と書かれているため、Environmentメトリックの「Modified Attack Vector」を「Adjacent（隣接）」に変更し、下記のように評価すればいいということがすぐに分かるようになっています。

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

式の変更（Roundup（切り上げ）の計算）

　Base、Temporal、Environmentのスコアの計算式が変更されました。スコアリング自体には変更はありません。

　CVSS 3.0の仕様書で定義されたRoundup関数には、実装方法で値が違ってしまう可能性がありました。例えば、0.1＋0.2は0.3になりますが、JavaScriptの実装によってはこれが「0.30000000000000004」として返ってきてしまい、これがRoundup関数を通すことで切り上げられて「0.4」となってしまうことがありました。

　このような事が起きないように、CVSS 3.1ではRoundup関数を再定義しました。3.0と3.1でスコア値が（差は0.1以内ですが）異なるという事態が発生します。

　例えば下記のスコアを見てみましょう。

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

　図1は上式をNVDの「CVS System Calculator」で計算したときのものです。

図1

　CVSS 3.1のときは図1のように下記が出てきます。

CVSS Base Score: 5.0
Impact Subscore: 4.7
Exploitability Subscore: 0.3
CVSS Temporal Score: 4.6
CVSS Environmental Score: NA
Modified Impact Subscore: NA
Overall CVSS Score: 4.6

　一方、「Calculator」内で「CVSS v3.0」を選ぶと、図2のように下記が出てきます。

CVSS Base Score: 5.0
Impact Subscore: 4.7
Exploitability Subscore: 0.3
CVSS Temporal Score: 4.7
CVSS Environmental Score: NA
Modified Impact Subscore: NA
Overall CVSS Score: 4.7

図2

　CVSS Temporal Scoreが「4.7」（CVSS 3.0）から「4.6」（CVSS 3.1）へと0.1ずれています。

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

　スコアリングガイダンスが複数変更になりました。

1．CVSS 3.1の仕様書では、スコアリングする際には「攻撃者がターゲットとなるシステムに対して、一般的な設定やデフォルトの防御メカニズム（ビルトインのファイアウォール、呼び出し制限、トラフィックポリシーなど）の高度な知識を持っている」と仮定する必要があると明確に記載されています。

2．「ソフトウェアライブラリ脆弱性が使用しているプログラムの脆弱性スコアリングに及ぼす影響」について、より詳しく解説されています。

　例えば、脆弱性のあるイメージ変換ライブラリがあるとします。このライブラリがネットワーク越しの信頼できないソースからのイメージを許可するプログラムによって使用されたとします。このプログラム実装のCVSSスコアリングを行う場合にはAttack Vector（AV）で「ネットワーク（N）」を仮定すべきです。

　一方、同じライブラリがローカルファイルでのみ動作するプログラムで使用されたとします。このプログラム実装のCVSSスコアリングを行う場合には、Attack Vector（AV）は「ローカル（L）」になります。

　また、このライブラリを組み込んだプログラムが、脆弱性を引き起こすモードをサポートしないプログラムだったとします。このプログラム実装のCVSSスコアリングを行う場合には、Attack Vector（AV）は存在せず、実装のスコアは「0」になります。

　このように、脆弱性のあるライブラリを使用したプログラムは、そのライブラリを「どう使用しているか」に依存してスコアリングが変わってくることがあります。その場合には、当然「ワーストケースの導入シナリオ」を考慮してスコアリングする必要がありますが、さらにCVSS情報に前述のような「どのような仮定でスコアリングしたか」の詳細を記す必要があるとうたわれています。

3．複数のCVSS Baseスコアの許容

　複数のバージョン／プラットフォーム／OSをサポートしているアプリの場合、状況によってはBaseメトリックもバージョンやOSによって異なる場合があり得ます。

　例えば、複数のOSのバージョンをサポートしている、あるアプリケーションに脆弱性があったとします。このサポートしているOSのバージョンが古い場合には、攻撃の複雑さ（AC）は「低い（L）」になります。しかし、新しいOSで新規のセキュリティ機構（メモリのランダム化など）が実装され、攻撃の複雑さが「高い（H）」になるとします。このような場合には、2つのOSで同じ脆弱性のBaseスコアが異なります（図3）。

図3

　このような製品では、単一の脆弱性に対して複数のBaseスコアをスコア付けして公開することが許容されるようになりました。また、複数のBaseスコアが適用可能であるが単一のスコアのみを提供する場合には、最も高い値のBaseスコアを使用する必要があります。

CVSS拡張フレームワーク

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

　CVSS BaseとEnvironmentalメトリックの組み合わせを重ね合わせてプライバシーへの影響を引き出すことにより、「CVSSにプライバシーを組み込む」という提案がCVSS Special Interest Group（SIG）に提示されました。CVSS SIGは拡張機能を公式には承認していませんが、IETF1と同様にコンサルティングbodyとして機能しています。

　フォーマットとしては、下記のようにCVSS＋Extを組み合わせるような形となります。

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
  それぞれの新しいメトリック値に対するユニークな属性値

まとめ

　CVSS 3.1は、3.0からのマイナーバージョンチェンジであるため、ドラスチックに変化しているわけではありません。3.0で出ていた細かい問題を解決したり、最近の環境に合わせたスコアリングができるようになったりするなど改善されたバージョンです。

　既にRed Hatなど一部のベンダーではCVSS 3.1を使用して情報を発信しています。この機会に、CVSSのスコアリング方法をもう一度学び直すと為になるかと思います。

次回は、Compliance As Codeについて

　次回は、2019年から活発に開発が続けられている「Compliance As Code」の動きを、システムに適用しながら確認します。

筆者紹介

面和毅

略歴：OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログ、Red Hatブログを連載中。

CISSP：#366942

近著：『Linuxセキュリティ標準教科書』（LPI-Japan）」