令和7年度 春期 情報処理安全確保支援士試験 午後 問2｜「重要情報がないから大丈夫」が崩れた日——情報処理安全確保支援士で学ぶ脆弱性管理とCVSS・EPSSによる対応優先度の決め方

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士

• 出典: 令和7年度 春期 情報処理安全確保支援士試験 午後 問2

• 主なテーマ: 脆弱性診断、ブラインドSQLインジェクション、CVSS基本値・現状値・環境値、EPSS、KEV的な悪用予測、対応優先度の判断

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「脆弱性は見つかった。でも、このサイトに大事な情報は入っていないから、急いで直さなくてもいいですよね」——セキュリティ担当者なら、現場で一度は聞いたことのある言葉ではないでしょうか。

情報処理安全確保支援士試験の令和7年度春期 午後 問2は、まさにこの「対応するかどうかをどう決めるのか」という、脆弱性管理のいちばん悩ましい部分を正面から扱った事例です。脆弱性は次から次へと報告されます。すべてに同じ熱量で対応する余裕はどの企業にもありません。だからこそ、深刻度をどう測り、どの順番で直すかという判断が、セキュリティの実力を分けます。

この記事では、ある企業のキャンペーンサイトで見つかった一件のSQLインジェクションが、「対応不要」という油断をどう覆したのか、そしてその反省からCVSS（共通脆弱性評価システム）とEPSS（悪用される確率の予測値）をどう組み合わせて対応優先度を決めるに至ったのかを、一つのインシデント事例として読み解きます。受験対策としての着眼点はもちろん、限られた人手で脆弱性に立ち向かう実務の判断軸まで持ち帰れるはずです。

インシデントの概要

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

M社には脆弱性診断のルールがありました。重要なサイト（以下、重要サイト）については、プラットフォームに対する脆弱性診断（以下、PF診断。OSやミドルウェア、通信設定など土台部分の検査）と、Webアプリケーションプログラムに対する脆弱性診断（以下、Webアプリ診断。画面やリクエスト処理など、アプリの作り込みを検査）を初回リリース前に両方実施する——この二つを併せて「両診断」と呼んでいました。ただし、初回リリース後の両診断は任意。そして、どのサイトを重要サイトに指定するかは、扱う情報の重要性や停止による影響をもとに、各サイトの所管部門が判断していました。重要サイト以外への両診断も任意です。

つまりM社では、「重要かどうか」の線引きが、対応のレベルを大きく左右する構造になっていたのです。この線引きの甘さが、後の事態の伏線になります。

何が起きたのか

ある日、M社の問合せ窓口に一本の指摘が届きます。「あなたの会社のキャンペーンサイトX（以下、サイトX）に、SQLインジェクション（入力欄やURLに細工した文字列を送り込み、データベースへの命令を不正に操作する攻撃）の脆弱性が存在している」——。

サイトXは、キャンペーン情報をデータベース（以下、DB）に格納して表示する、よくある販促用のページでした。キャンペーンページのURLには、表示するコンテンツを指定する番号がクエリパラメータとして含まれています。たとえば `article=20250101` のような形です。存在しない番号を指定したり、SQLが構文エラーになったりすると、「コンテンツがありません」というメッセージが返る仕様でした。そして、このarticleの値は、SQL（DBを操作する言語）の中で数値型として扱われていました。

そして決定的だったのは——サイトXは、重要サイトに指定されていなかったのです。

情報システム部のEさんとJ課長は、報告内容を確かめるため、Webアプリ診断用の診断ツールをサイトXに対して実行しました。結果は、深刻度レベルがHighのSQLインジェクション。Eさんは、攻撃者の目線でいくつかのリクエストを試します。

`article=20250401` を送ると、2025年4月1日のキャンペーンが正しく返ってきます。ところが、末尾に引用符を一つ付けて `article=20250401'` とすると、SQLが構文エラーになり「コンテンツがありません」が返る。さらに `article=20250401 and 1=0`（必ず偽になる条件）を付けると「コンテンツがありません」、`article=20250401 and 1=1`（必ず真になる条件）を付けると今度はキャンペーンが返ってくる。

ここでEさんの背筋が伸びます。条件式を付け足したときに、返ってくる結果が「真か偽か」で変わる——これは、画面にDBの中身が直接表示されなくても、応答の違いから一文字ずつ情報を推測できる「ブラインドSQLインジェクション」の典型的な挙動でした。ブラインドSQLインジェクションとは、エラーメッセージやデータが画面に出てこなくても、応答が変化するかどうか（あるいは応答が返るまでの時間）を手がかりに、DBの内容を間接的に読み出していく攻撃手法です。

Eさんはすぐにサイト担当者に連絡し、インターネットからサイトXにアクセスできないようネットワーク構成を変更したうえで、該当プログラムを修正するよう依頼しました。ところが、サイトXの担当者の反応は冷ややかでした。

「重要情報の漏えいなどの問題は発生しない。DBには重要情報もない。サイトXにアクセスできないようにする必要はない」

ここが、この事例のいちばん緊張する場面です。担当者の言い分は、一見もっともらしく聞こえます。たしかにサイトXは顧客情報を保有していません。しかしEさんは、こう切り返しました。「本脆弱性はブラインドSQLインジェクションの脆弱性に該当します。そのため、先ほどと同様の手法を用いることで、DBのテーブル名が特定できることになります」。

DBのテーブル名が分かると、攻撃者は次にどんな攻撃を仕掛けられるのか——Eさんはその先のシナリオを具体的に説明し、対応の必要性を説きました。「重要情報がない」ことと「攻撃に悪用されない」ことは、まったく別の話だったのです。これを受けて、ようやく迅速な対応が行われました。

このインシデントは、M社に二つの宿題を残しました。一つは、「重要サイト以外は任意」という線引きそのものの見直し。もう一つは、見つかった脆弱性に対して「対応するかどうか」「どの順番で対応するか」を、担当者の主観ではなく一貫した基準で決める仕組みづくりです。

対応完了後、情報システム部は公開サイトをすべて重要サイトに指定するようにルールを変更しました。そして、M社が保有するすべての公開サイトに対して一斉に両診断（以下、一斉診断）を実施することにし、専門ベンダーのP社に依頼します。

一斉診断の結果は、Eさんの不安を裏づけるものでした。深刻度レベルHigh以上の脆弱性が検出されたサイトが数サイト、Medium以下の脆弱性が数十件検出されたサイトも多数。さらに気になる点がありました。初回リリース時の両診断では「不具合はなかった」と報告されていたサイトでも、今回の一斉診断では結果が異なっていたのです。

P社の診断は、決められた手順に従って行われ、診断結果は技術レビューを経るため、診断員による差異はほぼないとEさんは聞いていました。にもかかわらず、なぜ結果が変わったのか。改めてP社に確認すると、要因は二つでした。一つは「新たな脆弱性が発見されたこと」。もう一つは「（P社が独自の知見で）リスクが変わったと評価し、値を変えたこと」。脆弱性の世界は静止画ではなく動画です。当時は安全に見えても、新たな攻撃手法の登場で評価が変わる。Eさんは、初回リリース後も定期的な両診断が必要だと結論づけました。