FutureVuls Blog

SSVC Supplier Treeの概要と自動化 | 製造業における脆弱性管理の課題と対応方法

image.png

2024年7月12日に開催された「製造業における脆弱性管理の課題と対応方法@大阪」セミナーの「SSVC Supplier Treeの概要と自動化」セッションのスライドです。

米国CISAが推奨する脆弱性管理の優先順位付け手法であるSSVC(Stakeholder-Specific Vulnerability Categorization)の概要を説明し、PSIRT用の決定木であるSupplier Treeを紹介します。SSVCは脆弱性をリスクベースで優先度付けするフレームワークですが、そのまま組織に適用すると人的工数と専門知識が必要です。講演者はSSVCの導入には自動化が肝要であると考え、自動化の方法を模索しています。本セッションでは、SSVC Supplier Treeを用いて製造業のPSIRTの脆弱性トリアージを自動化する方法を探求します。具体的には、Supplier Treeの各Decision Pointを分解し、最近CISAから公開されたNVDを補完する脆弱性情報「Vulnrichment」などのデータソースとロジックを共有し、自動化のための現実的な実装方法を模索します。

現状の脆弱性管理の課題

自己紹介

Xでのジョーシスな誰かのつぶやき(抜粋)

ランサムウェアのニュースで騒がれている中、X(旧Twitter)にジョーシスな人の心の叫びを目にしました。今回参加されている製造業のPSIRTの皆さんも普段の脆弱性管理で似たような悩みを抱えているのではないでしょうか。

公開される脆弱性は年々増加

大量の脆弱性が公開され、その数は年々増えています。2024年は年間で4万件を超えそうな勢いで増えており、前年比で40%も増加傾向です。

おさらい:脆弱性の深刻度を示すCVSSスコア

ご存じの通り、脆弱性はCVEというIDがつけられます。CVEはCVSSと呼ばれる脆弱性の深刻度を「0-10」で計算した値がセットで公開されます。Log4Shell(CVE-2021-44228)のスコアは最大の「10」がつけられています。

CVSSスコアでの絞り込みについて

優先度付けのためにCVSSスコアでフィルタすれば良いと考えるかもしれませんが、公開されている全てのCVEの半数は「HIGH」と評価されています。
脆弱性の半分が「重要度HIGH」であり、CVSSスコアだけでは対応可能な数まで絞り込めません。
スコアだけではなくCVSS Vectorも使って絞り込んでみても、「9以上かつインターネット経由で権限なしで攻撃可能」な脆弱性が「1.4万件」もヒットしてしまいます。

このようにCVSSのスコアとCVSSの詳細情報でフィルタしても対応可能な数まで絞り込めないのが実情です。

CVSSスコアと武器化の関係

また、CVSSスコアが高いものだけが実際の攻撃に使われるわけではありません。CVSSスコアが低いものにも攻撃コードがあり、安全とは言えません。以下のデータを見ると、CVSSスコアが「4.0-6.0」の「Medium」な脆弱性にも悪用されているものがあります。

実際に攻撃に使われる脆弱性とは

それでは、実際に攻撃に使われている脆弱性はどれくらいあるのでしょうか。
以下のデータを見ると、実際に攻撃に使われている脆弱性は「2-4%未満」だそうです。
当然ですが、実際に攻撃に使われているものは特に危険なため最優先で対応する必要があります。
しかし、CVSSスコアは攻撃に使われる脆弱性を予測したり脅威の大小の判断はできません。

リスクを考慮した脆弱性管理とは

「リスク」についておさらいしましょう。リスクの3要素は「脆弱性」「脅威」「影響」です。脆弱性管理では組織の対応力が限られるため、高リスクな脆弱性から順番に対応する必要があります。
つまり、重大な脆弱性、かつ実際に悪用されている、かつビジネスに影響の大きいものから優先的に対応していくのが理想です。
では、この高リスクな脆弱性を具体的にどうやって絞り込めば良いでしょうか。何か良い方法があるでしょうか。

リスクを考慮した脆弱性管理が可能なSSVC - Stakeholder-Specific Vulnerability Categorization

SSVC (Stakeholder-Specific Vulnerability Categorization)は、カーネギーメロン大学によって考案され、米国のCISA(Cybersecurity and Infrastructure Security Agency)でも利用されているリスクベースの優先度判断フレームワークです。参考: CISAのサイト

SSVCは『リスク = 脆弱性 x 脅威 x 影響』に相当する情報を元に決定木を用いて脆弱性の対応優先度を4段階に決定できるフレームワークです。

2024年7月現在、以下の役割ごとに異なる決定木が用意されており、利用者の立場に応じて利用する決定木を使い分けます。

  • CERTや企業のリサーチャー向けの 「Coordinator Tree」
  • システム運用者向けの「Deployer Tree」
  • パッチ提供者向けの「Supplier Tree」

3つの決定木については「デモ」で詳細を確認できます。この決定木を「あみだくじ」のように辿っていけば、検知した脆弱性の対応優先度が4段階で決定できます。

下のスライドの図はDeployer Treeです。次のセクションではシステム運用者用の木である「Deployer Tree」について紹介します。
(本記事のメインテーマであるパッチ提供者向けの木「Supplier Tree」はDeployer Treeの後で解説します。)

スライド内のリンク:

システム運用者向けのSSVC Deployer Tree

SSVC Deployer Treeの概要

システム運用者向けの決定木である「デプロイヤー」では、以下の4つを用いてリスク(脅威 ✕ 脆弱性 ✕ 資産重要度)を計算し、対応優先度を4段階に判別します。

リスクの種類 Decision Point 説明
脅威 Exploitation 既知のエクスプロイトの存在や攻撃のアクティブさで判断されます。
脆弱性 Utility 対象システムが保持する価値や、攻撃がツールなどにより自動化可能かで判断されます。
資産重要度 Human Impact 脆弱性が人命やビジネスに与える影響を評価します。
- Exposure 脆弱性の存在する資産がどの程度インターネットに露出しているかを評価します。

SSVC Deployer Treeの決定木

SSVC Deployer Treeの各Decision Pointはリスクの3要素をカバーしており、リスクを総合的に判断可能です。

スライド内のリンク:

SSVC Deployer Treeの効果

5つの環境を想定して、4,716件の脆弱性をSSVC Deployer Treeで分類してみました。インターネットに公開された重要システムを見ると、緊急対応「immediate」と早対応「out-of-cycle」が「1.4%」まで絞り込めました。インターネットに公開されていない社内システムはさらに絞られ「immediate」は0件になりました。緊急、重大な脆弱性に対して必要以上に即時対応する事態は解消され、現実的に対応できる数に絞り込めています。

SSVC Deployer Treeの導入事例

FutureVulsのSSVCを用いて脆弱性管理を自動化し、社内数千台のサーバの脆弱性管理をわずか数名で運用している事例が公開されています。詳細は、「Log4Shell のような経験はもう二度としない ~ SSVC が搭載された FutureVuls を活用し、現実的な脆弱性管理を実現 |株式会社マイナビ」を参照してください。

パッチ提供者向けのSSVC Supplier Tree

SSVC Supplier と Deployer の比較

これまでは「パッチを適用する運用者」向けのDeployer Treeについて説明しました。ここからは「パッチを提供する立場」向けのSupplier Treeについて見ていきましょう。

左側がSupplier Treeで、右側がDeployer Treeです。見比べると、Supplierの方がDeployerよりもimmediateout-of-cycleの数が多いことがわかります。これは、Deployerが対応するためにはSupplierがパッチや回避策を提供しなければならないため、Supplierの対応を急ぐ必要があることを示しています。

SSVC Supplier Treeの概要

Supplier Treeは、パッチを提供するサプライヤーが、自社のソフトウェアの脆弱性に対するパッチ作成の優先順位を決定するための意思決定モデルです。

ある1つの脆弱性を入力として、「Exploitation」「Utility」「Technical Impact」「Public Safety Impact」の4つの項目を評価し、「脆弱性 × プロダクト」における4段階の対応優先度を出力します。

SSVCのSupplier Treeの特徴は以下のとおりです。

  • 判断理由がわかりやすい
  • 木のカスタマイズも可能
  • 自動化可能

スライド内のリンク:

SSVC Supplier Treeの決定木詳細

SSVCの各Decision Pointはリスクの3要素をカバーしており、リスクを総合的に判断可能です。

スライド内のリンク:

本家サイト「カーネギーメロン大学 SSVC 公式サイト>Supplier Decision Model」も参照してください。

SSVC Supplier Treeのデモ

次ページより、SSVC Supplier Treeでパッチ提供・回避策提供のための優先度を判断してみましょう。
SSVCの決定木を実際に試す際は、SSVC公式サイトの「Dryad - SSVC Calc App」で木を辿ってグラフィカルに判断できます。

DyradでSupplier Treeを使う際は、右上の「Deployer」を「Supplier」に変更する必要があります。

デモ: IP CameraのDoSの脆弱性 (Supplier目線)

最初のデモは、IP Cameraの脆弱性について、サプライヤ側のパッチ提供・回避策提供の対応優先度を見ていきましょう。

CVE-2019-18228を見ると、細工されたHTTPリクエストでサービス拒否状態になる脆弱性です。
CISA SSVC On Demand Trainingでもこの脆弱性をSSVC Supplier Treeでトリアージしていますので、興味のある方は参照してください。

まずはPoCが公開されていない状況を想定してSupplier Treeを辿ってみます。
前のページの判断ロジックを参照しながら判断してみましょう。

  • PoCがまだ公開されていない想定なのでExploitationはnone
  • インターネット経由でサービスと脆弱性を発見可能であり、インターネット越しに権限なしで攻撃可能なのでAutomatableはYes
  • 一般的にIP Cameraは重要な情報を持っていないため、Value Densityはdiffuse
  • DoSなのでTechnical Impactはpartial
  • IP Cameraがサービスを停止しても影響は限られるため、Public Safety Impactはminimal

これらの評価により、パッチ提供と回避策の提供の優先度はScheduled(次回の定期パッチ提供時でOK)となりました。

状況が変わり、インターネットにPoCが公開された場合や、実際の攻撃が観測された場合に、サプライヤとしての対応の優先度がどのように変わるかを見てみましょう。

SSVC Supplier Treeによると、

  • PoCが公開された場合はScheduledのまま
  • 攻撃が観測された場合はout-of-cycle(パッチ提供サイクルの前に対応)となります。

同じ脆弱性・同じプロダクトであっても、脅威の状況に応じて対応の優先度が変わることがわかります。

デモ: Microsoft DefenderのRCE (Supplier目線)

次は、Microsoft Defenderの脆弱性について、サプライヤ側のパッチ提供・回避策提供の対応優先度を見ていきましょう。

CVE-2021-1647は、Microsoft Defender Malware Protection Engineに存在するリモートコード実行の脆弱性で、特別に細工されたファイルをスキャンするとそのPC上で任意のコードを実行できてしまうというものです。

CISA SSVC On Demand Trainingでもこの脆弱性をSSVC Supplier Treeでトリアージしていますので、興味のある方は参照してください。

まずはPoCが公開されていない状況を想定してSupplier Treeを辿ってみます。
前のページの判断ロジックを参照しながら判断してみましょう。

  • Vulnrichmentにはまだ存在しない
    • Vulnrichmentに存在する場合は、Exploitation、Automatable、Technical Impactの値が利用できます。
  • PoCがまだ公開されていない想定なのでExploitationはnone
  • AV:Lであり、KillChainの1.偵察が自動化できないのでAutomatableはno
  • Windows Serverを想定するとValue Densityはconcentrated
  • Technical ImpactはRCEなのでtotal
  • Public Safety Impactはminimal
    • 一般的にWindowsは安全性が重要な環境に適しているとは説明されていない(意見が分かれるところですが、CISAの動画でも言及されています)。

これらの評価により、PoCが公開される前の時点ではパッチ提供と回避策の提供の優先度はScheduled(次回の定期パッチ提供時に対応)となりました。

PoCや攻撃が観測された時点での判断はどのようになるでしょうか。

実はこの脆弱性は、実際にCISA Known Exploited Vulnerabilities Catalogに掲載されている脆弱性です。 Known Exploited Vulnerabilities Catalogについては、CISAのサイトを参照してください。 KEVに登録されたということは「実際に攻撃に活発に利用されている」ということですので、ExploitationがActiveと判断されます。

SSVC Supplier Treeによると、

  • PoCが公開された場合はScheduledのまま
  • 攻撃が観測された場合はout-of-cycle(パッチ提供サイクルの前に対応)となります。

同じ脆弱性・同じプロダクトであっても、脅威の状況に応じて対応の優先度が変わることがわかります。

デモ: ワイヤレスルータのRCE (Supplier目線)

次は、ワイヤレスルータのRCEについて、サプライヤ側のパッチ提供・回避策提供の対応優先度を見ていきましょう。

CVE-2023-26801は、ワイヤレスルータに対して巧妙なリクエストを送信することでRCEが可能となる脆弱性です。悪用されると、不正アクセス、デバイスのセキュリティ侵害、ラテラルムーブメント(横方向の移動)が発生します。この脆弱性はMiraiボットネットに利用されています。詳細はこちら

  • ShadowServerによると、2024年7月16日時点でこの脆弱性は活発に悪用されているため、ExploitationはActiveと判断します。
  • KillChainの1-4.偵察が自動化できるのでAutomatableはyes
  • ルータのRCEであり、ネットワークに侵入される可能性があるため、Value Densityはconcentrated
  • Technical ImpactはRCEなのでtotal
  • Public Safety Impactはminimal
    • 一般的なワイヤレスルータの用途を想定

これらの評価により、現時点で悪用が確認されている場合、パッチ提供と回避策の提供の優先度はimmediate(即時対応)となりました。

デモ: OpenSSHのRCE regreSSHionの場合

CVE-2024-6387は、OpenSSHサーバー(sshd)の脆弱性で、特権でリモートから認証なしの任意コード実行をされる恐れがある脆弱性です。

製造業のPSIRTの立場から、自社製品のうち該当するバージョンのOpenSSHが組み込まれた製品が対象となります。

  • この脆弱性はVulnrichmentに情報がありますので、その情報を使います。
    • “Exploitation”: “poc”
    • “Automatable”: “no”
    • “Technical Impact”: “total”
  • EPSSが37%と高い値(2024年7月16日時点)なので、Activeと判断しても良いでしょう。
  • Value Densityは該当する自社プロダクトごとに判断します。
  • Public Safety Impactも自社プロダクトごとに判断します。

Public Safety Impactが「minimal」の場合と「significant」の場合でどのような判断となるかをスライドにまとめました。結果を見ると、「significant」は対応の優先度レベルが1段階上がることがわかります。

デモ: インスリンポンプの脆弱性 (Supplier目線)

最後は、生命に影響があるインスリンポンプの脆弱性について見てみましょう。
CVE-2022-32537は、近隣ネットワークから権限のないユーザがインスリンポンプの量をコントロールできる脆弱性です。PoCがまだ公開されていない状況を想定してSupplier Treeを辿ってみます。参考:ICS MEDICAL ADVISORY

  • PoCがまだ公開されていない時点を想定しているのでExploitationはnone
  • AV:Aであり、KillChainの1.偵察が自動化できないのでAutomatableはno
  • 機器自体の価値密度はdiffuse
  • Technical ImpactはRCEではないのでpartial
  • Public Safety Impactは生命の危険があるのでsignificant

これらの評価により、PoCがない現時点ではパッチ提供と回避策の提供の優先度はscheduledとなりました。

まとめ

本講演ではSSVCのシステム運用者向けのDeployer Treeの概要と、パッチ提供者向けのTreeであるSSVC Supplier Treeについて紹介しました。
SSVCのSupplier Treeを用いることでリスクに応じてパッチ提供や回避策の提供のための対応優先度を判断できることがおわかりいただけたと思います。

FutureVulsはCSIRTはもちろん、PSIRTの脆弱性管理業務についても自動化を模索していきます。

資料請求、無償PoC、詳細なデモ、脆弱性管理のお悩み相談などは、Vulsのランディングページよりお気軽にお問い合わせください。