Techカテゴリ

脆弱性対応に有用なSSVCと、適用について

こんにちは。井上です。

FutureVulsは「日々更新される脆弱性情報を補足し、より効果的な運用・管理をサポートする」サービスですが。
2022/9/14リリースにて運用部分で有用なSSVC(Stakeholder-Specific Vulnerability Categorization)をサポートしました。

本稿では、脆弱性対応の現状からSSVCの説明、SSVCの適用例を説明します。

目次

  • 脆弱性対応の現状
    • 問題点
    • どうしたらよいのか
  • SSVCとは
    • 概要
    • どのような利点があるのか
  • SSVCを適用する
    • 従来の判断
    • SSVCでの判断
  • まとめ

脆弱性対応の現状

脆弱性を検知した後にどのように判断/対応するのか、は悩みどころの多い問題です。
一般的には以下を考慮して対応を検討しています。

  • 脆弱性自体の危険度
  • 自システムへの影響度
  • 対策難易度
  • 未対策でのリスク

その為、上記を判断する基準を組織で準備する場合があります。

  • CVSS Base Scoreが 8.0 以上のものは対応する
  • CVSSの深刻度が HIGH 以上のものは対応する
  • ニュースで、「危険」「対応が必要」と言及されている物は対応する

基本的に「対応する/対応しない」の判断とすることが多く、「対応する」となった場合は「なるはやで」となることが多い、と聞くことが多いです。
また、Base Scoreで画一的に対応を決めるため、「対応難易度が高い(適用は難しい)ので、何とかして基準値から外れるように調整する」という事も行われやすい方法です。

問題点

これらの判断は「脆弱性それ自体のリスク」で判断されることが多く、脆弱性による「システムへのリスク」への考慮があまりされていない場合が多いようです。
また、「危険か」の判断だけであり、それを受けて「どのタイミングで対応するか」はあまり考慮されてい無い場合も多いようです。

  • 影響を受けるシステム自体の重要度により、対応緊急度が変わります。
    • 個人情報のような重要機密を持っているサーバと、会社説明だけを表示しているサーバでは、保有している情報が異なる
      • 両方とも同じ「脆弱性の影響」はあるが、侵害された場合の「リスク」は異なる
      • リスクを考慮すると、対応時間（なるべく早く、次のメンテナンス時に、等）の要求は異なる

また、脆弱性やシステムが置かれている環境の考慮がされていない、ということも多いようです。

  • 脆弱性それ自体の表現としてCVSS Base Scoreがあります。
    • これは、対象が置かれている環境でのリスクを表してはおらず、脆弱性自体のリスクを示している
    • その為、対象環境での脆弱性のリスクを別途検討しなければいけない
  • 脆弱性が置かれてる環境として、攻撃コード(Exploit)の公開状況や、攻撃キャンペーンなどの情報があります。
    • CVSS Base Scoreには、Temporal Metrics(現状評価基準)やEnvironmental Metrics(環境評価基準)という指標がある
    • これらの指標を適用することで、Base Scoreを調整させる事が想定されている
    • しかしながら、これらのMetricsは一般の企業ではほとんど使われることはない状況=事実上、形骸化している
  • システムが置かれている環境も、考慮対象となりえると考えられます。
    • システムの保有情報なども含む、重要度
    • システムで要求される、機密性/完全性/可用性(所謂、セキュリティのCIA)の要求レベル

まとめると以下になります。

  • CVSS Base Scoreは、トリアージ用途のものではない
  • 環境に対する評価が適切に行われていない
  • 判断のための情報だけであり、意思決定をするためのガイドラインは用意されていない

どうしたらよいのか

脆弱性自体の影響度ではなく、システムにおけるリスク、で判断する必要がありそうです。

以下の点を考慮する必要があると考えられます。

  • 当該システムにおけるリスク
    • 脆弱性の対象となる製品を、当該システムで利用しているか
      • 利用しているライブラリなどの情報
      • SBOM(Software Bill Of Materials:ソフトウェア部品表)を使える場合がある
    • 脆弱性それ自体のリスク
      • CVSS Base Score/Vector等で表現される、脆弱性自体のリスク
    • 脆弱性の悪用状況
      • PoC/Exploitの有無や、”既に攻撃が始まっている”等の情報、など
    • システムの置かれる状況
      • インターネット接続があるのか、WAFがあるのか、等の利用環境
      • 対象システムの事業におけるインパクト
    • システム自体の重要度
      • システムが保有する情報と、侵害された際にどの程度事業影響が発生するか
  • どのようなアクションをすればいいのか
    • 対応有無
      • リスクを受容できるかという点で、対応を判定
    • いつまでに
      • どの期間までにやるべきか、という指標

単純に「脆弱性それ自体で判断する」状況よりも多数の情報が必要になり、判断基準が増えたことで「どのように判断するのか」を明確にしなければいけなくなります。
判断情報収集は自動化ができるとしても、これを特定のフローなしに行うことは難しいと思われます。

このような状況対し、カーネギーメロン大学から出された SSVC(Stakeholder-Specific Vulnerability Categorization:直訳「利害関係者固有の脆弱性分類」) が解決策となりえます。

SSVCとは

2019年にカーネギーメロン大学 ソフトウェア工学研究所により提案された、「脆弱性管理でのアクションの優先順位付け(prioritizing actions during vulnerability management)」をする為のフレームワークです。

脆弱性やシステムに関する情報を入力しすることで決定木により具体的な意思決定を示す、意思決定を行うステークホルダー毎に決定木を用意された、意思決定のためのツールとして利用ができます。

概要

決定木(Decision Tree)を利害関係者(Stakeholder:ステークホルダー)毎に用意しておき、判断情報を入れることで意思決定を示します。
決定木には判断分岐点(Decision Points)が用意されています。例えば「Exploitが存在するか」等の情報であみだくじのように分岐を辿り、最終的に意思決定としての出力(Outcomes)が得られます。

以下のサイトで決定木を試すことができます。

脆弱性対応においては、”Deployer”と呼ばれる決定木を利用することになります。
入力する情報としては以下を用意します。

  • Exploitation
    • 攻撃コードの公開有無や、悪用が行われているかなどの情報
    • active, poc, none から選択する
  • Exposure
    • 脆弱なコンポーネントの露出レベルとして、インターネットに直接接続されているかなどの情報
    • small, controlled, open から選択する
  • Utility
    • 攻撃者における攻撃有効性を示す
    • 以下の2項が考慮対象となる
      • Automatable(攻撃の自動化が可能か), Value Density(価値密度：攻撃対象のリソースは豊富か)
    • laborious, efficient, super effective が、上記2項から導き出される
  • Human impact
    • 攻撃された際の影響を示す
    • 以下の2項が考慮対象となる
      • Situated Safety Impact(人的影響を基にした被害の種別や、影響の大きさ), Mission Impact(業務に不可欠な機能(MEF)への影響)
    • low, medium, high, very high が、上記2項から導き出される

これらの結果として、意思決定としての出力(outcomes)が以下の様に用意されています。

  • Immediate
    • 即座に、緊急に対応が必要
    • 既に攻撃が発生している等の、緊急な対応が必要なものを想定
      • CISA Known Exploited Vulnerabilities Catalogに掲載されたもの、等
  • Out-of-Cycle
    • 定期メンテナンス外、で対応が必要
    • メンテナンス時期まで放置はできず、Immediate程ではないが早めに対応すべきもの、等
  • Scheduled
    • 定期メンテナンスで対応
    • 直近で攻撃が行われているわけではないが、放置するわけにもいかないもの、等
  • Defer
    • 保留
    • 脆弱性による影響が軽微と考えられ、リスクとしては許容できるもの、等

判断情報としては目新しいものは無いように見えますが、情報をどのように意思決定に落とし込むか、出力として意思決定が示される、という部分が重要と考えます。
また、決定木を用いていることで再現性のある決定が行え、意思決定プロセスの透明化が図れます。

どのような利点があるのか

SSVCを利用することは、以下の利点があると考えられます。

  1. 意思決定が提示される
  2. 自動化できる
  3. 意思決定プロセスの透明化

決定木により、「対応が必要か/不要か」の先にある「いつやるべきか」まで示される事は大きな利点と言えます。
今までは、自組織で自発的に意思決定ルールを作る必要がありました。これは「どのような時に、どのように対応するか」という標準が示されておらず、適用負担を減らすべく「なるべく対応をしないように判断する」というルールになりがちでした。
SSVCでは、標準的な対応として Deployer の決定木を提示している為、本来あるべき姿が提示されています。運用上提示されている決定木では適用が難しい場合に、標準からカスタマイズする、という方法で変更ができます。これにより、標準的な対応から変更していることが認識できます。

自動化については、決定木の分岐点(Decision points)を2つに分類することで可能と考えられます。

  • あらかじめ定義しておく
    • システムの特性などは、あらかじめ決めておけばその値が使えると考えられます。
      • ExposureやValue Density等が該当します。
  • 自動的に取得する
    • 攻撃コードの有無等の情報は自動化できます。
      • Exploitation, Automatable等が該当します。

自動化によるメリットは改めて言うまでもなく、運用負荷が減少する点です。あらかじめ自動である程度判断がされたものを、人間がその他の情報をもって最終的に決定する（若しくはこのプロセスが省けるほど自動化ができる）、のが理想と考えられます。

意思決定プロセスの透明化は、決定木を用いていることで再現性のある決定が行え、意思決定プロセスを追跡ができることを示します。人に依存する決定が含まれないことで、「本来はどのようにすべきか」が明確に示されます。
また、outcomesを基に独自の判断をした場合も、本来行うべき対応がガイドとして示されているので、意図的に判断したと分かります。

SSVCを適用する

例として、CVE-2019-19781 (Citrix製品の脆弱性) について見てみます。

今回は、インターネットに直接公開されているCitrix Gatewayとして考えてみます。(任意のコード実行の脆弱性です)

従来の判断

情報源として、NVDやMitreの情報を見ることになります。

日本語の情報源として、JPCERT/CCやIPAを参照します。

基本的な判断基準として BaseScore 8.0以上を対応する としていた場合、以下の決定が導き出せます。

  • 基本的な対応方針
    • BaseScore 9.8である為、緊急に対応すべき
    • 但し、その他の情報で軽減ができないか考える
  • その他情報で軽減が可能か
    • Vector値
      • ネットワークから自動で簡単に攻撃ができ、影響がおおきい(機密性、完全性、可用性)
      • 軽減不可と思われる
    • Environmental Metrics(環境評価基準)
      • CVSSでの実際の対応では、あまり使われていないと思われます。
      • 機密性/完全性/可用性において、対象システムのセキュリティ要求度でBaseScoreを軽減します
        • 評価基準としては「未評価」「高(H)」「中(M)」「低(L)」があります。
        • 「何をもって中とする」が示されない為、定義することが難しいと考えられます。
        • これがすべて「Low」と仮定しても、CVSSの再計算上は8.0であり、対応必須となります。
        • 実運用上、インターネットに面しているCitrix Gatewayを全て「Low」と判断することはありえないと思われます
      • 実質として、CVSSの再計算をしても軽減はできないと考えられます

今までの検討から、BaseScoreは9.8 Criticalである、という情報から意思決定をする必要があります。
10.0点中9.8であり、攻撃も観測されていることから、緊急で対応すべきという人的判断がされます。
しかしながら、この判断は人によってブレることはないでしょうか。人的意思が意思決定をしており、人によっては異なる判断になる可能性はあります。

SSVCでの判断

SSVCの決定木を、順番に見ていきます。
CERTのデモンストレーションサイトである https://democert.org/ssvc/ を見ながら確認すると良いでしょう。

  • Exploitation
    • 既に攻撃が発生している事が、前述のサイトを見るとわかります
      • None
        • 積極的な悪用の証拠はない
      • PoC(Proof of Concept)
        • 1.Exploitが限られた場所で取引されている、2.MetasploitやExploitDB等でPoCが公開されている、3.悪用方法が良く知られている
      • Active
        • Exploitが既に攻撃者により使用されているという、信頼できる証拠がある
    • active が選択されます
  • Exposure
    • システムが置かれている環境を選択します
      • small
        • ローカルサービス/プログラム。高度に制御されたネットワーク。
      • controlled
        • いくつかのアクセス制限及び緩和策が実施されているネットワーク。
      • open
        • インターネットまたはアクセスを制限または制御できない可能性のあるネットワーク
    • open が選択されます
  • Utility
    • Automatable及びValueDensityで判断されます
      • Automatable
        • 自動化の可能性で yes / no を選択します
      • Value Density
        • 価値密度と呼ばれ、攻撃者が単一の悪用で制御可能なリソースにより選択します
        • deffuse
          • 1回の悪用で制御できるリソースは少ない事を示します。
          • 電子メールアカウントや一般的な携帯電話などを意図します。
        • concentrated
          • 1回の悪用で制御できるリソースが多いことを示します。
          • データベースシステムやKerberosサーバ、クラウドサービスプロバイダなどを意図します。
    • 出力として以下が選択できます
      • Laborious, Efficient, SuperEffective
    • Automatable:yes, Value Density:deffuse が想定されます。
    • efficient が選択されます
  • Human Impact
    • 組織のミッションと安全性の影響を1つにまとめて判断します
      • situated safety impact
        • none, minor, major, hazardous, catastrophic
        • “状況に応じた安全性への影響”と訳され、どの程度”安全”への影響があるかを選択します
        • 例示の分類としては”身体的””環境””金銭的””心理的”影響が示されています
        • コンピュータシステムの場合、システムそれ自体というより、システムが侵害された場合の周囲への影響、を対象とします
          • 影響閾値以下、金銭的損失、複数人の破産的金銭的損失、社会的に影響が出る、等の周囲への影響
      • mission impact
        • none, degraded, crippled, mef failure, mission failure
        • 企業としてのミッション（使命や存在意義）への影響を選択します
          • 主に、Mission Essential Function（MEF）を考慮した評価です
          • コンピュータシステムの脆弱性対応という点では、業務継続性という観点で評価してよいと考えます
    • 出力として以下が選択できます
      • none, degraded, crippled, mef failure, mission failure
        • おおよそ、crippledまでは重要な機能を残し対応が劣化、mef failure以上はミッションに不可欠な機能が許容できないほど影響を受ける、と定義できる

まとめ

判断をSSVCに切り替えることで、「いつまでに対応すべきか」という意思決定が自動でできるようになります。
今までのやり方では「対応すべきか」は自動で導出できても、「いつまでにやるべきか」等は人に依存していました。
システムの特性を考慮したうえで「いつまでにやるべきか」を示せるため、運用時の意思決定が楽になると考えられます。

また、SSVCの出力に直接従わない場合でも、「一般的には”すぐに対応するべき(immediate)”物である」という判断ガイドとして利用できます。

現状利用している判断基準と並行してSSVCを使ってみることで、自社に有効かどうかを判断できると考えます。

FutureVulsは本記事で紹介した最新のリスクベースのトリアージエンジン「SSVC」を搭載することで、脆弱性判断から対応指示までを賢く全自動化してます。

SSVCの詳細やFutureVulsの自動トリアージについては下記ページを参照下さい。