情報処理安全確保支援士 2017年 春期 午後2 問01

解答の論理構成

• 図2の該当部分には
  “①電源をオフにすると消去されてしまう情報について、必要な調査を電源オンの状態で行い…”
  とあります。
• 電源を切ると内容が失われるのは RAM 上のデータ、すなわち揮発性情報です。
• 選択肢を検討すると
  • ア「HDDのパーティションテーブルの情報」
  • イ「OSのバージョンの情報」
  • オ「脆弱性修正プログラムの適用状況」
    → いずれも不揮発性ストレージに保存されており、電源を切っても消えません。
  • ウ「画面に表示されているウィンドウの名称一覧」
    → 画面描画内容はメモリ内の情報なので電源断で消失します。
  • エ「起動しているプロセスの一覧」
    → プロセスは RAM 上で管理されるため電源断で消失します。
• よって、①に該当するのは「ウ」「エ」です。

誤りやすいポイント

• “パーティションテーブルや OS バージョンもシステム情報だから揮発性では？”と早合点する。これらはディスクに記録されており電源断では失われません。
• “脆弱性修正プログラムの適用状況はレジストリにある＝メモリ？”と混同する。レジストリ内容はディスクに保存されます。
• “画面に表示されている情報はスクリーンショットを撮れば残るから揮発性ではない”と考える。保存操作をしなければ RAM 上だけに存在するため揮発性です。

FAQ

解答の論理構成

1. 不審通信の発見場所
   • 問題文には「IS部では、…プロキシサーバのアクセスログを確認している」とあります。この“アクセスログ”から被疑サーバあて通信が判明したので、同じログを使って送信元を洗い出すのが自然です。
   • 表3「順序1」の最初の箇条書きに「aのログから、被疑サーバを宛先としたエントリを抽出」とあり、ここに入る装置は“アクセスログ”を保持し、社内 PC の Web 通信を中継している機器でなければなりません。表1の記述「プロキシサーバ ― 取得ログ：アクセスログ」に合致します。
     ⇒ a ＝ 「プロキシサーバ」
2. IP アドレスから MAC アドレスを得る方法
   • 表3「順序1」の二つ目の箇条書きでは「送信元IPアドレスとアクセス時刻を基に、b のログを検索し…MACアドレスを特定」とあります。
   • IP と MAC の対応を記録している代表的なログは DHCP です。表1の「DHCPサーバ ― 取得ログ：DHCPによる割当て結果」には、リース時刻・IP・MAC が残ります。
   • したがって、特定時刻に同じ IP を使っていた端末の MAC を知るには DHCP サーバのログを参照するのが最適です。
     ⇒ b ＝ 「DHCPサーバ」

誤りやすいポイント

• ファイアウォール（FW1/FW2）の“許可ログ”を選んでしまう
  被疑サーバあての HTTPS は FW1 の外向き通信なので許可ログにも現れますが、IP と MAC の対応情報までは得られません。
• ARP テーブルを想定する
  一時的に IP と MAC を対応づける ARP はルータや L2SW に存在しますが、恒常的なログを残さない、またセグメントを跨いで確認できない点で不適切です。
• 認証サーバのログと誤解する
  認証結果には利用者 ID は残りますが IP・MAC の確定には使えず、問い合わせ時刻も毎通信では発生しません。

FAQ

解答の論理構成

1. マルウェアの通信先
   【問題文】には「被疑サーバを宛先とした通信であった」とあり、さらに詳細解析環境でも「被疑サーバにHTTPS通信を行おうとする」と繰り返し記載されています。
2. HTTPS 通信の成立条件
   改竄や盗聴を防ぐため、HTTPS ではサーバ証明書のサブジェクト（CN など）がアクセス先ホスト名と一致しているかをクライアントが検証します。検証に失敗すると通信は切断されます。
3. 図5への対策の目的
   【問題文】下線②「サーバ証明書の検証を行っている可能性を考慮し、検証が成功するよう、②サーバ証明書を発行し…」と明記されており、検証を通すことが狙いです。
4. CN に何を入れるべきか
   クライアント（マルウェア）が接続要求時に指定するホスト名＝被疑サーバの FQDN であり、ここが証明書の CN と一致していなければ検証は成功しません。
5. 以上より、「発行する証明書のサブジェクトのコモンネームに組み込むべきもの」は
   被疑サーバのFQDN となります。

誤りやすいポイント

• IP アドレスを CN に入れてしまう。多くの場合 HTTPS はホスト名で検証します。
• 「被疑サーバ」とだけ書き、具体的な FQDN を省略してしまう。表記ゆれは検証失敗の原因です。
• subjectAltName にだけ設定すれば良いと思い、CN を空欄にしてしまうケース。旧実装では CN が参照されることがあります。
• 社内の解析用サーバの名前を CN にしてしまう。マルウェアは外部ホスト名で検証するため一致しません。

FAQ

解答の論理構成

1. 証明書を組み込む目的
   本文には「検証が成功するよう、②サーバ証明書を発行し、図5の環境に、サーバ証明書と、それに対応する秘密鍵を組み込んだ」とあります。被疑PCが確立する HTTPS セッションを復号するためには、被疑PC側から見て“サーバ”となる機器が、自身の正当性を示す証明書を提示しなければなりません。
2. “サーバ”となる機器の特定
   図6の通信フローより
   • 「（2）解析用プロキシサーバが、HTTPS通信を中継することによって、被疑PCと中継サーバ1間の通信路が確立する。」
   • 「（4）中継サーバ1は、HTTPS通信を復号してHTTP通信に変換した上で、中継サーバ2に転送する。」
     と記載されています。
     すなわち、被疑PCが TLS ハンドシェイクを行う相手は 中継サーバ1 であり、ここで提示される証明書が検証に用いられます。
3. したがって、②で発行したサーバ証明書と秘密鍵を組み込むべき機器は「中継サーバ1」となります。

誤りやすいポイント

• 「解析用プロキシサーバ」が“プロキシ”という語から第一候補に見えるが、図6ではプロキシが TLS を終端せず単なるトンネル動作を行う点を読み落としやすいです。
• 「中継サーバ2」はインターネット側との HTTPS を終端しますが、被疑PCとは直接 TLS ハンドシェイクを行わないため誤答になります。
• 「証明書＝HTTPSサーバすべてに必要」と考え、複数機器へ無条件に組み込むと設問趣旨とずれる結果になります。

FAQ

解答の論理構成

1. 図5の環境変更後、HTTPS通信の流れは図6の(1)〜(5)で説明されています。特に(2)に
   “解析用プロキシサーバが、HTTPS通信を中継することによって、被疑PCと中継サーバ1間の通信路が確立する。”
   と明記されています。
2. つまり、被疑PCが発行する“被疑サーバ”宛ての CONNECT 要求を、解析用プロキシサーバが受け取った時点で“中継サーバ1”へ転送先を書き換える必要があります。
3. これにより、(3)で被疑PCは確立済みの通信路を使ってデータを送信し、(4)(5)で復号・再暗号化を経て最終的にインターネット側と通信する構成が成立します。
4. 以上から、解析用プロキシサーバ上で行うべき特別な設定は「被疑サーバ宛てHTTPS要求の転送先を中継サーバ1に固定する」ことになります。

誤りやすいポイント

• DNSサーバ側で名前解決を書き換えればよいと考えてしまう
  → 図6の説明は“解析用プロキシサーバ”が中継点になることを前提としているため、DNSだけでは不十分です。
• サーバ証明書を配置するだけで通信経路も自動で切り替わると思い込む
  → 経路はプロキシの転送設定、証明書は信頼性確保の役割であり別問題です。
• 中継サーバ2までの経路を設定する必要があると誤解する
  → 図6(2)の時点で必要なのは“中継サーバ1”までの到達性です。以降は中継サーバ1が処理します。

FAQ

解答の論理構成

• 【問題文】では「③その他にも幾つかの方法」と述べ、代表例として「デバッガ環境下であるかどうかを調べるシステムコール」を挙げています。
• つまり設問は「システムコール以外でデバッガ環境を検知する代表的な手法を答えよ」と問うています。
• 典型的な手法の一つが、OS に登録されている「実行中プロセス一覧」を取得し、そこに gdb や dbgview など“よく知られたデバッガ名”が存在するかを確認する方法です。
• プロセス列挙は管理者権限不要で呼び出し関数も単純なため、マルウェアで広く用いられています。
• よって、解答は「実行中プロセスの一覧から既知のデバッガのプロセス名を探す」となります。

誤りやすいポイント

• システムコール利用と混同し、「特殊レジスタのフラグ確認」など別カテゴリーを書いてしまう。
• “プロセス名”ではなく“サービス名”“レジストリ名”と書いて減点される。
• 「プロセスを強制終了する」など“検知”ではなく“対策”を書いてしまう。

FAQ

解答の論理構成

1. 図7では、マルウェアが実行前に「暗号化済みコード部」を持ち、実行時に復号して本体を展開するしくみ（いわゆるパッカー）が説明されています。
   • 【問題文】「暗号化済みコード部のデータは実行プログラム部によって復号されて、見せかけのデータ部に書き込まれる」
2. 復号処理で使う暗号鍵や圧縮方式を都度変えれば、ファイルそのもののバイナリ列は毎回変化します。
3. ウイルス対策ソフトのシグネチャ方式は、既知のバイナリ列を「ウイルス定義ファイル」に登録して照合する仕組みです。
   • 【問題文】「このようなマルウェアは、ウイルス定義ファイルに基づくウイルススキャンでの検知が著しく難しい」
4. したがって、暗号鍵を変えてパックし直されるたびにシグネチャと一致しない新規ファイルが生成されるため、定義ファイルでは検知しにくいと結論づけられます。

誤りやすいポイント

• 「圧縮されているから検知できない」と圧縮だけを理由にする。鍵を変えればコード部そのものが変化する点まで触れないと不十分です。
• 「パッカーなら必ずヒューリスティックで検知できる」と思い込む。ヒューリスティックは万能ではなく、誤検知・過検知の問題があります。
• 「実行時に復号するので実行時検知は可能」とだけ述べ、ファイルスキャン段階での困難さを忘れる。

FAQ

解答の論理構成

1. 対応目的の確認
   表5の目的は“被疑サーバへの HTTPS アクセスの禁止”です。したがって社内PCから当該サーバへの通信を確実に遮断できる仕組みを使う必要があります。
2. 適切な遮断ポイントの抽出
   【問題文】表1でプロキシサーバは
   ・“社内 PC から社外の Web サーバへのアクセスを中継する。本サーバ以外から社外の Web サーバへの直接アクセスは、FW1で遮断される。”
   ・“アクセス先 URL に基づき、アクセス制御を行う。ホワイトリスト／ブラックリストの登録ができる。”
   と説明されています。つまり社内PCが外部Webへ出る経路は必ずプロキシ経由であり、ここで URL／IP をブロックすれば全PCに一括適用できます。
3. 表5の指示文の読み取り
   表5には「c に被疑サーバを登録するとともに、念のため FW1 のルールを変更する。」とあります。
   まずプロキシ設定だけで遮断し、さらに保険として FW1 でも止める二段構えを示しています。
4. 選択肢の特定
   プロキシサーバには“ホワイトリスト／ブラックリスト”機能があるため、被疑サーバを登録して拒否させるのはブラックリストが自然です。
5. 結論
   よって c に入る語句は
   「プロキシサーバのブラックリスト」
   となります。

誤りやすいポイント

• 「FW1 のアクセス制御リスト」とだけ書いてしまう
  → 表5は既に“念のため FW1 のルールを変更”と明記しており、c は別物を要求しています。
• 「DNS サーバのゾーンファイル」や「hosts ファイル」を想起する
  → DNS改変はHTTPS通信を完全には防げません。社内構成では全Web通信がプロキシ経由なので優先度が低い手段です。
• 「プロキシサーバのホワイトリスト」と書く
  → ホワイトリストに登録すると許可になってしまうため逆効果です。

FAQ

解答の論理構成

1. マルウェアの感染方法の把握
   • 詳細解析で「社内PCのOSで以前発見された脆弱性（以下、脆弱性Kという）を突いて攻撃を仕掛けている」ことが判明しました。
   • したがって感染を防ぐ鍵は「脆弱性K」をふさぐことにあります。
2. 既に用意されている対策の確認
   • 問題文には「脆弱性Kは、2か月ほど前に脆弱性修正プログラムと併せて公開されており、R社でも社内PCに脆弱性修正プログラムを配信していた」と記載されています。
   • 配信済みであれば“調達”ではなく“適用徹底”だけで済みます。
3. 応急措置の趣旨
   • 表5の該当行は「マルウェアの感染の防止」が目的です。
   • 目的を達する最短手段は「全ての社内PCで脆弱性Kを悪用できない状態にする」ことです。
4. 結論
   • よってdに入る文言は「脆弱性Kに対応した脆弱性修正プログラムを適用する」となります。

誤りやすいポイント

• 「再配信」や「ウイルス対策ソフト更新」など別の対策を書いてしまう。脆弱性を悪用して侵入するマルウェアなので、根本は OS の欠陥修正です。
• 「脆弱性Kのパッチ適用を確認する」と動詞を“確認”にするミス。本設問は“措置”を問うため“適用する”が適切です。
• 「全社PC」ではなく「全ての社内PC」と原文を変えてしまう。固有表現は問題文通りに書く必要があります。

FAQ

解答の論理構成

1. 流出した内容の確認
   【問題文】では、被疑サーバに送信されていた情報として
   「被疑PC内に一時的に保存された認証情報（利用者IDと、パスワードのハッシュ値を含む）」
   が挙げられています。
2. 流出したハッシュのリスク
   パスワードのハッシュ値は平文ではありませんが、辞書攻撃や総当たり攻撃で平文パスワードが推測される恐れがあります。
3. 悪用防止策の目的確認
   表5の該当行は
   「窃取されたアカウント情報の悪用の防止」
   と明示しており、流出したハッシュ値を用いた不正ログインを未然に防ぐ施策が必要です。
4. 現実的・即効的な対処
   攻撃者が平文を割り出せる可能性を排除する最も確実で迅速な方法は、利用者に新しいパスワードを設定させること、すなわち“パスワードの変更”です。
5. したがって、eに入る字句は
   「パスワードの変更」
   となります。

誤りやすいポイント

• 「ハッシュ化されているから安全」と判断し、対処を “アカウント停止” や “ログオン履歴の監視” のみにとどめる。ハッシュは解読不能ではありません。
• “パスワードリセット” と “パスワードの変更” の混同。設問は「利用者のアカウントについて」と記載しており、利用者自身が新しいパスワードを設定する運用（変更）が適しています。
• 多要素認証を追加するなど長期施策を答えてしまう。設問は応急措置を問うているため、迅速性が求められます。

FAQ

解答の論理構成

• 被疑 PC は「昨日まで出張が続いていたので、被疑 PC の電源を入れるのは 3 か月ぶりであった。」と記載されており、長期間パッチ適用が行われていない状態でした。
• 一方、比較対照用 PC について図3では「OS及びアプリケーションソフトウェアをインストールした後に、最新の脆弱性修正プログラムの適用やウイルス定義ファイルの更新を行った社内PC」と定義されています。
• R社のパッチ運用は「OSとPDF閲覧ソフトの脆弱性修正プログラムを社内 PC に配信」し「公表から1か月以内に配信する運用」と明示されています。
• したがって、勤務開始時点の被疑 PC には PDF 閲覧ソフトの最新パッチが未適用であり、比較対照用 PC は適用済みというギャップが存在します。
• この差異こそが N ページ閲覧時にエクスプロイトが成功した／しなかった分かれ目であるため、④の「重要な点」は「PDF閲覧ソフトの脆弱性修正プログラムの適用状況」と結論付けられます。

誤りやすいポイント

• 「OS のパッチ未適用」と断定してしまう
• 「ウイルス定義ファイルの更新状況」と取り違える
• 比較対照用 PC 側ではなく被疑 PC 側の設定変更（スリープ設定など）を理由と誤解する
• パッチ配信サーバの障害を原因と想定してしまう

FAQ

解答の論理構成

1. 目的の確認
   本文では「比較対照用PCの状態と、今日の勤務開始時刻時点の被疑PCの状態では、重要な点が異なっている可能性が高い」と指摘されています。ここで“重要な点”とは、被疑PCが3か月間電源を入れていなかったために脆弱性修正プログラムが未適用であった点です。
2. 必要なログの種類
   未適用パッチを把握するには「各 PC の脆弱性修正プログラム適用結果」を確認できるログが必要です。
3. 該当機器の特定
   表1より
   「パッチ配信サーバ」の取得ログは
   ・「配信した脆弱性修正プログラムの情報」
   ・「各 PC の脆弱性修正プログラム適用結果」
   と明記されています。これがまさに目的のログです。
4. 結論
   したがって f に入る機器名称は「パッチ配信サーバ」です。

誤りやすいポイント

• DHCPサーバや認証サーバと混同する
  → これらには脆弱性修正プログラムの適用状況を示すログがありません。
• 「プロキシサーバのアクセスログ」で済むと勘違いする
  → アクセスログではパッチの適用有無を把握できません。
• “パッチ配信サーバ”を「パッチサーバ」などと表記を変えてしまう
  → 指示通り固有名詞は【問題文】の表記「パッチ配信サーバ」をそのまま用いる必要があります。

FAQ

解答の論理構成

1. 感染経路は「Q社のWebサイトを閲覧した際、PDFファイルを自動で開かされる」ことで生じました。
   ――【問題文】「NページをWebブラウザで開くと、Q社のドメイン外のサイトからPDFファイルをダウンロードして、PDF閲覧ソフトで開く。」
2. マルウェアLは PDF閲覧ソフトの脆弱性を悪用して侵入したと推測されます。
   ――【問題文】「比較対照用PCの状態と、今日の勤務開始時刻時点の被疑PCの状態では、重要な点が異なっている」
3. R社は「OSとPDF閲覧ソフトの脆弱性修正プログラム」を配信しています。
   ――【問題文】「OSとPDF閲覧ソフトの脆弱性修正プログラムを社内 PC に配信し、適用結果を収集する。」
4. よって、PDF閲覧ソフトに脆弱性修正プログラムが未適用の状態で Nページを閲覧した PC だけが感染し得ます。
   この判定を行うために、⑤ では「fのログ（＝パッチ配信サーバの適用結果ログ）」と「aのログ（＝プロキシサーバのアクセスログ）」を突き合わせるよう指示しています。
   ――【問題文】「過去1週間のaのログを調査し…　aのログとfのログを突き合わせ、⑤マルウェアLに感染する可能性があったかどうか判断する。」
5. 以上から、感染の可能性があったと判断する条件は
   「PDF閲覧ソフトの脆弱性修正プログラムを適用する以前に Q社のWebサイトを閲覧した場合」
   となります。

誤りやすいポイント

• OSの「脆弱性K」と混同し、OSパッチの適用有無を条件にしてしまう。
• Q社サイト閲覧の有無だけで判定し、パッチ適用時期を考慮しない。
• 参照すべきログを f ではなく DHCP や 認証サーバのログと誤解する。

FAQ

解答の論理構成

1. 事後評価での指摘
   • 本文には「⑥ディジタルフォレンジックスという観点から、実施するタイミングを見直す必要がある作業がある」と記載されています。
2. 該当する作業の洗い出し
   • 前段で実際に行われた作業として「解析作業による被疑PCの状態変化を考慮し、被疑PCのHDDの複製を作成した。」とあります。
3. タイミングの妥当性検討
   • ディジタルフォレンジックスでは“証拠保全は最初に行う”ことが原則です。
   • HDD複製を詳細解析フェーズ以降に行うと、マルウェア解析や環境変更によりディスク内容が変化してしまい、真正性が損なわれる恐れがあります。
4. 結論
   • 従って、タイミングを見直すべき作業は「被疑PCのHDDの複製作成」であると導けます。

誤りやすいポイント

• 「パケットキャプチャ装置での取得」や「ログ収集」を選んでしまう
  ディジタルフォレンジックスで最優先すべきは媒体イメージの保全です。ログ取得は後でも再現可能な場合が多く優先度が下がります。
• 「電源遮断の是非」を答えにしてしまう
  電源操作は図2の①で触れられていますが、事後評価の課題として明示されていません。
• HDD複製の目的を“解析用データ作成”と誤解し、タイミングに問題がないと判断する
  保全と解析は目的が異なり、フォレンジックでは“手を加える前”に複製を取る必要があります。

FAQ

解答の論理構成

• 【問題文】ではインシデント対応の事後評価として、⑦被疑PCの利用者の業務継続を考慮して対応する必要があると課題が示されています。
• 被疑PCは初動対応の段階でLANから切り離され、解析室に移動して長時間の解析が実施されました。利用者であるサポート部の Sさん は自分の PC を失い、業務が中断される恐れがあります。
• 業務継続を確保する最も直接的な方法は、解析中に利用者が業務を遂行できる 代替 PC を手配することです。
• 以上より、「被疑PCの解析中に使用する代替PCを貸与する」ことが具体策となります。

誤りやすいポイント

• 解析終了後に元の PC を返却すればよいと考え、解析中の業務停止を見逃す。
• リモート接続やスマートフォン活用など部分的代替策のみを挙げ、PC 本体の継続的利用ニーズを軽視する。
• 代替 PC の準備を IS 部の裁量に任せ、手順書に明記しないため実務で漏れる。

FAQ

解答の論理構成

1. マルウェアが自身を再起動させる設定を残す
   • 本文には「発見したプロセスは、一通りの処理を終えると…『自身を所定の時間経過後に起動するための設定をOSに対して組み込み』…」とあります。
   • つまり感染判定時点ではプロセスが終了していても、OS の自動起動設定（レジストリの Run キー、スケジュールタスクなど）が改変されています。
2. 既存のチェックリストではこの改変を見落とす
   • 図3のチェックリスト(1)～(4)は「プロセス一覧」「不審通信」「システムファイル差異」などであり、自動起動設定そのものは対象外です。
   • 実際に「今回のマルウェアLの場合、図3中の解析チェックリストではマルウェア感染を発見できない場合がある」と記載されています。
3. 追加すべき観点の具体化
   • そこで「“gを比較対照用PCと突き合わせると、差異が存在する”という項目を追加」すると決めています。
   • 比較すべき対象は「PC起動時や所定の時刻などに特定のプログラムを自動的に起動する設定内容」であれば、マルウェアが残した変更を検知できます。
   • 以上より、g には「PC起動時や所定の時刻などに特定のプログラムを自動的に起動する設定内容」が最も適切です。

誤りやすいポイント

• 「システムファイルの差異」を拡張すれば良いと早合点し、自動起動設定を別項目にしない。
• 「自動起動プログラム一覧」とだけ書き、設定そのもの（レジストリ・タスク・サービスなど）を含めない。
• 通常の常駐プロセスと混同し、「プロセス一覧比較」で十分と判断してしまう。

FAQ