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

解答の論理構成

1. 表3の情報を裏付けるには、“インターネットとの境界”で記録された通信ログを確認するのが最短です。問題文には
   “FW1とFW2は、ステートフルパケットインスペクション型である。”
   とあり、さらに FW1 は境界側に位置しています。したがって、C&C サーバ宛ての外向きセッションが存在したかどうかは 「FW1」 のログで即時確認できます。
   → a ＝ FW1
2. 次に、同じ通信が社内のどの端末から出たのかを突き止めるには、内部 IP アドレスが残るログが必要です。問題文には
   “プロキシサーバでは、各機器からの全てのアクセスについて、アクセスログを取得している。”
   とあります。プロキシログには「社内 PC のプライベート IP」＋「宛先ホスト情報」が記録されるため、端末を一意に特定できます。
   → b ＝ プロキシサーバ
3. 以上より、模範解答
   a：FW1
   b：プロキシサーバ

誤りやすいポイント

• “FW2 も境界機器だから a は FW2” と誤判定しがちですが、FW2 は社内セグメント間の境界であり、インターネット側トラフィックは通過しません。
• “内部メールサーバや認証サーバのログでも追跡できる” と考えがちですが、HTTPS 通信しか手掛かりがないためメール系ログでは検証できません。
• “b を DHCP サーバと解釈” するミス。DHCP では IP ⇔ MAC は分かりますが、外向き通信の宛先までは記録しません。

FAQ

解答の論理構成

1. まず本文には「コピーは ①ファイル単位ではなくセクタ単位で全セクタを対象とした」と明記されています。
   • ファイル単位バックアップでは、ファイルシステムが“存在している”と認識するデータしか保存されません。
2. インシデント対応では、攻撃者が痕跡を消すためにファイルを削除・隠蔽している可能性が高いです。
   • 削除されたファイルは“未割当て領域（空きセクタ）”に残留している場合があります。
3. そこでセクタ単位の完全コピーを行えば、
   • ファイルシステムが把握していない 未割当て領域 や スラックスペース も含めて複製できます。
4. これにより、攻撃の痕跡となる「削除済みマルウェア／ログ／設定ファイル」を後からフォレンジックツールで復元・解析できるようになります。
5. 以上より、P君が想定した調査は
   1. “削除されたファイルの内容” を
   2. “空きセクタの情報からファイル復元ツールを用いて”
      調査することだと導けます。

誤りやすいポイント

• 「全セクタ＝バックアップを安全に取りたいだけ」と早合点し、フォレンジック目的を見落とす。
• “ログの完全性確保”と解答してしまい、削除ファイルという核心を外す。
• 手段を「イメージコピー」とだけ書き、具体的に“空きセクタの復元”を示さず減点される。

FAQ

解答の論理構成

1. 【問題文】には
   “② WPA2を使用していても、無線LANの通信が傍受されてしまうとBさんが利用しているタブレットPCのMACアドレスを攻撃者が知ることができる”
   とあり、攻撃者が MAC アドレスを取得できる事実が示されています。
2. これは IEEE 802.11 の仕様上、暗号化対象が “フレーム本体（データ部分）” であり、送信元・宛先 MAC アドレスを含む “フレームヘッダ” は暗号化されないためです。
3. 従って、無線区間を受動的に傍受するだけでヘッダを読めるので、攻撃者は簡単に “MACアドレス” を取得できます。
4. 以上より、設問に対する理由は
   “MACアドレスが平文の状態で送信されるから”
   となります。

誤りやすいポイント

• 「WPA2はすべてのフレームを暗号化する」と思い込み、ヘッダも保護されると誤解する。
• “MACアドレスを隠すにはWPA2-Enterpriseが必要” など、認証方式とヘッダ暗号化を混同する。
• 暗号化対象を “パケット” と表現して payload と header の区別をあいまいにする。

FAQ

解答の論理構成

1. 総務部の W-AP では
   “・登録済みMACアドレスをもつ端末だけを接続可能とする接続制御”
   が行われています。したがって接続可否は MAC アドレスに依存します。
2. W 主任は
   “②WPA2を使用していても、無線LANの通信が傍受されてしまうとBさんが利用しているタブレットPCのMACアドレスを攻撃者が知ることができる”
   と説明しており、攻撃者は正規端末の MAC アドレスを取得できます。
3. 問題の下線③は“攻撃者が、自分の無線LAN端末を総務部のW-APに接続可能にする方法”です。
4. 攻撃者が自端末の無線 LAN インタフェースに取得した正規端末の MAC アドレスを設定（偽装）すれば、W-AP の接続制御を通過できます。
5. 以上を踏まえ、模範解答は
   “端末の無線LANポートのMACアドレスを、総務部のW-APに登録済みのMACアドレスに変更する。”
   となります。

誤りやすいポイント

• WPA2 の暗号を破ることが必須だと勘違いし、MAC アドレス偽装に気付かない。
• 802.1X 認証のバイパスを狙う攻撃と混同し、利用者 ID／パスワードの窃取だけを書いてしまう。
• “MAC アドレスの追加登録”と回答してしまい、既存登録との差し替え（偽装）を示さない。

FAQ

解答の論理構成

1. 問題文ではECBモードについて「仮にTCP/IPパケット全体をECBモードで暗号化した場合、cが繰り返して現れることになり、暗号の解読が容易になる」と示されています。
2. ECBモードは“同一の平文ブロック → 同一の暗号ブロック”という弱点があり、平文側に繰り返しパターンが存在すると容易に推測されます。
3. そこで下線部④が問い掛ける「パケットがもつある特徴」とは、パケット内に“毎回ほぼ同じ内容の部分”が存在する点だと考えるのが自然です。
4. TCP/IP通信では、送信元・宛先アドレスやポート番号、プロトコル番号などが格納される「IPヘッダ部」および「TCPヘッダ部」があります。端末間で継続的に通信する限り、これらヘッダの多くのフィールドは変化しにくく、同一のバイト列が複数パケットで繰り返し出現します。
5. よって、同じ端末間であれば「IPヘッダ部及びTCPヘッダ部は、同一のバイト列であることが多い」という特徴こそが、下線④で求められる答えとなります。

誤りやすいポイント

• 「ペイロード（データ部）が似通っている」と思い込み、ヘッダではなくデータ側を答えてしまう。ペイロードはアプリケーション毎に変動しやすく繰り返しパターンが保証されません。
• 「CRCやチェックサムが一定」と解釈してしまう。チェックサムはパケット毎に再計算されるため一定にはなりません。
• 「TCPシーケンス番号が増分で一定」など、増分値を“同一”と誤認してしまう。増分はブロック単位で見ればバイト列が変わるため繰り返しにはなりにくいです。

FAQ

解答の論理構成

1. ECBモードの性質を確認
   • 【問題文】「仮にTCP/IPパケット全体をECBモードで暗号化した場合、cが繰り返して現れる」とある。
   • ECBモードは“同じ平文ブロック → 同じ暗号ブロック”になるため、繰り返し現れるものは「同一の暗号ブロック」である。
   • よって c＝「同一の暗号ブロック」。
2. CTRモードの構造を確認
   • 【問題文】「CTRモードでは、暗号ブロックは、dとeの排他的論理和である。」とある。
   • 図3より、CTRモードは
     $e_i=m_i\oplus {\text{Enc}}_k(c+i-1)$
     で表される。ここで
     ・$m_i$ … 平文ブロック
     ・${\text{Enc}}_k(c+i-1)$ … カウンタ値を暗号化した値
   • したがって
     ・d＝「平文ブロック」
     ・e＝「カウンタ値を暗号化した値」。
3. 結論
   • c：「同一の暗号ブロック」
   • d：「平文ブロック」
   • e：「カウンタ値を暗号化した値」

誤りやすいポイント

• ECBモードの説明を「同一の平文ブロック」と書き換えてしまうミス。問われているのは暗号化後の結果。
• CTRモードのeを「カウンタ値」そのものと誤解するケース。暗号化後の値である点に注意。
• dとeの順序を逆に記入してしまう混同。

FAQ

解答の論理構成

• 本文では、ブラックリスト機能の可否を説明する場面で次の文が示されています。
  “HTTP通信の場合、プロキシサーバでは内容をfことができる。”
• HTTPは暗号化されていない平文通信です。したがってプロキシサーバはパケット内のリクエストヘッダや本文をそのまま確認できます。
  例：URL のパスやクエリ、POSTデータなどを把握可能。
• 続けて本文は、HTTPS では「社内PCとWebサーバの間でTLSセッションが成立して暗号通信路が確立した後は、プロキシサーバでは内容をfことはできない」と述べています。
  HTTPSは TLS により暗号化されるため平文読取りが不可能になることを示唆しています。
• したがって f には“暗号化されていないデータを確認する”という意味の語が入る必要があります。プロキシが行うのはデータの「閲覧・参照」よりも直接的に“中身を読む”行為であるため、「読み取る」が最も自然です。
• 以上より解答は
  f：読み取る

誤りやすいポイント

• 「解析する」「検査する」「確認する」など広義の言葉を選ぶと、後段の “内容をfことはできない” と接続した際に不自然になる場合があります。
• HTTP と HTTPS の違いを暗号化有無ではなくポート番号（80/443）の差とだけ捉え、文脈を読み落とすと適切な動詞を選べません。
• プロキシサーバがパケットを中継する位置情報に気を取られ、“取得する”や“保存する”とする誤答も発生しがちです。

FAQ

解答の論理構成

1. 問題文では
   “社内PCからプロキシサーバにCONNECTメソッドによって接続要求を送る時点では平文でWebサーバのg名とポート番号が渡される”
   と記載されています。
   HTTP CONNECT は TLS を張る前に CONNECT www.example.com:443 HTTP/1.1 のように送信し、プロキシに対し接続先ホスト名とポート番号だけを明示します。したがって g には “ホスト” が入ることになります。
   ─ 選択肢「カ：ホスト」が合致します。
2. 続けて
   “実質的にブラックリストに登録できるのが、URLのg部とポート番号部だけであり、h部は指定できない”
   とあります。URL 構文では
   https://ホスト:ポート/パス
   となるため、ホストとポート以外の部分は “パス” です。TLS セッション確立後は /download/evil.exe などのパス情報が暗号化されるため、プロキシは参照できません。従って h には “パス” が入ります。
   ─ 選択肢「オ：パス」が該当します。
3. 以上より
   g：カ（ホスト）
   h：オ（パス）

誤りやすいポイント

• 「ドメイン名」「URL」などの語をそのまま当てはめてしまう。CONNECT で送られるのはドメイン名ではなくホスト名（FQDN）。
• パスを「リソース」「ファイル名」と早合点する。問題文では URL 構成要素の正式名称「パス」を求めている。
• HTTPS でもプロキシが“すべて”見ることができると誤解する。実際は CONNECT 要求時点のヘッダだけで、本通信は暗号化される。

FAQ

解答の論理構成

• 下線⑤には「マルウェアが窃取した情報を社内 PC から社外に送信する経路がFW1 を経由した HTTPS 以外にもあり」とある。
  すなわち、FW1 の HTTPS‐復号と L7FW 機能をすり抜ける “別ルート” を特定する必要があります。
• ルート①：無線 LAN からの直接脱出
  • 本文には「不審なW-APが、N社敷地外にあることを発見」とあり、攻撃者が自前のアクセスポイントを設置している事実が確認できます。
  • 感染 PC がこの W-APへ接続すれば、通信は FW1／FW2 を通らずインターネットへ到達できるため、情報送信経路になります。
  • したがって「攻撃者が用意したW-APに接続し、情報を送信する。」が成立します。
• ルート②：社内メール経由
  • 表1 には「項番6 内部メールサーバ → 外部メールサーバ SMTP 許可」と明示され、FW1 上で SMTP が恒常的に許可されています。
  • マルウェアが内部メールサーバを踏み台にし、自動的に “窃取情報を添付したメール” を外部メールサーバへ送信すれば、HTTPS 復号の対象外であり検知困難です。
  • これが「内部メールサーバを利用して攻撃者にメールを送信する。」という経路です。
• 以上より、要求された「二つの具体例」はモデル解答のとおり正当であると論証できます。

誤りやすいポイント

• FW1／FW2 のどちらを通過するかを混同し、社内 PC→プロキシ→FW1 以外の経路を見落とす。
• SMTP は“平文メール”と決めつけ、暗号化（SMTPS）なら検知できると誤解する。実際には FW1 の HTTPS 復号は SMTP には無関係。
• DMZ からの送信（外部メールサーバやプロキシサーバ）を「社内 PC が直接使えない」と思い込み、攻撃者が内部メールサーバを経由できる事実を見逃す。

FAQ

解答の論理構成

1. 問題文（図5の説明）には
   “FW1 が発行した自己署名証明書を i として全ての社内 PC に登録する。”
   とあります。ここで FW1 は社内 PC と外部 Web サーバとの間に入り込み、TLS セッションを中継・復号するため、自らが発行する証明書を“信頼できるもの”として PC 側に認識させる必要があります。
2. 信頼できる証明書として登録する場合、一般には「ルート CA（Certification Authority）証明書」を OS やブラウザの“信頼済みストア”に格納します。問題文の別箇所にも、 “FW1には、FW1の製造元によって安全性が確認されたCAのディジタル証明書だけが、信頼されたルートCAのディジタル証明書としてインストールされている。”
   とあり、信頼の対象が“CAのディジタル証明書”であることが示されています。
3. よって、i には「信頼するCAのディジタル証明書」と入れることで、FW1 が自己署名した証明書を CA 証明書として登録し、以降 FW1 が動的に発行するサーバ証明書を社内 PC が検証可能になる仕組みを正確に表せます。

誤りやすいポイント

• “自己署名証明書”という語だけを拾い、「自己署名サーバ証明書」と答えてしまう。登録すべきは“CA 証明書”であり、サーバ証明書ではありません。
• “ルート証明書”とだけ書いてしまい「何のルートか」が曖昧になる。CA を明示しないと意図が伝わりにくく減点されがちです。
• ブラウザ側にインポートする対象を“公開鍵”と誤認するケース。TLS では公開鍵そのものではなく“ディジタル証明書”を信頼ストアに登録します。

FAQ

解答の論理構成

1. 表5の項番1には、制約の原因として【問題文】「図4の流れの中で、FW1は、社内PCがもっているクライアント証明書に対応した秘密鍵を利用することができない。」とあります。
2. 秘密鍵が使えないということは、TLSハンドシェイクで社内PCがクライアント証明書を提示しなければならないタイプの通信（いわゆる相互認証）が対象であると分かります。
3. FW1は中継型でTLSを二重終端しますが、社内PCの秘密鍵は保持していません。そのため相互認証が要求される外部Webサーバに対しては復号処理を適用できず、例外扱いにする必要があると読み取れます。
4. よってjに入る通信の種類は「クライアント証明書の提示が必要な外部Webサーバにアクセスする」となります。

誤りやすいポイント

• 「サーバ証明書に不備がある場合」と混同し、サーバ証明書関連の項目をjと勘違いする。
• 制約の原因だけを見て「秘密鍵が使えない＝復号不可」と理解できず、単に「HTTPS通信」と答えてしまう。
• 相互認証＝VPNと誤解し、Webアクセスでのクライアント証明書利用を想起できない。

FAQ

解答の論理構成

1. 表5の項番3には、 “FW1には、FW1の製造元によって安全性が確認されたCAのデジタル証明書だけが、信頼されたルートCAのデジタル証明書としてインストールされている。”
   とあります。
2. つまり、FW1が信頼していないCAで署名されたサーバ証明書を提示する外部Webサーバへ接続すると、FW1はその証明書を検証できず復号処理を中断します。
3. したがってkには、 “FW1の製造元によって安全性が確認されていないCAが発行したサーバ証明書を使用した外部Webサーバにアクセスする。”
   が入ります。

誤りやすいポイント

• “自己署名証明書を使う場合”と混同しやすいですが、設問は“信頼されていないCAが発行した証明書”を指しています。
• “クライアント証明書”の有無を理由にしてしまうミス。項番3の原因はCA信頼性であり、クライアント証明書は無関係です。
• “FW1が証明書を生成するケース”と誤解しやすいですが、制約の対象は外部Webサーバ側の証明書です。

FAQ