情報処理安全確保支援士試験 2025年 春期 午後 問2

脆弱性管理

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での検索では数値型として扱われる。

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

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

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

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

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

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

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

【PF診断で検出された脆弱性】

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

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

脆弱性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に示す。

脆弱性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. ログには特定のアカウントだけがアクセスできる。

【脆弱性評価方法の検討】

一斉診断が一段落したところで、情報システム部は脆弱性管理についての課題を議論した。対応の要否判断が不適切であったサイトや対応が遅すぎたサイトがあったので、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領域に分類します。

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の最終的な対応優先度を決定します。

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

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

Eさん：分かりました。

【対応優先度評価の実施】

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

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