情報処理安全確保支援士 2015年 秋期 午後1 問01

解答の論理構成

• まず、Eシステムが担う役割を確認します。問題文には
  「“EシステムはQ社の販売チャネルの大部分を担っており、保守のための時間帯を除き、常時稼働している。”」
  とあります。売上に直結し、停止がそのまま機会損失になるため最優先は可用性です。
• 次に、Fシステムの役割を確認します。問題文には
  「“Fシステムは投資家などに対する財務情報・会社情報を提供している。”」
  とあります。投資家に対して誤った数値を出すことは企業価値や法令遵守に影響します。そこで最重要は完全性です。
• 以上より、情報セキュリティの3要素（機密性・完全性・可用性）のうち
  ・Eシステム：可用性
  ・Fシステム：完全性
  を重視するという解答に至ります。

誤りやすいポイント

• 可用性と完全性を逆にしてしまう
  「常時稼働」のキーワードを見落とし、Eシステムでも数値を扱うから完全性と誤解しがちです。
• Fシステムを“公開サイトだから可用性”と短絡的に判断する
  公開はしているものの、投資関連情報の正確さが最重要である点を逃さないことが必要です。
• 機密性を選んでしまう
  いずれの説明文にも“秘匿”や“個人情報”といった機密性を最優先する根拠が提示されていない点に注意します。

FAQ

解答の論理構成

1. 問題文には「表2の攻撃コードの送信後、WASのアクセスログ（以下、WASログという）のファイルがaに作成されます。」とあります。
2. 表2の項番1の説明は「WASログの出力先を公開ディレクトリ上に変更する。」であり、ここで “公開ディレクトリ” という言葉が明示されています。
3. 攻撃コードがログ出力先を “公開ディレクトリ” に変更してから任意コードを埋め込む流れであるため、a には攻撃者が意図的に設定したこの場所をそのまま入れるのが妥当です。
4. したがって、a に入る字句は「公開ディレクトリ」です。

誤りやすいポイント

• 「webapps/ROOT」を直接答えにしてしまう
  └ 説明文ではあくまでも “公開ディレクトリ” と表現しており、ディレクトリ名そのものを聞いているわけではありません。
• “ログファイル格納先” など抽象的に書く
  └ 問題は具体的な字句を求めており、表2で明示された言葉をそのまま使う必要があります。
• “公開フォルダ” と書き換える
  └ 固有表現を変更すると減点対象になります。

FAQ

解答の論理構成

• 【問題文】には「GETメソッドに限らずPOSTメソッド、Multipart/form-dataのPOSTメソッド、Cookieによる攻撃の可能性もあります。」とあり、攻撃はあらゆる HTTP リクエストに潜む可能性が示されています。
• 図2の説明では、[検証対象] に指定できる語として「GET」「POST」「ANY」「COOKIE」「Multipart」が列挙されています。
• 攻撃コードを完全に遮断したいので、[動作] は図2に定義されている「遮断」を用います。
• 以上を踏まえ、表3の各行の意図を整理すると次のとおりです。
  1. 行1は「任意のメソッドのパラメタ名」を対象にする必要があるため [検証対象]＝「ANY」。攻撃は防御したいので [動作]＝「遮断」。
  2. 行2は Cookie 由来の攻撃を想定しているため [検証対象]＝「COOKIE」。同じく [動作]＝「遮断」。
  3. 行3は 「Multipart/form-data のフィールド名」を対象とするため [検証対象]＝「Multipart」。同じく [動作]＝「遮断」。
• したがって、空欄は
  b：ANY
  c：遮断
  d：COOKIE
  e：遮断
  f：Multipart
  g：遮断

誤りやすいポイント

• ANY を「GET と POST の両方を対象にする語」と誤解し、Multipart や Cookie を別途カバーできていない回答をしてしまう。
• 図2の [動作] に「検知」もあるため、緊急対応であっても遮断ではなく検知を選んでしまう。
• Multipart と POST を混同し、Multipart の欄に POST を記入してしまう。

FAQ

解答の論理構成

• 【問題文】には、下線①として【引用】「①“^class¥..*”という[パターン]」が示されています。
• 図2で正規表現の要素が定義されており、該当部分を引用すると
  ・【引用】「^　 ：文字列の先頭にマッチする。」
  ・【引用】「¥. ：“.”とマッチする。」
  ・【引用】「*　 ：直前の要素と0回以上マッチする。」
  です。
• したがって ① の意味は
  1. ^…文字列の先頭
  2. class…文字列 class
  3. ¥.…直後にドット .
  4. .*…その後に 0 文字以上の任意文字列
     で構成され、「文字列の先頭が “class.” で始まるすべての文字列」に一致します。
• 解答群を検証すると
  • ア：anObject.class.classLoader → 先頭が class でないため不一致
  • イ：class.ClassLoader → 先頭が class. で始まるため一致
  • ウ：class.classLoader → 先頭が class. で始まるため一致
  • エ：class['classLoader'] → class の直後が [ でドットが無いので不一致
• よって、①の[パターン]にマッチする文字列は【解答】「イ、ウ」となります。

誤りやすいポイント

• .* の意味を「ドットを含む文字列」と誤解し、class['classLoader'] を選んでしまう。
• ¥. の存在を見落とし、ドットの有無を確認しないまま anObject.class.classLoader を選択する。
• ^ を無視して「途中に class. があれば良い」と判断してしまう。

FAQ

解答の論理構成

1. まず本文には
   “攻撃ではないHTTPリクエストを遮断してしまうhに注意する必要があります。”
   とあります。
2. これは「本来通過させるべき正常な通信を誤って遮断してしまう」状況を指しています。
3. 一般にセキュリティ製品で
   ・正常通信を“攻撃”と誤認 → フォールスポジティブ（False Positive）
   ・攻撃通信を“正常”と誤認 → フォールスネガティブ（False Negative）
   と呼び分けます。
4. 選択肢を見ると、正常通信を遮断するケースに該当するのは “エ：フォールスポジティブ” です。
5. よって h には “フォールスポジティブ” が入ります。

誤りやすいポイント

• 「フォールスネガティブ」と取り違える
  攻撃を見逃すケース（検知しない）がフォールスネガティブであり、本文の状況とは逆です。
• “フェールセーフ／フェールソフト”との混同
  これらは障害時のシステム挙動を示す設計思想で、検知精度の話ではありません。
• 「遮断＝安全だから正しい」と短絡する
  過剰遮断は可用性を損ね、業務影響が大きいことを踏まえる必要があります。

FAQ

解答の論理構成

• 【問題文】には、脆弱性 X を悪用すると「任意のファイルへの書込みなど、WASの動作権限で任意の攻撃コードを実行できる」とあります。
• さらに、表1では「WAS」の「現在の動作権限設定」が「管理者権限」と示されており、攻撃成功時にシステム全体へ深刻な影響が及ぶ状態です。
• 本文中の下線②には「現在のWASの動作権限設定を見直します」と記されており、見直しの方向性としては権限を下げる以外にありません。
• 以上より、攻撃コード実行後の被害を最小化するためには「WAS を必要最小限の権限で動作させる」ことが最適解となります。

誤りやすいポイント

• 「OS」や「HTTPサーバ」の権限を変更すると誤解しがちですが、指定対象は下線②が示す「WAS」です。
• 「WAF を導入したから権限制御は不要」と考えるのは誤りです。多層防御の観点から権限の縮小も必須です。
• 「一般ユーザ権限で動かす」と断定すると、サービスに必要な権限まで失う可能性があります。「必要最小限の権限」と抽象度を保つことが重要です。

FAQ

解答の論理構成

• まず設問は「本文中の下線③」―すなわち
  「開発検証用のシステムで③動作検証を実施し、問題ないことを確認後」と示された工程で、WAFに対して“何を”検証すべきかを問うています。
• 文中で WAF ルールについて説明する部分に
  「Tさん：攻撃ではないHTTPリクエストを遮断してしまうhに注意する必要があります。」
  とあり、誤遮断（フェールス・ポジティブ）への懸念が明示されています。
• さらに脆弱性 X への対策目的として
  「WAFによる対策は、脆弱性Xを悪用した攻撃を防ぐ効果があり」
  と記されています。
• よって動作検証では以下の2点を確認しなければなりません。
  1. 新ルールが “脆弱性Xを突く攻撃” を確実に遮断できること
  2. 同時に “Eシステムを通常利用する正当な通信” が阻害されないこと
• これを 30 字以内でまとめると模範解答の
  「①：脆弱性Xを突く攻撃を防げること」
  「②：Eシステム利用のための正常な通信が許可されること」
  となります。

誤りやすいポイント

• 攻撃遮断だけに着目し、業務トラフィックが通るかの検証を漏らす。
• ④で触れられる “検知モード運用” と ③の “動作検証” を混同し、ルール順序やログ出力を検証項目に挙げてしまう。
• 「POST だけ」「GET だけ」など特定メソッドだけを対象にしてしまい、本文で警告されている「POSTメソッド、Multipart/form-dataのPOSTメソッド、Cookieによる攻撃の可能性」を見落とす。

FAQ

解答の論理構成

1. 原文では、WAFのルールは通常 “遮断” で本番導入する前に “検知” で様子を見る運用が推奨されています。
   引用：
   「④本番環境のシステムに追加したルールの[動作]に“検知”を指定し、一定期間運用するのが望ましい。」
2. “検知” 動作は「通信を通過させ、ログに記録する」（図2）ため、ビジネスに影響を与えずにデータだけ取得できます。
   引用：
   「[動作]には…検知：通信を通過させ、ログに記録する。」
3. この運用により、実利用トラフィックでルールが誤ってマッチしないかを安全に確認できます。もし誤検知が多い場合でも遮断しないため「販売チャネルの大部分を担う」Eシステムへの影響を回避できます。
   引用：
   「EシステムはQ社の販売チャネルの大部分を担っており…常時稼働している。」
4. したがって、利点は「ビジネスへの影響を与えずに誤検知を検証できる」点に集約され、模範解答の内容となります。

誤りやすいポイント

• “検知” と “遮断” の違いを混同し、「攻撃を防げる」と答えてしまう。
• 「一定期間運用＝攻撃を受ける期間が延びる」と誤解し、利点を否定的に書く。
• 利点を「ログが取れる」だけにとどめ、なぜそれが重要か（ビジネス影響の回避）まで言及しない。

FAQ