【情報処理安全確保支援士試験令和3年度秋期午後2 問2 No.3】

情報処理安全確保支援士試験令和3年度秋期午後2 問2

【出典：情報処理安全確保支援士試験令和3年度秋期午後2 問2（一部、加工あり）】

[インシデントの発生]
9月11日、情報システム部のシステム管理者であるCさんは、差出人が総務部のDさんと表記されたメールを受信した。メールの文面に違和感を覚えたCさんが、念のためDさんに電話で確認したところ、”そのようなメールは送信していない”という回答だった。Cさんは、すぐさまA社のCSIRTに報告した。報告を受けたCSIRT所属のEさんは、調査を行い、Dさんの証言やBサービスの利用履歴などからDさんのBサービスのアカウントが第三者に不正利用されている可能性が高いと判断した。Eさんは、情報システム部のCさんに、Dさんのアカウントの無効化装置を依頼した。その後、契約中のセキュリティベンダX社に所属する情報処理安全確保支援士（登録セキスペ）のP氏の支援を受け、9月16日に図8に示す初期調査結果をまとめた。

同日、X社からマルウェアの解析結果が報告された。マルウェアα及びマルウェアβのどちらにもA社を標的にしたと思われる識別文字列、A社固有のファイルパス、並びにC＆CサーバのIPアドレス及びFQDNのリストが埋め込まれていた。また、どちらもA社が導入しているマルウェア対策ソフトでは検出されなかった。報告されたマルウェアの特徴を表2に示す。

A社は重大なインシデントが発生したと判断し、社内規程に従い緊急対策本部（以下、対策本部という）を設置した。

[インシデントへの対策の検討]
このインシデントでは、DさんがBサービスに脆弱なパスワードを設定していたことに加えて、新NWの導入に際してのBサービスの設定変更も攻撃が成功してしまった要因であることが分かった。
対策本部長（以下、本部長という）は、初期調査結果及びマルウェアの特徴をメンバと共有し、優先すべき対策を表3のように整理した。

次は、対策本部会議での、本部長、対策本部のメンバのGさん及びP氏の質疑である。

本部長：対策1については、どのように行うのか。

Gさん：マルウェアαとマルウェアβにはC＆CサーバのIPアドレスとFQDNのリストが埋め込まれていました。そのIPアドレス、及びそのFQDNのDNSの正引き結果のIPアドレスの二つを併せたIPアドレスのリスト（以下、IPリストという）を手作業で作成しておき、IPリストに登録されたIPアドレスへの通信をUTMで拒否します。

P氏：その対策だけでは、③攻撃者が行う設定変更によって、すぐにマルウェアαやマルウェアβの通信を遮断できなくなることが考えられます。④そこで、UTMでの通信拒否に加えて、追加の暫定対策として、UTMのDNSシンクホール機能の有効化を推奨します。

本部長：では、両方の対策を実施しよう。次に、対策2については、どのように行うのか。

Gさん：まず感染を確認するために、イベントログにαログ又はβログが存在するかどうかをチェックする確認ツールを作成してA社内に配布し、従業員に実行してもらいます。

P氏：イベントログに（f）が存在するかどうかもチェックする必要があると思います。さらに、確認ツールは暫定対策として有効ですが、全ての感染を確認できるわけではありません。⑤確認ツールを実行し、問題がないと判定されたPCやサーバであっても、その後、別のPCやサーバに感染を拡大させることが考えられます。

本部長は、確認ツールとは別に、より高い精度でマルウェアα及びマルウェアβを検出し、駆除できるツール（以下、駆除ツールという）の開発をX社に委託することにした。P氏は、開発する駆除ツールは、ディジタルフォレンジックスの経験を有する技術者だけが扱うことができるツールになることを説明した。
P氏は、対策本部会議の恒久対策に関する質疑の際に、将来的には連携サーバをDCのDMZに移設し、連携FWを廃止する検討をした方がよいとの意見を述べた。その理由として、⑥インターネットから連携サーバが攻撃を受けたときに、より迅速な対応が可能であることを挙げた。
その後の対策本部会議の質疑の中で、連携サーバ自体が感染していなくても連携サーバ経由で、会員にもマルウェアβの感染を拡大させている可能性が指摘された。本部長は、Eさんに、早急に連携サーバ経由の感染状況を確認し、感染拡大を防止するよう指示した。

下線③について、どのような設定変更か。40字以内で具体的に述べよ。：マルウェア内にFQDNで指定したC＆CサーバのIPアドレスの変更

「その対策だけでは、③攻撃者が行う設定変更によって、すぐにマルウェアαやマルウェアβの通信を遮断できなくなることが考えられます。」
その対策とは、対策1「C＆Cサーバへの通信の遮断」として「マルウェアαとマルウェアβにはC＆CサーバのIPアドレスとFQDNのリストが埋め込まれていました。そのIPアドレス、及びそのFQDNのDNSの正引き結果のIPアドレスの二つを併せたIPアドレスのリスト（以下、IPリストという）を手作業で作成しておき、IPリストに登録されたIPアドレスへの通信をUTMで拒否します。」と記述されているものです。
C＆CサーバのIPアドレスについては、マルウェアで直接指定されたIPアドレスと、FQDNのDNSの正引き結果のIPアドレスが該当し、これをUTMで通信を遮断しようとしています。
後者のFQDN（Fully Qualified Domain Name）はドメイン名であり、これに対応するIPアドレスは、DNSのAレコードでサーバ管理者が指定することが可能です。
つまり、攻撃者がC＆CサーバのIPアドレスをDNSのAレコードで自由に変更することで、上記の対策のIPリストから外れ、マルウェアが変更後のC＆CサーバのIPアドレス宛の通信を遮断できなくなります。

下線④について、DNSシンクホール機能を有効化した場合でも、UTMでの通信拒否が必要な理由を、マルウェアの解析結果を踏まえて40字以内で具体的に述べよ：C＆Cサーバとの通信時にDNSへの問合せを実行しない場合があるから

「④そこで、UTMでの通信拒否に加えて、追加の暫定対策として、UTMのDNSシンクホール機能の有効化を推奨します。」
UTMのDNSシンクホール機能について確認します。

表1から「DNSシンクホール機能：DNSクエリをチェックし、危険リストに登録されているFQDNの場合は、正規の名前解決を行わずにA社があらかじめ用意したIPアドレスを応答する。危険リストは、日次で自動更新される。」とあります。
この機能は、前の設問で示した「C＆CサーバのIPアドレスについては、マルウェアで直接指定されたIPアドレスと、FQDNのDNSの正引き結果のIPアドレスが該当」の後者に対する対策として有効なものです。
一方、前者に対してはDNSへの問い合わせを実行しないため、UTMのIPリストによる通信の遮断が必要となります。

f（20字以内）：イベントログの消去を示すログ

「イベントログに（f）が存在するかどうかもチェックする必要があると思います。」
対策2「マルウェアαおよびマルウェアβの駆除」として「まず感染を確認するために、イベントログにαログ又はβログが存在するかどうかをチェックする確認ツールを作成してA社内に配布し、従業員に実行してもらいます。」という発言に対するものです。
イベントログについては、表2（マルウェアの特徴）に「マルウェアα：このとき、イベントログにマルウェアαの実行を示すαログが記録される。」「マルウェアβ：このとき、イベントログにマルウェアβの実行を示すβログが記録される。」とあり、まずはαログ、βログが存在するかどうかをチェックすることは必要です。
さらに、図8（初期調査結果（概要））に「一部の業務PCでは、全てのイベントログが消去された痕跡があった。全てのイベントログが消去された後、イベントログにイベントログの消去を示すログが記録されていた。」とあります。

一時的にイベントログにαログ、βログが記録されますが、全てのイベントログが消去されることでαログ、βログも消去されてしまう可能性があります。
その場合であってもイベントログの消去を示すログが記録されるため、これをチェックすればマルウェアα、マルウェアβの感染を確認することができます。

下線⑤について、問題がないと判定されるのは、PCやサーバがマルウェアβに感染後、マルウェアβがどのような挙動をしていた場合か。25字以内で具体的に述べよ。：横展開機能と待機機能だけを実行していた場合

「⑤確認ツールを実行し、問題がないと判定されたPCやサーバであっても、その後、別のPCやサーバに感染を拡大させることが考えられます。」
確認ツールは、イベントログにαログ又はβログが存在するかどうかをチェックすることと、前の設問でのイベントログを消去を示すログをチェックするものでした。
表2（マルウェアの特徴）のマルウェアβについてイベントログに関するもの確認すると、⑶遠隔操作機能のみβログが記録されますが、⑴待機機能と⑵横展開機能ではβログが記録されていないことが分かります。
したがって、マルウェアβが待機機能と横展開機能だけを実行していた場合には、確認ツールを実行してもチェックできないことになります。

下線⑥について、可能である理由を45字以内で具体的に述べよ。：UTMのIDS機能によって攻撃が検知でき、システム管理者に連絡がされるから

「P氏は、対策本部会議の恒久対策に関する質疑の際に、将来的には連携サーバをDCのDMZに移設し、連携FWを廃止する検討をした方がよいとの意見を述べた。その理由として、⑥インターネットから連携サーバが攻撃を受けたときに、より迅速な対応が可能であることを挙げた。」
DCのDMZ、連携サーバ、連携FWについて、確認していきます。
まず、DCのDMZは図1のとおり、UTMを経由して通信する位置付けになっています。
インターネットからDMZのサーバが攻撃を受けたときに迅速な対応が可能になるということに着目して、UTMの機能を表1から確認すると、IDS機能に「全てのインバウンド通信をチェックし、不審な通信を検知した場合は、システム管理者に通知する。」とあります。

次に、連携サーバ、連携FWの構成と情報連携の手順を図3、図4で確認します。

また、図4の後に「連携サーバは、研究部が管理する連携FWを経由してインターネットに接続されている。連携FWでは、会員から伝えられたグローバルIPアドレス及び研究部セグメントから連携サーバへのアクセスだけを許可している。」とあります。
これらの記述から、インターネットから連携サーバが攻撃を受けたとき、その検知には連携サーバや連携FWのログを確認したタイミングでしか取れなさそうです。
したがって、連携サーバをDMZに移設すると、UTMのIDS機能で攻撃を検知でき、システム管理者に通知することで迅速な対応が可能になることになります。