電通総研のブログ

2023/10/10

【CSIRT向け】FutureVulsを活用した脆弱性対応模擬訓練をやってみた！

こんにちは、X イノベーション本部ソフトウェアデザインセンターセキュリティグループの福山です。今回は、弊社CSIRTチームの一機能として活動している「脆弱性管理チーム」の活動に関する内容となります。昨今では、Log4shellやSpring4shellなど、影響範囲の広い脆弱性が後を絶ちません。これらの緊急度の高い脆弱性情報が公開された場合を想定した、情報収集〜現場対応までのCSIRT目線での模擬訓練を、FutureVulsを含めて実施してみましたので紹介したいと思います。 FutureVulsとは 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の採用に至った条件は以下仮想の脆弱性ではなく、既存の脆弱性を利用した方がやりやすい社内で利用されているソフトウェア擬似サーバへの CPE 登録が想定されるもの参考：擬似サーバとはリモートコード実行が可能な脆弱性で、PoCが公開されているもの公表された時点でCVE未採番で、セキュリティパッチが公開されていないもの事前にプロジェクトに協力を募り、3プロジェクトからの協力を取り付ける FutureVulsの擬似サーバを利用し、 CPE 形式でソフトウェア情報を登録プロジェクトA Spring Framework 5.3.17 OracleJDK 9 Apache HTTP Server 2.4.53 Apache Tomcat 9.0.60 プロジェクトB Spring Boot 2.5.0 OpenJDK 9 nginx 1.6.0 Apache Tomcat 9.0.59 プロジェクトC Spring Framework 5.2.0 OracleJDK 8 Apache HTTP Server 2.4.52 Apache Tomcat 9.0.59 模擬訓練模擬訓練の流れは以下となります。情報収集 -> トリアージ -> 全社周知 -> 個別周知 -> 対応状況の確認なお、全社周知と個別周知の役割の違いは以下です。全社周知個別周知・ゼロデイ脆弱性等、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への連携も可能です。 Slack連携： https://help.vuls.biz/manual/notification/slack_app/ Teams連携： https://help.vuls.biz/manual/notification/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 で執筆されました）

電通総研 の技術ブログ

コンテンツ

電通総研の技術ブログ