こんにちは、コーポレート本部 サイバーセキュリティ推進部 セキュアシステムデザイングループの福山です。
脆弱性が日々報告される中、迅速かつ適切な対応を行うためには、効果的なトリアージが欠かせません。
今回は、脆弱性対応を行う組織向けに、効率的な対応プロセスの進め方についてご紹介します。
はじめに
2024年7月、IPAより「脆弱性対応におけるリスク評価手法のまとめ」が公開されました。
下記に公開資料のPDFと資料のポイントが掲載されています。
https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2024/risk-assessment-methods.html
まずリスク評価とは、「脅威」「脆弱性」「資産」の3要素を考慮して実施し、その結果をもとに優先度をつけることが推奨とされています。
脆弱性対応におけるリスク評価も同様で、リスクの3要素を加味しつつ、運用負荷も考慮したリスク評価が望ましいです。
上記資料では、SSVC（Stakeholder-Specific Vulnerability Categorization）を活用したリスク評価手法が有効とされています。
そこで本記事では、SSVCを活用したリスク評価をツールを用いて実現する流れをご説明します。
FutureVulsについて
今回は脆弱性管理ツールFutureVulsを使ってみたいと思います。
FutureVulsは、OSS 脆弱性スキャナのVulsをベースに、脆弱性管理を実施できる機能を備えたクラウドサービスです。
参考：https://vuls.biz/
FutureVulsのような脆弱性管理ツールを導入することで得られるメリットは大きく次の3つです。
- 脆弱性情報の収集を手動で行うことによるチェック漏れや、脆弱性対応への対応漏れを防止できる。
- 脆弱性情報を一元管理できる。
- 脆弱性管理における一連の作業（脆弱性のレポート、対応判断等）を自動化することで作業負担を軽減できる。
3の「対応判断」を自動化する機能としてSSVCがあり、リスク評価で活用します。
SSVCを活用したリスク評価の概要
IPAによるとSSVCを活用したリスク評価は、下図の通りとなっています。
本当に対応が必要な脆弱性を抽出し、対応優先度を決定します。
SSVC を活用したリスク評価例の概要は、図 2-3 の通りである。
引用元：「脆弱性対応におけるリスク評価手法のまとめ」（p.29）0次評価では、緊急性の高い即時対応を求められる S ランク相当の脆弱性情報を評価する。
0次評価の概要は、図 2-4 のとおり。
引用元：「脆弱性対応におけるリスク評価手法のまとめ」（p.31）SSVCの具体的な出力結果とランクの対応としては、図2-6のとおりである。
ImmediateがSランク、Out-of-cycleがAランク、ScheduledがBランク、DeferがCランク判定となる。
引用元：「脆弱性対応におけるリスク評価手法のまとめ」（p.33）
ここでは各用語について説明します。
| 用語 | 説明 |
|---|---|
| KEV | KEV（Known Exploited Vulnerabilities catalog）は、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）が公開している既知の悪用された脆弱性カタログのこと。KEVには、実際に悪用されたことが確認された脆弱性の情報が集められており、脆弱性が最初に発見された時期や、どのように悪用されているかなどの詳細が含まれている。 |
| JPCERT/CC 注意喚起 | JPCERTコーディネーションセンター（JPCERT/CC）によって、日本国内における深刻かつ影響範囲の広い脆弱性などに関する情報が発信される。 |
| CVSS | CVSS（Common Vulnerability Scoring System） は、脆弱性の深刻度を評価するための標準的なスコアリングシステム。本記事ではCVSS Base Scoreについて取り上げる。以下のとおり、スコアの範囲によって深刻度が定められている。 ・緊急： 9.0~10.0 ・重要： 7.0~8.9 ・警告： 4.0~6.9 ・注意： 0.1~3.9 ・なし： 0.0 |
| EPSS | EPSS（Exploit Prediction Scoring System）とは、Firstが提唱したもので、脆弱性が悪用される可能性を示す指標。次の2つの情報を提供しており、本記事ではEPSS Probabilityについて取り上げる。 ①EPSS Probability: EPSSスコアのことで、今後30日以内に脆弱性が悪用される確率 ②EPSS Percentile: 脆弱性全体の中で、悪用される可能性がどの程度高いかを示す順位（上位何％に位置するか） |
| SSVC | SSVCは脆弱性の対応優先度を決めるための指標のことで、4つの入力を基に、緊急度を4段階評価で出力する仕組み。 【入力】 (1)Exploitation: 攻撃コードの公開有無や悪用レベル (2)Exposure: インターネット露出レベル (3)Utility Automatable: 攻撃の自動化 (4)Human Impact: 攻撃された際の業務影響 【出力】 「Immediate」: 全リソースを集中し必要に応じて組織の通常業務を停止して可能な限り迅速に対応する 「Out_of_cycle」: 通常よりも迅速に行動し、計画外の機会に緩和策または修復策を実施する 「Scheduled」: 定期メンテナンス時に対応する 「Differ」: 現時点では対応しない |
評価の流れについて、細かく図に落とし込んでみました。
IPAによるSSVCを活用したリスク評価では、下図のように0次評価と1次評価は独立しています。
なお、SSVCは「脅威」「脆弱性」「資産」の3要素が全て考慮されています。
ここまでIPAが提唱する評価手法を紹介しました。
これから紹介するFutureVulsのようなツールを用いることで、SSVCによる評価を自動算出できれば、リスクの3要素全てが網羅されたSSVC一本でのリスク評価が実現できると捉えています。
FutureVulsによるリスク評価
FutureVulsを運用する上で発生する作業には、「各システムの管理者が行う作業」と「組織のFutureVuls管理者が行う作業」の2種類があります。
後述の作業が発生する場面においては、上記のどちらが対応する作業かを色を分けて示しています。
I. 事前準備
今回は、サンプルシステムとしてAWS上の仮想Webシステムを想定して評価を行います。
リスク評価対象とするサンプルシステムの概要
- 外部のユーザーが利用する簡易Web受付サイト
- AWS上に構築されている小規模なシステムで、OSSを利用したWeb3層構造を想定。
- 各サーバは全てEC2インスタンスであるため、OS以上はユーザ側でメンテナンスが発生する。
- Webサーバの前段でALB等による認証を行わない。
- わざと脆弱性が検出されるように、2年ほど前にリリースされた古いソフトウェアバージョンで構成（※実際には攻撃者によって脆弱性を突かれる可能性があるため、利用を避けるべきバージョン）。
- システム構成
- ソフトウェア構成
- Webサーバ
- NGINX 1.23.2
- OpenSSL 3.0.6
- APサーバ
- Python 3.11.0
- Flask 2.2.2
- uWSGI 2.0.21
- OpenSSL 3.0.6
- DBサーバ
- MySQL 8.0.31
- OpenSSL 3.0.6
資産の登録
スキャン方法については、「CPEスキャン」という擬似サーバ上にソフトウェアをCPE形式で登録し、脆弱性スキャンできる便利な機能があります。
CPEスキャンで実際のシステムにスキャナを導入する必要はありませんので、ちょっとした検証をする際に役に立ちます。
登録方法としては下図のように、ベンダー名やソフトウェア名を入力するとCPEの候補が表示されるため、登録したいCPEを選択し、バージョン情報を選択するだけで完了します。
ただし、OSの脆弱性も検出したいといった場合には、実際にサーバを構築し、OSSをソースからインストールした上で、「スキャナ」をインストールする必要がありますので注意が必要です。
なおDBサーバについては、マネージドサービスであるRDSを例にあげると、「マイナーバージョンの自動アップグレード」を有効化している場合には自動パッチ適用が行われるため、スキャン対象から除外して問題ないと考えます。
参考：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Upgrading.html#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades
今回はEC2インスタンスにMySQLをインストールしており、ユーザー側でパッチ適用が必要なため、スキャン対象とします。
SSVCの設定
Exploitaion（攻撃コードの公開有無や悪用レベル）とUtility Automatable（攻撃の自動化）は自動出力されるため、Exposure（インターネット露出レベル）、Human Impact（攻撃された際の業務影響）の2つを手動で設定します。
Exposure（インターネット露出レベル）
Exposureについては、技術的な判断が必要です。
設定基準については、FutureVulsの記事を参考にしました。
SSVCのExposureとは、「対象システムがインターネットに露出しているレベル」です。対象システムのインターネット露出度に応じて以下の3段階の中から選択します。説明欄には決定のための具体例を記載しています。
引用元：「インターネット露出サーバの自動特定とSSVC Exposure設定ガイド」
- Webサーバ ：前段でALB等による認証はしておらず、インターネットから直接アクセス可能なため、「Open」と判断します。
- APサーバ：パブリックIPを保持しておらず、一見controlledと判断してしまいそうになります。
しかしながら実質的なIPアドレス制限がなく、インターネットからのアクセス経路があるため、こちらも「Open」とします。 - DBサーバ：APサーバからのみアクセス可能であり、インターネットに直接面していないため、「Controlled」と判断します。
Human Impact（攻撃された際の業務影響）
Human Impactの設定基準については、IPAの記事を参考にしました。
「Human Impact」
影響の大きさとして、安全性の影響と業務遂行への影響の両面から評価する。安全性の影響としては、「None / Minor / Major / Hazardous / Catastrophic」の五段階で評価する（表C-5）。業務遂行への影響としては、「None / Degraded / Crippled / MEF Failure / Mission Failure」の五段階で評価する(表C-6)。最終的に、「HumanImpact」は安全性の影響と業務遂行への影響の評価を組み合わせて、決定木の選択項目として「Low / Medium / High / Very High」の4種類から評価される（表C-7）。
引用元：「脆弱性対応におけるリスク評価手法のまとめ」（p.93 - p.95）
脆弱性の種類によってはWeb/APサーバの脆弱性を突かれることによって、DBに保存されている機密情報が漏洩するケースも考えられます。
よってHuman Impactについてはシステム単位で検討することにします。
- 安全性の影響：機密情報が漏洩した場合、集団に対する精神的または心理的な損害が発生する恐れがあるため、「Major」とします。
- 業務遂行への影響：機密情報が漏洩した場合、サービスの重要度によっては、複数または全てのミッションに障害を及ぼし、組織のミッションが果たせなくなる可能性があります。今回のWeb受付システムの場合では、組織のミッション達成が低下するレベルの影響と判断し、「MEF Failure」としておきます。
- Human Impact：Major × MEF Failure = High
SSVCの入力値をまとめると以下の通りとなりました。
| サーバ名 | Exposure | Human Impact |
|---|---|---|
| Webサーバ | Open | High |
| APサーバ | Open | High |
| DBサーバ | Controlled | High |
ここでSSVCのロール設定という機能を使うことで、サーバ別にSSVCの設定を作成することができます。
ロールを作成し、各サーバに紐づけることによって設定が完了します。
対応期限の設定
FutureVulsに登録されている全グループの設定を管理する「オーガニゼーション設定」と呼ばれる画面では、SSVCのレベルに応じた対応期限を設定できます。
参考：https://help.vuls.biz/manual/csirt_option/ssvc/config/#%E5%AF%BE%E5%BF%9C%E6%9C%9F%E9%99%90
対応期限についてはIPAの資料に目安の記載がありますが、ここは組織のポリシーに応じて設定してください。
引用元：「脆弱性対応におけるリスク評価手法のまとめ」（p.61）
II. スキャンの実施から対応方針を決めるまで
STEP1： スキャン
CPEスキャンでは日次で自動スキャンされますが、ソフトウェア登録後すぐに実行したい場合は、「手動スキャン」を実行することで即時スキャンが可能です。
STEP2： トリアージ
脆弱性対応におけるトリアージとは「対応判断」のことです。
検出された脆弱性に対して重要度・緊急度を見極め、許容するものの選別や優先順位の決定などを行います。
SSVCによる評価
スキャン後、「脆弱性」タブを開くと、脆弱性の検出結果を確認できます。
「重要な未対応」タブの中に、SSVC Out_of_cycleと判断された脆弱性が表示されました。
脆弱性としては4件、NGINX、OpenSSL、Pythonの脆弱性が検出されているようで、この4件は計画外対応を行う必要があります。
SSVCの算出根拠も確認できます。
一方、SSVC Scheduledの脆弱性は「その他の未対応」に分類されました。
ここからは、「重要な未対応」タブに含まれるOut_of_cycle以上の脆弱性の調査・対応判断を行います。
STEP3：調査・対応判断
対応優先度が最も高い「Immediate」として検出されたNGINXの脆弱性から見ていきます。
まずはタスクのステータスを「INVESTIGATING」に変更し、調査中であることを明示します。
FutureVulsでは脆弱性が検出されると、サーバごとに脆弱性単位で「タスク」が作成され、ステータスを管理します（チケットに近いイメージです）。続いて「詳細」タブにて、脆弱性の詳細情報を確認します。
該当システムに対してどの程度リスクがあるか、といった観点で確認すると良いと思います。
以下、一例として確認する項目をピックアップしました。- 「サマリ」：攻撃を受けた場合に想定される影響、各機関が評価したCVSSスコアの一覧
- 「CVSS」：ネットワークから攻撃可能か等
- 「攻撃コード」：Exploit-DBやGitHub上での攻撃コード・実証コードの公開有無
- 「緩和策」：Red Hat,Microsoftのデータソースにおける緩和策・回避策の有無
参考：https://help.vuls.biz/manual/cve/#詳細タブ
「トピック」タブでは、脆弱性の調査結果やコメントの共有を行います。
参考：https://help.vuls.biz/manual/topic/
例えば下記のような内容は機械的に収集できないため、トピックを利用して情報共有する使い方がおすすめです。- 攻撃の成立条件
- CVE-2023-44487への対策として、AWSの基盤自体に緩和策が適用されているといった情報
参考：https://aws.amazon.com/jp/security/security-bulletins/AWS-2023-011/ - NGINX自体の緩和策（下記リンク先の「Steps for Mitigating Attack Exposure」参照）
参考：https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/
「タスク×サーバ」タブで、どのサーバに脆弱性が存在するか確認します。
「タスク詳細」では、対応期限が表示されます。
これは、事前に「オーガニゼーション設定」で設定したSSVCのレベルに応じた「対応期限」が自動的に設定されます。
この対応期限に間に合うように対応予定日を決め、入力後、ステータスを「ONGOING」に変更します。
以上で、NGINXの脆弱性調査・対応判断が完了しました。
以上で、「重要な未対応」に関する一連の調査・対応判断の作業が完了し、実際の脆弱性対応（事前のテスト、本番パッチ適用等）に移る準備が整いました。
残りの「その他の未対応」については定期メンテナンス実施時に対応するとします。
まとめ
脆弱性管理ツールFutureVulsを用いて、SSVCによるトリアージを試してみました。
今回の例では77件のうち、4件の脆弱性に対して優先度を上げて対応する結果となりました。
今回は3つのサーバで構成された単一のシステムでしたが、これが複数の環境が混在するシステムとなった場合には、この評価手法はより効果を発揮すると考えられます。
脆弱性対応において、IPAが提唱する0次評価・1次評価を導入することで運用負荷を削減し、FutureVulsのようなツールがある場合には2次評価のみで完結するため、より効率化できると言えます。
また、ツールを用いることで脆弱性情報の収集、調査、判断の自動化のメリットが得られるため、改めてツールの必要性を実感しました。
以上、最後までお読みいただきありがとうございました。
執筆：@fukuyama.kenta、レビュー：@kou.kinyo
（Shodoで執筆されました）
