はじめに
ここ最近脆弱性管理についてずっと考えていたのですが、SSVCを知ってからというもの、かなりシンプルに考えられるようになりました。試み自体はまだ途上なのですが、以下のようなことを目的として、SSVCの概要や、現時点での経過や私の考えを文字に起こしてみます。
SSVCとは？
Stakeholder-Specific Vulnerability Categolizationの略。CERT/CCが考案した脆弱性管理手法です。CVSSが「脆弱性の評価手法」であることに対して、SSVCは「脆弱性対応方針の判断手法」であると言えます。
たぶん今一番分かりやすい解説ページ。PWCだいしゅき！
実際の資料は、CERT/CCのGitHubリポジトリ内にあるファイル名に日付が降ってあるPDFのうち、一番新しいのを見るといいと思います。
（2022-12-24追記） OSS脆弱性管理製品である「FutureVuls」の開発元がSSVCの和訳を公開してくれています。ありがたや🙏原文も割と平易な表現で書かれていると思いますが、英語に抵抗がある方や時間がない方はこちらをおすすめします。
FutureVulsはたぶん世界で初めて、そしてたぶん現在世界で唯一のSSVCによる脆弱性評価を実装した鬼🆒な製品なので、脆弱性とかあんまよく分からなーいという方は、一度トライアルしてみるといのではないかと。
よくある脆弱性対応方針の判断（n=1）
私の脆弱性情報収集から対応方針判断までのフローは、だいたいこんな感じです。
- JPCERT/CCの注意喚起やTwitterで騒がれている脆弱性情報をキャッチする
- この時点で明らかにアチアチなこともある→即対応
- CVSSの基準値とAVを見て、大体のアツさ（=精読するかどうか）を判断する
- AVはNだったら激アツ、LやPだったらひとまず安心しちゃう（よくない）
- AC、C、I、Aあたりを見て、最終的な方針を決める
- 「cve-xxxx-xxxxx poc」でググってみる
- 「site:github.com」を付ける場合もある
人力かつ判断基準が明らかでないところが、属人化を招く点や説明性が低いという点でよくないと思っています。でもきっと多くの方がこんなもんだと思うんですよね……ちがう？
CVSSが全てじゃないよね
CVSSは脆弱性評価手法としてよく整理されていていい感じなのですが、判断基準が曖昧とか、現状評価基準の評価があんまりされていないとか、シブいところもあったりします。特に現状評価基準が運用されていないというのは、昨今の脅威ベースアプローチブームと矛盾してませんか？何なんすか一体。
……『脅威インテリジェンスの教科書』を拝読してからというものニワカ脅威インテリ厨なもんでイキってしまいましたが、きっと業界の先達にとって、脅威ベースの考え方は昨日今日始まったものではありませんよね。『脅威インテリジェンスの教科書』、めちゃいい本なので読んで欲しいです。
SSVCのココがすごい！
そこで脆弱性管理界のジャンヌ・ダルクことSSVCの登場です。SSVCの推しポイントを列挙します。
アウトプットが具体的なアクションである
CVSSのアウトプットがスコアや各属性の評価であることに対して、SSVCのアウトプットは脆弱性に対するアクションです。具体的には以下の4通り。
- defer（静観）
- scheduled（計画対応）
- out-of-cycle（計画外対応）
- Immediate（緊急対応）
アクションの判断基準を明確に提示している
SSVCは、アクションを導き出すまでにどういった判断材料があるのかを提示してくれています。我々のようなパッチを当てる立場、SSVCでいうDeployerの場合は、以下の4つです。それぞれが3〜4段階の分類を持ちます。
- Exploitation（脆弱性の悪用実績やPoCの公開状況がどの程度か）
- Exposure（システムの公開度合いはどの程度か）
- Utility（脆弱性の有用性=悪用によって得られる対価 * 悪用（自動化）のしやすさ）
- Well-being and Mission Impact（悪用された時のインパクト）
Deployerの判断木を見てみましょう（最新の資料ではPDF35ページ目）。見てもらうとわかる通り、4つの質問に答えた結果は予めプロットされています。要するに、「Exploitationは？」「Exposureは？」「Utilityは？」「Human-being and misson impactは？」という4つの問いに答えることで、「その脆弱性にどう対応すべきか？」という問いの答えが導かれるわけです。
ある架空の脆弱性の対応方針をSSVCに沿ってやってみると、こんな感じです。
- 調べたらGitHubにエクスプロイトが公開されていた、そのまま悪用に転用できそう
- →Exploitation = active
- 対象システムはインターネットから隔離されている
- →Exposure = small
- 悪用されたら機密情報抜かれるし、自動化も容易そう
- →Utility = super effective
- 悪用されたらマジでエグい
- →Well-being and Mission Impact = very high
結果はout-of-cycle、「優先度を上げて計画外対応をしよう！」ということになります。
このことには、以下のようなメリットがあります。
- 判断基準や経緯の説明がしやすい
- 最終的な対応判断がプロット済みである
- 一番迷うところ（決めの問題、とよく言われる部分）を考えなくてよい
- やってみて違うならいじればいい
- 実状と乖離した結果が出た場合に、調整しやすい
ついでに、これらの判断基準は、脆弱性に関わる複数の立場に対して異なるものが提示されています。
- Supplier（パッチを作る人、メーカー）
- Deployer（パッチを当てる人、利用者）
- Coodinator（……誰？）
ここまでのまとめ: SSVCは関数、CVSSは引数
前述の通り、CVSSはあくまで「脆弱性の評価手法」であって、そこから対応方針を導き出すための判断基準は、セキュリティ担当者が用意しなければなりませんでした。SSVCはまさにその基準になるわけです。CVSSをはじめとした脆弱性情報を引数、SSVCを関数の関係にプロットすると理解しやすいです。そう私は思っているんですが、図にすると途端に陳腐になるのなんなの？
運用するために必要なこと
最後に、SSVCを運用していくためにやらなければならなさそうなことを列挙します。
action毎の具体的な対応期限を決める
まずはscheduled、つまり脆弱性の計画対応はどれぐらいの期間毎にやるのかが決まっていないと、計画も計画外も緊急もないので、これらばかりは決めるしかありません。決めましょう。
判断ポイントの判断基準を決める
Exposureは（controlledの判断は迷うところですが）ほぼ自ずと決まるので置いておくとして、Exploitation、Utility、Well-being and Mission Impactを何に基づいて決めるかを決めなければなりません。
原著には「SSVC using Current Information Sources」という節がありまして、要するに「各判断ポイントにおける判断材料として、既存の情報源が一定有用である」といったようなことが書いてあります。個人的にこんな感じでいいんじゃないというのを書いておくので参考まで。
Exploitation
Exploitationの評価はactive > poc > noneで、脆弱性データベースが主な情報源です。個人的にはここでの評価が最も重要だと思っています。
- GitHubやExploit-DB、VulnDBを見てみる
- 単なるPoCに留まるならpoc
- 即・悪・用な感じならactive
- JPCERT/CCの注意喚起で、既に悪用が観測されているならactive
- CISAのKnown Exploited Vulnerability Catalogに載っていたらactive
Utility
Utilityは Automatable（自動化できるか）とValue Density（得られる対価）で決まります。AutomatableについてはCVSSのACやUIを参考にしてもいいですし、コードがあるということを一定自動化の余地があると解釈して、Exploitationの判断結果を流用してもいいと思います。Value Densityは、CVSSのCIAを参考にするといいのではないでしょうか。
Well-being and Mission Impact
CVSSのCIAがよさそうだと思っています。
判断を自動化する
全脆弱性をあのクソデカ判断木を見ながらトリアージするのはきっとしんどいので、コードにルールベースで判断させて、最初のうちは人間が目検して過小評価・過大評価が起きていないかを確認しながら調整していく必要がありそうです。自動化するためには、「判断ポイントの判断基準を決める」で、ある程度自動化を見越した基準を定めなきゃならないですね。
また、PoCの公開のような状況の更新に伴う判断のし直しも、考慮に入れなければなりません。これについても、定期的な脆弱性情報の更新、および状況の変化をトリガーとした再評価までが自動で行われてほしいです。
さいごに: 調整する
とりあえず決めて、回してみて、うまくいかなければ調整しましょう。調整しやすいというのもSSVCのいいところですから（自戒）。
