トップ > テクノロジー > CVSSを逆から読むと？脆弱性対応の意思決定に使えるSSVCについて

CVSSを逆から読むと？脆弱性対応の意思決定に使えるSSVCについて

テクノロジー セキュリティ アドベントカレンダー

この記事は、 NTT Communications Advent Calendar 2024 14日目の記事です。

脆弱性対応の分野で注目度が高まりつつあるSSVCの概要と、その運用方法について紹介します。

こんにちは。イノベーションセンターの志村（@mshim03）です。 普段はMetemcyber PJというチームでSBOMを利用した脆弱性対応の研究開発の取り組みや、Network Analytics for Security（通称NA4Sec） PJで攻撃インフラの解明・撲滅に関する技術開発、自組織のセキュリティ運用に取り組んでいます。

本記事では、脆弱性対応の文脈で注目度が高まっているSSVCとは何か、どのような問題を解決するのか、どのように利用すべきかについて紹介します。 本記事では、サーバやソフトウェアが依存するソフトウェア（パッケージ）で公開されている脆弱性情報を特定し、パッチ対応などを行うことを脆弱性対応と呼称します。

脆弱性対応の課題

サービスを開発、運用する上では、利用しているソフトウェアなどで発見された脆弱性に対応していくことが欠かせません。 公開された脆弱性に対してパッチ適用を実施したり、適切な設定変更や緩和策を適用するなど、悪用を防ぐための活動が必要になります。

しかし現在の脆弱性対応には、以下のような課題が存在しています。

公開される脆弱性の増加

CVE-ID (CVE:共通脆弱性識別子のID) が付与された脆弱性の数は年々増加傾向にあります。 2023年の公開数29,066件に対し、2024年は37,514件 (12/9現在) の脆弱性がすでに公開されており、急速に脆弱性公開数が増加していることがわかります。


CVE Details より

実際に悪用される脆弱性は一部に過ぎない

大量の脆弱性が公開される一方で、実際に悪用される脆弱性の数はわずかです。 悪用が確認された脆弱性は全体の6%ほどだったという調査結果が存在しています。 1

脆弱性の悪用までが高速化

実際に悪用される脆弱性は一部ですが、攻撃者にとって有用な場合は即座に攻撃が開始される傾向にあります。 例えば、2024年に発生したPalo Alto Networks製品の脆弱性は、4月12日に情報が公開され、4月14日時点ですでに国内での攻撃が観測されていました。 2

すなわち、昨今の脆弱性を取り巻く環境は以下のような状態といえます。

  • 脆弱性の数は増加しており、大量の脆弱性情報が届けられる
  • 一方で大半の脆弱性は悪用されない
  • ただし攻撃者にとって有用な脆弱性な場合、即座に対応しないと被害を受ける蓋然性が高い

そのためすべての脆弱性に対応するというよりも、対処が必要な脆弱性を素早く特定・対応することが必要になっています。 このような活動は脆弱性のトリアージと呼ばれることもあります。

CVSSによる脆弱性のトリアージ

トリアージを実施する際の問題は「何を基準に優先順位を決定するのか」という点があります。 悪用された際の影響の大きさや、悪用がどの程度考えられるかといった観点で優先度を考える必要があります。

脆弱性の危険度を表す指標としてはCVSS（共通脆弱性評価システム）が有名です。 CVSSは脆弱性に関するオープンな評価指標であり、悪用時の影響や攻撃の前提条件などをもとに0~10.0 までの値で算出されます。

一方でCVSSは攻撃の技術的評価をスコアリングしたものであり、意思決定に利用するには以下のような問題があると指摘されています。

  • 脆弱性対応でよく使われるCVSS基本スコアは脆弱性を技術的観点で評価したもので、悪用可能性などは考慮していない
  • 具体的な意思決定までサポートがされない
    • CVSSスコアがある値より上なら即座に修正すべき、といった基準を与えるものではない

CVSSスコアは高いものの実際には悪用困難で攻撃が発生していない脆弱性が存在するなど、CVSSスコアのみをトリアージに使うのは現実的でないことが多いです。

そのような状況の中、脆弱性対応の意思決定をサポートする概念としてSSVCが注目されています。

SSVCとは

SSVC （Stakeholder-Specific Vulnerability Categorization）は、カーネギーメロン大学ソフトウェア工学研究所によって提案された手法です。 脆弱性管理に関わるステークホルダー （脆弱性に対するパッチを作成する開発者、脆弱性に対するパッチを適用するソフトウェア利用者など）のニーズに基づいて脆弱性に優先順位をつけ、対応順を明確にできる方法論となっています。

SSVCは以下のドキュメントで詳細が紹介されています。
https://certcc.github.io/SSVC/

SSVCは、Decision Tree（決定木）を用いて、数値ではなく脆弱性対応の優先度を出力します。 そのため最終的に算出度される優先度が明確であり、なぜその優先度が算出されたかを即座に理解できます。

以下はSSVCが用意している、ソフトウェア利用者（Deployer）向けの決定木（一部抜粋）です。 四角で囲まれたDecision Points（後述）の値によって判定が分岐し、最終的に1つの優先度が出力されます。 以下の例ですと、 「Exploitation（脆弱性の悪用状況）」が「PoC（悪用コードのPoCが存在）」、「Exposure（システムのネットワーク接続状態）」が「controlled（制限されている）」、 「Automatable（脆弱性の悪用を自動化できるか）」が「no」、「Human Impact（脆弱性の影響）」が「low」 ならば、最終的に「defer（現時点では脆弱性に対応する必要はない） 」という結果が出力されます。

SSVCの決定木の一部:3

SSVCを脆弱性管理に活用しようという動きは近年増しており、IPAが発行する脆弱性対応における リスク評価手法のまとめで言及されるなど、存在感を高めています。

SSVCを構成する要素

SSVCの方法論を構築する要素を、SSVC Howtoページをベースに紹介します。SSVCを利用して優先度を算出するためには、決定しなければならない要素がいくつかあります。

ステークホルダーのロールの特定

SSVCは “Stakeholder Specific” という名が表すように、脆弱性管理におけるステークホルダー、すなわちどのように脆弱性対応に関わるか、という概念が重要になります。

SSVCのドキュメントでは、以下のようなステークホルダーの立場が想定されています。

  • Supplier
    • ソフトウェア開発者。脆弱性が発見された時にパッチを作成する役割を担う
  • Deployer
    • ソフトウェア利用者。提供されたパッチを環境に適用する役割を担う
  • Coordinator
    • CERTなどの立場が想定されている。脆弱性対応を統制したり、脆弱性情報の展開などをする役割を担う。

決定すべき優先度（Decision）の特定

脆弱性対応への関わり方によって、決定すべき優先度は変わります。

例えばSupplierが算出すべき優先度は、「どの順序で脆弱性のパッチを作成・提供すべきか」になりますし、Deployerであれば「どの順序で脆弱性パッチを適用するか」になります。

このように、ステークホルダーが決定すべき優先度を、SSVCではDecisionと呼びます。

Decisionが取りうる値（Outcome）の定義

Decisionの取りうる値が定義されている必要があります。 SSVCではこれをOutcomeと呼びます。

SSVCが提供するDeplolyer向けのModelでは、以下のようなOutcomeが定義されています。

  • Defer
    • 現時点で対応しない。
  • Scheduled
    • 定期的なメンテナンスで対応する。
  • Out-of-cycle
    • 定期的なメンテナンスは別に、早期に軽減策か修正策を適用する （次の機会か、必要ならば作業時間外での実施）。
  • Immediate
    • 脆弱性に即時対応する。すべてのリソースをできるだけ早く脆弱性の修正に集中させる。必要であれば組織の通常の運用を停止させる。

優先度はImmediateが最も高く、Deferが最も低いです。

Outcomeの算出に使う入力の決定（Decision Points）

どのような情報をもとにOutcomeを算出するかを決定します。 この入力をDecision Pointsと呼びます。
Decision Pointsの例としては、脆弱性の悪用状況、脆弱性の対象となるシステムのネットワーク接続状態などがあります。

SSVCではさまざまなDecision Pointsを定義しています。 以下ページより参照できます。
https://certcc.github.io/SSVC/reference/decision_points/

Outcomeの算出方法の決定（Policy）

Decision PointsからOutcomeを算出する方法を決定します。 これをPolicyと呼びます。PolicyはDecision Pointsを入力として受け取り、Outcomeを返す関数と考えることができます。

SSVCはPolicyの表現として決定木を使うことが一般的です。 決定木を活用することで、各Decision PointsがどのようにOutcomeの算出に使われるのか明確になります。

要素のまとめ

SSVCを構成する要素をおさらいします。

  • Stakeholder
  • Decision
  • Outcome
  • Decision Points
  • Policy

SSVCを構成するこれらの要素をまとめた概念をDecision Modelと呼びます。 SSVCを用いた意思決定をする場合は、自組織のニーズにあった適切なDecision Modelを決定し、それを運用に落とし込む必要があります。

既定のDecision Modelの活用

SSVCを利用するために、Decision Modelを一から構築するのは難易度が高いです。

そのためSSVCは、あらかじめSupplier、Deployer、Coordinatorのステークホルダー向けのDecision Modelを提供しています。 それぞれ Supplier Decision Model、Deployer Decision Model、Coordinator Decision Models4と呼ばれています。

Deployer Decision Model

最も多くのユーザに関係するであろう、Deployer Decision Modelについて紹介します。 このModelでは、Stakeholderは「Deployer」、Decisionは「パッチを適用する優先度」になります。 Outcomeは前述したDefer、Scheduled、Out-of-cycle、Immediateです。

Policyは以下の決定木で表されます。 この決定木はDeployer Treeと呼称されます。


Deployer Tree:5

Deployer Treeは以下のようなDecision Pointsを有しています。 脆弱性自体の情報と、脆弱性対応の対象となる資産の情報が主に含まれています。

  • Exploitation
    • 現時点での脆弱性の悪用状況。時間と共に変化しうる
    • PoCの有無や、実際の攻撃が悪用されているかによって判断される
  • System Exposure
    • システム・サービスのアタックサーフェース（攻撃可能な境界）のアクセス可能状態
    • インターネットなどからアクセス可能か、アクセスが制限されているかなどによって決定される
  • Automatable
    • 脆弱性を利用した攻撃が自動化可能か（人間のインタラクションがなくても実行可能か）
  • Human Impact
    • その脆弱性が及ぼす影響の大きさを表す。Safety Impact と Mission Impactから算出される 6
    • Safety Impact
      • 脆弱性が安全性に与える影響
    • Mission Impact
      • 組織のミッションに不可欠な機能へ与える影響

SSVCの活用

SSVCを実際に活用する際のポイントを2つ紹介します。

組織に合わせたModelの選択

Deployer Decision Modelをそのまま採用するには、資産管理を適切に実施し、資産の外部への露出状況や用途をデータとして継続的に収集する必要があります。 これは組織の規模や状態によっては難しいことがあります。

そのような場合、既存のModelをカスタマイズしたり、組織のポシリーに合致するようなDecisionやDecision Pointsを採用することも可能です。 7

SSVCのドキュメントでは、組織のリソースに応じて以下のように、段階的にDecision Modelを成長させていく例が示されています。 https://certcc.github.io/SSVC/howto/acuity_ramp/#an-acuity-ramp-in-action

  1. CISA KEV8を利用
  2. Exploitationを利用
  3. Exploitation, System Exposureを利用
  4. Exploitation, System Exposure, Automatable を利用
  5. Exploitation, System Exposure, Automatable, Mission Impact, Safety Impact を利用

SSVC運用のデータの取得

SSVCはDecision Points のためのデータをどのように収集するかは定義していません。 ( Reference ページに目安となる方法は紹介されています。)

組織はDecision Pointsの決定に必要なデータを収集し、適切にマッピングする方法を決定する必要があります。

Deployer TreeのDecision Modelを利用する場合、収集すべき情報は主に脆弱性自体の情報と、ソフトウェアをデプロイしている環境の情報になります。

脆弱性自体の情報としてExploitationやAutomatableなどの情報がありますが、これらはCISAが情報を提供しています。 この情報はVulnrichment GitHub Repositoryや、CVEのCISA ADPから参照できます。9

CISA ADPは、CVE Websiteで提供される脆弱性ページから参照できます。10 View JSONを選択すればJSON形式で取得可能で、プロセスの自動化に役立てられます。11

環境情報の収集は資産管理と深く紐づいており、組織の資産管理のデータをDecision Pointsに反映する方法を定義する必要があります。 またShodanなどの公開デバイスの検索サービスや、ASM（Attack Surface Management）サービスを利用してのデータ収集も可能でしょう。

まとめ

SSVCを活用することで、脆弱性対応の優先度を算出し、組織の対応順序を明確にできます。 また利用するデータとその影響が明確になり、改善しやすい脆弱性対応が可能になります。

SSVCを活用することで何を決定すべきか、そのためにどんな情報が必要かを明確にできます。 意思決定プロセスが明確になることで、改善も容易になっています。

NTTコミュニケーションズではSSVCとSBOMを組み合わせて脆弱性対応の意思決定をサポートするツールを開発しています。 SBOM、SSVCというワードに興味がある方はぜひチェックしてください。 https://github.com/nttcom/threatconnectome

それでは、明日の記事もお楽しみに！

  1. https://jp.tenable.com/blog/epss-shows-strong-performance-in-predicting-exploits-says-study-from-cyentia-and-first↩
  2. https://www.jpcert.or.jp/pr/2024/PR_Report2024Q1.pdf↩
  3. https://github.com/CERTCC/SSVC/blob/679610194d4062d5638aeb6df6d0f561a0c415c9/docs/pdf/ssvc_2_deployer_SeEUMss.pdf↩
  4. 複数形になっているのは、Coordinator向けのModelは2つ存在しているからです。受け取った脆弱性レポートに基づいて調整を実施するかを決定するTriage に関するModelと、脆弱性を公開するかを決定するPublication に関するModelです。↩
  5. https://github.com/CERTCC/SSVC/blob/679610194d4062d5638aeb6df6d0f561a0c415c9/docs/pdf/ssvc_2_deployer_SeEUMss.pdf↩
  6. Human Impactを脆弱性ごとに算出することが現実的かについては議論があります。FutureVuls Blog などをご参照ください。↩
  7. 独自のDecision PointsやDecisionを採用する例は、SSVCのPrepare to Use SSVC に記載されています。業界規制やSLAをDecision Pointsとして採用する事例が紹介されています。↩
  8. CISA KEVは、CISAが公開している悪用が確認された脆弱性のカタログです。↩
  9. Authorized Data Publisher（ADP） は、認定された組織がCVEレコードに追加情報を付与できる仕組みです。詳細はCVE WebsiteのADPページ を参照ください。↩
  10. ブログ内で紹介したPalalto脆弱性（CVE-2024-3400）の場合、次のURLでCISA ADPを含んだ情報が公開されています: https://www.cve.org/CVERecord?id=CVE-2024-3400↩
  11. CVE-2024-3400の場合、次のURLからJSON形式で取得できます: https://cveawg.mitre.org/api/cve/CVE-2024-3400↩
© NTT Communications Corporation 2014