情報処理安全確保支援士 2018年 秋期 午後2 問02
セキュリティインシデントへの対応に関する次の記述を読んで、設問1~5に答えよ。
A社は、玩具を製造販売する従業員数1,500名の企業である。A社の組織図を図1に示す。

A社は、情報セキュリティ基本方針を定めており、これに従い、情報セキュリティ委員会を設けている。情報セキュリティ委員会は、A社の情報セキュリティについて意思決定する。情報セキュリティ委員会の委員長は社長、委員は各部の部長であり、事務局は総務部が担当する。情報セキュリティ委員会は、下部組織として、セキュリティインシデント(以下、インシデントという)に対応する非常時対応チームをもつ。非常時対応チームには、各部の代表者が参加する。ただし、非常時対応チームが取り扱うべきインシデントの範囲や、具体的な活動内容は明文化されていない。これまでのところ、非常時対応チームの活動実績は極めて少ない。
〔ネットワーク構成〕
A社は、国内に本社を置き、海外に工場をもつ。A社のネットワーク構成を図2に示す。
A社本社のネットワークに接続する機器には、サーバ、ネットワーク機器及びPCがある。各部は、必要に応じて部門サーバをサーバLANに設置し、業務に利用している。各部の部門サーバは、各部が管理している。開発部は、開発部の部門サーバに加えて、開発用サーバを設置し、管理している。部門サーバと開発用サーバ以外のサーバ、全てのネットワーク機器及び全てのPCは、システム部が管理している。各部でシステム管理者を任命し、そのシステム管理者が適切に機器を管理するというのがA社の機器管理方針である。
DMZに設置されたサーバにはグローバルIPアドレスが付与され、インターネットとの間で通信できる。DMZ以外に設置された機器には固定のプライベートIPアドレスが付与され、インターネットとの間の直接の通信はFWによって禁止されている。ただし、業務PC-LANに接続されたPCは、プロキシサーバを介してインターネットにアクセスできる。プロキシサーバは直近60日分のログを保存している。開発LANからDMZへの通信は、FWによって禁止されている。
〔情報漏えいの発生〕
2018年9月11日、A社において、インシデント(以下、本インシデントをインシデントPという)が発覚した。この日、A社の商品問合せ窓口に、A社の発売前の新製品αの操作説明書(以下、漏えい文書Xという)がインターネットの掲示板Uに投稿されている旨の通報が寄せられた。開発部の担当者が確認したところ、投稿されていたのは間違いなくA社のもので、開発過程で作成された文書であることが分かった。
情報セキュリティ委員会は、インシデントPへの対応方法を議論した。同委員会は、次の理由から、非常時対応チームではなく、当該文書を所管する開発部がインシデントPに対応することを決定した。
・個人情報及び重要な秘密情報の漏えいは見つかっておらず、緊急度及び重要度は低い。
・社内での調査活動について、非常時対応チームの権限及び調査手順が明確に定められておらず、調整が必要である。
・非常時対応チームのメンバの多くは、本来の業務のため、対応する時間の確保が難しい。 開発部は、急きょ、インシデントPに対応するためのチーム(以下、開発部対応チームという)を立ち上げ、対応を開始した。同チームの調査結果と措置状況を図3に示す。

開発部対応チームの調査結果と措置状況は情報セキュリティ委員会に報告された。報告を受けて、委員会では、図3中の(5)に挙げられた一連の措置の完了をもってインシデントPへの対応を終了することが了承された。また、インシデント対応能力の向上を目指すことを決め、システム部のG部長に対応を指示した。
〔早期に取り組むべき事項のとりまとめ〕
G部長は、情報セキュリティ委員会の承認の下、情報セキュリティに関わるコンサルティングサービスを提供するE社に支援を依頼した。
E社のコンサルタントであるF氏は、A社がインシデント対応能力の向上のために早期に取り組むべき事項を図4のとおりまとめ、G部長に報告した。
〔インシデント対応能力の向上への取組み〕
G部長は、図4の事項の具体化を、F氏の支援を受けながら進めることにした。
インシデント対応ポリシの適用範囲は全社とした。非常時対応チームは、A社におけるインシデント対応のための組織横断チーム(以下、A-CSIRT という)として、再編成することにした。インシデント対応ポリシでは、A-CSIRT 及び各部の役割、責任及び権限レベルを規定した。A-CSIRTは、従来の非常時対応チーム同様、各部の代表者で構成することにした。ただし、インシデントへの迅速な対応を可能にするため、各部で人選を見直し、更にシステム部所属のメンバを増やした。A-CSIRTのリーダはG部長が務めることにした。メンバのスキルを高めるため、定期的に勉強会を開催し、外部の研修などにも積極的に参加してもらう方針を立てた。
ログについては、ログの管理に関する規程(以下、ログ管理ポリシという)を作成することにした。ログ管理ポリシの適用対象は、社内の全ての機器であり、システム部が管理する機器、部門サーバ及び開発用サーバも含まれる。ログ管理ポリシでは図3中の(6)dに挙げられたログに関わる課題を解決できるように、次の要件を定める。 要件1 取得するログについての要件
・fについて
・gについて
要件2 取得したログについての要件
・hについて
・バックアップの作成について
・アクセス制御について
要件3 各機器の時計を同期するとともに、各機器が出力するログに記録する時刻情報のiをjするという要件
情報セキュリティ委員会は、各部に対して、それぞれが管理する機器について、早急に、ログ管理ポリシに従った運用を開始するよう指示した。また、システム管理者に対して、①管理する機器について、通常時のネットワークトラフィック量や日、週、月、年の中でのその推移などの情報(以下、通常時プロファイルという)の把握に努めるよう指示した。
〔マルウェアについての通知〕
マルウェアを配布していたサイト(以下、サイトMという)にA社の機器のうち1台がアクセスし、遠隔操作の機能をもつ、“new3.exe”というファイル名のマルウェアRをダウンロードした可能性がある旨の通知が、10月10日に、ある民間組織からA社に対してあった。伝えられたサイトMのIPアドレスはA社管理外のものであり、サイトMのログに残っていたアクセス元のIPアドレスはA社のプロキシサーバのものだった。この通知はA-CSIRTに伝えられ、インシデント対応ポリシに照らして判断した結果、A-CSIRTが、インシデント(以下、本インシデントをインシデントQという)として直ちに対応を開始することになった。
A-CSIRTのメンバであるシステム部のCさんが、外部のインシデント対応研修に参加して得た知識を基に手順を手探りしながらも調査したところ、次のことが分かった。
・9月4日14時30分頃、②業務PC-LANに接続されているPCであるPC-AがサイトMにアクセスし、“new3.exe”をダウンロードした。
・PC-Aの利用者は開発部のDさんである。
・プロキシサーバのログに、上記のダウンロードの直後、③PC-Aが特定のサイトにアクセスし、その後頻繁に同じサイトにアクセスを繰り返す様子が記録されていた。プロキシサーバのログのうち、送信元がPC-Aであるものを図6に示す。


Cさんは、直ちに④PC-Aをネットワークから切断して回収した。また、ここまでに分かったことを基に、kを調査して、マルウェアKがほかの機器にも感染している可能性を簡易的に確認した。
その後、Cさんは、試行錯誤しながら更に詳しく調査を進め、図7に示す調査結果を得た。




次は、これまでの調査結果についての、CさんとG部長との会話である。
Cさん:PC-Aが攻撃者によって遠隔操作されたことは間違いないと思います。また、PC-Bは、少なくとも、Dさんがオフィスに来ていなかった9月5日に攻撃者に遠隔操作されていたようです。
G部長:PC-Bで見つかったファイルAについては、どのように考えればよいか。
Cさん:ファイルAは、情報を社外に送信するために攻撃者が作成したと考えればよいと思います。しかし、PC-Bはインターネットにアクセスできないので、情報は社外に送信されなかったと思われます。
G部長:そうだろうか。例えば、ほかの機器を経由して送信された可能性はないのか。
Cさん:ほかの機器もいろいろと調査しましたが、ファイルAと同じ名前のファイルは見つかりませんでした。
G部長:ファイル名が同じとは限らない。ファイルが既に削除されている可能性もある。そういった可能性も考えて調査を続けてほしい。
Cさんは、Dさんが利用している機器について、フォレンジックツールを用いて、ファイルAのファイルサイズとlをキーにしてファイルを検索した。その結果、PC-Aにおいて、9月8日3時35分に、ファイル名は異なっていたものの、ファイルAと同じ内容のファイルが作成されていたことが分かった。また、プロキシサーバのログから、⑥当該ファイルが社外に送信された可能性があることが分かった。
加えて、Cさんがインターネット検索をしたところ、ファイルAに格納されていた複数のファイルが、掲示板Uに、インシデントPのときと同じ投稿者によって投稿されていたことが分かった。これらのファイルのうち幾つかは、USBメモリRに格納されたことはないと考えられるものだった。
〔インシデントQのタイムラインと措置〕
G部長は、調査結果の確認及び対応措置の検討についてF氏の支援を受けるようCさんに指示した。F氏の支援を受けてCさんが作成したインシデントQのタイムラインを表2に示す。


また、F氏による追加調査の結果、社内の文書Zが、9月22日までの間に、攻撃者によって社外に送信されていたことが確認された。文書Zは、それまでに漏えいしたものとは別の新製品βの設計書である。
Cさんは、F氏の支援を受け、インシデントの封じ込め、根絶及び復旧のための措置を検討した。マルウェアLとマルウェアKについては、Y社から、これらを検知するためのマルウェア定義ファイルの提供を受け、全てのサーバ及びPCに適用することにした。Cさんは、そのほか必要と思われる措置をまとめて、G部長に提案した。
G部長は、Cさんの提案を承認し、承認された措置が実施された。
〔インシデント対応のレビュー]
インシデントQの対応が一段落した後、インシデント対応ポリシに従い、インシデントQの対応についてレビューが開催された。レビューにおいて、最初にG部長から、インシデントPとインシデントQは一連の攻撃だと推定されるという報告があった。次にインシデントQの対応が報告された。インシデントQの対応は、インシデントPの対応に比べて大幅に改善されたとの評価を受け、インシデント対応能力が向上してきていると判断された。最後に、⑦インシデント対応能力について未対応の課題を解決するための措置がまとめられ、順次実施されていくことになった。
設問1:〔早期に取り組むべき事項のとりまとめ〕について、(1)、(2)に答えよ。
(1)図4中のa、bに入れる適切な字句を、解答群の中から選び、記号で答えよ(aとbは順不同)。
解答群
ア:ISOJEC15408のPPの作成
イ:教育と意識向上
ウ:情報セキュリティポリシの管理
エ:侵入検知
オ:内部統制基準の作成
カ:ネットワーク機器の保守
模範解答
a:エ
b:イ
解説
解答の論理構成
- 該当箇所の確認
【問題文】には、「インシデント対応チームが提供するサービスの例として、NIST SP 800-61 Rev. 2は、a、脆弱性や脅威についてのアドバイザリの配信、b、及び社内外での情報共有の推進を挙げている。」と記載されています。 - NIST SP 800-61 Rev. 2 の代表的サービス
同文書では CSIRT(Computer Security Incident Response Team)の典型サービスとして
・侵入の兆候を検知する「侵入検知」
・利用者の理解を深める「教育と意識向上」
などが例示されています。 - 解答群との照合
解答群には「エ:侵入検知」「イ:教育と意識向上」が存在し、両者とも上記サービスに完全合致します。 - 他の選択肢が不適切な理由
・「ISOJEC15408のPPの作成」「内部統制基準の作成」は CSIRT の日常サービスではなく、規格策定寄りの業務です。
・「情報セキュリティポリシの管理」「ネットワーク機器の保守」は組織全般の管理・運用に関する活動であり、CSIRT の代表的サービス例としては挙げられません。 - 以上より、a=「侵入検知」、b=「教育と意識向上」と決定できます。
誤りやすいポイント
- 「情報セキュリティポリシの管理」を CSIRT サービスに含めてしまう。ポリシ管理は経営層または統制部門の仕事であり、NIST での CSIRT 代表例には含まれていません。
- 「ネットワーク機器の保守」を“技術的だから CSIRT 向き”と誤判断する。保守は運用部門の通常業務であり、インシデント対応サービスとは区別されます。
- 「侵入検知」と「インシデントハンドリング」を混同し、後者の語を探してしまう。問題文はすでに「インシデントが発生した時点での対応活動」と別に記載しているため、空欄はそれ以外のサービスを問うています。
FAQ
Q: NIST SP 800-61 Rev. 2 における「教育と意識向上」は具体的にどのような活動を指しますか?
A: 社員向けのセキュリティ講習、メール訓練、啓発ポスター掲示、被害事例の共有など、利用者のリテラシ向上を目的とした取り組み全般を指します。
A: 社員向けのセキュリティ講習、メール訓練、啓発ポスター掲示、被害事例の共有など、利用者のリテラシ向上を目的とした取り組み全般を指します。
Q: 「侵入検知」は CSIRT 自ら実装・運用するものなのでしょうか?
A: 自前で IDS/IPS を運用する例もありますが、監視センターや SOC と連携しアラート分析・対応支援に特化する運用形態も一般的です。
A: 自前で IDS/IPS を運用する例もありますが、監視センターや SOC と連携しアラート分析・対応支援に特化する運用形態も一般的です。
Q: CSIRT サービスの例は組織規模で変わりますか?
A: 変わります。大規模組織はモニタリングや脆弱性診断まで内製化する場合がありますが、小規模組織では外部サービスと連携し、インシデント調整・連絡窓口機能に注力するケースもあります。
A: 変わります。大規模組織はモニタリングや脆弱性診断まで内製化する場合がありますが、小規模組織では外部サービスと連携し、インシデント調整・連絡窓口機能に注力するケースもあります。
関連キーワード: インシデント対応、CSIRT, 侵入検知、セキュリティ教育、NIST SP 800-61
設問1:〔早期に取り組むべき事項のとりまとめ〕について、(1)、(2)に答えよ。
(2)図5中のc〜eに入れる適切な字句を、解答群の中から選び、記号で答えよ。
解答群
ア:CVSSv3基本値
イ:SIEM
ウ:インシデント
エ:受付窓口
オ:個人情報
カ:情報公開
キ:情報システム部門
ク:ポリシ
ケ:マネジメント層
コ:優先順位付け
サ:ログと証跡
模範解答
c:ケ
d:ウ
e:コ
解説
解答の論理構成
-
図5の箇条書きを見ると、最初の項目は「cの責任表明」です。責任を公式に示すのは経営トップ・経営層であるため、「ケ:マネジメント層」が最も適切です。
――【問題文】「・cの責任表明」 -
次に「dと関連用語の定義」および「・dについてのe又は深刻度評価」という2か所で同じ語が入ります。どちらも“何をインシデントと見なすか/インシデントの深刻度をどう評価するか”という文脈なので、「ウ:インシデント」を当てはめるのが自然です。
――【問題文】「・dと関連用語の定義」
――【問題文】「・dについてのe又は深刻度評価」 -
最後に「e又は深刻度評価」で要求されるのは、発生した出来事を処理する順序付けの考え方です。解答群を見ると「コ:優先順位付け」が一致します。
――【問題文】「・dについてのe又は深刻度評価」
以上より、
c:ケ
d:ウ
e:コ
となります。
d:ウ
e:コ
となります。
誤りやすいポイント
- 「責任表明」を“ポリシ”や“情報システム部門”と誤読しがちですが、ガバナンス文書では経営者が責任を宣言することが求められます。
- “インシデント”という語が2か所に入ることに気付かず、別々の語を当てはめてしまうミスが起こりやすいです。
- “優先順位付け”を“深刻度評価”そのものと混同すると「ア:CVSSv3基本値」などスコアリング手法を選びたくなりますが、文中に“又は深刻度評価”と併記されているため別概念であると判別できます。
FAQ
Q: 「責任表明」とはどのような内容を指すのですか?
A: 経営層が情報セキュリティやインシデント対応の重要性を宣言し、ポリシを遵守する責務を負うと明言する部分です。トップマネジメントのコミットメントを示すことで、全社的な取組みを後押しします。
A: 経営層が情報セキュリティやインシデント対応の重要性を宣言し、ポリシを遵守する責務を負うと明言する部分です。トップマネジメントのコミットメントを示すことで、全社的な取組みを後押しします。
Q: “インシデントの優先順位付け”と“深刻度評価”の違いは?
A: 深刻度評価は影響と発生確率を定量・定性的に評価する作業を指し、優先順位付けは複数のインシデントが並行して発生した際にどれから対処するかを決める行為です。文書では両者を併記し、どちらかの方式を採用することを示唆しています。
A: 深刻度評価は影響と発生確率を定量・定性的に評価する作業を指し、優先順位付けは複数のインシデントが並行して発生した際にどれから対処するかを決める行為です。文書では両者を併記し、どちらかの方式を採用することを示唆しています。
Q: CVSSを使った評価は不適切なのですか?
A: CVSSは脆弱性の深刻度評価指標であり、インシデントポリシの汎用的な“優先順位付け”項目に直接当てはまるとは限りません。ポリシはCVSSに限定せず、社内ルールで定める分類基準を記載するのが一般的です。
A: CVSSは脆弱性の深刻度評価指標であり、インシデントポリシの汎用的な“優先順位付け”項目に直接当てはまるとは限りません。ポリシはCVSSに限定せず、社内ルールで定める分類基準を記載するのが一般的です。
関連キーワード: インシデント対応、ポリシー策定、優先順位付け、深刻度評価、ガバナンス
設問2:〔インシデント対応能力の向上への取組み〕について、(1)〜(3)に答えよ。
(1)本文中のf〜hに入れる適切な字句を、それぞれ12字以内で答えよ(fとgは順不同)。
模範解答
f:ログを取得する機器
g:取得するログの種類
h:保存期間
解説
解答の論理構成
- 問題文では、ログ管理ポリシの要件を
“要件1 取得するログについての要件”
“要件2 取得したログについての要件”
と二段階に分けています。 - 要件1の箇条書きは「取得するログ」に対する観点なので、
・“どの機器でログを取得するか”
・“どのようなログを取得するか”
を定めると読み取れます。これを表す語句が
「ログを取得する機器」、「取得するログの種類」。 - 要件2は「取得したログ」に対する管理事項です。図3中(6)dでは
“取得していたログの種類や保存期間にはばらつきがあった。”
と明示され、ばらつき是正の代表項目が「保存期間」であることが示唆されています。 - 以上から
f:ログを取得する機器
g:取得するログの種類
h:保存期間
が順当な補充となります。
誤りやすいポイント
- 要件1と要件2の違いを見落とし、「保存期間」を要件1に入れてしまう。
- f と g の順番に着目しすぎ、語順で迷う。問題文は「順不同」と明言しています。
- 「保存期間」を「保管期間」「保有期間」などと書き換えてしまう。数字・固有名詞だけでなく語句も原文通りが原則です。
FAQ
Q: f と g の順番を逆に書くと減点になりますか?
A: 問題文に “f と g は順不同” とあるので、順序は採点に影響しません。
A: 問題文に “f と g は順不同” とあるので、順序は採点に影響しません。
Q: 「保存期間」は何年など具体値を書くべきですか?
A: 設問は字句補完なので具体値は不要です。ログ管理ポリシ策定時に個別設定します。
A: 設問は字句補完なので具体値は不要です。ログ管理ポリシ策定時に個別設定します。
Q: なぜ「バックアップの作成」や「アクセス制御」が h にならないのですか?
A: それらは要件2の残り二項目として既に明示されており、空欄は「保存期間」だけが該当します。
A: それらは要件2の残り二項目として既に明示されており、空欄は「保存期間」だけが該当します。
関連キーワード: ログ管理、保存期間、CSIRT, インシデント対応、ポリシ策定
設問2:〔インシデント対応能力の向上への取組み〕について、(1)〜(3)に答えよ。
(2)本文中のi、jに入れる適切な字句を、それぞれ8字以内で答えよ。
模範解答
i:タイムゾーン
j:統一
解説
解答の論理構成
- 問題文には次の記述があります。
各機器の時計を同期するとともに、各機器が出力するログに記録する時刻情報のiをjするという要件
- ログを横断的に突き合わせる際、機器ごとに時刻の基準が異なると分析が困難になります。特に「タイムゾーン」が異なると、同一時刻が別の日付として扱われることもあります。
- したがって“時刻情報”に関して 何を “どうする” かを埋めると、
- “何を”=タイムゾーン
- “どうする”=統一
となります。
- よって i は「タイムゾーン」、j は「統一」です。
誤りやすいポイント
- 「NTPで時刻を同期する」と読んで “i” に「時刻」や「時刻情報」と入れてしまう。空欄は既に “時刻情報の○○を” の形で使われているため、重複は不自然です。
- “j” に「同期」や「合わせる」などを入れてしまう。文中の前半で既に「時計を同期」と述べているため、後半は別の観点(基準の揃え方)を求めています。
- “UTC へ変換” と具体策を直接書くミス。設問は字句レベルでの要件を問うため、「統一」とまとめる方が適切です。
FAQ
Q: タイムゾーンを統一する機器はサーバだけで良いですか?
A: 問題文では「社内の全ての機器」がログ管理ポリシの適用対象とされているため、クライアントPCやネットワーク機器も含めて統一する必要があります。
A: 問題文では「社内の全ての機器」がログ管理ポリシの適用対象とされているため、クライアントPCやネットワーク機器も含めて統一する必要があります。
Q: “統一” する先は UTC と決め打って良いのでしょうか?
A: ポリシでは「統一すること」までを要件にし、具体的に UTC か JST かは運用設計で決定するのが一般的です。
A: ポリシでは「統一すること」までを要件にし、具体的に UTC か JST かは運用設計で決定するのが一般的です。
Q: NTP 同期だけで十分ではありませんか?
A: NTP は「時刻のズレ」を小さくする仕組みであり、タイムゾーン設定が異なるとログの表記時刻は依然として食い違います。両方を合わせて初めて一貫したログになります。
A: NTP は「時刻のズレ」を小さくする仕組みであり、タイムゾーン設定が異なるとログの表記時刻は依然として食い違います。両方を合わせて初めて一貫したログになります。
関連キーワード: タイムゾーン、NTP, ログ管理、CSIRT
設問2:〔インシデント対応能力の向上への取組み〕について、(1)〜(3)に答えよ。
(3)本文中の下線①について、取得した通常時プロファイルの利用方法を35字以内で具体的に述べよ。
模範解答
ネットワークトラフィック量と比較して異常を検知する。
解説
解答の論理構成
- 【問題文】は、情報セキュリティ委員会がシステム管理者へ
「①管理する機器について、通常時のネットワークトラフィック量や日、週、月、年の中でのその推移などの情報(以下、通常時プロファイルという)の把握に努める」
と指示しています。 - 通常時プロファイルは、“平常時の振る舞い”を数値化した基準値です。したがって活用場面は「実際の通信が基準から逸脱していないか」を判断する局面になります。
- インシデント対応では、早期検知が最重要課題です。基準値と当日のトラフィックを比較することで、マルウェア感染や情報漏えいにつながる異常通信を即時に発見できます。
- 以上から、取得したプロファイルは「比較用ベースライン」として利用し、異常検知に役立てるとの結論になります。
誤りやすいポイント
- プロファイルの用途を“容量計画”や“性能改善”と誤解し、インシデント検知との関連を示さない。
- 「ログ分析」だけに言及し、ネットワークトラフィックという具体的な比較対象を外してしまう。
- 「通常時と比較する」視点を欠き、単に「監視する」と記述してしまう。
FAQ
Q: 通常時プロファイルはどの単位で作成するべきですか?
A: 【問題文】にある通り「日、週、月、年」の推移を把握し、多角的に基準値を用意すると変動要因を吸収しやすくなります。
A: 【問題文】にある通り「日、週、月、年」の推移を把握し、多角的に基準値を用意すると変動要因を吸収しやすくなります。
Q: プロファイルと実測値はどのように比べればよいですか?
A: スループットやセッション数など主要指標ごとにしきい値を設定し、超過をイベントとしてSIEMや監視ツールに通知させる方法が一般的です。
A: スループットやセッション数など主要指標ごとにしきい値を設定し、超過をイベントとしてSIEMや監視ツールに通知させる方法が一般的です。
Q: プロファイル更新のタイミングは?
A: 業務変更やシステム増強時は再取得が必須です。定期的(例:四半期毎)に見直すことで現実の業務負荷に合った基準が維持できます。
A: 業務変更やシステム増強時は再取得が必須です。定期的(例:四半期毎)に見直すことで現実の業務負荷に合った基準が維持できます。
関連キーワード: ベースライン、異常検知、トラフィック監視、SIEM, しきい値設定
設問3:〔マルウェアについての通知〕について、(1)〜(7)に答えよ。
(1)本文中の下線②について、サイトMにアクセスしたPCを特定した方法を60字以内で具体的に述べよ。
模範解答
プロキシサーバのログからアクセス先がサイトMのエントリを抽出し、このエントリからPC-AのIPアドレスを特定。
解説
解答の論理構成
-
通知内容の確認
【問題文】には「サイトMのログに残っていたアクセス元のIPアドレスはA社のプロキシサーバのものだった。」とあり、外部にはプロキシサーバしか見えていないことが分かります。 -
調査対象の特定
A社内で外部アクセスの詳細を把握できるのは「プロキシサーバは直近60日分のログを保存している。」という記述からプロキシサーバのログであると判断できます。 -
ログの検索
プロキシログに含まれるリクエスト先 URL/IP をキーに、通知で示された「IPm=サイトM」へのアクセスエントリを抽出します。図6の No.6 と No.7 にが出ていることが確認できます。 -
内部 IP の把握
図6は「送信元がPC-Aであるものを図6に示す。」と明記されています。抽出したエントリの“送信元”欄に記録されていたアドレス「192.168.70.131」を資産台帳と突き合わせ、「業務PC-LANに接続されているPCであるPC-A」と判定しました。 -
結論
よって「プロキシサーバのログからサイトM(IPm)への通信を検索し、そのエントリに記載された送信元IP 192.168.70.131 を照合して PC-A を特定する」方法となります。
誤りやすいポイント
- FW や IDS のログを優先してしまい、Proxy ログを見落とす。
- 抽出条件を FQDN で検索し、IP アドレスしか記録されていない行を取り逃す。
- 送信元欄に NAT 後のアドレスが載ると誤解し、内部 IP が記録されている事実を見逃す。
- 資産台帳との対応付けを怠り、IP だけで PC 名を断定してしまう。
FAQ
Q: Proxy ログには必ず内部 PC の IP が残るのでしょうか?
A: 多くの環境では送信元 PC の IP または利用者 ID が記録されますが、設定次第です。設計時に要件を確認しておくことが重要です。
A: 多くの環境では送信元 PC の IP または利用者 ID が記録されますが、設定次第です。設計時に要件を確認しておくことが重要です。
Q: 通知にユーザエージェントなど追加情報があれば活用すべきですか?
A: はい。該当エントリを特定するヒントになりますが、本設問ではアクセス先 IPm をキーにするだけで十分でした。
A: はい。該当エントリを特定するヒントになりますが、本設問ではアクセス先 IPm をキーにするだけで十分でした。
Q: もし Proxy を経由しない機器があった場合はどう調べますか?
A: ルータや FW の NAT テーブル、NetFlow、エンドポイントログなど複数データを突き合わせて送信元を追跡します。
A: ルータや FW の NAT テーブル、NetFlow、エンドポイントログなど複数データを突き合わせて送信元を追跡します。
関連キーワード: プロキシログ解析、NAT, ログ相関、アクセス経路追跡、インシデントハンドリング
設問3:〔マルウェアについての通知〕について、(1)〜(7)に答えよ。
(2)本文中の下線③について、このアクセスによってマルウェアが何を行っていたと考えられるか。HTTPリクエストとHTTPレスポンスによってマルウェアが行っていた活動を、HTTPリクエストによる活動は30字以内で、HTTPレスポンスによる活動は20字以内でそれぞれ具体的に述べよ。
模範解答
HTTPリクエストによる活動:C&Cサーバへのコマンド要求又は応答
HTTPレスポンスによる活動:C&Cサーバからのコマンド受信
解説
解答の論理構成
-
ログの事実確認
・プロキシサーバのログには、"GET http://IPn/news.php HTTP/1.1" や "POST http://IPn/login/pro.php HTTP/1.1" のように、IPn への繰り返しアクセスが記録されています(図6)。 -
マルウェアの挙動
・表1において、new3.exe は「遠隔操作の機能をもつマルウェアKである。実行されると、IPnのサイトにアクセスして、そのレスポンスに従って動作する」と明記されています。
・したがって、IPn は攻撃者が用意した C&C(Command & Control)サイトとみなせます。 -
HTTPリクエスト側の意味付け
・マルウェアが C&C サーバに接続するとき、まず自分の状態を送信し「次に何をすればよいか」を問い合わせるのが一般的です。
・"POST http://IPn/login/pro.php" が存在するため、リクエストには「状態報告/命令要求」が含まれていると解釈できます。 -
HTTPレスポンス側の意味付け
・表1の「そのレスポンスに従って動作する」という記述より、レスポンスには実行すべきコマンドやパラメタが含まれていると分かります。 -
以上より、下線③に該当するアクセスは以下の活動を示唆します。【HTTPリクエストによる活動】C&Cサーバへのコマンド要求又は応答
【HTTPレスポンスによる活動】C&Cサーバからのコマンド受信
誤りやすいポイント
- 「POST なのでファイル送信」と早合点し、レスポンスの役割を見落とす
- IPn を単なる外部サイトと判断し、C&C 通信であることを見逃す
- 表1の「そのレスポンスに従って動作する」記述を引用忘れして根拠不足になる
FAQ
Q: POST があるのにファイル送信ではないのですか?
A: 今回はコマンド取得のためにも POST を使っています。ファイル送信は後続の別リクエストで行われる設計と推測できます。
A: 今回はコマンド取得のためにも POST を使っています。ファイル送信は後続の別リクエストで行われる設計と推測できます。
Q: GET と POST が混在していますが目的は同じですか?
A: はい。GET で定期ポーリング、POST で詳細な状態報告やコマンド受信といった役割分担が想定されます。
A: はい。GET で定期ポーリング、POST で詳細な状態報告やコマンド受信といった役割分担が想定されます。
Q: ログに 200 が返っているのは成功の証拠ですか?
A: 200 は HTTP レベルの成功を示し、マルウェアが C&C サーバとの通信に成功しコマンドを受け取った可能性を高めます。
A: 200 は HTTP レベルの成功を示し、マルウェアが C&C サーバとの通信に成功しコマンドを受け取った可能性を高めます。
関連キーワード: C&C通信、HTTPポーリング、遠隔操作、コマンド取得、データ送信
設問3:〔マルウェアについての通知〕について、(1)〜(7)に答えよ。
(3)本文中の下線④について、調査の観点から見たときの問題は何か。40字以内で具体的に述べよ。また、この問題を軽減するために本文中の下線④を実行する前に行うべき措置を、30字以内で具体的に述べよ。
模範解答
問題:PCのネットワークインタフェースや通信の状態についての情報が失われること
措置:メモリダンプを取得する。
解説
解答の論理構成
- インシデントQの初動で、A-CSIRTメンバのCさんは
「④PC-Aをネットワークから切断して回収した。」
と記録されています。 - 切断によって PC-A と外部との通信は即座に止まりますが、同時に
- ネットワークインタフェースの統計情報(送受信バイト数・エラー数)
- 宛先IPやポートを保持するコネクションテーブル
- RAM 上に存在するプロセスの通信中データ
など揮発性情報が消失します。
- これらは「遠隔操作の有無や攻撃者の接続元」を裏付ける重要証跡であり、調査の観点では 失われる=問題 となります。
- 消失を避けるには、切断前にメモリ内容を保存する手順(メモリダンプ取得)を実施し、RAM 内のコネクション情報を確保しておく必要があります。
誤りやすいポイント
- 物理的切断=安全確保だけに着目し、証跡保全の優先度を見落とす。
- ハードディスクのイメージ取得だけで十分と誤解し、メモリ内通信情報の一時性を忘れる。
- 先に電源を落とせば痕跡が残ると勘違いしてしまう。
FAQ
Q: 取得したメモリダンプからは具体的に何が得られますか?
A: OS の ARP/ルーティング表、未書き込みのログバッファ、マルウェアのプロセス本体、暗号化前の通信データなどが確認できます。
A: OS の ARP/ルーティング表、未書き込みのログバッファ、マルウェアのプロセス本体、暗号化前の通信データなどが確認できます。
Q: オフライン化せずにそのまま調査を続けるのは危険では?
A: 通常はダンプ→切断→詳細調査の順に行います。ダンプ取得は数分で終了し、リスクを大きく増やしません。
A: 通常はダンプ→切断→詳細調査の順に行います。ダンプ取得は数分で終了し、リスクを大きく増やしません。
Q: ダンプが取得できない状況ではどう対処すべきですか?
A: ネットワークタップやポータブルパケットキャプチャ装置を接続して短時間だけ通信を記録する方法があります。
A: ネットワークタップやポータブルパケットキャプチャ装置を接続して短時間だけ通信を記録する方法があります。
関連キーワード: メモリダンプ、揮発性情報、フォレンジック、コネクションテーブル、証跡保全
設問3:〔マルウェアについての通知〕について、(1)〜(7)に答えよ。
(4)本文中のkに入れる適切な調査内容を、40字以内で具体的に述べよ。
模範解答
k:プロキシサーバのログから、IPnのサイトにアクセスした機器がほかにないか
解説
解答の論理構成
- 調査の目的を確認
- 【問題文】「マルウェアKがほかの機器にも感染している可能性を簡易的に確認した」とあるため、感染判定の“手掛かり”を短時間で探す必要があります。
- マルウェアKの特徴を抽出
- 表1「new3.exe…IPnのサイトにアクセスして、そのレスポンスに従って動作する」とあり、感染端末は必ず IPn と通信します。
- 全社的に取得できる通信ログを選定
- 【問題文】「プロキシサーバは直近60日分のログを保存している」。
- 業務PC-LANに接続された PC はインターネットへは必ずプロキシサーバ経由で通信する設計です。
- 感染端末の特徴的通信をキーに検索
- 図6 に示された PC-A のログには IPn との頻繁な HTTP GET/POST が残っており、これがマルウェアK動作の痕跡であると判断できます。
- 結論
- 従って「プロキシサーバのログを調べ、IPn にアクセスした別の機器が存在しないか」を調査するのが最も効果的であり、k には模範解答の文が入ります。
誤りやすいポイント
- 「マルウェアKがダウンロードされたサイトMへのアクセス有無」を調べると誤答になる
IPm はダウンローダ段階の接触先であり、感染後は IPn との通信が継続するため指標として弱いです。 - 「FW や L3SW のログ」を優先する誤り
これらはインターネット向け HTTP の詳細を把握していない前提の構成なので感染判定には適しません。 - 「全端末をスキャン」と書くと“簡易的確認”の条件を満たさず意図と外れます。
FAQ
Q: IPn ではなく FQDN を条件に検索しても良いですか?
A: IPn が提示されており、C&C サイトが IP アドレスで記録されているため IP ベースで検索するのが確実です。
A: IPn が提示されており、C&C サイトが IP アドレスで記録されているため IP ベースで検索するのが確実です。
Q: 開発LAN の PC は直接インターネットへ出られないが調査対象に含めるのですか?
A: はい。開発LAN から DMZ 方向は遮断されていますが、業務PC-LAN 経由で Web に出る端末がある可能性もあるため全ログを横断的に確認します。
A: はい。開発LAN から DMZ 方向は遮断されていますが、業務PC-LAN 経由で Web に出る端末がある可能性もあるため全ログを横断的に確認します。
Q: PC-A を切断した後でログを追加取得できますか?
A: PC-A を物理隔離してもプロキシサーバ側のログは保全されているため、そこから過去の通信状況を遡って調査可能です。
A: PC-A を物理隔離してもプロキシサーバ側のログは保全されているため、そこから過去の通信状況を遡って調査可能です。
関連キーワード: プロキシログ、C&C通信、侵害判定、HTTPアクセス、ログ分析
設問3:〔マルウェアについての通知〕について、(1)〜(7)に答えよ。
(5)図7中の下線⑤について、Dさんの利用者IDを用いたPC-Bへのログインに最初に成功するまでに、攻撃者が何回ログインに失敗したことが記録されているか。記録されている失敗の回数を答えよ。
模範解答
保持期間:7日
解説
解答の論理構成
- 図7の説明
【問題文】では、図7(2)の注記として
“9月5日10時35分から45分までに、PC-Aから、⑤Dさんの利用者IDでのログイン試行が複数あり、一部は失敗し、一部は成功していた。”
とあり、ログイン試行が集中した時刻帯が示されています。 - 失敗の記録を確認
PC-B 上の失敗ログは図9(lastbコマンド結果)に列挙されています。該当する“d0325”の行を時刻順に抜粋すると次のとおりです。
・“Wed Sep 5 10:35 - 10:35”
・“Wed Sep 5 10:36 - 10:36” ×2
・“Wed Sep 5 10:37 - 10:37” ×3
・“Wed Sep 5 10:40 - 10:40”
・“Wed Sep 5 10:43 - 10:43”
・“Wed Sep 5 10:44 - 10:44” ×2 - 最初の成功時刻を確認
図8(lastコマンド結果)には成功ログがあり、9月5日の最初の成功は
“Wed Sep 5 10:41 – 10:43”
であると分かります。 - “最初に成功するまで”に該当する失敗を抽出
成功時刻 “10:41” より前の失敗だけを数えます。対象は
10:35 ×1、10:36 ×2、10:37 ×3、10:40 ×1
の合計 7 件です。 - 結論
攻撃者が最初に成功するまでに記録されている失敗回数は 7 回 となります。
誤りやすいポイント
- “10:41” 以後の “10:43”・“10:44” の失敗を含めてしまい 10 回と誤答する。
- 9月3日の “Mon Sep 3 09:34” を含めて 8 回と数えてしまう。設問は図7の下線⑤の時間帯に限定しています。
- 図8の 10:45 の成功を “最初の成功” と読み違える。図8には 10:41 と 10:45 の成功が両方載っているため注意が必要です。
FAQ
Q: lastb コマンドの 1 行は 1 回の失敗とみてよいのですか?
A: はい。lastb は認証に失敗したセッションを 1 行ずつ記録するため、行数がそのまま失敗回数になります。
A: はい。lastb は認証に失敗したセッションを 1 行ずつ記録するため、行数がそのまま失敗回数になります。
Q: 9 月 3 日の失敗は攻撃者のものか分かりませんが無視して良いのですか?
A: 図7の下線⑤は “9月5日10時35分から45分まで” の事象を指しているので、設問でもこの範囲だけを対象とします。
A: 図7の下線⑤は “9月5日10時35分から45分まで” の事象を指しているので、設問でもこの範囲だけを対象とします。
Q: 同じ時刻が複数行ある場合、重複カウントしなくていい?
A: 同じ時刻でも行が別なら別回の失敗です。今回は 10:36 と 10:37 に重複があり、行単位でカウントしました。
A: 同じ時刻でも行が別なら別回の失敗です。今回は 10:36 と 10:37 に重複があり、行単位でカウントしました。
関連キーワード: lastb, 認証失敗ログ、タイムライン分析、不正ログイン、アカウント乗っ取り
設問3:〔マルウェアについての通知〕について、(1)〜(7)に答えよ。
(6)本文中のlに入れる適切な字句を,8字以内で答えよ。
模範解答
l:ハッシュ値
解説
解答の論理構成
- 問題文には
「Cさんは、Dさんが利用している機器について、フォレンジックツールを用いて、ファイルAのファイルサイズとlをキーにしてファイルを検索した。」
とあります。 - ファイル名を変更・削除されても同一ファイルかどうかを判定したい場合、ファイルサイズだけでは衝突(偶然同じサイズになる別ファイル)が起こり得ます。
- デジタルフォレンジックの現場では、ファイルの一意性確認に「ハッシュ値」(MD5、SHA-1 など)を利用するのが定番です。
- よって、ファイルサイズと併せて検索キーにしたもう一つの情報は「ハッシュ値」であると導けます。
誤りやすいポイント
- 「タイムスタンプ」や「作成日時」を選ぶと、改ざんやコピーで変化・消滅しやすく、攻撃者対策として不十分です。
- 「ファイル名」は既に本文が「ファイル名は異なっていたものの」と示しており、識別子には使えません。
- ハッシュ値の具体的なアルゴリズム名(例:SHA-256)をそのまま書くと問題の要求を外すことがあります。
FAQ
Q: ハッシュ値はどの段階で計算するのですか?
A: 一般には調査対象ディスクをビット列そのまま取得(イメージ化)した後、フォレンジックツールで全ファイルのハッシュ値を一括算出します。
A: 一般には調査対象ディスクをビット列そのまま取得(イメージ化)した後、フォレンジックツールで全ファイルのハッシュ値を一括算出します。
Q: なぜファイルサイズとハッシュ値を“両方”使うのですか?
A: サイズで一次絞り込みを行い、該当候補のハッシュ値を比較することで検索効率と精度の両立を図るためです。
A: サイズで一次絞り込みを行い、該当候補のハッシュ値を比較することで検索効率と精度の両立を図るためです。
Q: ハッシュ値は改ざん検知にも使えますか?
A: はい。取得したハッシュ値を後日再計算して一致しなければ改ざん・破損が疑われます。
A: はい。取得したハッシュ値を後日再計算して一致しなければ改ざん・破損が疑われます。
関連キーワード: デジタルフォレンジック、ハッシュ関数、ファイル同一性判定、マルウェア解析
設問3:〔マルウェアについての通知〕について、(1)〜(7)に答えよ。
(7)本文中の下線⑥について、ファイルの社外への送信の可能性を示す記録を図6中から選び、行番号で答えよ。また、プロキシサーバ又はFWが取得できる情報のうち、当該記録と併せて見ることによってファイル送信の有無を判断するのに役立つ情報を35字以内で答えよ。ただし、送信元のIPアドレス及び図6中に示された情報は対象外とする。
模範解答
行番号:28行目
役立つ情報:プロキシサーバがインターネットに送信したデータのサイズ
解説
解答の論理構成
- 図7で、ファイルが作成された時刻は「9月8日3時35分」と示されています。
- 「ファイル送信の有無」を探るためには、この直後の通信を図6のプロキシサーバログから確認します。
- 図6の「28: [08/Sep/2018:03:39:04 +0900] "POST http://IPn/admin/g.php HTTP/1.1" 200 35618 "-" "▽▽"」は、
・時刻が3時39分04秒と作成直後である
・HTTPメソッドが「POST」でありアップロード系通信を示す
ことから、下線⑥「当該ファイルが社外に送信された可能性がある」に直接対応します。 - ファイル送信の事実確認には、通信方向や応答コードだけでなく「送信されたデータ量」が不可欠です。プロキシサーバまたはFWが保持する転送バイト数を照合することで、ファイルサイズ相当のデータが外部へ流れたかを判断できます。
誤りやすいポイント
- 「7行目」や「9行目」など別日のPOSTに注目してしまう。ファイル作成時刻との前後関係を必ず確認しましょう。
- HTTP 200 応答を「ダウンロード成功」と早合点しがちですが、POST はアップロード側のメソッドです。メソッド種別を見落とすミスに注意です。
- プロキシログの「レスポンスサイズ」と「送信サイズ」(アップロードバイト数)を混同しやすい点も要注意です。
FAQ
Q: POST 行が複数ある場合、どれを選ぶべきですか?
A: 該当ファイルの作成時刻直後で、タイムライン上に示された送信可能性と合致するものを選びます。本設問では 3 時 39 分の「28 行目」が該当します。
A: 該当ファイルの作成時刻直後で、タイムライン上に示された送信可能性と合致するものを選びます。本設問では 3 時 39 分の「28 行目」が該当します。
Q: レスポンスサイズが小さいのに送信済みと判断できるのはなぜ?
A: プロキシが保持する“送信バイト数”を確認することで、HTTP ボディ部にファイルが含まれていたかどうかを裏付けられるためです。
A: プロキシが保持する“送信バイト数”を確認することで、HTTP ボディ部にファイルが含まれていたかどうかを裏付けられるためです。
Q: FW で確認できる情報はありますか?
A: セッション中に転送された総バイト数や宛先ポート番号などが参照できます。特に総バイト数はプロキシと合わせて送信量を二重確認するのに有効です。
A: セッション中に転送された総バイト数や宛先ポート番号などが参照できます。特に総バイト数はプロキシと合わせて送信量を二重確認するのに有効です。
関連キーワード: HTTP POST, ログ解析、データ転送量、タイムライン、アップロード検知
設問4:〔インシデントQのタイムラインと措置〕について、(1)、(2)に答えよ。
(1)表2中のア〜ウに入れる適切な日時を答えよ。
模範解答
ア:9/4 14:31
イ:9/4 14:37
ウ:9/5 10:41
解説
解答の論理構成
-
ア の決定
*【図6】には4: [04/Sep/2018:14:31:15 +0900] "GET http://yyyy/dl/samplebun.zip HTTP/1.1" …
とあります。No.1 の記述「ZIP形式のファイルをダウンロード」に該当する唯一のアクセスはこの時刻です。ゆえに ア は 9/4 14:31 になります。 -
イ の決定
- IPn との最初の通信を示す行は【図6】の
8: [04/Sep/2018:14:37:06 +0900] "GET http://IPn/news.php HTTP/1.1" …
です。No.5 の「頻繁な通信を開始」の直前イベントなので分刻みで丸め、イ は 9/4 14:37 となります。 -
ウ の決定
*【図8】の last 結果にd0325 … Wed Sep 5 10:41 – 10:43 (00:01)
があり、これは PC-B へのログイン成功を示します。
*【図9】の lastb には 10:35〜10:40 の失敗履歴が並び、10:41 の失敗はありません。したがって「初成功」は 10:41 です。
よって ウ は 9/5 10:41 となります。
誤りやすいポイント
- GET と POST が混在しているため、IPn への最初の“頻繁な通信”を 14:37:32(POST)と誤読しやすい。初回アクセスは 14:37:06(GET)です。
- last と lastb の出力を混同し、10:35 を成功と勘違いするケースが多い。lastb は失敗履歴です。
- ZIP ダウンロード時刻を 14:28:42(別サイトの HTML 取得)と取り違えるミスが目立ちます。
FAQ
Q: なぜ 14:31 と 14:31:15 の秒単位を切り捨てて良いのですか?
A: タイムラインの他項目が分単位で記載されているため、同粒度に合わせています。
A: タイムラインの他項目が分単位で記載されているため、同粒度に合わせています。
Q: 14:37 の根拠は GET と POST のどちらですか?
A: 最初の IPn への接続が GET で 14:37:06 なので、これを採用します。POST はその 26 秒後です。
A: 最初の IPn への接続が GET で 14:37:06 なので、これを採用します。POST はその 26 秒後です。
Q: 10:41 のログインが本当に“初成功”と言い切れるのはなぜ?
A: 10:41 以前は lastb(失敗)のみで last(成功)が存在しないため、初めて成功したのが 10:41 と判断できます。
A: 10:41 以前は lastb(失敗)のみで last(成功)が存在しないため、初めて成功したのが 10:41 と判断できます。
関連キーワード: プロキシログ解析、SSHログ、タイムライン作成、マルウェア通信、インシデント対応
設問4:〔インシデントQのタイムラインと措置〕について、(1)、(2)に答えよ。
(2)表2中のm〜sに入れる適切な字句を、解答群の中から選び、記号で答えよ。
解答群
ア:“samplebun.zip”
イ:Cさん
ウ:Dさん
エ:IPnのサイト
オ:PC-A
カ:PC-B
キ:SQLインジェクション
ク:WHOISサービス
ケ:遠隔操作
コ:サイトM
サ:総当たり攻撃
シ:ファイルA
ス:フィッシング
セ:プロキシサーバ
ソ:マルウェアK
タ:マルウェアL
模範解答
m:タ
n:コ
o:ソ
p:ケ
q:シ
r:カ
s:オ
解説
解答の論理構成
-
m
- 表2の No.2 は「これをダブルクリックし、mを実行」と記述。
- 図7(1)でファイルWについて「ダウンローダの機能をもつマルウェアL」と説明。
- 従って実行されたのは“マルウェアL” → 解答群「タ」。
-
n
- 表2 No.3 は「mは、nにアクセスし、“new3.exe”をダウンロード」。
- 表1で「ファイルWは、サイトMからプログラムをダウンロード」と明記。
- よってダウンロード先は“サイトM” → 解答群「コ」。
-
o
- No.3 でダウンロードしたのは“new3.exe”。
- 表1で「new3.exe は遠隔操作の機能をもつマルウェアK」と記載。
- No.4 の「mは、oを実行」は“new3.exe”=マルウェアKの実行を示す。
- 従って o=“マルウェアK” → 解答群「ソ」。
-
p
- No.5 は「oは、IPnのサイトとの頻繁な通信を開始 攻撃者によるpが始まったと推測」。
- マルウェアKの説明で「遠隔操作の機能をもつ」とある。
- 頻繁な通信=C&C によるリモートコントロール → “遠隔操作” → 解答群「ケ」。
-
q
- 図7(2)で「アーカイブファイル(以下、ファイルAという)」の存在を報告。
- 表2 No.8 には「漏えいが疑われるファイルのコピーとqを…作成」とあり、アーカイブ化した漏えい用ファイルを指す。
- よって q=“ファイルA” → 解答群「シ」。
-
r
- 同じ No.8 「…rのローカルディスクに作成」。
- 図7(2)でファイルAが置かれていたのは「PC-B」。
- したがって r=“PC-B” → 解答群「カ」。
-
s
- No.9 では「…同じ内容のファイルをsのローカルディスクに作成」。
- Cさんの追加調査で「PC-Aにおいて、9月8日3時35分に…ファイルAと同じ内容のファイルが作成」と判明。
- s=“PC-A” → 解答群「オ」。
誤りやすいポイント
- ファイルW(マルウェアL)と new3.exe(マルウェアK)を混同しやすい。説明を丁寧に読み、どちらがダウンローダでどちらが遠隔操作型か区別すること。
- “サイトM”と“IPnのサイト”は別物。ダウンロード先はサイトM、C&C 通信は IPn と押さえる。
- ファイルAとマルウェアKを同じ「実行ファイル」と誤解しがち。ファイルAは攻撃者がまとめたアーカイブでありマルウェアではない。
- PC-A/PC-B の役割を逆に読んでしまうミス。表・図を突き合わせて確認すること。
FAQ
Q: 「遠隔操作」と判断できる根拠は何ですか?
A: マルウェアKの説明に「遠隔操作の機能をもつ」と明記されており、表2 No.5 でも IPn との頻繁な通信が開始されたとあるため、攻撃者の遠隔操作開始と推測できます。
A: マルウェアKの説明に「遠隔操作の機能をもつ」と明記されており、表2 No.5 でも IPn との頻繁な通信が開始されたとあるため、攻撃者の遠隔操作開始と推測できます。
Q: “サイトM”ではなく IPn を n に入れてはいけないの?
A: 表1で「ファイルWは、サイトMからプログラムをダウンロード」とあるため、ダウンロード元はサイトM。IPn はマルウェアKの C&C 先であり時系列的に後段の通信対象です。
A: 表1で「ファイルWは、サイトMからプログラムをダウンロード」とあるため、ダウンロード元はサイトM。IPn はマルウェアKの C&C 先であり時系列的に後段の通信対象です。
Q: PC-A と PC-B のどちらにファイルAが最初に作成されたのですか?
A: 表2 No.8 が示す通り最初は PC-B で 9/7 4:15 に作成され、その後 No.9 で 9/8 3:35 に PC-A にコピーが作られた流れです。
A: 表2 No.8 が示す通り最初は PC-B で 9/7 4:15 に作成され、その後 No.9 で 9/8 3:35 に PC-A にコピーが作られた流れです。
関連キーワード: ダウンローダ、C&C通信、アーカイブファイル、遠隔操作、タイムライン
設問5:
本文中の下線⑦について図3中の(6)に示された課題a〜dの中から、この時点で未対応の課題を選び、記号で答えよ。また、その課題を解決するための措置を、25字以内で具体的に述べよ。
模範解答
課題:b
措置:インシデント対応の作業手順書を作成する。
解説
解答の論理構成
- ⑦は「インシデント対応能力について未対応の課題を解決するための措置」を問うています。
- 参考にすべきは「図3中の(6)」で列挙された課題 a~d。原文を引用します。
- a. 「インシデント対応についての各部の責任や役割が曖昧」
- b. 「インシデント対応についての作業手順が明確になっておらず、手探りの作業となった」
- c. 「インシデント対応の経験をもつ者又はスキルをもつ者がおらず、非効率な作業になった」
- d. 「ログが少なく調査が難航した」
- インシデントQ 対応後に実施済みの対策を本文から整理します。
- a の解決:A-CSIRT 再編成と「インシデント対応ポリシ」策定で「各部の役割、責任及び権限レベルを規定」。
- c の解決:A-CSIRT メンバに対し「定期的に勉強会を開催し、外部の研修などにも積極的に参加」。
- d の解決:「ログ管理ポリシ」を策定し、取得・保存・時計同期など具体的要件を定義。
- よって未対応は b のみ残存します。
- b の解決策は「インシデント対応についての作業手順」の整備であるため、具体措置として「インシデント対応の作業手順書を作成する」となります。
誤りやすいポイント
- 「a も未対応では?」と誤解する:役割・責任は既に「インシデント対応ポリシ」で明確化済み。
- 「d がまだ部分的に残る」と考える:時計同期・保存期間などログに関する主要課題はポリシで網羅済み。
- 措置に「手順書の整備」と書かず「マニュアル整備」「フロー図作成」など曖昧表現にすると減点されやすい。
FAQ
Q: 役割と手順の違いは何ですか?
A: 役割は「誰が何を担当するか」、手順は「具体的にどう動くか」です。ポリシで役割は明確化されたものの、具体的な作業フローは未整備だったため b が残りました。
A: 役割は「誰が何を担当するか」、手順は「具体的にどう動くか」です。ポリシで役割は明確化されたものの、具体的な作業フローは未整備だったため b が残りました。
Q: 手順書作成だけで十分なのでしょうか?
A: 最初の一歩として必須です。手順があれば訓練や改善サイクルを回しやすくなり、実運用での混乱を防止できます。
A: 最初の一歩として必須です。手順があれば訓練や改善サイクルを回しやすくなり、実運用での混乱を防止できます。
Q: 手順書作成時に注意すべき点は?
A: NIST SP 800-61 Rev.2 のフローを参考に、検知・分析・封じ込め・根絶・復旧・事後レビューの各フェーズを網羅し、関係部署との連絡経路も明記します。
A: NIST SP 800-61 Rev.2 のフローを参考に、検知・分析・封じ込め・根絶・復旧・事後レビューの各フェーズを網羅し、関係部署との連絡経路も明記します。
関連キーワード: インシデント対応、ポリシ、ログ管理、フォレンジック、CSIRT


