[新機能]日々沢山出る脆弱性のトリアージを自動化する「SSVC機能」にFutureVulsが対応したので自動で対応優先度をつけてみた

決定木を元に脆弱性の対応方針を自動で決めることができるSSVC設定を使い、FutureVulsが自動でトリアージをサポートできるようになりました。これでまた人に依存した工程がなくなって業務に集中できますね！

#FutureVuls

#セキュリティ

#Vuls

#AWS

臼田佳祐

2022.09.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、脆弱性管理してますか？(挨拶

今回はめちゃくちゃイケてる脆弱性管理ソリューションであるFutureVulsの新機能を試してみたのでこちらの紹介です。

FutureVulsと脆弱性管理

久しぶりのFutureVuls記事なのでかんたんに紹介します。

みなさんは管理しているITインフラストラクチャの脆弱性をどのように管理していますか？

脆弱性管理のためには資産(サーバーなど)のリストとインストールしているパッケージのバージョンのリストが必要ですね。例えばサーバーリストをExcelの表にまとめて管理していますか？あるいは資産管理ツールやAWS Systems Manager Inventoryで自動収集していますか？それとも全くやっていないでしょうか？

これらの情報を収集したら、今度は日々沢山出てくる脆弱性情報と突き合わせていく必要があります。JVNやNVDなどのRSSから日々情報を収集していますか？あるいはTwitter？それとも何も収集していないでしょうか？

この資産の管理と脆弱性情報の収集をめっちゃいい感じにやって明確に対応する脆弱性を洗い出し、タスクを管理できるのがFutureVulsです。脆弱性管理のプラットフォームです。

とにかく脆弱性を洗い出し管理できる仕組みと、日本語で利用できる丁寧な脆弱性情報を扱えることが強いほか、AWSとSystems Managerを利用した連携ができるなど運用まで頼れる素晴らしいサービスです。

SSMとの連携は下記も参考になるのでぜひご確認ください。

これまでの脆弱性管理

今回FutureVulsは新機能に対応したわけですが、その背景を説明します。

既知の脆弱性を収集して自身の環境に対して洗い出すと、多数の脆弱性のリストが出来上がります。そのため優先順位の高いものから対応していきたいわけですが、この対応方針の判断が難しいです。従来は脆弱性の重要度を表すCVSSを利用し脆弱性を並べて、このスコアを参考に優先度を考えるわけですが、これは実際の環境をスコアに反映していないことや、どう対応すべきか示していないため、CVSSを読み解き脆弱性を理解しつつシステム側も勘案して対応方針を立てる必要がありました。

この脆弱性は次のパッチ適用のタイミングで良いのか？
優先して影響の調査を始めたほうが良いのか？
危険すぎるので業務に影響があっても早急に対応すべきなのか？
などなど

つまり熟練の知識やテクニックが必要とされていました。

正確にはCVSS v3には環境評価基準 (Environmental Metrics)というこの判断を助けるスコアリングの手法が設けられていましたが、CVSSは脆弱性を評価するところまでがスコープであるため、どちらにしろ対応方針の決定打にはならず、最後の判断は対応する個人任せでした。

SSVCによる対応方針の決定

実運用上では脆弱性の評価を行ったあとは必ず対応方針を決めていくため、これを迅速に回す仕組みが必要になりました。

そこで2019年12月、米カーネギーメロン大学ソフトウェア工学研究所によってSSVCが提案されました。SSVCでは4つのDecision Pointと呼ばれる入力を決定木に入れると、4つのSSVC Priorityと呼ばれる対応レベルが導出される仕組みです。以下のような図になります(引用元)。

対応レベルは下記4つで、主に対応までのリードタイムを決めています。シンプルでわかりやすいですね。

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

これを決めるための決定木は長いですが以下のようになっています。(これはDeployer向け)

諸々参考:
- 米カーネギーメロン大学ソフトウェア工学研究所公開のSSVC論文
- SSVC（Stakeholder-Specific Vulnerability Categorization）を活用した脆弱性管理 | PwC Japanグループ

この導出のための入力であるDecision Pointは下記4つです。脆弱性の情報と環境の情報を扱っていますね。

システムのNW環境
システムの業務影響
実際の攻撃状況
攻撃者目線の利用価値

この4つを求めれば決定木により対応方針が固まるというわけです。意思決定がスムーズにできますね。

FutureVulsにおけるSSVC対応

FutureVulsではもともと脆弱性情報を収集し、CVSSの値などはもちろん、そのPoCが存在しているかや実際に悪用されているかなどもすでに材料として揃っている状況です。つまり、更に環境の情報を与えてあげれば、SSVCを利用した対応方針の判断が完了します。そしてFutureVulsではそのまま脆弱性をタスクとして対応の管理ができますので、優先順位が決まったらあとは対応していくだけです。

脆弱性管理のプラットフォームとしてSSVCと非常に相性がいいですね！

実際にSSVCで判断した内容は以下のように表示されます。判断根拠が明確にできていいですね！

FutureVulsではシステムをグループという単位でまとめて管理できますので、グループ毎にDecision Pointの環境部分に対する値を決めておけば、自動でトリアージが可能です。

最初に設定しておけば、あとは自動で対応方針が決まるので、トリアージに時間をかけずに優先度の高いタスクから着手できます。

やってみた

実際にFutureVulsでSSVCを有効化し、トリアージしてみます。参考ドキュメントは以下です。

なお、SSVC機能はCSIRTプランのみ対象です。

オーガニゼーション設定

まずオーガニゼーション設定から全体で有効化を行います。有効化ボタンをポチッと。

有効化すると、オーガニゼーション全体でのSSVC Priorityに対する具体的な優先度や対応期限を決めていきます。

一番優先度の高いimmediateに対して、今回はタスクステータスをnew、優先度をHIGH、対応期限を1日としました。immediateは「全てのリソースを集中し必要に応じて組織の通常業務を停止して可能な限り迅速に対応する」というレベルですから、これぐらいになりますね。このあたりは組織の状況などを反映させると良いと思います。

続いてout of cycleについてステータスと優先度はimmediateと同じで、期限を7日としました。scheduledが次のパッチ適用のタイミング、という感じになるので、この期限はパッチ適用の間隔より早い日数で検討すると良さそうです。

今回はこの2つだけ設定しました。ちなみにscheduledとdeferは対応期限にcron式を入れるようになっており、定期パッチのサイクルなどを表現できるようになっています。

グループ設定

続いてグループ設定です。システム単位の設定と考えるとわかりやすいでしょう。

こちらでは環境の状況を表すDecision Pointを設定します。先程4つあると表現しましたが、Utilityを表すために2つの値を使うので実質5つの入力値があります。この内FutureVulsが2つを脆弱性から自動的に導出するので、利用者は3つ設定すればOKです。それぞれ以下の値から選択します。

Exposure: 脆弱なコンポーネントの露出レベル
- small: ローカルサービスや高度に制御されたネットワーク上のシステム
- controlled: 攻撃を検知でき十分な速さで対応できる制御されたシステム
- open: インターネットから制限なしにアクセス可能なシステム
Utility Density: 対象システムの価値密度
- diffuse: 重要情報が集中していない（例：社員PC）
- concentrated: 重要情報が集中している（例：サーバ、データベース）
Human Impact: 攻撃された際の業務影響
- Low: 影響がほぼない(例：PC, 開発環境)
- Medium: 基幹業務には影響がない（例: 勤怠管理システム）
- High: 一つの基幹業務に長期間影響が出る（例: 一つの基幹システム、一つのWebサービス）
- Very High: 複数の基幹業務が停止し会社全体の基幹業務が続行不能で回復不能になるような超重要システム。（例：オンランバンキングやトレーディングシステムなど）

デフォルトでExposure: open、Utility Density: concentrated、Human Impact: highとなっていて、今回はこのままで良かったので特に変更しませんでした。

その下にはオーガニゼーションで設定したSSVC Priorityに対するアクションのオーバーライドがありますが、今回は特に変更しませんでした。また、決定木のカスタマイズもオーガニゼーションとグループでそれぞれできるようになっています。決定木の結果を自社のポリシーで調整したい場合に活用できます。

ここまででSSVCの設定が完了です。かんたんでしたね。

SSVC Priorityの適用

実際にSSVCを使っていきます。今回はすでにサーバー(EC2)が登録された環境を用意しています。SSVCの設定後は一度スキャンが実行されないとSSVC Priorityが反映されないため、グループ設定から「全サーバを手動スキャン」することでその代わりとします。以降はスキャンで新しいものが出てきたら自動的にSSVC Priorityが反映されていきます。

SSVC Priorityを利用したトリアージ

スキャンが終わると各脆弱性と対象サーバーをかけ合わせた脆弱性対応タスクに対してSSVC Priorityが割り当てられ、今回設定しておいたimmediate(緊急対応)が割り当てられたタスクには自動的にタスク優先度と対応期限が設定されました。SSVCの根拠も詳細で確認できました。どのような意思決定によりこのSSVC Priorityになっているか確認できます。機能有効化後しばらくは、このあたりを眺めながら、実際の自分たちの決定木とギャップがないか確認して調整する作業が必要かもしれません。

タスクは担当者をアサインしたりできるので、このままアサインして進めても良いのですが、脆弱性管理画面でもどう見えるか確認します。こちらでは新しくSSVC PriorityがImmediateやOut of Cycleに設定されたタスクの件数を表示する列が追加されています。この列を一番左に持ってきてみました。この値を使ってソートすると、優先的に見ていくべき脆弱性を把握しやすそうです。