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

解答の論理構成

1. 表1「A社 IRT の運用手順（概要）」の番号2「トリアージ」には、 “あらかじめ定めた基準に従い、重要度や優先度を考慮して、aを判断する。”
   と記載されています。
2. さらに同じ行の「次の手順の番号」欄では、 “aに応じて、番号3又は番号6に進む”
   と書かれています。
3. 番号3「調査依頼検討」は重大インシデントを想定した対応フェーズ、番号6「完了」はそのまま終結フェーズです。
4. したがって、番号2で下す判断は「これをインシデントとして対応すべきか、ここで終了してよいか」という“対応の要否”であると分かります。

誤りやすいポイント

• “a”を「重要度」や「優先度」そのものと思い込むケース。実際には重要度・優先度“を考慮して”決める対象がaです。
• 番号3と番号6の内容を読み飛ばし、トリアージの目的が“影響度分類”だけと誤解するケース。流れを追うと、最終的に行動するか否かの判断を示しています。
• “要否”を落として「対応要否」「要対応」など語形を誤ってしまうケース。設問は“決定すべきこと”を問うているため、名詞＋「の要否」とするのが自然です。

FAQ

解答の論理構成

1. 表2には「（省略）」という分類に対して「bが不明確である」と記載されています。
2. どの内容が“不明確”なのかを探すため、本文中の現状記述を確認します。
3. 〔A社IRTの現状〕には次のとおり明確な課題が記されています。
   • “A社の従業員に対して、A社IRTの存在を積極的には周知しておらず、A社IRTに報告すべきインシデントの範囲についても明確には定義していない。”
4. 上記引用から、曖昧になっているのは「インシデントを報告すべき範囲」であることが読み取れます。
5. したがって、bに入るべき字句は
   「報告すべきインシデントの範囲」
   となります。

誤りやすいポイント

• “インシデント自体の定義”と“報告すべき範囲”を混同しやすい。問題が問うているのは「誰が・何を報告対象とするか」という範囲設定です。
• 「重要度判定基準が不明確」など別の課題に目を奪われるケース。本文では重要度ではなく“報告対象の範囲”が明確に欠如していると指摘されています。
• 表2の「（省略）」という書き方から“分類名”を埋めると誤認しやすい。実際に求められているのは“問題点の中身”です。

FAQ

解答の論理構成

• 【問題文】の表1「対応指示」では
  “インシデントの全社への影響度に基づいて、インシデントの対応内容を決定し、必要な対応指示を行う”
  と明示し、指示主体は A社IRT であると定めています。
• しかし【問題文】表2「対応指示手順」の問題点には
  “現状はインシデントを発見した事業部が独自に影響度を判断し、事業部の都合を優先”
  とあり、表1の意図が守られていません。
• これを是正する改善策として経営陣は
  “①表1における対応指示は、A社IRTが直接行える”
  と規定し、事業部ではなく A社IRT が中央集権的に指示できるよう変更しました。
• 以上より、改善策の目的は
  “インシデントが A社全体に与える影響度を踏まえ、A社IRT が統一的な対応指示を出せるようにする”
  ことに帰結します。

誤りやすいポイント

• 「事マネの負荷軽減」が主目的と誤読しやすい。実際は影響度を一元評価する統制強化が本質です。
• 「指示権限を IT部から移管」と勘違いしがちですが、改善後の A社IRT は経営陣直属であり IT部ではありません。
• 表1の“対応指示”文を引用せずに理由づけすると根拠不足と判断されます。

FAQ

解答の論理構成

• 【問題文】には、IT部の運用保守について
  ――「IT部では…運用保守は、IT部のOA用PCから実施している。」
  とあり、管理用ポートへは通常業務にも使うOA用PCが直接アクセスしています。
• そのOA用PCはメール・Webも利用しているため、図4のような攻撃経路が現実に存在します。
  図4より
  ――「攻撃者がマルウェアを添付した攻撃メールを…OA用PC は攻撃者による遠隔操作が可能になった。」
• Yさん案の運用管理セグメントは
  ――「運用管理PCからサーバLAN…利用者LANからサーバLANへのアクセスについては、管理用ポートへのアクセスを禁止」
  と記載され、運用管理PCを“メール・Webとは分離した専用PC”として隔離します。
• したがって、従来はメール経由で IT部のOA用PC が乗っ取られるとサーバLANへ管理者権限で侵入されましたが、セグメント分離後は “利用者LANから管理用ポートは閉塞” されるため同一シナリオの攻撃を遮断できます。
• 以上から、問われる「現状では防げない攻撃」は
  「IT部のOA用PCに攻撃メール→マルウェア感染→サーバLANに不正アクセス」という一連の流れになります。

誤りやすいポイント

• SS部独自LANの侵入と混同し、IT部側のOA用PCを経由しないシナリオを書いてしまう。
• 「運用管理セグメント＝DMZ強化」と誤解し、管理ポートの閉塞効果を挙げ忘れる。
• 攻撃経路を“サーバLAN→利用者LAN”と逆に想定し、回答が内側発生型になる。

FAQ

解答の論理構成

1. 現状案の限界を確認
   • 【問題文】「同一のLDAP IDによる連続した認証失敗回数をカウント…」
     この方式は同じIDを繰り返す“ブルートフォース攻撃”には有効でも、IDを変えながら試行する“リバースブルートフォース攻撃”は検知できません。
2. 必要要件の明示
   • 【問題文】「リバースブルートフォース攻撃についても検知できる仕組みが必要」
     多数のIDを対象にした試行を検出するには“誰がアクセスしてよいか”を絞り込む視点が欠かせません。
3. LDAPサーバ管理画面の特性を活用
   • 【問題文】「運用チーム4名のLDAP IDでだけログインできる」
     正常系で許可されるIDは4つしか存在しません。したがって、この4ID以外で管理画面へログインしようとする行為は即座に異常と判断できます。
4. 検知ロジックの導出
   ホワイトリストに含まれないLDAP ID で管理画面にアクセス→即アラート
   こうすれば、“IDを変えながら1回ずつ試す”リバースブルートフォースでも1回目から検知できます。
5. 以上より、下線③の“新たな検知方法”は
   「IT部運用チームのメンバのLDAP ID以外によるログイン要求の検知」となります。

誤りやすいポイント

• 失敗回数をIPアドレス単位で数える案
  攻撃者がプロキシやボットネットでIPを変えるとすり抜けます。
• 単に「連続失敗回数を全ID合計で監視」と書く案
  正常利用時の偶発的失敗まで拾いやすく、誤検知増大。
• 管理画面の利用者制限を読み飛ばし、ホワイトリスト発想に至らない。

FAQ

解答の論理構成

1. 【問題文】図5「課題1：情報機器の現状の構成情報を正しく把握していない部署がある」と明記されています。
2. 構成管理情報が無いと、どの機器が存在し、どの OS・ミドルウェア・バージョンを使っているかが分かりません。その結果、脆弱性情報を“闇雲に”集めるか、逆に“集め漏れ”を起こします。
3. U課長は「A 社 IRT が各部署の構成管理情報を把握することを目指す」と述べています。これは IRT 側で“対象の情報機器を確定”し、効率的に脆弱性情報を収集する狙いです。
4. したがって、構成管理情報を活用する効果は「A社IRTが収集すべき脆弱性情報の対象を的確に特定できること」であり、模範解答「A社IRTが収集すべき脆弱性情報を把握するため」と一致します。

誤りやすいポイント

• 構成管理情報の“保有目的”を、パッチ適用の優先度決定と誤解しやすいですが、まずは「対象機器の特定」が主目的です。
• 「各部署の適用状況を監査するため」とだけ書くと、課題1ではなく課題2・3の文脈になりやすいです。
• 収集主体を「各部署」と書き違え、IRT が主導するという前提を落としやすいです。

FAQ

解答の論理構成

• 【問題文】図5の課題1で「情報機器の現状の構成情報を正しく把握していない部署がある。」と指摘されています。
• A社IRTの運用手順（表1）では、手順2「トリアージ」で「重要度や優先度を考慮して、aを判断する。」、手順5「対応指示」で「インシデントの全社への影響度に基づいて、インシデントの対応内容を決定」すると定められています。
• 影響度や優先度を正しく判断するには、どのシステム・ネットワークがどの部署に属し、どのように接続されているかという構成管理情報が不可欠です。
• さらに、セキュリティポリシ（図2）の「インシデントハンドリング」で「A社IRTは…受け付けた内容の事実確認を行う。」とあるように、“事実確認”の迅速化にも同情報が役立ちます。
• 以上より、構成管理情報は「インシデント発生時や対策時の影響範囲を特定する」場面で活用できるため、模範解答の内容となります。

誤りやすいポイント

• 構成情報の活用場面を「原因究明」や「再発防止」に限定してしまう。影響度判定こそが主要ポイントです。
• “資産台帳の整備”と書いて目的を示さない。問われているのは具体的な活用方法です。
• 「対応を迅速化」とだけ書いて抽象的になる。どのように迅速化されるのか（影響範囲の特定）を明示しましょう。

FAQ

解答の論理構成

1. 現状の問題認識
   • 図5の課題2では
     「情報機器の脆弱性情報を、ベンダのWebサイトや、脆弱性情報が記載されたWebサイトから収集するには多くの工数が必要だが、現状の要員では対応ができない。」
     とされ、人的リソース不足が明示されています。
2. 経営層の短期的対処方針
   • 本文には
     「短期的には増員せず、④A 社の各部署の取組みと連携して対応することによって、工数の発生を最小限に抑える。」
     とあります。増員せずに工数を減らすためには、各部署が既に行っている作業を再利用するのが自然です。
3. 各部署の既存活動
   • 各部署は「部署ごとに対応が異なっており、多忙なときは、漏れてしまったり、遅くなってしまったりするケースもある。」ものの、脆弱性情報の収集自体は行っています。
4. 連携の具体策
   • IRT が自ら全件を収集するのではなく、各部署が日常業務の中で取得した脆弱性情報を共有してもらえば、IRT 側の新規工数を抑えつつ網羅性を向上できます。
5. まとめ
   • 以上より「各部署が収集している脆弱性情報」を IRT が受け取り、一元的に活用する連携が最適となり、模範解答の「各部署が収集している脆弱性情報の提供を受ける。」に帰結します。

誤りやすいポイント

• 「IRT が代わりに全ての情報を収集する」と考えると、増員しないという前提と矛盾します。
• 「情報収集ツールを新規導入する」と答えると、本文で触れられるのは課題1の中長期策であり、課題2の短期策には含まれていません。
• 「対応計画の提出を義務付ける」は課題3の話題であり、課題2の連携方法ではありません。

FAQ

解答の論理構成

1. ゼロデイ攻撃とは、公開済みの攻撃コードが存在し、まだ有効な対策（パッチや回避策）が提供されていない状態の脆弱性を突いた攻撃を指します。
2. 【問題文】では CVSS の三つの評価基準を説明しており、該当箇所は次のとおりです。
   • 「二つ目は“現状評価基準”であり、攻撃コードの出現有無や対策情報が利用可能であるかどうかを基にした評価基準である。」
3. ゼロデイ攻撃が可能か否かは、まさに「攻撃コードの出現有無」や「対策情報の有無」がポイントになります。
4. よって、ゼロデイ攻撃の可否は「現状評価基準」に最も強く反映されると判断できます。

誤りやすいポイント

• 基本評価基準は「時間の経過や環境の違いによるスコアの変化はない」と明記されており、ゼロデイかどうかの“現時点”の状況は評価対象外です。
• 環境評価基準は各組織固有のネットワーク環境や対策状況を反映するもので、攻撃コードの公開・未公開そのものは評価の直接要素ではありません。
• ゼロデイという言葉から「まだ環境に依存していない＝基本評価基準」と早合点しやすい点に注意が必要です。

FAQ

解答の論理構成

1. FW1 の攻撃元区分を特定
   • 【問題文】「外部業者の担当者が遠隔地からインターネットを経由し、SSHクライアントソフトを用いて更新作業を行っている。」
   • 表5「ネットワークN：…インターネットからの攻撃など」
   • インターネット経由で管理チャネルが開いているため、FW1 は「ネットワーク」に該当し、c＝ネットワーク。
2. FW2 の攻撃元区分を特定
   • 【問題文】「ポリシー変更は、FW2のコンソールポートに常時接続されたMPCからだけ許可されている。」
   • 表5「ローカルL：…ローカルアクセス権限での攻撃が必要…」
   • MPC は SS 部独自 LAN 内のローカル端末であり、外部から直接は到達できない。したがって FW2 は「ローカル」に該当し、d＝ローカル。
3. どちらのスコアが高くなるか
   • CVSS の環境評価基準では、到達しやすい攻撃元区分ほどスコアが高くなる。
   • 「ネットワーク」は「ローカル」より攻撃しやすいためスコアが高い。
   • よって e＝FW1。

誤りやすいポイント

• 「MPC がネットワークに接続されているから FW2 も“ネットワーク”」と早合点する。MPC はインターネットに公開されておらずローカル限定。
• CVSS の“隣接A”と“ローカルL”を混同する。今回 MPC は同一サブネットなので「ローカル」。
• スコアが高い機器＝脆弱性が多い機器と誤解する。実際は「到達しやすさ」と「影響度」を評価した結果であり、脆弱性の数とは無関係。

FAQ