SSVC v2.1徹底解説：脆弱性対応フレームワークの変更点と進化 | FutureVuls Blog

はじめに

SSVC（Stakeholder-Specific Vulnerability Categorization）は、脆弱性対応の優先度を決定するフレームワークであり、2023年7月にv2.1がリリースされました。本バージョンでは、判断基準がシンプル化され、Decision Point「Utility」の削除や「Automatable」への統一によりリスク評価の精度と効率が向上しています。また、デプロイヤーツリーの分岐数が減少したことで、手動での判断がより簡単にできるようになりました。これらの変更により、Immediateとなるパスが減ったため、組織は緊急対応すべき脆弱性をより明確に特定し、効率的に対応できるようになります。本記事では、SSVC v2.1の変更内容とFutureVulsへの影響について詳しく解説します。

※注意事項
本記事はSSVCの基本知識を有している前提で執筆していますので、SSVCについて詳しく知りたい方は「脆弱性対応に有用なSSVCと、適用について」をお先にご一読ください。

SSVCとは？ 脆弱性対応フレームワークの基本解説

SSVC（Stakeholder-Specific Vulnerability Categorization）の仕組み

カーネギーメロン大学ソフトウェアエンジニアリング研究所が提案した評価手法であり、ステークホルダーのニーズに基づいて脆弱性の対応優先度を決定します。SSVCは、脆弱性、システム環境、被害発生時の影響に関する情報を「Decision Tree」（決定木）に入力することで対応優先度を導出します。

決定木の各分岐点は「Decision Point」と呼ばれ、ステークホルダーが各分岐点でどのような判断をすればどのような対応優先度になるのかを表現可能です。これによって高い説明性を持った評価を実現できます。

SSVCの詳細な情報はGitHub上で公開されおり、仕様はオープンな場で議論されているため高い透明性があります。
更にSSVCは、米国サイバーセキュリティ庁（CISA）でも活用されており、その信頼性は高く評価されています。

デプロイヤーツリーで脆弱性の優先度を決める方法

デプロイヤー（脆弱性に対応する組織）が脆弱性の対応優先度を決定する際に使用する決定木のことを指します。
デプロイヤーの意思決定は緩和策や修復策をどの優先度でソフトウェアに対して実行するかに集中するため、対応優先度を決定するには以下のDecision Pointsを準備する必要があります。

• Exploitation
  • 攻撃コードの公開有無や脆弱性の悪用状況の情報
  • active, poc, noneのいずれかを選択
• Exposure
  • 脆弱なコンポーネントの外部への露出度（インターネットに直接接続可能かなど）
  • small, controlled, openのいずれかを選択
• Utility
  • 攻撃者にとっての有用性
  • laborious, efficient, super effectiveを以下の2項目から導出する
    • Automatable（攻撃の自動化可能性）
    • Value Density（価値密度：エクスプロイトにより攻撃者の制御下に置かれる可能性のあるリソースの密集度）
• Human Impact
  • 攻撃された場合の影響
  • low, medium, high, very highを以下の2項目から導出する
    • Safety Impact(物理的な安全性や人命への影響)
    • Mission Impact(業務に不可欠な機能(MEF)への影響)

上記のDecision Pointsの選択によって、対応レベルを4段階に分類します。

※備考

• 上記はv2.0のDecision Pointsの情報です。
• SSVCについて詳しく知りたい場合は「脆弱性対応に有用なSSVCと、適用について」をご一読ください。

  バージョン変更について

SSVC v2.1で変わった重要なポイント

v2.1ではDecision Pointの「Utility」が「Automatable」へ変更になりました。
「Utility」は、「Value Density」と「Automatable」によって値が決まる指標でしたが、v2.1では「Value Density」はSSVCの対応レベル算出時の対象から外れました。

SSVC v2.1変更の経緯と議論の背景

GitHub上のissueで、デプロイヤーツリーはUtilityをAutomatableに置き換えるべきかどうかという観点で議論されていました。

issueの起票者は、デプロイヤー観点では業務影響（Mission Impact）を価値密度（Value Density）と同等に扱うべきと述べています。
すなわち、リソースが「集中的」であれば攻撃された場合の業務影響は大きく、「拡散的」であれば業務影響は小さいということを示唆していると考えられます。
結論としては、SSVCリポジトリのメンテナーはデプロイヤーツリーの「Utility」を削除し、「Automatable」に置き換える決定を下しました。

その理由は以下の通りです。

業務影響（Mission Impact）を識別可能であると予想される状況では、攻撃の自動化可能性（Automatable）と業務影響は対応優先度を考える指標として独立した関係となります。この文脈では、価値密度（Value Density）により追加される情報は主に「緩和策」や「修復策」の実施に必要な労力に関することになるが、デプロイヤー観点からするとリソースが「集中的・拡散的」であるかは、以下の2点を考慮すると明確な対応優先度を必ずしもつけられないと述べています。

• 修正作業が自動化されているような状況を仮定すると、「緩和策」や「修復策」の実施に必要な労力は関心事ではない。労力のほとんどは適用前のパッチのテストに費やされるし、作業が自動化されていればリソースが集中的・拡散的かという差で労力は変わらない。
• リソースが「集中的・拡散的」であるかに関わらず、パッチを実施する際は業務影響を考慮せずに実施することは困難

そのため、「Value Density」を指標から外し、「Utility」を「Automatable」に置き換えるという判断となりました。

ちなみにデプロイヤーツリー上から「Utility」は削除されましたが、メンテナーは「Utility」の一部としての「Value Density」は脆弱性の影響を受ける可能性があるシステムの状況について不十分な知識のまま潜在的な影響について代理で判断する必要がある意思決定者（サプライヤーやコーディネーター）にとっては適した指標であると述べています。
サプライヤーやコーディネーターは、システムの状況について知ることはできないので、攻撃者と同じ目線に立って対応優先度を判断する必要がある（攻撃者にとって有用なものほど優先度が高い）と考えることができ、この理由から攻撃者にとっての有用性の判断に必要な「Value Density」はサプライヤーツリーやコーディネーターツリーで使用する指標として適しているという風に考えられます。

※備考
FutureVulsでは現時点のデプロイヤーツリーにおける「Human Impact」は実装簡素化のため、「Mission Impact」によって決定することを想定しています。上記で記載している「Mission Impact」はFutureVuls内では「Human Impact」として捉えています。
「Human Impact」を「Mission Impact」によって決定することを想定している理由については「SSVCにおける Human Impact 決定方法例」をご参照ください。

SSVC v2.1の変更がリスク評価に与える影響

デプロイヤーツリーの分岐数削減とその効果

「Utility」から「Automatable」への変更により、決定木がシンプルになり分岐数が108から72に減少しました。

従来「Immediate」と判定されていた条件の一部が「Out-of-cycle」に変更されました。これにより、緊急対応が本当に必要な脆弱性だけに集中できるようになりました。

SSVC v2.1で優先度が変わる条件の詳細解説

Decision Pointが「Utility」から「Automatable」に変更されたことで、一部の条件で対応優先度が「Immediate」から「Out-of-cycle」になる理由を以下の内容を確認しながら説明します。

• 1. v2.0の「Immediate」判定条件
• 2. v2.1の「Immediate」判定条件
• 3. v2.0とv2.1の「Immediate」判定条件の対応関係
• 4. 対応優先度が「Immediate」から「Out-of-cycle」になる条件

まずは、v2.0の「Immediate」判定条件を確認します。

バージョン変更に関係する「Utility」の条件に注目します。
「Utility」は「laborious」「efficient」「super effective」のいずれかの値をとります。それぞれの条件は以下です。

これらより、「Immediate」になるのは以下の7パターンです。

次にv2.1の「Immediate」判定条件を確認します。

v2.0と2.1の「Automatable」と「Human Impact」の値を比較すると、パターン3以外は「Value Density」の値によらず、「Immediate」と判定されるので以下の対応関係が成り立ちます。

上記の対応関係からv2.1への変更で影響を受けるのは、パターン3「Utility: efficient (Automatable: no AND Value Density: concentrated)、Human Impact: high」と言えます。
パターン3はv2.1ではAutomatable: no、Human Impact: highとして扱われるため「Out-of-cycle」と判定されます。これらより、v2.0からv2.1への変更で「Immediate」から「Out-of-cycle」に対応優先度が下がるのはパターン3の扱いの変化によるものと言えます。

※備考
SSVC v2.1で、Automatable: no、Human Impact: highをデプロイヤーツリー上で「Immediate」として扱うことは可能です。FutureVulsでは、Decision Pointsの値の組み合わせに対して任意の対応優先度を設定可能な機能を用意しているので、柔軟に対応優先度を変更できます。

FutureVulsがSSVC v2.1に対応した変更点

FutureVulsでSSVC設定がさらに簡単に！

SSVC 設定の Decision Pointは、「Exploitation、Exposure、Automatable、Human Impact」になりました。
バージョン更新により、「Value Density」が削除されたことで手動設定が必要な項目は3つから2つに減り、設定がさらに簡単になりました。手動設定が必要な項目は 「Exposure」 と 「Human Impact」 のみです。

FutureVulsを使ったSSVC v2.1の検証結果

SSVC v2.0とv2.1のトリアージ結果を徹底比較

対応優先度が「Immediate」から「Out-of-cycle」となるのは、v2.0のパターン3「Utility: efficient (Automatable: no AND Value Density: concentrated)、Human Impact: high」であるため、Decision Pointを以下の条件で検証しました。

想定環境は「インターネット公開の重要システム」で、「33,566」件の脆弱性をSSVCで分類しました。

結果は以下です。

想定通り、v2.1では「Immediate」の判定基準が厳しくなり「Immediate」の数が減少することを確認しました。
v2.1への変更により「Immediate」は、これまで以上に緊急な対応を要する脆弱性のみに絞り込めるようになりました。

SSVC v2.1とFutureVulsの進化まとめ

デプロイヤーツリーへの影響

• 分岐数の削減
  デプロイヤーツリーの分岐数が108から72に減少し、判断プロセスがよりシンプルになりました。
• 「Immediate」判定基準の厳格化
  従来「Immediate」と判定されていた条件の一部が「Out-of-cycle」に変更されました。これにより、緊急対応が本当に必要な脆弱性だけに集中できるようになり、リソースの最適化が実現します。

FutureVulsへの影響

• 設定の簡素化
  FutureVulsのSSVC設定の設定項目が3つから2つ（ExposureとHuman Impact）に削減されました。

最後に

本記事では、SSVC v2.1への変更がデプロイヤーツリーやFutureVulsに与える影響について解説しました。v2.1への変更で「Immediate」判定の基準が厳しくなるため、SSVCを活用している運用担当者はこれまで以上に対応すべき脆弱性の絞り込み精度の高さを実感できるようになるでしょう。

FutureVulsでは、SSVCによる脆弱性の対応優先度付けの自動化を簡単に使える機能をご用意しております。
対応優先度付けのノウハウや業務負荷にお困りの方は、ぜひ一度FutureVulsからお問い合わせください。

参考文献

[1] CERTCC/SSVC: Stakeholder-Specific Vulnerability Categorization – GitHub, CERTCC
[2] PRIORITIZING VULNERABILITY RESPONSE: A STAKEHOLDER-SPECIFIC VULNERABILITY CATEGORIZATION (VERSION 2.0), Carnegie Mellon University