SSVCとは？ステークホルダーに合わせた脆弱性の分類について解説

記事サムネイル

　SCAP中のCVSSの様な「脆弱性の重大性スコアリング」には様々な問題も指摘されており、最近は他の指標値として「SSVC(Stakeholder-Specific Vulnerability Categorization)」というキーワードなどが聞こえてきていると思います。こちらの記事では、SSVCについて説明します。v2.0からv2.1でUtilityが無くなるなどの簡略化もされていますので、それらも併せて説明します。

「未経験からでもホワイトハッカーになれる！」実践的セキュリティスクール「セキュ塾」

セキュ塾コース診断

SSVC(Stakeholder-Specific Vulnerability Categorization)について

　SSVC(Stakeholder-Specific Vulnerability Categorization)とは、その名の通り「ステークホルダーに合わせた脆弱性の分類を行おう」というものになります。脆弱性の悪用状況や安全性への影響、システムで影響を受ける製品の普及状況を考慮した脆弱性分析手法を提供します。SSVCを実装することで脆弱性への対応や一般へのアナウンスの優先順位付けに役立ちます。

　2019年にカーネギーメロン大学のSoftware Engineering Institute (ソフトウェアエンジニアリング研究所: SEI) がCISAと共同でSSVCを作成しました。2020年には、米国政府 (USG)や州・地方等の政府や重要なインフラストラクチャに関する脆弱性を調査するため、カスタマイズされたSSVC決定ツリーを開発しています。こちらの「カスタマイズ」については後述するとして、まずはオリジナルの「SSVC」を見てみます。

SSVCの情報（PDF)

　SSVCの詳細な情報に関しては、SEIのサイト(Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0))からPDFをダウンロードできますので、こちらを参考に説明していきます。ただし、こちらのPDFは詳しすぎる内容のため、このWeb記事ではざっくりと説明します。

SSVC 2.0 -> 2.1への変更点

　SSVC v2.1では

  1. Deployerツリーを更新し、UtilityではなくAutomatableを使⽤(こちらのIssueで会話が行われていた)
  2. 情報表現におけるいくつかの決定ポイントを明確化
  3. フィードバックを受けていくつかのツリーをブラッシュアップ

特に1.のところは大きく、結果としてツリーのノードが108から72に減少しています。

CVSSの問題点

　CVSSの問題点としては、以下の様なものが挙げられています。

  • 実際に標準化グループでも認めていますが、CVSSスコアリングアルゴリズムに関する議論は透明性に⽋けています。実際CVSSv4.0の所でも書いていますが、基本的にアルゴリズムについては「FIRSTのタスクフォースで専門家の方々と意見を交わして」決めているため、我々には結果のみが公開されます。また私もFIRSTの年一回のイベントにも参加しましたが、CVSSに関する議論は「タスクフォースメンバーのみ参加可能」でしたので、中でどのように議論されているかは、ほぼクローズドです。
  • CVSSスコアは公開されますが「それでどうすれば良いの？」という決定(Decision)については提供されません。これはCVSSでも「技術的な重大度を出しているのみです」と強調している通りです。
  • CVSS スコアでは、どの脆弱性が⼀般的に悪⽤されるか／エクスプロイトが公開されるかが予測できません。CISA KEVなどで見てみてもわかりますが、CVSS BaseScoreが小さい(3.9 Low)の「CVE-2023-20867」などでも実際に悪用が観測されています。
  • CVSS情報を出したアナリスト・ベンダーにより同じ脆弱性でもCVSSのスコアリング方法がまちまちだったりします。例えば「CVE-2022-43641」などはNISTでつけたBaseScoreは7.8High, Zero Day InitiativeがつけたBaseScoreは3.3Lowだったりします。

このようなCVSSの問題から、「脆弱性に関する決定(Decision)」に関するアプローチを検討したものがSSVCになります。

脆弱性に関する決定(Decision)を導くための設計目標

　脆弱性に関する決定(Decision)を導くための設計目標として、下記の様なものが挙げられます。

  • アウトプットは値などではなく決定（Decision）です。
  • 管理できる数のステークホルダーのグループから、多元的な推奨事項が作成されます。
  • 入力は定性的（qualitative）なものです。
  • 出力も定性的（qualitative）なもので、 定量的なものへの（正当ではない） 移行はありません。
  • 透明性があるプロセスになります。
  • 結果は説明可能です。

以上を「設計の目標」として掲げて実装方法を考えた結果、「Decision Trees（決定木）」がSSVCとして採用されました。

ステークホルダー

　SSVCではソフトウェアのサプライチェーンでどのような役割を行なっているかに応じて、ステークホルダー（利害関係者）を

  1. サプライヤー（提供者）
  2. デプロイヤー（導入者）
  3. コーディネーター

の３つのチームに分けます。もちろん、一つの組織に複数の役割が混在していることもあります。 たと えば、 独自のソフトウェアを開発して使用している場合には、サプライヤーが自社内の開発チーム・デプロイヤーがIT運用チームとなります。また、DevOpsを使用している場合にはサプライヤーとデプロイヤーが一つの組織になっていることもあります。

決定ポイント(Decision Point)と関連データ(Relevant Data)

　SSVCでは脆弱性の優先順位付けを決定する際に考慮すべき要素として、以下の決定ポイントと関連する値が提案されています。下記はv2.0を元にしていますので、v2.1で変更があった箇所にはそれぞれ注意書きがしてあります。それぞれの決定ポイントは各ステークホルダーによって使うもの・使わないものがあります。

Exploitation(脆弱性悪用の攻撃)

　脆弱性の悪用の証拠がどれくらいあるか、になります。以下は「Exploitation Decision Values（Exploitationの決定値）」の表になります。

Value(値)Definition(定義)
None実際に悪用されているという証拠はなく、脆弱性を悪用する方法のPoCも公開されていない
PoC(Proof of Conecpt)次のいずれかのケースが当てはまる
(1) エクスプロイトコードがダークウェブまたは制限されたフォーラムで販売または取引されている
(2) MetasploitやExploitDB などの場所で一般的なPoCが知られている
(3) 脆弱性の悪用方法が広く知られている
Active（活発）エクスプロイトが攻撃者によって実際に使用されていることを示す、信頼できる証拠や公開レポートがある

Technical Impact（技術的な影響）

　エクスプロイトによる脆弱性悪用での技術的な影響になります。以下は「Technical Impact Decision Values（Technical Impactの決定値）」の表になります。

ValueDefinition(定義)
Partial（部分的）エクスプロイトにより、攻撃者は脆弱性のあるソフトウェアの動作を限定的に制御したり、情報を漏洩することができる。または、エクスプロイトにより、攻撃者は非常に低い（Low）確率でコンポーネントを完全に制御できます。この文脈での「低い（Low）」とは、攻撃の成功確率に対して十分な試行を行うことができない状態であることを意味している。例えばDoSは、脆弱なコンポーネントの動作を限定的に制御する形式である。
Total（全体的）エクスプロイトにより、攻撃者はソフトウェアの動作を完全に制御できるようになり、脆弱性のあるソフトウェアを含むシステム上の全ての情報が完全に公開されることになる。

Utility（ユーティリティ）（SSVC v2.1ではDeployerに関してはツリーから廃止しAutomotableに変更）

　攻撃者にとってのエクスプロイトの有用性になります。以下は「Utility Decision Values（Technical Utilityの決定値）」の表になります。

Value(値)Definition(定義)
Laborious（面倒）No Automatable（自動化）できず拡散(diffuse)の価値がない
Efficient（効果的）{Automotabale（自動化）出来て拡散(diffuse)の価値がある} 又は {Automotable（自動化）できないが集中化された(concentrated)価値がある}
Super Effective（非常に効果的）Automotable（自動化）出来てが集中化された(concentrated)価値がある

　また下記はAutomotable（自動化）とValueDensity（価値密度）の敵対者（Adversary）への有用性になります。

Automotable（自動化）ValueDensity（価値密度）Utility
nodiffuse（拡散）Laborious
noconcentrated（集中）efficient
yesdiffuse（拡散）efficient
yesconcentrated（集中）Super Effective

　以下は上記表の用語説明になります。

Automotable（自動化）(v2.1からはDeployerではUtilityではなくこれがTopにくる)

Automatable は、「攻撃者はこの脆弱性の悪用を確実に自動化できるか?」というものになります。このメトリックは、no または yes の値を取ることができます。

  • no: 攻撃者はこの脆弱性に対するサイバーキルチェーンのうちの4ステップ「(1) reconnaissance（偵察）, (2) weaponization（兵器化）, (3) delivery（配信）, (4) exploitation（悪用）」を自動化することはできません。例えば兵器化に人間の指示が必要になったり、ASLRなどのエクスプロイト防止機構が問題になってExploitationが出来ない場合などです。
  • yes: 攻撃者はこの脆弱性に対するサイバーキルチェーンのうちの4ステップを自動化することができます。

ValueDensity（価値密度）(v2.1からはDeployerではこちらは廃止/他では引き続き残っている)

　価値密度は、敵対者が単一の悪用イベントで制御できるリソースに基づいて、diffuse(拡散)またはconcentrated(集中)として説明されます。

  • diffuse（拡散）：脆弱性のあるコンポーネントを含むシステム上に限られたリソースしかありません。つまり攻撃者が1回のエクスプロイトで制御できるリソースは比較的小さいということです。価値が分散しているシステムの例としてはメールアカウント、オンラインバンキングアカウント、一般的な携帯電話などがあります。
  • concentrated（集中）：脆弱性のあるコンポーネントを含むシステムには、リソースが豊富にあります。価値が集中している例としては、データベース・Kerberosサーバー・ログインページをホストするWebサーバー、クラウドサービスプロバイダーなどがあります。ただし、脆弱なシステム上のリソースの有用性と独自性も、価値の密度に影響します。

Human Impact（人間の影響）

　SSVCではSituated Safety ImpactとMission Impactをまとめて一つの「Human Impact」としています。マッピングは以下の表のようにまとめられています。

Situated Safety ImpactMission ImpactCombined Value (Human Impact)
None/MinorNone/Degraded/CrippledLow
None/MinorMEF FailureMedium
None/MinorMission FailureVery High
MajorNone/Degraded/CrippledMedium
MajorMEF FailureHigh
MajorMission FailureVery High
HazardousNone/Degraded/CrippledHigh
HazardousMEF FailureHigh
HazardousMission FailureVery High
CatastrophicNone/Degraded/CrippledVery High
CatastrophicMEF FailureVery High
CatastrophicMission FailureVery High

Safety Impact（安全性への影響）

　影響を受けるシステムが侵害されることによる、安全性への影響になります。安全性については広い視野で検討しており、安全性への違反はCDCなどで言うところの「Well-being」への違反だと考えています。物理的・経済的・社会的・心理的な「安全性」への影響です。以下は「Safety Impact Values（Safety Impactの決定値）」の表になります。

Value（値）影響の種類Definition(定義)
NoneAll（全て）完全に影響が無いと言うわけではないが、Minorで定義されている閾値を下回ったものになる。
MinorPhysical Harm（身体的影響）システム利用者の物理的不快感や物理的なシステム安全マージンの減少
MinorEnvironment（環境）他の外部に課せられる軽微な損害（財産損害、環境損害など）
MinorFinancial（経済的）容易に吸収できない経済的損失が複数の人に及ぶ場合。
MinorPsychological（精神的）一定の人間に対してカウンセリングやセラピーの対象となるぐらいの、感情的または心理的な危害。
MajorPhysical Harm（身体的影響）システムのユーザーに対する身体的苦痛および傷害、または重大な労働安全上の危険、または安全な操作をサポートする物理的なシステム機能の障害。
MajorEnvironment（環境）他の外部に課せられる重大な外部性（財産損害、環境損害など）。
MajorFinancial（経済的）複数の人の破産につながる可能性のある経済的損失
MajorPsychological（精神的）カウンセリングやセラピーを必要とする程の感情的または心理的な危害が、広範囲にわたる人々の間に広がること。
Hazardous（危険）Physical Harm（身体的影響）緊急サービスや安全な操作をサポートするサイバーフィジカルシステム等の手段により死亡を回避できる可能性がある程度の、重傷または致命傷。
Hazardous（危険）Environment（環境）他の外部に課せられる重大な問題（生命および財産への脅威、広範囲にわたる環境被害、測定可能な公衆衛生リスクなど）。
Hazardous（危険）Financial（経済的）影響を受けるコンポーネントが含まれる社会技術システム（選挙、金融グリッドなど）が不安定になって、安全でない状態になる。
Hazardous（危険）Psychological（精神的）N/A
Catastrophic（壊滅的）Physical Harm（身体的影響）多数の死者（緊急対応では被害者を救うことはおそらく不可能）
Catastrophic（壊滅的）Environment（環境）他の外部に課される極端な問題（差し迫った公衆衛生上の脅威、小規模な生態系の崩壊につながる環境破壊など）。
Catastrophic（壊滅的）Financial（経済的）ソフトウェアによって支えられている社会システム（選挙、金融グリッドなど）が崩壊。
Catastrophic（壊滅的）Psychological（精神的）N/A

Public Safety Impact（公共安全への影響）

　サプライヤーは、上記で説明した広義のSafety Impact（安全への影響）については、かなり大まかな視点を持っています。そのため上記を簡略化します。重大とは、いずれかの影響が上記の表の重大、危険、または壊滅的影響の基準を満たす場合です。最小とは、いずれも基準を満たさない場合です。

Value（値）Definition(定義)
Minimal（最小）「Safety Impact」がNone又はMinor
Significant（明白）「Safety Impact」がMajor, Hazardous, Catestrophic

Situated Safety Impact（状況的安全への影響）

　デプロイヤーは、「安全性への影響」で広く定義されている影響について、よりきめ細かな視点を持つことが期待されます。デプロイヤーの実装を簡素化するために、ミッションへの影響と組み合わせるため、このトピックについては保留されています。

Mission Impact（ミッションの影響）

　組織のミッションの重要な機能への影響です。ミッション必須機能 (MEF) とは、「組織の法定または執行憲章に定められた、組織のミッション達成に直接関連する」機能です。MEF と非必須機能の大まかな違いは、組織が「通常業務の中断中に MEF を実行する必要がある」ことです。ミッションとは組織が存在する理由であり、MEF はそのミッションにどのような影響を与えるかです。非必須機能はミッションそのものを直接サポートするものではありませんが、MEF の円滑な遂行や成功をサポートします。特に上場営利企業の財務損失は、そのような企業の (法的に義務付けられた) ミッションが財務実績であるため、ここで取り上げます。以下は「Mission Impact Decision Values（Mission Impactの決定値）」の表になります。

ValueDefinition(定義)
None / Non-Essential Degraded（なし / 必須ではない）劣化非必須機能（非MEF）の劣化まではほとんど影響がないが、慢性的な劣化は最終的に必須機能に悪影響を及ぼす。
MEF Support Crippled（MEFサポートの機能不全）重要な機能を直接サポートする活動は機能不全に陥りますが、重要な機能はしばらく継続する。
MEF Failerいずれかのミッションに不可欠な機能が許容範囲よりも長い期間機能しなくなり、組織全体のミッションは低下しますが、しばらくの間は達成可能です。
Mission Failer複数またはすべてのミッション必須機能が失敗し、それらの機能を回復する能力が低下し、組織が全体的なミッションを遂行する能力が失われます。

System Exposure（システムの露出）

　影響を受けるシステムやサービスのアタックサーフェースになります。以下は「System Exposure Decision Values（System Exposureの決定値）」の表になります。

ValueDefinition(定義)
Smallローカルサービスやプログラム、又は高度に制御されたネットワーク。
Controlled（制御下）何らかのアクセス制限や緩和策がすでに導入されているネットワーク サービス (ローカルまたはネットワーク上)。
緩和策を成功させるには、敵対者の攻撃を確実に阻止する必要があるため、攻撃を確実・迅速に検出して対応できる必要がある。
Open（オープン）アクセス制限／制御することが不可能なインターネットなどのネットワーク上のサービス（(DNS サーバー、Web サーバー、VOIP サーバー、電子メール サーバーなど）。

Public Value Added

　この決定(Decision)ポイントでは、コーディネータからの公開がコミュニティ全体にどの程度の利益をもたらすかを考えます。その価値(Value)は、脆弱性に関する既存の公開情報の状態に基づいています。

ValueDefinition(定義)
Precedence（優先）当該Publicationは、初めて公開されるものとなります。
Ampliative（増幅）脆弱性に関する既存の公開情報を拡充および/または補足するものになります。たとえば詳細な情報を追加したり、他の公開情報の誤りを修正したりする事などです。
Limited（限定的）既存の情報はすでに高品質であり複数の媒体で公開されているため、追加される価値は最小限になります。

Supplier Improvement

　この決定（Decision）ポイントでは、脆弱性対処の為のサプライヤーの作業状況を考慮します。

Value
Fix Ready（修正完了）サプライヤーがパッチや修正プログラムを既に提供している状態です。
Cooperative（積極的）サプライヤーは積極的にパッチや修正プログラムを作成しています。緩和策や回避策に関しては提供している場合・提供していない場合の両方があります。
Uncooperative（消極的）/Unresponsive（応答なし）サプライヤーが応答しない場合や、修復を拒否している場合などです。

アクション・プライオリティなどについて。

　以下は、SSVCのアクションに関する用語説明や考え方となります。

脆弱性管理アクションの列挙

　SSVCでは「組織は特定の脆弱性管理作業単位に対してどの様な優先順位で対処すべきか」という決定をモデル化していま す。作業単位とは、 パッチの適用など脆弱性の修復・或いは緩和策の展開を意味します。

サプライヤー（提供者）の作業単位

　サプライヤーは通常、（プロセスの入力と考えると）自社製品の複数のバージョンに存在する脆弱性の報告を受け取ります。最初の報告を受け取った際のサプライヤーのタスクは、報告された脆弱性の影響を受ける一連の製品とバージョンを明らかにすることです。

　SSVCではサプライヤーの作業単位として、脆弱性と影響を受ける各製品の組み合わせから成り立っていると仮定しています。つまりSSVCを最大限に活用するためには、サプライヤーが受け取ったあらゆる問題をそのレベルの粒度で解決できる必要があることを意味しています。

　サプライヤーが影響を受ける製品のセットを明らかにするのは、たとえば

  1. 最初の報告を更に調査した結果、製品のAdditionalバージョンも影響を受けていることが判明した
  2. 製品間でのコード共有や、同じプログラマーが起こしたエラーにより、他の製品が影響を受けていることが見つかった
  3. 自社製品で利用しているサードパーティのライブラリの脆弱性に関する報告を受けた
  4. 1つ以上の自社製品で使用されているサードパーティライブラリの修正が含まれたソフトウェアを受け取った（修正済みのソフトウェアによって複数の脆弱性が解決されたり、新機能が追加される事があります)

などがあり、多くの場合個別に対処する必要があります。

　最終的に、サプライヤーは影響を受ける製品に対する修正バージョンや緩和策を提供します。サプライヤーが提供する修正バージョンは通常、複数の脆弱性に対する修正と、多くの場合新機能を含むソフトウェアアップデートです。また、推奨される設定変更などの緩和策を作成して提供することもできます。

サプライヤーの出力は、デプロイ担当者への入力となります。

デプロイヤー（導入者）の作業単位

　デプロイヤーは通常、デプロイした製品についてサプライヤーから修復や緩和策を（入力として）受け取ります。その後、インスタンス等に修復や緩和策をデプロイするかどうかを決定します。

　修正バンドルなどの修復の一部のみをデプロイするオプションがあるかどうかは、サプライヤーのリリースプロセス設計に依存します。例えばサービスパックとして修正バンドルを出しつつ、個別デプロイ可能な修正をリリースする、などです。

　デプロイヤーの脆弱性管理プロセスでは、次のようなデータが必要になります。

  1. 展開済みインスタンスの製品バージョンのインベントリ
  2. 脆弱性と修復または緩和策のマッピング
  3. 修復や緩和策と製品バージョンのマッピング

1.に関してはデプロイヤー側で収集するものですが、2,3に関しては通常サプライヤーから提供されます。これらの情報の管理は一般に「情報資産」と呼ばれるものになります。SSVCと情報資産の関係については「資産管理との関係」で後述します。

　次にデプロイ担当者はこれらの情報を元にして、修復または軽減策を製品の特定のインスタンスに施すために作業をスケジュールする必要があります。SSVCにおけるデプロイ担当者ツリーでは、インスタンスが属するシステムのカテゴリにミッションや安全性のリスクも考慮します。このため、修復や軽減策と製品バージョンインスタンスの組み合わせが、SSVCでの作業単位になる事をお勧めしています。

コーディネーターの作業単位

　コーディネータの作業単位は、製品の特定のバージョンに影響を及ぼす脆弱性から、欠陥のある仕様を実装した全てのサプライヤー・製品に影響を及ぼす可能性のある仕様欠陥まで多岐にわたります。

　コーディネータは、リクエストに応じてレポートを再編成(例:結合、分割、拡張、縮小)する必要があります。SSVCは、最初期のレポート作成や改良に使用できます。

作業単位全体でのSSVCの集約

　SSVCの利用者は、検討している個別の作業単位ごとに提案された質問に答える必要があります。

パッチの提供

サプライヤーにおけるパッチの提供

　サプライヤーがパッチを提供する際には優先順位をつける必要があります。優先順位付けが必要なのは、少なくともこれまでの経緯では、既知の脆弱性すべてにパッチを適用する作業は利用可能なリソースを超えるためです。下記にサプライヤーでの優先順位をまとめています。

提供のプライオリティ説明
Defer（延期）現状ではパッチ提供作業を行わない。
Scheduled（スケジュール）通常どおりのリソースを使用して、定期的にスケジュールされたメンテナンスの範囲内で修正プログラムを開発する。
Out-of-Cycle（サイクル外）他のプロジェクトからエンジニアリソースを引き離してサイクル外で緩和策や修正を開発し、準備ができたらセキュリティパッチとして修正をリリースする。
Immediate（迅速に）場合によっては組織の他の部署のリソース活用の調整も含めて利用可能なすべてのリソースを活用し、できる限り早く修正プログラムを開発してリリースする。

デプロイヤーにおけるパッチの提供

　修正が利用可能な場合、通常はそれを適用するというアクションが取られます。修正がまだ利用できない場合の行動は幾つかありますが

  • 脆弱性を軽減する（サービスのシャットダウンや他のセキュリティソリューションによる緩和策など）
  • 脆弱性を軽減しないリスクを受け入れる

等が必要になります。緩和策を適用すると、決定ポイント（後述）の価値が変わる場合があります。たとえば、効果的なファイアウォールとIDSルールにより、システムの露出がオープンから制御済みに変わる可能性があります。

　決定ポイントの値を変更する緩和策により、その後のアクションの優先度が下がる場合があります。 　以下の表は、デプロイヤーのアクション優先度を示しています。

デプロイヤーのプライオリティ説明
Defer（延期）現時点では何のアクションも起こさない。
Scheduled（スケジュール）定期的に予定されているメンテナンス時間中に実施する。
Out-of-Cycle（サイクル外）通常よりも迅速に行動し、必要に応じて残業を行なってサイクル外の緩和策または修正策を適用する。
Immediate（迅速に）迅速な実施を行う。必要に応じて通常業務を一時停止するなどし、全てのリソースを掛けて出来るだけ早く修正を適用する。

コーディネーターによるパッチの調整

　Coordinated vulnerability disclosure (調整された脆弱性開示：CVD)ではSSVC v2でモデル化された２つの決定（Decision）が利用可能です。

  1. 脆弱性レポートを調整するかどうか（トリアージ）
  2. 脆弱性に関する情報を公開するかどうか

1.に関しては下記の表でトリアージの優先順位をまとめています。

トリアージの優先順位説明
Decline（減少）レポートに関連したアクションを起こさない
Track脆弱性に関する情報を受け取り、ステータスの変化を監視するが、明白なアクションは実行しない。
Coordinate（調整）レポートに基づいてアクションを実行する。「アクション」には技術的な分析・複製・ベンダーへの通知・公開・および他の当事者への支援のどれかが含まれます。

リスク許容度と対応の優先順位づけ

　SSVCを使うことでステークホルダーはリスクのバランスと管理ができる様になります。脆弱性管理を成功させるためには以下の二つのリスクのバランスを取る必要があります。

  1. 変更リスク：「実稼働システムに変更を加えることで発生する可能性のある問題」＋「テストと修正の展開に関わってくるコスト」。
  2. 脆弱性リスク：脆弱なシステムの悪用によって発生する可能性のあるインシデントに対するコスト

SSVCの説明で使用されるツリーに関してはリスクに関する許容度が中程度のステークホルダーが意識されています。

Scope（範囲）

　Scopeは対応の決定について重要なファクターになります。例えばサプライヤーの立場ではEoLを過ぎた製品のサポートは範囲外であるとしてScope外に出来ます。しかしデプロイヤーの立場ではEoLを過ぎた製品がシステム内に残る可能性はあり、脆弱性が出た場合にデプロイヤーが他のセキュリティ製品などを使って緩和などを行う必要があるため、デプロイヤーに対してはそのようなSSVCが提供されなくてはなりません。

コーディネーターがSSVCを使用して決定を下す場合(CERT/CCの例)

　コーディネータは支援のため、内部では使用しないSSVC決定ポイントに関する情報を収集して公開する場合があります。さらに、コーディネータは、決定を下すために使用する情報の一部のみを公開する場合があります。

　他の利害関係者の視点(サプライヤと展開者)と同様に、SSVCでは、コーディネータが定義済みのアクションを実行する優先順位を提供しますが、そのアクションの実行方法は提供しません。以下ではCERT/CCを例に取って説明しています。

　CERT/CCがコーディネータとして下す2つの決定について、SSVCの観点から説明します。それは、脆弱性レポートの初期トリアージと、脆弱性に関する公開が必要かどうかです。

　最初の決定は優先順位付けの決定ですが、デプロイヤーやサプライヤーによる優先順位付けと同じ価値はありません。CERT/CCにとっての公開の決定は、はい/いいえの2択です。これら2つの決定は脆弱性調整のすべてではありませんが、プロセスの詳細については今後の作業に残します。コーディネータごとにスコープと構成員が異なります。

　コーディネータが自分の作業スコープの範囲外のレポートを受け取った場合は、レポートをより適切なコーディネータに転送します。以下のセクションの決定では、問題のレポートまたは脆弱性がコーディネーターの作業範囲内にあることを前提としています。

調整トリアージ決定（Decision）

　CERT/CCでは、受信したレポートに基づいて、脆弱性をどう調整するかを決定する際に、3つの優先順位を用いています。

  • 拒否（Decline）
    • 報告者に対して行動を起こさないことを伝え、ベンダーに連絡するか公開することを提案するなど、さまざまな形をとる場合があります。
  • 追跡（Track）
    • 脆弱性に関する情報を受け取り、ステータスの変化を監視しますが、明白なアクションは実行しません。
  • 調整（Coordinate）
    • 報告に基づいて「行動」を起こします。「行動」には、技術分析・再現・ベンダーへの通知・主導的な調整(通知、伝達、公開)・公開のみ・アドバイスのみ・二次コーディネーター(別の主導的なコーディネーター)への変更等が含まれます。

コーディネーターの決定（Decision）ポイント

　調整での決定の目標は、CERT/CCが脆弱性レポートを受け取ったときにアナリストが利用できる情報に基づいて決定することです。調整では、可能性のある決定ポイントの一部を使用するほか、ユーティリティや公共の安全への影響の決定ポイントも使用します。CERT/CCの調整および公開の決定は、脆弱性管理の社会的および協力的な状態に関するものです。これを評価するために、決定には5つの新しい決定ポイントが含まれます。

レポートの公開

　脆弱性の詳細に関する実用的なレポートはすでに公開されていますか?

  • Yes
  • No
サプライヤーへの連絡

　報告者は、確実な連絡方法を使用して、脆弱なコンポーネントのサプライヤーに連絡するように努力しましたか?

  • Yes
  • No
サプライヤーの数

　脆弱なコンポーネントとその修復または軽減を担当するサプライヤーはいくつありますか?

  • 1
  • 複数
サプライヤーとの関わり

　サプライヤーは報告者の連絡に真摯に応じ、積極的に関わっていますか?

  • Active（アクティブ）
  • Unresponsive（応答なし）
報告の評価

　報告の信頼性を評価するのは複雑ですが、評価では次のいずれかの結論に達する必要があります。

  • Credible（信頼できる）
  • Not Credible（信頼できない）

アナリストは、報告の信頼性の推定から始めて、失格に持っていく方向に進む必要があります。これは信頼性の判断に関して、FalsePositiveをFalseNegativeよりも優先することを意味しています。

次のサブセクションでは、信頼性の評価に関する示唆的なガイダンスを提供します。

Credibility Indicators（信頼性指標）

　レポートの信頼性は、バランステストによって評価されます。レポートは、(1)ベンダーが脆弱性の存在を確認した場合、または(2)報告者でもベンダーでもないアナリストが脆弱性を独自に確認した場合、信頼できるものとして扱われます。これらの確認がどちらも得られない場合、レポートの信頼性の決定ポイントの値は、次の指標間のバランステストによって決まります。

決定木

　SSVCではステークホルダー（サプライヤー・デプロイヤー・コーディネーター）用にサンプルの決定木を出していますので、こちらを貼り付けます。以下では「サプライヤー」の立場としての読み方を提示していますが、デプロイヤー・コーディネーターも同様になります。

サプライヤーの決定木

下記はサプライヤーの決定木になります。

画像はCERT/CC: SSVC(Version 2.1)より引用

デプロイヤーの決定木

下記はデプロイヤーの決定木になります。

画像はCERT/CC: SSVC(Version 2.1)より引用

コーディネーターの決定木

　下記はコーディネーターの決定木になります。

画像はCERT/CC: SSVC(Version 2.1)より引用

　また下記はコーディネーターのトリアージになります。

画像はCERT/CC: SSVC(Version 2.1)より引用

SSVC Calculator

　この決定木を利用してSSVCの計算（実際には条件を選択）していくわけですが、この作業（上記に当てはめてくれる作業）を簡単に行ってくれる「SSVC Calculator」も用意されています。

SSVC Calculator: SSVC: Stakeholder-Specific Vulnerability Categorization より画面キャプチャ

この「Calculator」では、それぞれのステークホルダー（立ち位置）を選択してSSVCを計算していく事ができます。画面は動的に動きますので、なかなか面白いです。

実際にSSVCを試してみる（CISA Vulnrichment情報を使用）

CISA Vulnrichment

　CISA VulnrichmentはCISAが公開されているCVE レコードの情報を強化する目的で作っているプロジェクトで、最近のCVEを評価して主要なSSVC決定ポイントを追加してい流ものになります。Vulnrichmentに関しては別記事でまとめたいと思いますが、まずはこの「CISA Vulnrichment」から情報を引っ張ってきましょう。

CVE-2024-6387（regreSSHion）のSSVC

　VulnrichmentはGithubで公開されているので、gitで情報を持って来れます。ここでは、「CVE-2024-6387（regreSSHion）」を見てみましょう。

コードはCISA VulnrichmentのGitHubから取得

　ssvcとしては「Exploitation: poc, Automatable: no, Technical Impact: total」になっています。

では、これを自身が「Deployer」だったと仮定してSSVC Calculatorを使ってみます。Exposureは「Controlled」／Safety Impactは「No」／Mission Impactは「Degraded」のシステムだとします。

CVE-2024-6387に上記の条件を組み合わせて「Deployer」としてCalculatorに入れた場合のSSVCv2

この場合、SSVCは「SSVCv2/E:P/X:C/A:N/S:N/M:D/H:L/P:D/2024-12-06T03:51:53Z/ 」になります。プライオリティとしては「Defer（延期）」になり、「現時点ではパッチ作業を行わない」となります。

まとめ

　SSVCは最終的には「自分たちではどうスコアリングするか」という考え方にもつながってきますので、これに関しては導入する側の熟練も必要になってきそうです。ただ、ユーザ側がSSVCについて学んでいる状態であるとすれば、これは中々使えるものになると思われます。

「未経験からでもホワイトハッカーになれる！」実践的セキュリティスクール「セキュ塾」

セキュ塾コース診断

参考リンク

CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)

SEI: Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0)

CERT/CC: SSVC(Version 2.1)

SSVC Calculator: SSVC: Stakeholder-Specific Vulnerability Categorization

CISA KEV: CVE-2023-20867

NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-43641

CISA: Vulnrichment

JapanSecuritySummitUpdate: 2024年7月版　最速！危険度の高い脆弱性をいち早く解説「脆弱性研究所」第24回

関連記事:

【OSINT実践ガイド著者が教える】OSINT（オシント）とは？ランサムウェア攻撃の対策方法とは？被害を防ぐ防止策と感染後の対策ランサムウェアグループ「RansomHub」についてSCAP（セキュリティ設定共通化手順）とは？専門家が解説

コメント