こんにちは、Xイノベーション本部 ソフトウェアデザインセンター セキュリティグループの福山です。
今回は、弊社CSIRTチームの一機能として活動している「脆弱性管理チーム」の活動に関する内容となります。
昨今では、Log4shellやSpring4shellなど、影響範囲の広い脆弱性が後を絶ちません。
これらの緊急度の高い脆弱性情報が公開された場合を想定した、情報収集〜現場対応までのCSIRT目線での模擬訓練を、FutureVulsを含めて実施してみましたので紹介したいと思います。
FutureVulsとは
フューチャー株式会社が開発するOSSの脆弱性スキャナVulsがベースになっており、組織単位で継続的に脆弱性管理するための脆弱性管理サービスです。
参考：https://vuls.biz/
FutureVulsの主な特徴についてピックアップします。
スキャンについて
- 検知精度、検知スピードに優れており、サーバへの負荷が軽い。
- スキャナを導入せずに手動でソフトウェア情報を登録し、管理することも可能。
検出された情報について
自動トリアージについて
脆弱性の危険度合いをスコアで示すCVSSによる従来の評価手法では、以下の点が考慮されていません。- 脆弱性の悪用の容易さ
- 実際の資産が攻撃を受ける環境にあるか
- 資産価値
- 攻撃を受けた際の業務影響度合い
また、現場でどのように対応すべきかの判断がもう一段階必要となってきます。
そこで2019年12月、これらを解決する新しい評価手法「SSVC（Stakeholder-Specific Vulnerability Categorization）」が米カーネギーメロン大学ソフトウェア工学研究所によって提案されました。
SSVCでは意思決定ツリーを用いて「immediate」「out_of_cycle」「scheduled」「defer」の4段階で対応優先度を導出します。
FutureVulsにはSSVCの機能が早くも導入されており、各脆弱性に対して4段階評価で対応優先度が自動で付与されることで、現場の負担を減らすことができます。
参考： SSVC（Stakeholder-Specific Vulnerability Categorization）を活用した脆弱性管理
FutureVulsを導入した経緯
FutureVulsを活用した脆弱性管理チームの緊急時運用フローを確認したい
弊社ではNIST NVD、JVN iPediaから収集した情報と、シートに入力された各プロジェクトのソフトウェア情報を突き合わせ、該当する脆弱性情報の個別周知運用を行っていました。
ただし以下の課題があり、その要件を満たすべく2023年7月よりFutureVulsに本番移行することが決まりました。
<FutureVuls導入前の課題>
事前準備
- 訓練に使用する脆弱性はSpring4Shell(CVE-2022-22965)を採用
Spring4Shellの採用に至った条件は以下 - 事前にプロジェクトに協力を募り、3プロジェクトからの協力を取り付ける
- FutureVulsの擬似サーバを利用し、CPE形式でソフトウェア情報を登録
模擬訓練
模擬訓練の流れは以下となります。
- 情報収集 -> トリアージ -> 全社周知 -> 個別周知 -> 対応状況の確認
なお、全社周知と個別周知の役割の違いは以下です。
| 全社周知 | 個別周知 |
|---|---|
| ・ゼロデイ脆弱性等、CVEが採番される前の段階でも情報をいち早く整理し伝える | ・該当プロジェクトに直接周知することで、対応が必要であることを認識していただく |
| ・影響を受ける条件や、PoCの再現結果を掲載する | ・該当プロジェクトの対応状況を可視化する |
| ・FutureVulsを利用しない社員向けにも周知する |
以上を踏まえて、実際の訓練の内容に移ります。
情報収集
社内で利用されているソフトウェアにおいて、ゼロデイ脆弱性や影響範囲の広い脆弱性情報が公開されていないか、複数のWebサイトでチェックしています。
よく参考にしている情報発信元を紹介します。
- CyberSecurityHelp：独自の脆弱性DBを公開しており、リスク評価、パッチの提供有無、Atack Vector、Public exploit（実際の悪用有無）、Exploit availability（PoC、攻撃コードの有無）、回避策などの情報をタイムリーに提供するサイトで、公開されるタイミングはCVE採番後。
URL:https://www.cybersecurity-help.cz/ - Lunasec：米セキュリティ企業。2021年に公開されたLog4Shellの際にもブログをいち早く公開しており、影響を受ける条件、PoC、回避策などをわかりやすくブログにまとめている
URL:https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/ - Bleeping Computer：脆弱性情報を含む最新のセキュリティニュースをいち早く提供する海外サイト
URL:https://www.bleepingcomputer.com/tag/vulnerability/ - Security Next：脆弱性情報を含む最新のセキュリティニュースを日本語でいち早く提供するサイト
URL:https://www.security-next.com/135304 - piyolog：脆弱性情報を含む最新のセキュリティニュースがわかりやすく日本語で解説されたブログ
URL:https://piyolog.hatenadiary.jp/entry/2022/04/01/065946 - GitHub Advisory Database：GitHub Security Advisoriesで公開された脆弱性や、依存関係を追跡して得られた依存先ソフトウェアの脆弱性を一覧表示する
URL:https://github.com/advisories
ただし、これらはあくまで参考情報ですので、最終的に一次情報源の確認は必須です。 - 公的機関（JPCERT/CC、JVN、IPA、NIST NVD）
- 開発元（今回はSpring）
URL:https://spring.io/security/
トリアージ
これまでの情報を整理した上で、全社周知要否（トリアージ）を2つの観点で実施します。
影響範囲の確認
各プロジェクトにおける利用状況を確認するため、FutureVulsのグループセットからソフトウェア名で検索します。
参考：グループセット内のソフトウェア名検索
| No | RCE | PoC | 開発元の評価 | 緊急度 |
|---|---|---|---|---|
| 1 | 可能 | 有 | 高以上 | 緊急 |
| 2 | 可能 | 無 | 高以上 | 高 |
| 3 | 不可 | 有 | 高以上 | 高 |
| 4 | 不可 | 無 | 高以上 | 中 |
| 5 | 可能 | 有 | 中以下 | 高 |
| 6 | 可能 | 無 | 中以下 | 中 |
| 7 | 不可 | 有 | 中以下 | 中 |
| 8 | 不可 | 無 | 中以下 | 中 |
| 9 | 可能 | 有 | 未評価 | 緊急 |
| 10 | 可能 | 無 | 未評価 | 高 |
| 11 | 不可 | 有 | 未評価 | 高 |
| 12 | 不可 | 無 | 未評価 | 中 |
公表時点では、No.9の「緊急」に該当しました。
トリアージの結果、全社周知が必要と判断したため次のステップに進みます。
全社周知
- 全社周知の準備を進めつつ、MITRE社によるCVE採番状況のチェックもしながら状況変化をキャッチアップします。
URL:https://cve.mitre.org/cve/search_cve_list.html - PoC、回避策の検証
まずはPoCを探すところからですが、例として以下のリポジトリでは、GitHubで公開されているPoCを自動収集しています。
URL:https://github.com/nomi-sec/PoC-in-GitHub/tree/master
当時、実際に対応した際は以下のPoCが出回っており、こちらを実施しました。
LunaSec社も改善に加わっているようです。（※中には悪意のあるPoCを公開しているリポジトリもあるため、コードの中身をよく読んで、社内と隔離されたネットワーク上で実行するようにする）
URL:https://github.com/reznok/Spring4Shell-POC
dockerを利用するため容易に実施できるものになっています。（環境構築に時間が掛かる場合があります）
また、Lunasecによると、脆弱パターンのブラックリストを記載したInitBinderを挿入することが緩和策になると謳っています。 - 全社周知（社内ポータルサイトへのニュース掲載）
内容としては以下の項目をまとめています。- 脆弱性の概要（RCEの可否、PoCの有無も含む）
- 影響を受けるソフトウェアバージョンおよび条件
- 根本対策（パッチ公開情報）
- 回避策（PoCの実施結果）
- 攻撃の兆候がないかログの確認を依頼（SOCがあれば活用）
- 参考情報
- CVE採番後の対応
MITER社から公開されるCVE採番情報を確認したら、以下のチェックおよび対応します。- 公的機関、開発元から情報が公開・更新されているか
- 情報収集の際にチェックした各発信元の情報が更新されているか
- パッチのリリース状況
- 社内ポータルサイトに投稿した記事に追記
個別周知
次に、脆弱性バージョンを利用している該当プロジェクトに対して個別周知、対応期限を設定します。
オーガニゼーショントピック（CVE別にトピックを立てて情報共有できる機能）の投稿
参考：トピックによる情報共有・注意喚起
送信すると、該当するグループの全メンバへメールが発報されます。
また、SlackやTeamsへの連携も可能です。スペシャル警戒タグの設定
こちらの機能を簡単にご紹介します。- 脆弱性単位で独自のタグを付けられる
例えば、「全社周知対象（トピック掲載あり）」や「緊急対応必須」として、ユーザへの情報認識を早めたり、CSIRT側で後から状況を見返す時に便利になると思います。
タグは1つのCVE-IDに対して複数設定できます。 - 対応期限を設定でき、該当タスクの対応期限を一括で上書き更新できる
- CVE検知済みのグループに対して設定された旨の通知ができる（通知の際、コメントは不可）
参考：スペシャル警戒タグ機能
今回の対応期限は判断日の5営業日後としました。
各プロジェクトの脆弱性情報のサマリに警戒タグが入りました。
- 脆弱性単位で独自のタグを付けられる
対応状況の確認
最後に各プロジェクトの対応状況を後追いします。
FutureVulsではタスクステータスを用いて、対応状況を管理できます。
タスク対応の流れは以下です。
引用：ステータス
次のアクションとして、スペシャル警戒タグで設定した対応期限を超過したタスクに対してリマインドします。
対応期限の翌営業日になったら、グループセットのタスクタブから、フィルターでCVE-2022-22965のタスクステータスが「NEW（新規）」と「INVESTIGATING（調査中）」を抽出します。
タスクに一括チェックした上で、タスクを編集からコメントを送信することで、該当グループの所属メンバ全員にメールを送信できます。
その後はタスクのコメント上でのやり取りも可能です。
対応結果
模擬訓練に参加したプロジェクトの対応結果は以下のようになりました。
| プロジェクト | 結果 | ソフトウェア別の対応 |
|---|---|---|
| プロジェクトA | CPEスキャン(*)にて検出され、対応完了 | Spring Framework 5.3.17が検出対象となったため、最新バージョンにCPEを更新し、クローズ |
| プロジェクトB | CPEスキャンでは検出できず、個別連絡にて対応依頼の上、完了 | Spring Boot 2.5.0はSpring Frameworkに依存しているが、CPEスキャンでは検出されず。原因と対応策は下記課題3を参照。Spring Bootの最新バージョンにCPEを更新。 |
| プロジェクトC | CPEスキャンにて検出され、対応完了 | JDK 8は影響を受けないが検出対象となった。原因と対応策は下記課題4を参照。タスクのステータスを「NOT_AFFECTED（影響なし）」に変更し、クローズ。 |
*CPEスキャン：擬似サーバ上にソフトウェア名、バージョン情報を手動登録し、日次でスキャンさせる機能。
参考：CPEスキャン
見つかった課題
模擬訓練を通して発見した課題についてまとめます。
| No | 課題 | 対応策 | 補足 | |
|---|---|---|---|---|
| 1 | CVE未採番の状態でもユーザへ第一報を通知したい | グループセットのソフトウェアタブで「Spring」と検索し、該当するプロジェクトメンバに連絡する | FutureVulsのオーガニゼーショントピックやスペシャル警戒タグはCVE採番済みの脆弱性に対してしか利用できない。現状はチャットなど別の手段で連絡するしかない。 | |
| 2 | 対応済みのプロジェクトにもオーガニゼーショントピックが通知されてしまう | オーガニゼーショントピックをなるべく早めに発報することで、対応済み案件へ通知される確率を下げる。またトピック内に注意書きを入れる。 | オーガニゼーショントピックは脆弱性単位で通知する機能となっており、各タスクのステータスまでチェックしないため、既に対応がクローズしている案件にも通知されるため、注意が必要。 | |
| 3 | Spring Bootの脆弱バージョンをCPEスキャンしても、CVE-2022-22965が検出されない | 依存ライブラリスキャンを利用する | CPEスキャンは登録したライブラリやフレームワークの依存ライブラリの脆弱性までは検知できない。依存ライブラリスキャンの手法の1つとしてGitHub Security Alerts連携がある。PoCで利用したSpring Bootのpom.xmlをスキャン対象のGitHubリポジトリに手動であげるとFutureVuls側で検出されることを確認。 | |
| 4 | JDK 8であれば影響を受けないはずだが検出されてしまう | トピック内に影響を受ける条件を記載し、プロジェクト側にステータスを「NOT_AFFECTED（影響なし）」に変更してもらうようにする | FutureVulsには外部条件を考慮した検知の仕組みは現状ないため、ステータスを変更してもらう必要がある |
最後に
今回、脆弱性対応模擬訓練を行うことで、FutureVulsを活用した緊急時の一連のフローを確認することができました。
また、課題はいくつか見つかりましたが、運用でカバーできそうであることもわかりました。
FutureVulsはリリース頻度が高いため、このあたりの課題が機能アップデートによって解消されることに期待したいと思います！
私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。
セキュリティエンジニア執筆：@fukuyama.kenta
（Shodoで執筆されました）
