令和元年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問3｜電源を切ってはいけなかった——情報処理安全確保支援士で学ぶ標的型攻撃とインシデント対応の実例

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和元年度（2019年）秋期 情報処理安全確保支援士試験 午後Ⅰ 問3
• 主なテーマ: 標的型攻撃、C&Cサーバ通信、揮発性情報の保全（フォレンジック）、感染拡大（ラテラルムーブメント）、ハッシュ値によるIoC検索、インシデント対応手順の改善

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

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

標的型攻撃という言葉は、いまや経営会議の場でも珍しくありません。けれども、「対策製品を入れたから安心」と考えている組織は、まだまだ多いのではないでしょうか。情報処理安全確保支援士試験の午後Ⅰで出題されたこの事例は、その思い込みを正面から揺さぶります。

舞台となるのは、ビッグデータ解析を専門とする調査会社です。一度、標的型攻撃によって秘密情報を外部に流出させ、48時間も業務を止めるという痛手を負いました。その反省から監視サービスとマルウェア対策製品を導入し、インシデント対応手順を整備します。そして数週間後、再び攻撃の兆候が現れたとき、担当者は手順どおりに動きました。ところが、その手順にすら見落としがあったのです。

この記事を読むと、標的型攻撃がどのように進行するのか、なぜ感染したPCの電源を切ってはいけないのか、データサイズという一見地味な数字から何を読み取るのか、そして「一台を封じ込めれば終わり」ではないインシデント対応の本質が見えてきます。受験者にとっては揮発性情報の保全やハッシュ値によるログ検索といった頻出論点が詰まっており、経営者にとっては「製品導入は対策の始まりであって終わりではない」という現実を突きつける教材になります。

インシデントの概要

主人公となるのは、ビッグデータ解析を専門とする従業員150名の調査会社、J社です。J社の従業員は、情報収集のためのWebアクセスと、営業活動や情報交換のための社外との電子メール送受信に、日常的にインターネットを使っていました。情報セキュリティポリシ（組織として守るべきセキュリティの方針や規則をまとめた文書）も整備し、運用していた——つまり、決してセキュリティに無頓着な会社ではありませんでした。

それでも、攻撃は起こりました。20XX年3月、J社は標的型攻撃を受けます。標的型攻撃とは、不特定多数にばらまくのではなく、特定の組織を狙い撃ちにして、業務メールを装ったりして時間をかけて侵入を試みる攻撃です。あるPCがマルウェア（コンピュータに害を与える不正なプログラム）に感染し、業務サーバ上の秘密情報を外部へ送信してしまいました。

被害が確認されたあとの対応も、決して軽くありませんでした。情報システム部（以下、情シ部）は感染状況を調査し、感染が確実なPCだけでなく、感染が疑わしいPCも合わせて40台ものPCを初期化します。調査を始めてから初期化を完了するまでに48時間。その間、業務は停止せざるを得ませんでした。データ解析を生業とする会社にとって、2日間の業務停止が何を意味するかは想像に難くありません。

事態が一段落したところで、J社は情報セキュリティコンサルティング会社のK社にアドバイスを求めます。ここから、この事例の本題である「次に同じことが起きたら、どう食い止めるか」という物語が始まります。

何が起きたのか

K社の担当コンサルタントは、情報処理安全確保支援士（登録セキスペ）の資格を持つN氏でした。N氏はJ社に対し、過去の標的型攻撃への対応事例を示したうえで、一つの本質的な助言をします。それは「感染予防だけに頼ってはいけない」ということでした。

標的型攻撃のマルウェアは巧妙で、どれだけ入口を固めても侵入を100%防ぐことはできません。だからこそ、侵入されることを前提に、その後の動きを止める発想が要る。N氏は具体的に、マルウェアが外部のC&Cサーバ（Command and Control。攻撃者がマルウェアに指令を送ったり、盗んだ情報を受け取ったりするための外部の司令塔サーバ）と通信を開始しようとする段階や、ほかの機器へ感染を拡大しようとする段階で検知し対処できれば、情報漏えいの被害を軽減できると伝えました。

この助言を受けて、J社は二つの仕組みを導入します。一つは、ITサービス会社P社が提供する監視サービス（以下、Pサービス）。もう一つは、マルウェア対策ソフトベンダR社が提供するマルウェア対策製品（以下、Rシステム）です。あわせてインシデント対応手順などの規則類も改定しました。この作業は情シ部のE部長の指示のもと、Gさんら3名が担当します。

ここで、導入された二つの仕組みの役割を押さえておきましょう。Pサービスは、J社のFW（ファイアウォール。通信を許可・拒否で振り分ける関所のような装置）のログを受け取って分析し、C&Cサーバへの通信を検知すると、情シ部員に電子メールと電話で通知してくれます。通知される内容は、C&Cサーバへの接続日時、送信元のIPアドレス、宛先のC&CサーバのIPアドレス、ポート、そしてデータサイズの5項目です。ただしPサービスはFWのログを蓄積せず、過去に遡っての分析は行いません。あくまで「いま流れている通信」を見張る役割です。

一方のRシステムは、管理サーバとエージェントプログラムで構成されます。エージェントプログラムはPCと業務サーバに導入され、すべてのプロセス（実行中のプログラム）の生成から終了までの動作、実行したプログラムのハッシュ値（データから計算される固有の指紋のような値。同じファイルなら必ず同じ値になる）、そして通信の宛先IPアドレスとポートを、ログ（以下、Rログ）として記録し、ログ蓄積サーバに送ります。さらに、J社がマルウェアのハッシュ値を入手して管理サーバに登録すると、エージェントはそのマルウェアの実行を禁止します。加えて、Rログをハッシュ値で検索し、そのマルウェアが実行された痕跡を調べることもできます。Rシステムは、いわば各端末の行動を逐一記録し続ける監視カメラのような存在です。

そして、PサービスとRシステムを導入して数週間が経った20XX年10月8日、Pサービスから一本の通知が届きます。「C&Cサーバへの通信を検知した」——。Gさんは、改定された手順に従って対応を開始しました。

通知が届いたのは13時27分。内容を見ると、C&Cサーバへの接続日時は同日13時17分15秒、送信元IPアドレスは192.168.1.20、宛先のC&CサーバのIPアドレスはw1.x1.y1.z1（グローバルIPアドレス。インターネット上で一意に割り当てられる住所）、ポートは80/tcp、データサイズは200バイトでした。Web通信に使われる80番ポート経由で、社内の一台が外部の司令塔と接触したのです。

Gさんはまず、送信元IPアドレスの正体を突き止めます。13時43分、IPアドレス管理台帳で192.168.1.20を調べると、営業部の従業員Lさんが使うPC——以下、L-PC——だと分かりました。13時49分、GさんはLさんに電話を掛け、ある指示を出します。「L-PCの電源は入れたまま、LANケーブルだけを抜いてください」。

ここが、この事例で最も象徴的な場面です。普通の感覚なら、感染した疑いのあるPCは真っ先に電源を落としたくなります。けれどもGさんは、電源を維持したまま、ネットワークからだけ切り離させました。なぜそうしたのか——その理由は、後ほど設問の解説で明らかにします。

続いて14時03分、Gさんは宛先がw1.x1.y1.z1の通信を拒否するフィルタリングルールをFWに登録します。たとえ他にこのC&Cサーバへ通信しようとする端末があっても、関所でせき止められるようにしたのです。

14時28分、FWのログを確認すると、C&Cサーバへ送信されたデータサイズはPサービスの通知どおり200バイトでした。情報漏えいの規模を見積もるうえで、この「200バイト」という小ささは重要な手がかりになります。

そして14時42分、GさんはRログの出番を迎えます。13時17分15秒前後のRログを確認し、C&Cサーバに接続したプログラムを「マルウェアM」として特定しました。同時に、L-PC上でマルウェアMによって、いくつものコマンドが実行されていたことも判明します。`ipconfig /all`、`systeminfo`、`tasklist`、`dir /a`、`net view`——これらはいずれも、攻撃者が侵入先の環境を下調べするために使う、いわゆる偵察コマンドの典型でした。攻撃者がL-PCの中で、次の一手のために情報を集めていた様子が、ログから生々しく浮かび上がってきたのです。

14時58分、GさんはマルウェアMのハッシュ値を管理サーバに登録しました。これで、もし他の端末で同じマルウェアMが動こうとしても、Rシステムが実行を禁止します。Gさんはここまでの対応を報告書にまとめ、E部長に提出しました。

物語は、ここで終わりません。報告書を読んだE部長は、他社での標的型攻撃への対応事例と比較して、「この対応では不十分だ」と考えます。E部長が投げかけたのは、こういう問いでした。「ほかにもマルウェアMに感染したPCやサーバがある場合を、想定する必要があるのではないか」。

Gさんは答えます。「13時27分以降、Pサービスから新たな通知は来ていません。感染したのはL-PCだけと考えてよいのでは」。一見、もっともな推論です。しかしE部長は、ここに落とし穴があることを見抜いていました。Pサービスが検知できるのは「これからC&Cサーバへ通信しようとする端末」だけ。すでに感染していても、まだC&Cサーバと通信していない端末は、Pサービスの網にかからないのです。

E部長は二つの確認を指示します。一つは、13時17分15秒より前のFWのログに、あるものが含まれていないかを調べること。もう一つは、それだけでは取りこぼすケースがあるため、Rログを使った確認も併用すること。Gさんはログを精査し、結果として「ほかに感染したPCやサーバは発見されなかった」とE部長に報告しました。最終的にE部長は、感染端末を特定するためのログ調査手順を、インシデント対応手順に正式に追加するよう指示します。こうしてJ社のインシデント対応手順は、もう一段階、改善されたのです。