https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000d05l-att/2020r02o_sc_pm1_qs.pdf
以下のおすすめ問題の解説となります。
良書。
問3 Webシステムの セキュリティ診断に関する次の記述を読んで、設問1、2に答えよ。
L社は、ECサイトを運営している従業員数800名の企業である。L社のモールの会員は、モールで買物をすると、購入金額に応じてL社が独自に発行するポイントが得られる。L社のポイントサービス部が管理するポイントシステム(以下、Pシステムという)のネットワーク構成を図1に示す。
Pシステムが受信する1日の時間帯別の通信量の比率は、0時〜8時が2%、8時〜16時が55%、16時〜24時が43%である。Pシステムの機器は全て固定IPアドレスで運用している。
Pシステムの機器の概要を表1に示す。
[Pシステムの診断計画]
ECサイトへの 情報セキュリティ上の脅威の高まりを受け、L社は、Pシステムの脆弱性診断を実施することを決定した。L社のリスク管理部のT主任と部下のUさんが、診断計画を策定する担当に任命された。T主任は、図3に示す診断要件を基に診断計画を策定するようUさんに指示した。
Uさんは、専門業者の診断サービスについて調査し、図4に示す調査結果を得た。
Uさんは、調査結果を基にL社で実施すべき脆弱性診断の検討に入った。Web診断については、次のように実施することにした。
- 診断用の利用者IDを作成する。その利用者に診断用のポイントを付与し、Pシステムにログインして診断する。
- ログイン無しでアクセスできるページも診断する。
- 診断前の状態に戻せないようなデータの更新が発生する診断は実施しない。
PF診断については、T主任から助言を得ることにした。次は、本番Webサーバがインターネットから攻撃される脅威を想定した時の、PF診断に関する、UさんとT主任の会話である。
Uさん:インターネットから診断する場合、調査した幾つかの事例によると、PF診断の実施時だけ、N-IPSの脅威通信判定を無効にすることがあるようです。有効なまま診断するケースと比べ、無効にすると、①より多くの脆弱性を検出する可能性があります。
T主任:無効にすると、PF診断実施時に本物の攻撃を防げないというリスクも生ずる。無効にするのではなく、②N-IPSの設定を変更すれば、そのようなリスクは生じない。
Uさん:分かりました。
T主任:それと、インターネットからのPF診断の通信経路を考慮すると、インターネットからのPF診断だけでなく、内部のネットワークからのPF診断も実施すべきだ。
Uさん:分かりました。その場合は、想定する脅威を踏まえると、診断PCを図1中の接続点(a)に接続して診断すれば良いでしょうか。
T主任:そのとおりだ。
UさんはT主任のアドバイスを踏まえ、更に検討を進め、診断計画を表2のとおりにまとめた。
下線①について、その理由を35字以内で述べよ。:
脅威通信判定によって、遮断されていた通信に対して診断解析の対象となるため、脆弱性を検出することができる
N-IPSの脅威通信判定とはPシステムの概要にあります
①より多くの脆弱性を検出する
理由としては、脅威通信判定によって、遮断されていた通信に対して診断解析の対象となるため、脆弱性を検出することができる。
下線②について、その理由を35字以内で述べよ。:ホワイトリストに診断PCのIPアドレスを登録する。
無効にすると、PF診断実施時に本物の攻撃を防げないというリスクも生ずる。無効にするのではなく、②N-IPSの設定を変更すれば、そのようなリスクは生じない。
N-IPSの設定は2つある
- ホワイトリスト判定
- 脅威通信判定
ここでいう無効は両方がOFFになってしまうため良くないというのが指摘である。
N-IPSの設定を変更する際に現在、ホワイトリスト判定の設定は何もされていないので、許可したい通信のIPアドレスを登録することで限定的に通信を許可することが可能となる。
(a)
内部ネットワークからインターネットの線を検査すると考えると(a)が正解となる
[Pシステムの診断計画レビュー]
診断計画レビューにおいてT主任は、診断の検査項目の内容は妥当であるとした上で、次の指摘を行った。
指摘1:Web診断は本番環境ではなく、ステージング環境で行うべきである。ステージング環境で実施する際、全ての診断の終了後に、担当者が、FW1の設定を元に戻すこと、及びステージング環境の(b)を削除することを、明確に手順書に記載すること
指摘2:PF診断は本番環境で実施すべきだが、 サーバが異常停止した場合の影響を最小化するために③計画の一部を変更すること
指摘3:診断2の実施に当たっては、警告灯が点灯することで社内に混乱が起きないよう、運用グループに④機器の設定の変更を依頼すること
その後、指摘3に従い、Uさんは運用グループに診断計画を説明して設定の変更を依頼した。運用グループから、設定の変更については承諾を得られたが、診断計画について、診断2の診断 PCを接続するポイントを、図1中の(e)から(d)に変更する必要があるという提案があった。
この提案について、運用グループから説明があった。運用グループによれば、最近配属された担当者が、Web管理用PCから本番DBサーバにログインを試みた。その結果、警告灯が点灯し、運用グループは緊急対応体制をとることになってしまった。その再発防止策の一つとして、FW2のルールを修正し、(c)宛ての通信については、(d)からの通信だけを(e)することにした。その影響で、接続ポイントの変更が必要になるとのことだった。
UさんはT主任の指摘及び運用グループからの提案を踏まえ、診断計画を確定し、診断実施に向けて準備を進めた。
b)診断用の利用者ID
指摘1:Web診断は本番環境ではなく、ステージング環境で行うべきである。ステージング環境で実施する際、全ての診断の終了後に、担当者が、FW1の設定を元に戻すこと、及びステージング環境の(b)を削除することを、明確に手順書に記載すること
2)日時。9時から~17時から0時から8時に変更する
PF診断の計画:10営業日の中で、9時から17時
通信量に着目すると利用時間帯少ない時間は0時から8時。
この時間にすることで、サーバが停止した影響を最小限に抑えることができる
3)本番DBサーバのホスト型IPSのホワイトリストに診断PCのIPアドレスを追加し、侵入検知設定をOFFにする
警告灯が点灯する条件。
本番DBサーバの概要
4)c本番DBサーバ dDB管理PC e許可
当初緑の線では許可されていたのだが、赤い線の部分でNGとなったので、
Web管理PCから本番DBサーバへのアクセスは禁止となった。
本番DBあての通信はDB管理PCからのアクセスのみ許可することとなった。
つまり青の線となる。