EN

NRIセキュア ブログ

CVSSに代わる脆弱性の評価手法「SSVC」とは|迅速な脆弱性対応を目指して

目次

    blogtop

    発見されている脆弱性の数が年々増えていることを皆様ご存じでしょうか。以下のグラフをご覧ください。

     

    このグラフは、「CVSS v2」という評価手法を使って、脆弱性の重大度合いを分類したグラフです。現在は、CVSS v2の改良版である「CVSS v3」が主流になっているため、2022年7月を境にNVDではCVSS v2の集計を中止しており、2022年の脆弱性の数が低くなっています。しかし、近年の傾向を考慮すると、非常に多くの脆弱性が発見されていると推測できます。

     

    多くの脆弱性を正確に判断し対応することが求められている一方で、CVSSを用いた対応に課題があることもわかってきています。

     

    本稿では、CVSSに代わる脆弱性の評価手法「SSVC」についてご紹介します。

    図1.2013年から2022年までの脆弱性数の推移[1]

    01

    出所)NVD[2]のCVSS Severity Distribution Over Timeより抜粋

     

    ▶「【解説書】セキュリティ担当者のためのCSPM導入・運用のポイント」を読む

    CVSSを用いた対応方針の課題

    CVSSを用いた対応方針に対して、以下の課題が挙げられます。

    課題①対応方針を決定するために必要なガイドが示されていない

    CVSSとは情報システムの脆弱性に対するオープンで包括的、汎用的な評価手法の確立と普及を目指して作成された評価手法であるため、CVSSによる評価結果から対応方針を決定するためのガイドが示されていません。評価結果であるスコアがレベル分けされている(表1)ことにより、一目で深刻度を把握できる分かりやすさがある一方で、各組織は自ら活用方針を決めていく必要があります。

     

    例えば、一概に「重要以上は緊急対応」などと決めると大量の脆弱性に緊急対応していく可能性があり、システム担当者の負荷増大につながる恐れがあります。システム担当者は脆弱性対応のみを行うわけではないので対応方針にて優先度をつけることが大事ですが、各組織が一から考え対応方針を決定することに難しさが生じており、課題の一つとなっています。

    表1.深刻度レベル分け[3]

    深刻度

    スコア

    緊急

    9.0~10.0

    重要

    7.0~8.9

    警告

    4.0~6.9

    注意

    0.1~3.9

    なし

    0

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

    課題②運用している個々のシステムに関する情報を評価に含めることが難しい

    CVSSの評価基準は、表2 CVSS v3の評価基準の通りです。

    表2.CVSS v3の評価基準

    評価基準

    説明

    基本評価基準

    脆弱性そのものの特性を評価する基準です。情報システムに求められる3つのセキュリティ特性、『機密性』、『完全性』、『可用性』に対する影響を、ネットワークから攻撃可能かどうかといった基準で評価し、CVSS基本値を算出します。この基準による評価結果は固定していて、時間の経過や利用環境の異なりによって変化しません。ベンダや脆弱性を公表する組織などが、脆弱性の固有の深刻度を表すために評価する基準です。

    現状評価基準

    脆弱性の現在の深刻度を評価する基準です。攻撃コードの出現有無や対策情報が利用可能であるかといった基準で評価し、CVSS現状値を算出します。この基準による評価結果は、脆弱性への対応状況に応じ、時間が経過すると変化します。ベンダや脆弱性を公表する組織などが、脆弱性の現状を表すために評価する基準です。

    環境評価基準

    ユーザの利用環境も含め、最終的な脆弱性の深刻度を評価する基準です。脆弱性の対処状況を評価し、CVSS環境値を算出します。この基準による評価結果は、脆弱性に対して想定される脅威に応じ、ユーザ毎に変化します。ユーザが脆弱性への対応を決めるために評価する基準です。

     

    CVSSは3つの評価を組み合わせて、最終的なスコアを算出します。一見すると、環境評価基準を用いることで個々のシステムに関する情報を評価に組み込んでいるように見えますが、環境評価基準はセキュリティ知識が必要なことや影響度合いを基準に当てはめることに難しさがあります。現状評価基準は未評価であることも多く、基本評価基準のみを用いているとお客様よりお伺いすることが多いです。

     

    しかし、基本評価基準のみに基づいて対応方針を策定していると、影響や環境特性の考慮が無い対応方針を取ることになります。

     

    例えば、ネットワーク機器のマネジメントポートに関して、リモートから任意のコマンド実行が可能な脆弱性が公表されたとします。対応方針に従うと緊急対応が必要となりますが、マネジメントポートをインターネットに公開しておらず第三者から到達不可能であるならば、内部犯行の可能性を除くと緊急性はないと言えます。対応方針に従うならば緊急対応が必要ですが、システム担当者からすると緊急性はないと考えることができます。このように対応方針の基準とシステム担当者の考え方による違いから、混乱を生む可能性があります。

     

    公表される脆弱性の多くはCVSSによって評価され、CVSSのスコアに則り対応方針を策定するやり方は非常に明確でわかりやすい一方で、課題①や課題②が生じることがあります。

    CVSSに代わる脆弱性の評価手法「SSVC」とは

    SSVCは、前ページで述べた課題を解決する評価手法として、カーネギーメロン大学ソフトウェア工学研究所によって公開された手法[4]です。

    3つのステークホルダー

    SSVCでは、3つのステークホルダー(デプロイヤー、サプライヤー、コーディネーター)に応じて3種類の決定木が用意されており、決定木に従い判断することで最終的に脆弱性に対応する優先度を示します。

    表3.ステークホルダーの説明

    ステークホルダー

    説明

    デプロイヤー

    パッチを適用する組織。脆弱性の対応を行う組織が該当する。

    サプライヤー

    パッチを提供する組織。製品ベンダなどが該当する。

    コーディネーター

    脆弱性情報を統制する組織。各組織のCSIRTが該当する。

     

     

    読者の多くが該当すると思われるステークホルダーは、パッチを適用する側であるデプロイヤーになると思いますので、以降はデプロイヤーに焦点を当てて説明します。

    デプロイヤーの例

    デプロイヤーの優先度は、表4「SSVCの優先度」の通りです。

    表4.SSVCの優先度

    優先度

    説明

    Defer

    現時点では対応しません。

    Scheduled

    定期的なメンテナンス内で対応します。

    Out-of-cycle

    緩和策または修正策を適用するために通常より迅速に対応します。

    Immediate

    利用可能なすべてのリソースを活用し、可能な限り迅速に修正策を適用します。

    必要であれば、通常業務の一時停止を行います。

     

     

    各脆弱性は、最終的に4つの優先度分けられ、現場のシステム担当者は、優先度に沿った対応を行うことになります。では、どのように優先度が導出されるのかを見ていきましょう。デプロイヤーの決定木の分岐で利用される判断条件は、表5「SSVCの分岐項目」の通りです。

    表5.SSVCの分岐項目

    分岐項目

    説明

    Exploitation

    攻撃実績があるかどうか、PoCが公開されているかどうかを調査し、判断します。

    Exposure

    脆弱性を持つ製品がインターネットからアクセスできるかどうかを判断します。

    Utility

    攻撃の自動化が可能か、また、攻撃することの有用性を判断します。

    有用性とは、攻撃が成立した場合に制御を得られるリソースを指し、例えば、1人のアカウント奪取のみであれば有用性が小さく、データベースシステムのオペレーションアカウントであれば有用性が大きいと判断します。

    Well-being and Mission Impact

    影響の大きさを判断します。

     

    ExploitationとUtilityは、脆弱性の現状や脆弱性自体について評価をしており、ExposureとWell-being and Mission Impactは、脆弱性がある製品が属するシステムについて評価をしているため、CVSSのスコアを用いた対応方針の策定の場合とは異なり、環境特性を判断に組み込んでいます。

     

    ExposureとWell-being and Mission Impactの判断に必要な情報は、事前に各システムの状況を整理しておくことで取得可能です。そのため、脆弱性が公表されたときには、ExploitationとUtilityの判断に必要な情報を取得すれば、自動的に優先度を決定することができます。言い換えると、事前に整理しておかなければ脆弱性が公表される度に同じことを確認することになります。迅速な判断を行うためには、構成管理も適切に行うことが大切です。

     

    表4「SSVCの優先度」と表5「SSVCの分岐項目」を用いて構成されるデプロイヤーの決定木は、図2の通りです。

    図2-1.SSVCのデプロイヤーの決定木(Exploitation-noneの場合)[4]

    02

    図2-2.SSVCのデプロイヤーの決定木(Exploitation-PoCの場合)[4]
    03図2-3.SSVCのデプロイヤーの決定木(Exploitation-activeの場合)[4]

    04

    環境特性を考慮した判断プロセスを示してくれるSSVC

    CVSSは、基本評価基準のスコアを与えてくれますが、各組織がスコア毎の対応方針を検討、決定する必要がありました。一方で、SSVCは環境特性を考慮した判断プロセスを示してくれるため、各社はSSVCの判断プロセスをベースに脆弱性の対応方針を決定することができ、事前に情報を整理しておくことで迅速な判断を行うことも可能です。近年大量に脆弱性が公表されるようになってきており、環境特性を考慮した迅速な判断を与えるSSVC は、脆弱性への対応の一つの答えとなるかもしれません。

    おわりに

    今回は、CVSSに代わる新しい評価手法としてSSVCをご紹介しました。読者の皆様の社内規定では、脆弱性が公表されたときにどのように判断して対応することになっていますでしょうか。

     

    SSVCはあくまで手法の一つとなりますので、CVSSのスコアを分岐条件に組み込むことやSSVCの判断条件をカスタマイズすることで各組織に適した脆弱性管理の規定を作ることができるかもしれません。NRIセキュアがご提供する「SecurePROtecht」でも、SSVCが発表される以前からSSVCで用いられるExploitationやExposureに近い判断を行い、WAFやIDS、プロキシなどのマネージドサービスの脆弱性対応を適宜行っています。

     

    また、社内規定の策定支援を行う「セキュリティポリシー策定支援」や、お客様がご使用の製品の脆弱性情報などを収集してお知らせする「マネージド脅威情報分析サービス」を展開しております。「セキュリティポリシー策定支援」ではもちろんSSVCの考え方を取り入れたポリシー策定も可能です。

     

    お悩み事やご相談事項がありましたらお気軽に弊社担当までお問い合わせいただければ幸いです。

     

     

    脚注・参考

    [1]

    CVSS Severity Distribution Over Time

    [2]

    NVD (National Vulnerability Database) は、アメリカ政府の脆弱性管理データのリポジトリです。世の中に公表されている脆弱性の多くが、NVD に登録されています。

    [3]

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

    [4]

    PRIORITIZING VULNERABILITY RESPONSE: A STAKEHOLDER-SPECIFIC VULNERABILITY CATEGORIZATION (VERSION 2.0)

     

    DMARCスタートガイド