JVN が CVSSv3 による脆弱性評価を開始

no extension

JVN が CVSSv3 による脆弱性評価を開始

当面(2017年度末まで)は CVSSv2 と CVSSv3 の併記で運用するらしい。

たとえば

では

CVSSv2 基本評価値 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N)

基本評価基準 評価値
攻撃元区分(AV) ネットワーク(N)
攻撃条件の複雑さ(AC) 低 (L)
攻撃前の認証要否(Au) 不要(N)
情報漏えいの可能性(機密性への影響, C) 部分的(P)
情報改ざんの可能性(完全性への影響, I) なし(N)
業務停止の可能性(可用性への影響, A) なし(N)

CVSSv3 基本評価値 7.5 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

基本評価基準 評価値
攻撃元区分(AV) ネットワーク(N)
攻撃条件の複雑さ(AC) 低 (L)
必要な特権レベル(PR) 不要(N)
ユーザ関与レベル(UI) 不要(N)
スコープ(S) 変更なし (U)
情報漏えいの可能性(機密性への影響, C) 高(H)
情報改ざんの可能性(完全性への影響, I) なし(N)
業務停止の可能性(可用性への影響, A) なし(N)

という感じで CVSSv2 と CVSSv3 では評価の観点も最終的な評価点も異なることがわかると思う1

余談だが CERT/CC では

CVSSv2 基本評価値 9.4 (AV:N/AC:L/Au:N/C:C/I:C/A:N)

基本評価基準 評価値
攻撃元区分(AV) ネットワーク(N)
攻撃条件の複雑さ(AC) 低 (L)
攻撃前の認証要否(Au) 不要(N)
情報漏えいの可能性(機密性への影響, C) 全面的(C)
情報改ざんの可能性(完全性への影響, I) 全面的(C)
業務停止の可能性(可用性への影響, A) なし(N)

と完全性への影響が高いと評価している2

CVSSv3 の変更点

CVSSv2 から CVSSv3 への変更点は以下の通り。 (なおこれは,以前書いた「CVSS に関するメモ 3」の再掲載である)

バージョン2からの大きな違いは深刻度をコンポーネント単位で評価できるようになったことだろう。 以前は攻撃対象となるシステムやホストマシンが対象だったので,更に細かい評価ができるようになったと言える。

これに合わせて「スコープ(Scope)」という評価軸が追加された。 厳密には「管理権限の範囲(Authorization Scope)」。 脆弱性のあるコンポーネントが他のコンポーネントに影響をおよぼす場合に,「他のコンポーネント」が管理権限の範囲の内側か外側かで深刻度が異なる。 脆弱性が管理権限の範囲の外側に影響を及ぼす具体例としてはクロスサイトスクリプティング(XSS)脆弱性などが挙げられるだろう。

基本評価基準(Base Metrics)で新たに追加された評価項目としては

  • 必要な特権レベル(Privileges Required)
  • ユーザ関与レベル(User Interaction)
  • スコープ(Scope)

がある。 一方,バージョン2にあった「攻撃前の認証要否(Authentication)」項目は廃止され,「必要な特権レベル」に含まれる形になった。

一番大きく変わったのは環境評価基準(Environmental Metrics)だろう。 環境評価基準では対策後の状況を再評価し,評価が低いものについては再度対策を行えるようになっている。 CVSS を使ってセキュリティ対策のプロセスをきちんと回せるようになったわけだ。

再評価の観点は以下のとおり。

  • 緩和策後の攻撃元区分(Modified Attack Vector)
  • 緩和策後の攻撃条件の複雑さ(Modified Attack Complexity)
  • 緩和策後の必要な特権レベル(Modified Privileges Required)
  • 緩和策後のユーザ関与レベル(Modified User Interaction)
  • 緩和策後のスコープ(Modified Scope)
  • 緩和策後の機密性への影響(Modified Confidentiality Impact)
  • 緩和策後の完全性への影響(Modified Integrity Impact)
  • 緩和策後の可用性への影響(Modified Availability Impact)

つか基本評価基準(Base Metrics)の評価観点で再評価するって感じかな。

最近の「セキュリティ対策」がこれまでと異なっているのは,目の前の脆弱性に対処すれば「完了」とはならない点である。 (私は今までもずうっと言ってきているけど)セキュリティは「ハザード(hazard)」ではなく「リスク(risk)」で考えなければならない。 リスクをゼロにするには無限のリソース(人的資源やもっと端的にお金)が必要だが,私たちの持っているリソースは無限ではない。 つまりリスクをゼロにすることはできないのだ。 したがって,業務プロセスの中で改善を行いながら,最適解を探っていくしかない。

「セキュリティ対策」をコストと考えるなら果てしなく不毛な話であるが,「セキュリティ対策」を投資と考え,きちんと PDCA サイクルを回していくならば,それほど不毛ではないはずである。

関連リンク


  1. CVSSv3 では基本評価値が 7.0 以上で「重要」レベル,9.0 以上で「緊急」レベルとしている。基本評価値が 7.0 以上あるならすぐに対策に向けたアクションを起こすべきだろう。 ↩︎

  2. 仮に完全性への影響が高いと考えると先ほどの CVSSv3 は CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N で,評価は 9.1 となる。なお,この脆弱性についてはベンダ企業から修正版がリリースされている。 ↩︎