公開サイトの脆弱性診断結果の優先度判断（CVSS・EPSS）

M 社は，従業員 3,000 名の情報サービス業を営む企業である。ソフトウェアの開発・販売を行っており，自社ホームページのほか，販売したソフトウェアのサポート用 Web サイトなど複数の Web サイト（以下，Web サイトをサイトという）を保有している。M 社では，メンテナンスのために管理者が自宅や外出先からサイトにリモートアクセスする。セキュリティに関する問合せ窓口は，情報システム部が担当している。

M 社が保有するサイトのうち，重要なサイト（以下，重要サイトという）は，プラットフォームに対する脆弱性診断（以下，PF 診断という）及び Web アプリケーションプログラムに対する脆弱性診断（以下，Web アプリ診断といい，PF 診断と Web アプリ診断を併せて両診断という）を初回リリース前に実施するルールになっている。初回リリース後の両診断の実施については任意である。重要サイトの指定は，扱う情報の重要性，停止による影響などを勘案し，各サイトの所管部門が判断している。重要サイト以外のサイトに対する両診断の実施は任意である。

両診断は，情報システム部の選定した専門ベンダーP 社に依頼して実施，又は情報システム部の選定した脆弱性診断ツール（以下，診断ツールという）を用いて各サイト担当者が実施する。ただし，緊急の場合，情報システム部が実施することもある。P 社の Web アプリ診断は，脆弱性が実際に悪用できることを確認した上で報告してくれるので，評判がよい。

脆弱性は Critical，High，Medium，Low，None の 5 段階の深刻度レベルに分類される。P 社に依頼して診断を行う場合は，P 社から深刻度レベルの報告を受ける。深刻度レベルは，情報システム部が選定した診断ツールの場合は CVSS 基本値によって分類される。P 社の診断では，P 社が独自の知見で CVSS 基本値を基に値を変え，分類している。M 社では，深刻度レベルが High 以上の場合は速やかな修正を必須とし，それ以外は所管部門が対応要否を判断する。

〔脆弱性の報告〕

ある日，M 社のキャンペーンサイト X（以下，サイト X という）のキャンペーンページに SQL インジェクションの脆弱性が存在しているという指摘が問合せ窓口に報告された。報告内容についてサイト担当者に確認したところ，脆弱性が存在する可能性があるとの回答であった。サイト X は重要サイトに指定されていなかった。サイト X の仕様を図 1 に示す。

・Web サーバ，Web アプリケーションサーバ及びデータベース（以下，DB という）サーバから成る。 ・キャンペーン情報を DB サーバに格納している。 ・顧客情報は保有していない。 ・キャンペーンページの URL のクエリパラメータにコンテンツ番号が含まれている。 　URL 例：https://site-x.m-sha.co.jp/info?article=20250101 ・コンテンツ番号が DB サーバ上に存在しない場合，又は SQL が構文エラーになる場合は，“コンテンツがありません”というメッセージを返す。 ・Web アプリケーションプログラムにおいて，クエリパラメータ article の値は SQL での検索では数値型として扱われる。

図 1　サイト X の仕様（抜粋）

情報システム部の E さんと J 課長は，報告の内容を確認するために，情報システム部が診断ツールを実行する旨をサイト X の担当者に伝えた。

Web アプリ診断用の診断ツールを該当ページに対して実行したところ，深刻度レベルが High の SQL インジェクションの脆弱性が検出された。SQL インジェクションの脆弱性検出時のクエリパラメータ及び応答を表 1 に示す。

表 1　クエリパラメータ及び応答（概要）

E さんは，速やかにサイト担当者に連絡し，インターネットからサイト X にアクセスできないようネットワーク構成を変更した上で，該当するプログラムを修正するよう依頼した。これに対してサイト X の担当者は，“重要情報の漏えいなどの問題が発生することはない。DB には重要情報もない。サイト X にアクセスできないようにする必要はない。”と主張した。それに対して E さんは，“本脆弱性はブラインド SQL インジェクションの脆弱性に該当する。そのため，表 1 と同様の手法を用いることによって，DB のテーブル名が特定できることになる。”と説明した。E さんは，DB のテーブル名を使うと攻撃者が次にどのような攻撃を行えるかを説明し，対応する必要性を説いた。これを受け，迅速に対応が行われた。

〔脆弱性が存在していた状況の確認と一斉診断の実施〕

対応完了後，情報システム部では，公開サイトは全て重要サイトに指定するようにルールを変更することにした。同時に，M 社が保有する全ての公開サイトに対する一斉の両診断（以下，一斉診断という）を実施することにし，その診断を P 社に依頼した。診断対象サイトの情報を表 2 に示す。

表 2　診断対象サイトの情報

診断の結果，深刻度レベル High 以上の脆弱性が検出されたサイトが数サイトあり，Medium 以下の脆弱性が数十件検出されたサイトも多数あった。

サイトによっては，初回リリース時の両診断以降にアップデートや設定変更をしていないにもかかわらず，初回リリース時の両診断結果と今回の一斉診断結果が異なっている場合もあった。P 社の診断は，決められた手順に従って行い，診断結果は技術レビューを行うので，診断員による差異はほぼないと，E さんは P 社から聞いていた。また，初回リリース時の両診断では，サイトに不具合はなかったと報告を受けている。E さんが，改めて P 社に確認すると，診断結果が異なっていた要因は，【 f 】や【 g 】だった。これらのことから，E さんは初回リリース後も定期的な両診断が必要であると結論づけた。

〔PF 診断で検出された脆弱性〕

PF 診断で検出された脆弱性を表 3 に示す。

表 3　PF 診断で検出された脆弱性（抜粋）

脆弱性 PA-1 と PB-3 について，CRYPTREC が作成し，IPA が発行している“TLS 暗号設定ガイドライン Ver. 3.1.0”の“4. 推奨セキュリティ型の要求設定”には，表 4 に示す鍵交換におけるビットセキュリティの基準を満たすよう記載されていた。そのため，サイト A 及びサイト B は基準を満たす設定に変更することにした。

表 4　鍵交換におけるビットセキュリティの基準

脆弱性 PB-1 は，管理者がメンテナンス用にリモートアクセスで使っている OpenSSH において検出された。OpenSSH では，ログインが一定時間内に成功しないと，認証試行のタイムアウト処理が実行される。脆弱性 PB-1 は，あるセキュリティベンダーの報告によると，認証試行のタイムアウト処理が同時に多数実行されると起き得る問題であり，認証試行の接続時間（LoginGraceTime）の設定が 120 秒の場合，その間に 100 件試行されると，OpenSSH のログに“Timeout before authentication”という認証タイムアウトのメッセージが多数出力され，3～4 時間で悪用に成功する可能性があるとのことだった。もしも，脆弱性を修正したバージョンの OpenSSH に更新できない場合には，次のいずれかを行う。

・トレードオフはあるものの，認証試行にタイムアウトを設けないようにサーバの設定を変更する。 ・①サイト担当者が攻撃を早期に検知する方法を採用することによって被害を抑制する。

サイト B では，OpenSSH の更新を行った。

脆弱性 PB-2 は，送信元 IP アドレス制限が対策の一つだが現実的な運用が難しい。代わりの対策として，ログイン画面のアカウントロックがあるが，採用する場合はロック解除の運用方法や実装について検討が必要である。サイト B では，②アクセス元の PC を認証する対策を採用した。

〔Web アプリ診断で検出された脆弱性〕

Web アプリ診断で検出された脆弱性を表 5 に示す。

表 5　Web アプリ診断で検出された脆弱性（抜粋）

注¹⁾　https://site-b.m-sha.co.jp/administrator0001/order_history

脆弱性 WA-1 と WB-1 は，HTTP リクエストの内容を一部変更することによって本来閲覧できない画面を閲覧できるという点では同じであるが，評価指標の値が異なる。評価指標のうち，③Attack Complexity（AC）の値はそれぞれ L と H であった。

脆弱性 WC-1 について，*④管理者権限が必要な操作ができなかったのは，サイト C の仕様どおりであった。*サイト C の仕様を図 2 に示す。

1. Web サーバ及び Web アプリケーションサーバから成る。
2. DB サーバとの連携はしていない。
3. Web アプリケーションプログラムは，一般利用者権限の専用アカウントでプロセスを実行している。
4. 問合せフォームに入力された値をメールコマンドで管理者宛てに送る。
5. 問合せ内容がログに保存され，その中にメールアドレスなどの個人情報をもつ。
6. ログには特定のアカウントだけがアクセスできる。

図 2　サイト C の仕様（抜粋）

〔脆弱性評価方法の検討〕

一斉診断が一段落したところで，情報システム部は脆弱性管理についての課題を議論した。対応の要否判断が不適切であったサイトや対応が遅すぎたサイトがあったので，J 課長は，E さんに新たな脆弱性評価方法を検討するよう指示した。

はじめに E さんが調査したところ，IPA のホームページに“脆弱性対応におけるリスク評価手法のまとめ”というレポートが公開されていたので，これを参考にすることにした。E さんは，検討内容を J 課長に報告した。次は，その際の E さんと J 課長の会話である。

E さん：レポートでは，対応要の脆弱性を簡易的な 1 次評価で選び，さらに，2 次評価で優先度を評価する手法が提案されています。

J 課長：1 次評価は具体的にはどのような評価をするのか。 E さん：1 次評価では，基本値と Exploit Prediction Scoring System（EPSS）値を用います。EPSS 値の代わりに CVSSv3 の現状値を用いる方法もありますが，⑤現状値と EPSS 値を比べると，現状値は手間が掛かり，EPSS 値は手間が掛からないとされています。1 次評価では図 3 のように脆弱性を領域図で 4 領域に分類します。

図 3 は，横軸を基本値（左端 0.0，右端 10.0。途中に縦の破線で“しきい値 A”），縦軸を EPSS 値（%）（下端 0，上端 100。途中に横の破線で“しきい値 B”）とした領域図であり，二本の破線で次のとおり 4 領域に分けられる。

注記　EPSS 値がしきい値 B の場合は，領域 III 又は I と，基本値がしきい値 A の場合は，領域 I 又は II と考える。

図 3　1 次評価の領域図

J 課長：しきい値はどうするのか。 E さん：しきい値 A は 7.0 に，しきい値 B は 1 %に設定しようと考えています。領域 IV は対応不要とし，領域 I ～ III を 2 次評価の対象にします。 J 課長：なるほど。では，そのしきい値に設定してみて，対応すべき脆弱性に漏れが出るなどの問題があれば，しきい値を見直すことにしよう。 E さん：はい。分かりました。 J 課長：あとは EPSS 値を用いた脆弱性評価について，しきい値の見直し以外にも，【 l 】を継続的に行うことで被害を防ぐ助けになるだろう。 E さん：分かりました。 J 課長：ところで，Web アプリ診断では，見つかった脆弱性の EPSS 値が報告されないことが普通だが，どのように評価するのか。 E さん：⑥P 社の Web アプリ診断であれば，見つかった脆弱性の EPSS 値は，しきい値 B よりも高いとみなすのが妥当であると考えられます。Web アプリ診断で検出される脆弱性を，全て領域 I か III とみなそうと考えています。 J 課長：その方法が安全だな。次に，2 次評価はどうするのか。 E さん：2 次評価は，環境値と先に評価した領域とを組み合わせた方法にしようと考えています。 J 課長：環境値を全て算出するのだな。 E さん：環境値の算出においては，現状評価基準の各評価指標を，“Not Defined”と設定することができます。環境評価基準での各評価指標の値の判断は各サイト担当者に依頼します。そして，表 6 に示す対応優先度表によって S～C の最終的な対応優先度を決定します。

表 6　対応優先度表

S：即時対応　　A：対応優先度高　　B：対応優先度中　　C：対応優先度低

J 課長：分かった。一斉診断の結果で幾つか評価して確認してほしい。 E さん：分かりました。

〔対応優先度評価の実施〕

E さんが 2 次評価を幾つか行った結果を表 7 及び表 8 に示す。

表 7　PF 診断で検出された脆弱性に対する評価結果（抜粋）

表 8　Web アプリ診断で検出された脆弱性に対する評価結果（抜粋）

この運用によって，脆弱性対応の優先度評価がサイト担当者によらず適切かつ迅速にできるようになった。