情報処理安全確保支援士 2021年 秋期 午後2 問02

解答の論理構成

1. 役割ごとの基本方針を押さえる
   【問題文】には、三つの役割が列挙されています。
   ――「経営者：組織のあるべき姿を検討し、テレワークセキュリティ全般を考え、必要なリソースを確保する。」
   ――「システム管理者：情報システムへの不正アクセス、マルウェア感染などのインシデント発生時の対処のルールを定める。」
   ――「テレワーク勤務者：定められたルールを遵守し、データを安全に扱う。」
   ここから、 ・経営者＝方針決定と予算確保
   ・システム管理者＝技術・運用面の管理
   ・テレワーク勤務者＝ルールを実践
   が読み取れます。
2. 各設問文と役割のマッチング
   【問題文】の［詳細］には次の記述があります。
   ①「1. a は、テレワークの推進に必要な人材・資源を確保するために、必要な予算を割り当てる。」
   →“予算を割り当てる”のは経営判断であり、「経営者」(ア)。
   ②「2. b は、情報セキュリティポリシーに従い、セキュリティ維持に必要な技術的対策を講じる…」
   →技術的対策を講じるのは「システム管理者」(イ)。
   ③「3. c は、社内システムに、強度の低いパスワードが用いられないように制限を掛ける。」
   →システム全体に制約を掛ける権限も「システム管理者」(イ)。
   ④「4. d は、パスワードの使い回しを避け…他人に推測されにくいものを設定する。」
   →実際にパスワードを設定する利用者は「テレワーク勤務者」(ウ)。
3. 以上から
   a：ア（経営者）
   b：イ（システム管理者）
   c：イ（システム管理者）
   d：ウ（テレワーク勤務者）

誤りやすいポイント

• 「強度の低いパスワードを禁止する設定」は利用者自身の行動と誤認しがちですが、設定を“掛ける”主体はシステム管理者です。
• 予算配分を「システム管理者」と考えてしまうケースがありますが、ガバナンス上これは経営者の責務です。
• テレワーク勤務者の責務は“設定”ではなく“遵守”である点を見落としやすいです。

FAQ

解答の論理構成

1. 図5の⑤に相当する箇所には、次の一文があります。

   システム管理者は、暗号化された通信路をテレワーク勤務者に提供する。その際、電子政府における調達の際にも参照される e 暗号リストを参照し、暗号化には危殆化していない暗号アルゴリズムを採用するものとする。

2. 「電子政府における調達の際にも参照される暗号リスト」と明示している点が手掛かりです。日本の電子政府関連文書で採用すべき暗号方式を示す代表的なリストは、経済産業省・総務省所管の「CRYPTREC 暗号リスト」です。
3. CRYPTREC（Cryptography Research and Evaluation Committees）は、電子政府推奨暗号リストを公開し、政府調達やガイドラインで参照されています。したがって、e に入るべき語として合致します。
4. 要求は「英字8字で答えよ」なので、正式表記「CRYPTREC」が条件を満たします。

誤りやすいポイント

• 「NIST」や「FIPS140」など米国基準を想起してしまい、国内の「電子政府」基準と結び付けられない。
• 「CRYPTREC 暗号リスト」の名称を「CRYPTRECリスト」「CRYPTREC推奨暗号」と変形してしまう。設問は“英字8字”を要求しているため、語尾の変換や省略は誤答。
• “電子政府推奨暗号”という和名のみで覚えており、アルファベット表記を即答できない。

FAQ

解答の論理構成

1. 【問題文】図6の下線①には
   “①Bサービスへのアクセスだけ、拠点VPNサーバから、DCを経由させずに支社に敷設したインターネット接続回線を経由させる”
   と明記されています。
2. ここで鍵となるのは「DCを経由させず」「支社に敷設したインターネット接続回線を経由」という点です。つまり、社内 WAN を通さずに支社で直接インターネットに出る構成を示しています。
3. このように各拠点・端末が本社やデータセンタをバイパスして“ローカル（拠点）側で直接インターネットをブレイクアウト”する方式は、一般に「ローカルブレイクアウト」と呼ばれます。
4. 解答群で「ローカルブレイクアウト」に該当するのは “エ” だけです。よって
   解答：エ

誤りやすいポイント

• “ゼロトラストネットワーク”と混同
  → ゼロトラストはアクセス判定モデルの概念であり、経路をローカルで分岐させること自体を指す用語ではありません。
• “Software-Defined Networking”や“OpenFlow”を経路制御のキーワードと勘違い
  → SDN はコントロールプレーンの分離技術、OpenFlowはその実装プロトコルの一つ。今回の設問は経路の“場所”に関する話であり制御プロトコルの選択ではありません。
• “VPN経由だからローカルではない”という思い込み
  → 設問は「Bサービスへのアクセスだけ」を“VPN終了後”に直接インターネットへ出す点が本質です。VPNの存在有無は混乱ポイント。

FAQ

解答の論理構成

1. 事前知識
   • 【問題文】には「“Bサービス”へのアクセス制限機能によって、アクセス元IPアドレスがUTMのグローバルIPアドレスの場合だけアクセスが許可される。」と明記されています。
2. 新NWテスト時の変更点
   • 【問題文】図6の説明で「“Bサービスへのアクセスだけ、拠点VPNサーバから、DCを経由させずに支社に敷設したインターネット接続回線を経由させる”」とあります。
3. 発生した現象
   • 支社テストで「インターネットへはアクセスできたが、Bサービスに接続できない」という事象（下線②）が発生しました。
4. 因果関係の整理
   • 拠点VPNサーバから直接インターネットへ出ると送信元は支社新回線のグローバルIPになります。
   • しかしBサービスは【問題文】で引用したとおり「UTMのグローバルIPアドレス」以外を拒否します。
   • そのため接続は遮断され、Bサービスだけ利用できない状態となりました。
5. 結論
   • 問題の根本は「アクセス元IPがBサービスの許可リストに入っていない」ことにあります。
   • よって模範解答「Bサービスのアクセス制限機能によって通信が拒否されたから」となります。

誤りやすいポイント

• 「VPN設定の誤り」や「FWポリシー不備」と誤解しがちですが、問題はBサービス側の“許可IP制限”です。
• BサービスへのアクセスのみDCを経由しないという構成変更を見落とすと原因を特定できません。
• UTMや拠点FWのフィルタリングログばかり追い、アプリ側の制限条件を確認し忘れるパターンが多いです。

FAQ

解答の論理構成

1. マルウェアの特徴
   • 【問題文 表2】に「“C&C サーバの IP アドレス及び FQDN のリスト”が埋め込まれていた」とある。
2. 暫定対策案
   • Gさんは「“IPリストに登録されたIPアドレスへの通信をUTMで拒否”」と提案。
3. P氏の懸念
   • P氏は下線③に対応して「“攻撃者が行う設定変更”によって遮断が無効化される」と指摘。
4. 可能な設定変更の内容
   • 埋め込まれた「FQDN」は固定である一方、「FQDNが解決するIPアドレス」はDNSで随時書き換え可能。
   • 攻撃者がDNS側で「FQDN → 新しいIPアドレス」へ変更すれば、UTMが遮断対象として登録した旧IPアドレスは無効になる。
5. 結論
   • よって「攻撃者が行う設定変更」は「マルウェアが参照するFQDNの名前解決先IPアドレスを変更すること」と導ける。

誤りやすいポイント

• 「C&CサーバのFQDN自体を追加する」と勘違いし、IPアドレス変更である点を見落とす。
• “マルウェアの更新”と誤読し、DNS上の動的変更という設定レイヤを想定しない。
• 「UTMのルール改ざん」と解釈してしまい、攻撃者が自組織外で操作できるDNSを忘れる。

FAQ

解答の論理構成

1. DNSシンクホールで遮断できるのは「危険リストに登録されているFQDN」に対する問い合わせです。
   引用：「DNSシンクホール機能：DNSクエリをチェックし、危険リストに登録されているFQDNの場合は…IPアドレスを応答する。」
2. しかしマルウェアの挙動は必ずしも DNS を利用しません。
   引用：「マルウェアα及びマルウェアβのどちらにも…C&C サーバの IP アドレス及び FQDN のリストが埋め込まれていた。」
3. 埋め込まれた「IP アドレス」を直接用いて通信すれば DNS クエリ自体が発生せず、シンクホールは作動しません。
4. よって「UTM の FW 機能で IP リストへの通信を拒否」する措置も残す必要があります。
   ⇒ 解答「C&Cサーバとの通信時にDNSへの問合せを実行しない場合があるから」と導けます。

誤りやすいポイント

• 「DNSシンクホールを有効にすれば全て遮断できる」と思い込み、IP 直指定の経路を失念する。
• マルウェアが DNS に依存しないケースを想定せず、FW ルールを削除してしまう。
• 「攻撃者が行う設定変更」の内容を DNS 側だけと誤解し、FW の重要性を軽視する。

FAQ

解答の論理構成

1. 本文には、攻撃者が痕跡隠蔽のためにイベントログを消去した事実が記述されています。
   引用：
   “一部の業務PCでは、全てのイベントログが消去された痕跡があった。全てのイベントログが消去された後、イベントログにイベントログの消去を示すログが記録されていた。”
2. P氏は確認ツールの機能追加を提案する際、次のように述べています。
   引用：
   “イベントログに f が存在するかどうかもチェックする必要があると思います。”
3. 上記 1. の引用にある「イベントログの消去を示すログ」が、そのまま P 氏の言う f に該当します。
4. したがって、f に入る語句は
   イベントログの消去を示すログ
   となります。

誤りやすいポイント

• αログ・βログと混同し、「イベントログ削除ログ」などと略称・意訳で書いてしまう。
• “イベントログを消去した痕跡”と“イベントログの消去を示すログ”を同一視し、前者を回答に書いてしまう。
• 日本語順序を入れ替え「消去を示すイベントログ」などにしてしまい、原文の正確な引用にならない。

FAQ

解答の論理構成

1. 確認ツールが検査する対象
   会話文でGさんは「イベントログにαログ又はβログが存在するかどうかをチェックする確認ツール」を作成すると述べています。このツールは「βログ」がなければ“問題ない”と判定します。
   引用：
   「イベントログにαログ又はβログが存在するかどうかをチェックする確認ツールを作成してA社内に配布」
2. 「βログ」が出力される条件
   表2によると「βログ」が記録されるのは「マルウェアβ」の「遠隔操作機能」を実行したときだけです。
   引用：
   「遠隔操作機能 … このとき、イベントログにマルウェアβの実行を示すログ（以下、βログという）が記録される。」
3. 「待機機能」「横展開機能」ではログは残らない
   同じく表2で「待機機能」「横展開機能」にはログ出力の記述がありません。したがって感染していても、これら二つの機能しか動いていない場合は「βログ」が生成されません。
4. 以上より
   PCやサーバが感染後も「横展開機能」と「待機機能」だけを実行していると「βログ」がなく、確認ツールは“問題ない”と判定します。

誤りやすいポイント

• 「横展開機能」で他端末に感染を広げるため問題だと考え、「遠隔操作機能」も含めてしまう。
• 「待機機能」の存在を見落とし、「横展開機能だけ」と答えてしまう。
• 「βログ」が何に対応するかを覚え違え、「待機機能」や「横展開機能」でも出力されると思い込む。

FAQ

解答の論理構成

• 連携サーバを DC の DMZ に置けば、外部との通信は必ず UTM を経由します。
  引用：「UTM は インターネットとの接続境界に設置され、グローバルIPアドレスをもつ。」
• UTM には IDS 機能があり、外部から届くパケットを常時監視します。
  引用：「IDS機能：全てのインバウンド通信をチェックし、不審な通信を検知した場合は、システム管理者に通知する。」
• したがって、インターネット経由で連携サーバが攻撃を受けても、IDS が即座に検知し、通知を受けた管理者が迅速に対応できます。
• この機能を活用できる位置に連携サーバを置くことが、下線⑥「より迅速な対応が可能である」理由であり、模範解答の「UTMのIDS機能によって攻撃が検知でき、システム管理者に連絡がされるから」に合致します。

誤りやすいポイント

• FW と IDS を混同し、FW の遮断だけで「迅速な対応」と考えてしまう。IDS の通知機能を忘れると理由が不完全になります。
• DMZ という言葉から「隔離されているから安全」とだけ答えてしまい、検知・通知の仕組みを明示しない。
• UTM の DNS シンクホール機能やステートフルインスペクション機能を挙げてしまい、設問の主旨から外れる。

FAQ

解答の論理構成

1. 図9の指摘1には「対象期間の開始日は、本来は、保存されている最も古いイベントログの日付にすべきだが、せめて連携サーバに紐づけされたファイルが置かれていた可能性のある最も早い日付である g にする必要がある。」とあります。
2. 「連携サーバに紐づけされたファイル」が最初に置かれ得るのは、研究部の業務PCがマルウェアに感染し、攻撃者が横展開を図った時点以降です。
3. タイムラインによると「7月14日：攻撃者は、Dさんのアカウントを使って研究部のFさん宛にマルウェアαを添付したメールを送信した。Fさんがそのメールの添付ファイルを開いた結果、Fさんの業務PCがマルウェアαに感染した。」と記載されています。
4. 研究部のFさんの業務PCは研究部セグメントにあり、連携サーバの共有フォルダへ「認証なしでアクセス可能」と図4に記載されています。従って、連携サーバに不正ファイルが置かれ得る最初の日は「7月14日」です。
5. よって g に入る日付は「7月14日」となります。

誤りやすいポイント

• 「7月9日」を選んでしまう
  ⇒ 7月9日は不正ログインのみで、社内PCの感染はまだ発生していません。
• 「7月19日」をそのまま採用する
  ⇒ これは連携サーバの最古ログの日付であり、感染拡大の最早日ではありません。
• 「7月28日」を選ぶ
  ⇒ 7月28日は社内宛メールを断続的に送った開始日であり、連携サーバ経由を考慮すると遅過ぎます。

FAQ

解答の論理構成

1. 目的の確認
   表5「調査2」は「会員FWのログに、次に該当する送信元から宛先への通信記録が存在するかどうか」を調べます。宛先欄には、マルウェアが接続を試みる C&C サーバ側アドレスを指定する必要があります。
2. IPリストの定義
   【問題文】には、 “Gさん：…IPアドレスのリスト（以下、IPリストという）を手作業で作成しておき、IPリストに登録されたIPアドレスへの通信をUTMで拒否します。”
   とあります。IPリストはマルウェアα・βに埋め込まれていた C&C サーバの IP や、それらの FQDN の正引き結果をまとめたものです。
3. 調査2に必要な宛先
   感染を疑うべき通信は「IPリストに登録されたIPアドレス」へのアウトバウンド通信です。したがって、調査2 の宛先欄 h にはこの語句が入ります。
4. 結論
   h には
   「IPリストに登録されたIPアドレス」
   が入るのが妥当です。

誤りやすいポイント

• 「FQDN そのもの」や「C&C サーバ名」を記載してしまう
  → 会員FW のログ検索は IP ベースが一般的。FQDN ではヒットしない場合があります。
• 「UTM のグローバル IP アドレス」と誤読する
  → それは B サービスへのアクセス許可条件であり、本設問の文脈とは無関係です。
• 「DNSシンクホールの応答 IP」を書く
  → シンクホールは暫定対策ですが、感染有無の判定には元の C&C 側 IP を見る必要があります。

FAQ

解答の論理構成

1. 目的の再確認
   • ⑦の下線部で、P氏は「連携端末からほかのPCやサーバへの感染拡大が明らかな会員に絞る」と述べています。
   • したがって“感染拡大の証拠”となる通信記録を抽出する必要があります。
2. 調査2が対象とする通信
   • 表5の調査2では、会員FWのログから
     「送信元：任意のIPアドレス／宛先：h」
     の通信記録を検索します。
   • ここで宛先 h は C&C サーバを示し、“任意のIPアドレス”とは会員ネットワーク内の全端末（連携端末を含む・含まない）のいずれでも良いことを意味します。
3. “感染拡大”を示す送信元とは
   • 連携端末自身が C&C サーバへ通信している場合は、あくまで連携端末単体の感染に留まります。
   • 一方、連携端末以外の PC／サーバが C&C サーバへ通信していれば、連携端末から組織内に感染が広がったことが明白です。
4. 導出される条件
   • よって、絞り込みに用いる通信記録は
     「送信元が連携端末以外」であるものと結論づけられます。

誤りやすいポイント

• 宛先 h を“連携サーバ”と誤認し、送信元に注目しない。
• “任意のIPアドレス”の記述を見落とし、連携端末だけが対象と勘違いする。
• 連携端末が複数あると想定し、送信元を“別支店の連携端末”まで除外してしまう。
• 感染拡大と C&C 通信の関係を混同し、内部 LAN 間通信のログを探してしまう。

FAQ

解答の論理構成

1. 対象箇所の確認
   • 会話文に「⑧既に行っている対応」とあり、内容が前述の対応を指していることがわかります。
2. 前述の具体的対応を特定
   • 〔連携サーバ経由の感染状況の確認と感染拡大防止〕で、Eさんは
     「連携サーバをネットワークから切り離し、…化学コンの全会員に連携端末を一時的にネットワークから切り離してもらうように連絡」
     と記載されています。
3. 論理的導出
   • ⑧は「連携端末」に対して「一時的にネットワークから切り離」す行為であり、これにより感染拡大リスクが下がるというP氏の説明と整合します。
4. 結論
   • よって解答は「連携端末を一時的にネットワークから切り離した対応」となります。

誤りやすいポイント

• 「連携サーバ」ではなく「連携端末」を対象とする点を取り違える。
• 「物理的に電源を切る」と誤解し、ネットワーク遮断というニュアンスを欠落させる。
• ⑧を新たな追加対策と勘違いし、既に完了している措置と結び付けられない。

FAQ