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

解答の論理構成

1. 目的の確認
   観察事項4では「法的要求事項を最新に保つ手法」が求められています。そのためには“誰が最終承認するか”というガバナンスの仕組みを明確にする必要があります。
2. 本文の該当箇所
   引用：
   「Fさん：4.については、新たな法律の制定や業界の動向を踏まえて社内のISMS運営事務局で法的要求事項の改訂案を検討し、aの場で承認を得るというルールを作るとよいと思います。」
3. ISMS運用で一般的な承認の場
   ISO/IEC 27001 では、 ・トップマネジメントが方針や改善状況を定期的に確認する「マネジメントレビュー」
   ・組織横断で情報セキュリティを審議する「情報セキュリティ委員会」
   が代表的な承認機関として推奨されています。いずれも“組織的に合意形成し、記録を残す”という要件を満たします。
4. 選択理由
   ・「社内のISMS運営事務局」が原案を作る ⇒ その上位に位置する承認機関が必要
   ・ガイドラインや監査報告書で頻出する承認の場は上記二つ
   以上より、a には
   「マネジメントレビュー又は情報セキュリティ委員会」
   を入れるのが妥当です。

誤りやすいポイント

• ISMS運営事務局自身を承認主体と誤解する。事務局は準備・運営を担い、承認権限は持たない点に注意が必要です。
• “取締役会”など会社法上の会議体を答えると、情報セキュリティに特化したレビューにならず不適切となる場合があります。
• 「マネジメントレビュー」と「内部監査」を混同するケース。内部監査は評価作業、マネジメントレビューは経営層が結果を踏まえて方針を見直す場です。

FAQ

解答の論理構成

1. 事実整理
   • 本文では、観察事項として「Web アプリケーションの開発委託におけるセキュリティ要件を明確にすることが望まれます。」と指摘されています。
   • その対応として G 部長は「①委託先に具体的なセキュリティ要件を提示する」と述べています。
2. 要件を提示しない場合の契約上の影響
   • 要件が契約書や仕様書に含まれないと、受託側はその実装義務を負いません。
   • したがって受入れ検査で脆弱性が発覚しても、委託側は「契約外の追加仕様」として扱われるリスクがあります。
3. 発生する具体的な問題
   • 「成果物に脆弱性が発見された場合でも受け入れざるを得ない」
   • または「改修費用の負担を巡って委託先とトラブルになる」
4. 結論
   • よって設問の問い（どのような問題が発生するか）には、上記いずれかを簡潔に述べれば十分です。

誤りやすいポイント

• 「品質が低下する」とだけ書いてしまい、具体的な契約・費用トラブルの観点が抜ける。
• 受入れ検査で不合格にできると思い込み、契約条項の有無の影響を見落とす。
• 技術的な対策（例：パッチ適用）に言及するが、設問は“問題”を問うている点を誤解する。

FAQ

解答の論理構成

• 【問題文】では、G部長が「ISO/IEC 27001のb計画でも対応すべき」と述べています。ISO/IEC 27001 でインシデント対応計画と並列に語られる代表的な計画は「事業継続計画」であり、英語の Business Continuity Plan (BCP) に相当します。したがって b に入る語は「事業継続」です。
• 同じ会話で、「社内のすべての機器は…標準時サーバと時刻を同期…通信の遅延を補正できるcというプロトコル」と記載されています。遅延補正機能を備え、標準時サーバと同期を取るプロトコルは Network Time Protocol の略称「NTP」であるため、c には「NTP」が入ります。

誤りやすいポイント

• 「事業継続計画」を「災害復旧計画」と混同しやすい。ISO/IEC 27001 では災害復旧は事業継続の一部として位置付けられるため、本設問で求められる語句は「事業継続」が正解です。
• Network Time Protocol（NTP）の特徴は「通信遅延を補正できる」点です。単に時刻合わせを行うだけの簡易プロトコルと取り違えないよう注意が必要です。
• 文字数条件に気を取られ過ぎると、本質的な用語選定がおろそかになることがあります。まずは標準規格・代表的プロトコルを思い出し、次に設問条件を確認する手順が有効です。

FAQ

解答の論理構成

1. 原因の把握
   • 本文には、対策が“実施している”と担当者が口頭で述べた場面があります。
     引用: 「G部長：『ウイルス定義ファイルの自動更新と定期スキャンも実施している』し、問題なさそうだ。」
   • しかし ISMS／PCI DSS では、実施“状況の証拠”を得て確認・記録することが要求されます。
2. 必要なエビデンスの特定
   • ウイルス対策ソフトは自動更新・定期スキャンを行うたびに結果をログへ記録します。
   • ログには日時・更新内容・スキャン結果など、設定が正しく作動したかどうかの客観的証跡が残ります。
3. 検証プロセスの確立
   • ログを「採取」して改ざん防止下に保管し、定期的に「レビュー」することで
     ・予定どおり更新が走ったか
     ・スキャンがエラー無く完了したか
     ・検知イベントが無いか
     を確認できます。
4. 以上を踏まえ、模範解答は
   「ウイルス対策ソフトの動作ログを採取し、レビューを行う。」
   となります。

誤りやすいポイント

• 口頭報告や設定画面の確認だけで済ませ、客観的証跡を残さない。
• OS のイベントログだけを確認し、ウイルス対策ソフト固有のログを見落とす。
• ログを取得しても保管・レビュー体制がなく、後日追跡できない。
• 「最新版が適用されたか」だけに着目し、定期スキャンの実行結果を確認しない。

FAQ

解答の論理構成

1. 【問題文】には、要件2への今後の対策として「システム上での不要なサービスや機能の無効化、停止」と明示されています。
2. 同じく【問題文】で G 部長は「③ポートスキャンツールを使って不要なサービスの有無を確認している」と述べています。
3. ポートスキャンでは “開いているポート番号＝提供中のサービス” を一覧できます。
4. したがって “不要サービスの有無” を判定するには、 ・そのサーバが正規に提供すべきサービスのポート番号表（業務要件や設計書で決定）と、 ・スキャン結果でオープンになっているポート番号
   を照合し、一致しないポートが存在するかをチェックすればよい、という論理になります。
5. この基準を踏まえると模範解答「システムで利用されるサービスのポート番号以外のポートがオープンになっていないかどうか。」となります。

誤りやすいポイント

• “脆弱性が検出されたかどうか” を基準にしてしまう
  → 設問はサービスの “必要／不要” 判定であり、脆弱性診断の合否ではありません。
• “外部ネットワークからアクセスできるか” を基準にする
  → 【問題文】は「検査対象と同一のネットワークセグメント」からのスキャンを前提にしています。
• ポート番号リストを更新し忘れる
  → 新規機能追加やバージョンアップ後はポート利用状況が変化します。

FAQ

解答の論理構成

1. 状況の把握
   本文では、「バックアップ媒体を④サーバ室に保管していますが、外部の施設への保管も検討する必要があります」とあり、バックアップがサーバ室という同一ロケーションに置かれていると分かります。
2. PCI DSS 要件9の意図
   Fさんは「要件9はカード会員データへの物理アクセスを制限すること」と説明しており、同時に「バックアップ媒体の保管の話があります」と述べています。要件9は盗難だけでなく、火災・水害など物理的災害からの保護も目的に含みます。
3. リスクの抽出
   サーバ室と同じ場所に置けば、火災・地震など発生時に「システムのデータ」と「バックアップ媒体」の双方が被災し、復旧に必要なデータが消失します。
4. まとめ
   したがって回答は、災害時に一次データとバックアップが同時に失われるリスクを指摘する内容になります。

誤りやすいポイント

• 「盗難リスク」だけを書く
  PCI DSS 要件9は災害も含む物理的リスク全般を対象にしているため、盗難だけでは不十分です。
• 「保管コスト増大」など管理面を中心に書く
  問われているのはリスク（被害）であり、コストは副次的要素です。
• 「外部施設に保管しないと基準違反」と断定する
  PCI DSS は代替策の余地を認めており、違反の可否を問う設問ではありません。

FAQ

解答の論理構成

• 【問題文】には「Fさんは…販売システムの管理を担当している」とあります。つまりＦさんは運用・保守の責任者です。
• 同じく【問題文】で「⑤私がPテストを実施するのは望ましくない」と発言しています。
• Pテスト（ペネトレーションテスト）は攻撃者の視点で脆弱性を検出する監査行為であり、公平性・客観性を担保するため運用担当者と独立した立場の者が行うのが原則です。
• 運用担当者自身がテストすると「自分が管理しているシステムを自ら検査」することになり、評価の独立性が損なわれます。
• したがって模範解答は「管理を行っているシステムを自ら検査することになるから」となります。

誤りやすいポイント

• 「社内実施＝常に不可」と早合点する。要件11.3は社内での実施も認めていますが、独立性の確保が前提です。
• 「スキル不足」が本質と誤解する。Ｆさんがスキルを習得しても独立性の問題は残ります。
• 「システム知識がある方が効率的」と考え、監査と運用の分離原則を軽視する。

FAQ

解答の論理構成

• 【問題文】では、WAFの方式として「ネガティブセキュリティモデル」が紹介され、下線⑥で「個々の攻撃に対してシグネチャを作成することが難しい」と述べています。
• ネガティブセキュリティモデルは、攻撃を識別するために「シグネチャや特定のパターンに合致した通信」を遮断する方式です。
• しかし、Webアプリケーション攻撃（SQLインジェクションやクロスサイトスクリプティングなど）は、 • パラメータ値の書式や長さ
  • 文字種（大文字／小文字、16進・URLエンコード）
  • 挿入位置や組合せ
  が無数に変化するため、単一の固定パターンでは捕捉できません。
• したがって「一つの脆弱性＝一つのシグネチャ」という対応が成立せず、シグネチャを網羅的に整備・維持することが困難である、という理由に帰結します。

誤りやすいポイント

• 「攻撃数が多いから大変」とだけ書き、パターンの多様性・変形手法に触れない。
• 暗号化通信（SSL/TLS）が原因で検査できない、と誤解する。
• ネガティブモデルとアンチウイルスのシグネチャ更新を同一視し、Web特有のパラメータ変形を軽視する。

FAQ

解答の論理構成

1. まず本文には、G部長の発言として「⑦Webアプリケーションの見直しをせずにWAFを導入することには問題がある」とあります。
2. これを受けて F さんは WAF の方式を説明し、「⑥個々の攻撃に対してシグネチャを作成することが難しい」と述べています。
3. つまり WAF は既知の攻撃パターンやあらかじめ定義した正常通信の範囲でしか防御できず、 ・未知またはシグネチャが未整備の攻撃
   ・アプリケーション固有のロジックエラー
   などを完全には防げません。
4. 一方、アプリケーション側の「見直し」（＝脆弱性修正）を行わなければ、攻撃ベクトル自体が残存し続けます。
5. よって「WAF だけに頼ると取りこぼしが発生し、脆弱性が修正されないままになるため攻撃を受けやすい」という結論になり、模範解答の内容に帰着します。

誤りやすいポイント

• 「WAF を導入すれば万能」と誤解し、根本的な脆弱性修正を後回しにしてしまう。
• シグネチャの更新やポジティブ／ネガティブモデル設定の運用コストを見落としがち。
• IPS と WAF を同一視し、アプリケーション層の防御範囲を正しく把握できない。

FAQ

解答の論理構成

1. 本文には次の記述があります。
   「要件を満たせない場合でも、関連するリスクをほかの手段を適用することでdできる場合には、その手段を代替管理策とすることで、要件の目的を実現することが可能です。」
   ここで［　d　］には“リスクに対して何をするか”を示す語句が入ります。
2. 代表的なリスク対応方針は、 「回避」「移転」「低減」「受容」の四つです。
3. 代替管理策は、追加または別のセキュリティ対策によってリスクの大きさを下げる取り組みです。これは「低減」に該当します。
4. 「移転」は保険契約やアウトソーシングでリスクを第三者に移す行為、「回避」は活動自体をやめること、「受容」はリスクを受け入れることなので、本文の文脈には合いません。
5. よって［　d　］に最適なのは「低減」であり、解答群の「エ」が正答です。

誤りやすいポイント

• 代替管理策＝別の部門や保険に任せる、と早合点して「移転」を選ぶミス。
• “要件を満たせない”→“受容”と連想し、「ウ」を選ぶミス。代替策はあくまで追加対策を講じる前提なので受容ではありません。
• 「回避」はシステム機能の廃止を意味するため、本文の“ほかの手段を適用する”文脈と矛盾します。

FAQ

解答の論理構成

1. 代替管理策が求められる背景
   • PCI DSSの「詳細要件3.4」は保存データを“判読困難”にすることを要求しますが、問題文では「ソフトウェアの制約によってトランザクションログを暗号化することができない。」と記載されています。
2. 追加で発生するリスクの特定
   • 表3の「3. 特定されるリスク」欄に「DBサーバにアクセス可能な従業員に対してトランザクションログに含まれるカード番号が露呈するリスクがある。」と明記されています。
3. 代替管理策の目的
   • 同表の「2. 目的」で「トランザクションログに含まれるカード番号を判読困難にすることによって、カード番号の露呈を防ぐ。」と示されています。
4. リスクを低減する現実的な手段の導出
   • 暗号化が困難であっても、「DBサーバにアクセス可能な従業員」を限定すれば、露呈リスクは大幅に低減できます。
   • 問題文の「要件を満たせない場合でも、関連するリスクをほかの手段を適用することでdできる場合には、その手段を代替管理策とすることが可能です。」というガイダンスからも、アクセス制御は正当な代替策と判断できます。
5. したがって e には
   トランザクションログに対して参照可能な利用者を制限する
   が入るのが妥当です。

誤りやすいポイント

• 「暗号化できないなら要件を満たせない」と早合点し、代替策を探さない。
• 「アクセス権を制限する」だけだと“判読困難”にならないと誤解し、追加の複雑な仕組みを考えてしまう。
• ログ全体を削除・非取得にする案を出し、トレーサビリティを欠落させる危険な提案をしてしまう。

FAQ

解答の論理構成

1. 追加対策の背景
   　問題文には「PCI DSSで求められる要件をベースラインとしてISMSにおける技術面及び管理面の改善を図るようにとの指示」が経営陣から出たとあります。つまり新たな管理策を導入した段階でPDCAサイクルの Plan／Do が完了しました。
2. ISO/IEC 27001 の要求
   　ISO/IEC 27001 では導入した管理策の「有効性の評価」「内部監査」「マネジメントレビュー」による Check／Act が必須です。
3. 次回審査に備え実施すべき作業
   　外部審査までに内部で Check を行い、必要に応じて改善 (Act) まで実施しておくことが ISMS の「継続的改善」の考え方です。したがって
   　「追加した対策の有効性を内部監査で確認し、改善計画を立てて改善を行う」
   　が最も直接的な回答となります。これは上記 PDCA サイクルにおける Check と Act の実行に該当し、ISO/IEC 27001 への適合維持を保証します。

誤りやすいポイント

• 「対策を文書化するだけ」で終えてしまい、内部監査や有効性確認を忘れる。
• ISMS のリスクアセスメントを更新せず、追加対策をリスク対応計画に反映しない。
• 外部審査対応と内部監査を混同し、内部監査の独立性・定期性の要件を満たさない。

FAQ