情報処理安全確保支援士試験 令和元年秋午後１問３の問題解説

以下は、令和元年度 秋期 SC 午後Ⅰ「問3 標的型攻撃への対応」の問題文を、流れと狙いがつかめるように噛み砕いて整理した解説です。まず“どんな状況で何を導入し、どう対応したか”の全体像を押さえると読みやすくなります。

全体像（どんな話？）

• J社の素性：ビッグデータ解析の調査会社（従業員150名）。Webアクセスや社外メールのやり取りでインターネットを常用。情報セキュリティポリシは整備済み。

• 事件の発端：3月に標的型攻撃でPCがマルウェア感染、業務サーバの秘密情報が外部に送信。感染“疑い”含め40台を初期化、復旧まで48時間で業務停止に。被害後、コンサルの助言で予防だけでなく“感染後の拡大防止・漏えい抑止”も重視する方針へ転換。

• この問の出題趣旨（公式）：近年は“完全な抑止は難しい”。一般的なネットワーク構成でのウイルス感染を題材に、「感染後のインシデント対応力」を問う。つまり、「検知→切り離し→特定→封じ込め→再発防止」を設計できるかがテーマです。

導入した仕組み（図1・表1の読み方）

J社は二つの柱を導入して、**“通信面の検知”と“端末面の可視化・封じ込め”**を両輪にしました。

1. Pサービス（監視）

• 材料：FW（ファイアウォール）ログをP社へsyslogで送信、Pサービス側でC&C通信の兆候をリアルタイム分析。

• できること：C&C通信を検知したら、日時・送信元IP・宛先（C&C）IP・ポート・データサイズをメールと電話で即通知（ただし、過去分の遡及分析はしない／ログ蓄積もしない点が重要な制約）。

2. Rシステム（EDR的な可視化／封じ込め）

• 材料：各PC/サーバにエージェント。プロセスの生成～終了、実行プログラムのハッシュ、外向き通信の宛先IP/ポートをRログとして収集し、ログ蓄積サーバへ。

• できること：既知マルウェアのハッシュ値を“管理サーバ”に登録すれば、実行を禁止できる。Rログは後から検索可能なので、感染プロセスの特定や**“どの端末がやられたか”の横断調査**に強い。

3. FW・ログ蓄積サーバ

• FWは状態保持＋フィルタリングし、日時/動作/送信元・宛先IP/ポート/データサイズをログ化。

• ログ蓄積サーバはFWログとRログを保管（＝Pサービスは“検知のみ”で蓄積せず、こちらが遡及調査の拠点）。

インシデント対応フロー（図2の狙い）

改定後の手順(1)～(9)は、**「即時の封じ込め」と「根治・再発防止」**を両立させる設計です。要点は以下。

• (1) 通知を基に不審PCの特定。

• (2) 電源は切らない：メモリ上アーティファクト（揮発情報）保全のため。

• (3) LANケーブルを抜く：社内横展開や追加の外向き通信を遮断。

• (4) FWで宛先C&Cをブロック：同系統の通信を網で止める。

• (5) データサイズで漏えい可否の初期判断（例：200Bならビーコン可能性、巨大だと持ち出し疑い）。

• (6) Rログで実行プロセスやハッシュを特定。

• (7) ハッシュを登録し実行禁止（以降の再発も封じる）。

• (8) 漏えい可能性大ならフォレンジック業者へ（メモリ・ストレージ解析）。

• (9) 初期化＋再配付：汚染痕跡を残さない“クリーン復旧”。

（この(2)や(3)の意味は、のちの設問でも問われます。問題は“行動の目的と言語化”ができているかを見ています。）

実際の検知事案（表2・表3を時系列で読む）

• 13:27 PサービスからC&C通信検知の通知（13:17:15に発生、送信元 192.168.1.20（LさんPC）／宛先 w1.x1.y1.z1／80/tcp／200B）。Gさんは手順通り、Lさんに電源ON維持＆LANケーブル抜線を指示。

• 13:49 FWにブロックルール登録。FWログでも200B送信を確認（＝Pサービス通知と一致）。

• 14:03 Rログ調査でC&C接続したプログラム＝マルウェアMを特定。同時刻に、L-PC上でipconfig /all、systeminfo、tasklist、dir /a、net viewなどが実行されていた事実を把握。

  • 意味づけ：

    • ipconfig /all・systeminfo＝初期調査（環境把握）

    • tasklist＝実行プロセス確認（解析環境回避の下見など）

    • dir /a・net view＝探索活動（機微ファイルや到達可能な共有の洗い出し）
      これらは感染“直後の行動連鎖”として自然で、横展開や窃取準備を示唆します。

• 14:58 マルウェアMのハッシュを管理サーバへ登録→実行禁止化。以後、同ハッシュの再実行は封じ込め。

改善フェーズ（“どこを強化すべきか”の読みどころ）

E部長は報告書を読み、**「L-PC以外の感染が潜んでいないか」**を疑います。指摘は二つ。

1. “13:17:15より前”のFWログに“e”がないかを確認

   • 狙い：同一C&C宛の通信履歴や類似挙動が無いかを遡って洗うこと。Pサービスは過去ログを蓄積しないため、“自社のログ蓄積サーバ側”で時系列を遡及確認する必要があります。

2. FWログだけでは検知できない状態もある → “Rログでも確認”

   • 例：感染はしたが、C&C通信を打つ前にネットワークから切り離された／あるいは通信が成立しなかったなど、FWログに痕跡が残らないケースでは、端末内の“プロセス実行・ハッシュ”記録で突き止める発想が必要。設問でもこの観点が問われます。

この問題が“具体的に”問うこと（設問の射程）

• 設問1：図2(2)(3)の行動目的を言語化できるか（なぜ電源OFF禁止？ なぜLANから切り離す？ → メモリ保全と拡散・漏えい抑止という“技術的理由”）。

• 設問2：表3のコマンドと目的（初期調査／探索／回避）の対応づけができるか（端末調査・横展開準備の文脈理解）。

• 設問3：

  1. “e”に何を探せと言っているか（該当C&C IPとの通信履歴などの具体化）、

  2. FWログで拾えない状態の定義、

  3. Rログでの検知手順（ハッシュ検索など）を短く正確に言い切る力。

重要キーワードと読み替え

• C&C（Command & Control）：攻撃者の指令サーバ。ここへの通信検知は**感染後の“生存確認ビーコン”**の合図になりやすい。

• データサイズ（200B）：少量の定期ビーコンの典型。巨大であれば持ち出しを疑う。

• EDR的なRシステム：プロセス・ハッシュ・外向き先の三点把握で端末内の事実関係を後追いできる。ハッシュ登録＝実行抑止が再発防止の肝。

• Pサービスの限界：リアルタイム検知は強いが、ログ蓄積・遡及分析は不可。過去調査は自社のログ蓄積サーバ＋Rログ検索で補完する設計。