SSVC（Stakeholder-Specific Vulnerability Categorization）を活用した脆弱性管理

2022-01-17

脆弱性管理の現状と課題

脆弱性の報告件数は増加の一途を辿っており、2021年のCVE登録件数は約20,000件に及びます。単純に計算すると一日約55件の脆弱性が報告されていることになり、日々これらの脆弱性による業務影響を評価し、対応要否を判断することが求められます。

また、近年、開発ベンダーによる修正パッチ提供から攻撃検証コードの作成・公開までの所要期間が短縮しており、パッチ提供後、平均して37日後には攻撃検証コードが公開されている*1との報告も確認されています。これは対策を実施する企業から見ると脆弱性対策を完了するまでの猶予期間が短くなっていることを意味します。企業にとって脆弱性管理の徹底は、セキュリティ対策の王道でありながらも実現が難しい状況になっていると言えます。

こうした状況を受けて企業は、CSIRTやPSIRTなどを中心に日々公開される脆弱性情報を収集し、以下の観点で一次評価を行い、対応要否を判断することが一般的です。

  • 脆弱性の対象となるソフトウェア・製品は、自社で利用されているか、関係があるか
  • 脆弱性のCVSS基本値は、組織で設定した閾値以上か

しかし、上記のようにCVSS基本値に基づいた運用方針には以下のような課題が存在します。

CVSS基本値は実際のリスクを十分に表現できていない

CVSS基本値は、ネットワーク経由での攻撃可否、攻撃における認証やユーザー関与の要否、攻撃を受けた際の影響などの脆弱性が持つ性質を入力とし、定義された計算式に基づいて深刻度が0.0～10.0の値として出力されます。しかし、この値は「脆弱性をどの程度容易に悪用できるか」「脆弱性が悪用された場合、ソフトウェア上でどのような事象が起こり得るか」といった技術的観点での深刻度となっており、「実際に攻撃を受ける可能性があるか」「攻撃を受けた際に業務影響が発生するか」といった実際のシステムに対するリスクを十分に表現することができていません。

現状評価基準・環境評価基準の利用が形骸化している

CVSSは設計上、上記の基本評価基準に加え、攻撃コードの有無・対策の有無を評価する現状評価基準、製品の利用規模などの製品利用当事者による環境評価基準の3つから構成されます。基本評価基準で算出された基本値に両基準による評価を追加して行うことで、CVSS現状値とCVSS環境値が算出できます。正確な影響評価を行うためには、冒頭に記載したようにNVDやJVNなどの第三者機関、製品の開発元ベンダー、または製品利用当事者が算出した基本値に対して追加評価を行い、CVSS環境値の算出が必要となります。しかし、多くの企業では現状評価基準と環境評価基準による評価は行われていません。現状評価基準については昨今、脅威インテリジェンスサービスなどの普及により攻撃発生状況、攻撃コードの作成・公開状況などを比較的容易に把握できるようになりつつありますが、環境評価基準での評価を正確に行うためには自社での当該ソフトウェア製品の利用状況を平時からインベントリ管理を通して把握する必要があり、この徹底が実現できていないことが形骸化の一因として考えられます。

意思決定に関するガイドが提供されていない

CVSSによるスコアリングは前述のとおり0.0～10.0の数値として表現され、Low:0.1～3.9、Meduim:4.0～6.9、High:7.0～8.9、Critical:9.0～10.0と定義されています。しかし、「Criticalの場合はどのような対応をすべきか」という意思決定のための情報は提供されていません。そのため意思決定者は、「Criticalの場合は緊急対応する」といった方針を自ら策定する必要があります。セキュリティアセスメントなどを行う中で実際のクライアントの運用ルールを確認すると、前述の課題と相まって、「Critical、またはHighかつ攻撃ベクターがネットワーク経由の脆弱性については緊急対応を行う」といったスコアリング結果を直接利用していない対応方針を策定しているケースも存在します。

また、仕様上、スコアリングは±0.5ポイントの誤差が許容されるため、例えばHighに分類されることが期待される入力値の組み合わせは6.6～9.3の値に収まることになります*2。したがって、算出された深刻度に基づいて画一的な判断を行った場合、結果的に不適切な対応を行っている恐れがあります。

ステークホルダーごとの意思決定に対応できない

脆弱性対応の優先度は、開発ベンダー、利用者などの意思決定者の立場によって異なります。また、一口に利用者と言っても当該製品を何のためにどのように利用しているか、といった利用状況によっても判断は異なりますが、CVSSはこうした要求に対応できていません。

SSVCによる脆弱性管理

上記のようなCVSSの課題に対応するため、2019年12月、米カーネギーメロン大学ソフトウェア工学研究所によってSSVCが提案されました。現在2.0版が同大学のウェブサイトでホワイトペーパーとして公開されています*3。SSVCは米サイバーセキュリティ・インフラストラクチャ・セキュリティ庁（CISA）によって脆弱性の評価に利用されています*4。また2021年5月12日に米国において発令されたサイバーセキュリティ強化のための大統領令*5を受けて、2021年11月16日にCISAが公開した連邦民間機関の情報システムを対象とする脆弱性やインシデント対応活動に関するプレイブック*6「Cybersecurity Incident & Vulnerability Response Playbooks」においても、「SSVC等に基づいた影響評価の実施」が言及されています。SSVCの特徴は以下のとおりです。

具体的な判断を導出

CVSSが脆弱性の性質などの定性的な情報を入力とし、計算式に基づいて深刻度を値として出力していたのに対して、SSVCでは以下のような実施すべき判断を出力します。各判断をどこまで厳密に解釈し、採用するかは利用者の判断に委ねられますが、基本的な方針は明確になります。

  • defer
    • 現時点では対応しない
  • scheduled
    • 定期メンテナンス時に対応する
  • out-of-cycle
    • 通常よりも迅速に行動し、計画外の次の利用可能な機会に、必要に応じて通常業務時間外を含めて緩和策または修復策を実施する
  • immediate
    • 全てのリソースを集中し、 必要に応じて組織の通常業務を停止して可能な限り迅速に対応を行う

決定木に基づいた透明かつ説明可能なアプローチ

SSVCでは入力から出力を得る過程に決定木を採用しています。決定木は、条件分岐を多段階で積み上げた樹形図として表現され、SSVCの利用者は起点から条件分岐ごとに判定を繰り返すことで上記のような最終的な判断を導出できます。決定木を採用している利点としては、最終判断に至るプロセスが明確であり説明可能であること、最終判断に納得が得られない場合、関係者でどの条件分岐の判定を見直すべきかを議論できることが挙げられます。議論によって条件分岐を見直す場合は、その議論・考察を記録することで透明性を担保できます。

ステークホルダーに応じた決定木を提供

前述のとおりCVSSでは意思決定を行うステークホルダーによる立場やリスク選好度の違いを取り扱うことができませんでした。SSVCは、あらかじめステークホルダーとしてサプライヤー、デプロイヤー、コーディネーターの3つが定義されており、ステークホルダーごとの決定木が提案されています。そのためSSVCの利用者は自身の立場に応じて対応する決定木を選択し、判断を導出することができます。

SSVCによる脆弱性の評価

上記のとおりSSVCはサプライヤー、デプロイヤー、コーディネーターごとに異なる決定木が提案されており、決定木を構成する条件分岐も異なります。本稿では、サプライヤーを例に具体的な脆弱性評価の方法を紹介します。なお、2021年4月に公開された2.0版ではいくつかの仕様は先送りとなっているため、詳細については同ホワイトペーパーを参照ください。

サプライヤー向けの決定木は以下が提案されており、利用者は、Exploitationを起点に樹形図の各節で設定された条件分岐について判断を繰り返すことで最終判断を導出します。

引用　米カーネギーメロン大学ソフトウェア工学研究所公開のオリジナル論文より https://resources.sei.cmu.edu/asset_files/WhitePaper/2021_019_001_653461.pdf

決定木を構成する設問は以下のとおりです。

Exploitation

現時点における脆弱性の悪用状況を以下の3つの中から判定します。
None 実際に悪用されている証拠がない、また攻撃検証コードが公開されていない。
PoC（Proof of Concept） ダークウェブ、ディープウェブなどのアンダーグラウンドで攻撃検証コードが売買されている、攻撃検証コードがインターネット上の脆弱性データベースやソースコードリポジトリで公開されている、または攻撃の再現手法が公知となっている。
Active 公的機関、セキュリティベンダー、ソーシャルメディアなどで脆弱性を悪用した攻撃の発生が確認、報告されている。

Utility、Automatable、Value Density

攻撃の自動化可否を判定するAutomatable、攻撃成功時に得られる価値密度を判定するValue Densityの2つの判定結果に基づいて、攻撃者にとっての攻撃の有用性を示すUtilityを判定します。

攻撃者にとっての攻撃の有用性（Utility）

  Automatable Value Density
Laborious no diffuse
Efficient no

concentrated
yes diffuse
Super Effective yes concentrated

攻撃の自動化可否（Automatable）
Automatableはサイバーキルチェーンの始めの4つのステップである偵察・武器化・デリバリー、エクスプロイトの自動化可否を判定します。

no

以下を含む理由により自動化が困難。

  • ネットワーク経由での脆弱性の検出・列挙が不可能
  • 武器化にあたり人間による個別の関与が必要
  • 配信にあたり広く普及しているネットワークセキュリティ対策の回避が必要
  • ASLR（Address Space Layout Randomization）などの既定で適用される脆弱性攻撃緩和策によりエクスプロイトの信頼性が低い
yes 偵察からエクスプロイトの自動化が可能。または、外部からのコードインジェクション、コマンドインジェクションなど、任意コード実行が可能。

攻撃成功時に得られる価値密度（Value Density）
攻撃が成功した際に攻撃者が得られる情報の価値を以下の2つから選択します。

diffuse

攻撃成功時に攻撃者が得られるリソースやコントロールが限定的。システム管理者ではない一般ユーザーのアカウント、端末など。
concentrated 攻撃成功時により高いリソースやコントロールを奪取することが可能。データベース、認証サーバー、ログイン機能を提供するウェブサーバー、クラウドサービスプロバイダー、秘匿性の高いデータなど。

Technical Impact

攻撃を受けた場合の技術的影響を以下の2つから判定します。判定は脆弱性が存在するコンポーネントを対象に行います。そのため、当該コンポーネントがシステムの中でどのような機能を担っているかを考慮して判定する必要があります。
Partial

攻撃成功時に攻撃者は、限定的なコントロールの奪取・情報の窃取を行うことが可能。または実現性が非常に低い前提の下、完全なコントロールを奪取することが可能。
Total 攻撃成功時に攻撃者は、脆弱性が存在するシステムの完全なコントロールの奪取・情報の窃取を行うことが可能。

Public Safety Impact、Safety Impact

攻撃による被害の種類、影響の大きさを示すSafety Impactの判定結果に基づいて、個別の組織に限定しない一般的な被害の種別、影響の大きさをPublic Safety Impactとして判定します。

Public Safety Impact

Minimal

Safety Impactの判定結果がNoneまたはMinor

Significant

 Safety Impactの判定結果がMajor、Hazardous、Catastrophic

Safety Impact

以下の定義に基づいて被害の種別、影響の大きさを判定します。

影響の大きさ 被害の種別 定義
None All すべての観点でMinorを下回る影響
Minor Physical Harm システム利用者の物理的な不便・不快、労働安全衛生上の軽度の問題、物理的なシステム安全マージンの減少
Environment 他者への軽微な影響（資産・環境への損害）
Financial 容易に吸収されない複数人への経済的損失
Psychological カウンセリング、セラピーの原因となる複数人への精神的・心理的被害
Major Physical Harm システム利用者の身体的苦痛や負傷、著しい労働安全衛生上の問題、安全な操作をサポートする物理的なシステム機能の故障
Environment 他者への重大な影響（資産・環境への損害）
Financial 複数人の破産につながる可能性のある経済的損失
Psychological カウンセリングやセラピーを受けるのに十分な広範囲にわたる集団への精神的的・心理的被害
Hazardous Physical Harm

重傷、または緊急処置により対応可能な致命的傷害。安全な動作を支えるサイバーフィジカルシステムの一部破壊
Environment 他者への深刻な影響（生命や財産への脅威、広範な環境破壊、測定可能な公衆衛生上のリスクなど）
Financial 影響を受けるコンポーネントの関連する社会技術システム（選挙、金融グリッドなど）が不安定化し、安全でない状態になる
Psychological N/A
Catastrophic Physical Harm 複数人にわたる生命の危機
Environment 他者への甚大な影響（即時の公衆衛生上の脅威、小規模な生態系の崩壊につながる環境破壊など）
Financial ソフトウェアによって支えられた社会システム（選挙、金融グリッドなど）の崩壊
Psychological N/A

上記のようにサプライヤーの決定木を構成する要素は、「脆弱性が悪用された場合に一般利用者に対してどの程度影響があるか」という観点になっていることが分かります。一方、デプロイヤーの決定木は以下のような設問から構成されており、脆弱性が存在するソフトウェアを利用する当事者としての観点が含まれています。

  • Exploitation
    サプライヤーと同様
  • System Exposure
    影響を受けるサービス・システムの外部露出の程度
  • Utility
    サプライヤーと同様
  • Human Impact
    Safety ImpactとMission Impactを統合した影響の大きさ。Safety ImpactおよびMission Impactの判定結果に基づいて4段階で判定
    • Safety Impact
      サプライヤーと同様
    • Mission Impact
      業務必須機能（Mission Essential Function）への影響に応じて5段階で判定

活用にあたっての考慮点

冒頭で述べたように、すでに多くの組織がCVSSによるスコアリングを前提とした脆弱性管理のためのプロセス整備、運用に取り組んでいます。本節では、こうした環境においてSSVCをどのように活用できるのかを考察します。

SSVCは前述のとおりCVSSによる課題を解決するために提案されました。そのため、CVSSによるスコアリングに基づいて脆弱性管理を行っているものの以下のような状況に陥っているケースでは、SSVCを利用する価値があります。

実運用において都度個別判断を行っているケース

「CVSS基本値9.0以上はパッチ適用、緩和策実施が必須」などの規定は整備しているものの、実運用では都度の個別判断が発生し、またその判断プロセスが明確になっていないケースです。このケースでは、判断の再現性が担保されておらず一貫性のない場当たり的な判断が繰り返されている恐れがあります。そのため対応する決定木に基づいて判断を行い、最終結果に納得感が得られない場合は関係者で議論し、判断を改めるポイント・変更内容・理由を明確化・記録します。この運用を継続して実績を積み上げることが、組織としての脆弱性管理のノウハウになると考えられます。また、ホワイトペーパー内では決定木のカスタマイズについても一定のガイダンスが示されているため、必要に応じて組織に合った決定木に変更することも考えられます。

CVSS基本値に基づいた対応の合理性が低いケース

「システムへのアクセスが十分に制限されている」「仕様上、攻撃を受けた際の影響が限定的である」など、システムの設計・運用を踏まえるとリスクが低く、CVSS基本値に基づいた対応の合理性が低いケースです。システムへのパッチ適用などの対処実務を行う担当者が自身でCVSSによるスコアリングを行う場合、アタックベクタ（AV）や機密性・完全性・可用性（CIA）への影響等の入力値を補正し、より実態に近いスコアに修正できる可能性があります。一方で、CVSSで環境評価基準でカバーされていた業務影響については、SSVCではSafety Impact、Mission Impactという形でより実務に近い広範な概念として取り込まれているため、より適切な判断が可能です。こうした判断の精度を高めるためにはシステムの構成情報・特性をより正確に把握する必要があり、サイバーセキュリティ資産管理（CSAM: Cyber Security Asset Management）といった事前の準備が重要になります。

また、全社的なCSIRTが各事業部門に対して脆弱性情報を展開し、対処を促すガバナンス体制となっている場合、SSVCを指示側と対応側のコミュニケーションツールとして利用することで、中央からの一貫した指示と現場に応じた個別判断を両立できるでしょう。

CSAMおよびCVSS・SSVCを併用した脆弱性管理プロセス

まとめ

本稿では、CVSSの課題を踏まえてSSVCの特長、導入の可能性について考察しました。CVSSについては課題を中心に記載しましたが、脆弱性の深刻度を定量的に評価する仕組みとしての有効性は高く、今後も脆弱性データベースや開発元ベンダーが対外的に情報発信し、脆弱性情報を流通させる際に利用し続けられると考えられます。SSVCは、その名称のとおり、流通している情報を受け取った各ステークホルダーが実効性のある脆弱性管理を行うために提案された手法です。決定木に基づいた脆弱性個別の対応判断と関係者間での合意形成は、特に運用初期において相応のコストが掛かることが予想されますが、こうしたトレンドを踏まえると、SSVCの採否にかかわらず自組織に合った脆弱性管理プロセスを整備することが今後益々重要になると考えられます。

*1 UNIT 42, 2020,  "The State of Exploit Development: 80% of Exploits Publish Faster than  CVEs" https://unit42.paloaltonetworks.com/state-of-exploit-development/

*2 FIRST "Common Vulnerability Scoring System v3.0: Specification Document"
https://www.first.org/cvss/v3.0/specification-document

*3 Carnegie Mellon University, 2021, "Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0)"
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=653459

*4 CYBERSECURITY & INFRASTRUCTURE SECURITY AGENCY "SUBPOENA PROCESS"
https://www.cisa.gov/subpoena-process

*5 THE WHITE HOUSE, 2021, "Executive Order on Improving the Nation’s Cybersecurity"
https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

*6 CYBERSECURITY & INFRASTRUCTURE SECURITY AGENCY, 2021, "New Federal Government Cybersecurity Incident and Vulnerability Response Playbooks" 
https://us-cert.cisa.gov/ncas/current-activity/2021/11/16/new-federal-government-cybersecurity-incident-and-vulnerability

執筆者

村上 純一

パートナー, PwCコンサルティング合同会社

Email

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
{{contentList.loadingText}}
{{contentList.viewAllLabel}}

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
{{contentList.loadingText}}
{{contentList.viewAllLabel}}

関連情報