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

解答の論理構成

1. 表3のaは「検査項目」の名称を問うている。
2. 同じ行の「検査内容」には
   ――「1～65535のTCPポートにSYNを送信し、①応答結果からポートが開いているかどうか確認する。」
   と記載されている。
3. TCPポートに対して SYN パケットのみを送り、返ってくる SYN/ACK（開放）や RST（閉塞）の応答でポート状態を判別する手法は、一般に「SYNスキャン」と呼ばれる。
4. したがって、a に入る検査項目名は「SYNスキャン」となる。

誤りやすいポイント

• 「ポートスキャン」とだけ書くと漠然とし過ぎて減点対象になりやすいです。問題では SYN を使う方法が明示されているため「SYNスキャン」と特定する必要があります。
• TCP コネクトスキャン と混同しがちですが、コネクトスキャンは 3 ウェイハンドシェイクを完了させる手法、SYNスキャンは半開状態で判断する手法です。
• 「SYNフラッド攻撃」と書く誤答も散見されますが、検査目的は脆弱性確認であって DoS 攻撃ではありません。

FAQ

解答の論理構成

1. 【問題文】には検査手順として
   「1～65535のTCPポートにSYNを送信し、①応答結果からポートが開いているかどうか確認する。」
   とあります。これは TCP SYN スキャン（ステルススキャン）の典型的な方法です。
2. SYN スキャンで送ったパケットに対し
   • ポートが開いている場合：対象ホストは TCP 三者握手の 2 つ目に当たる SYN ACK を返します。
   • ポートが閉じている場合：対象ホストは接続を拒否するため RST ACK を返すか、ファイアウォール等で破棄されて「応答なし」となるのが一般的です。
3. 解答群の記号に照らすと
   • 開いている場合の応答は「カ：SYN ACK受信」
   • 閉じている場合の応答は「エ：RST ACK受信」「ク：応答なし」
   となります。

誤りやすいポイント

• ACK受信（ア）と FIN ACK受信（イ）は、SYN スキャンではなく通常の通信終了や確立済み接続でやり取りされるパケットなので選択しない点に注意が必要です。
• 「RST受信」（オ）は実際には RST ACK と同義に扱われることが多いものの、解答群が RST ACK受信（エ）を明示しているため紛らわしくなっています。
• ファイアウォールで破棄された場合の「応答なし」（ク）は閉じているポートの一種（“filtered” 状態）として扱われることを忘れやすいです。

FAQ

解答の論理構成

1. 表3 項番6の説明
   – 「項番5で起動したプロセスが、bできるか確認する。」とある。
2. マルウェアＭの基本挙動
   – 表2 項番1に「HTTPを用いてC&Cサーバと通信し、ボットとして活動する。」と明記されている。
3. 項番5で“ダウンロードしたファイルを起動”しているため、ここで起動したのはマルウェアＭと同等機能を持つプロセスだと推定できる。
4. したがって、検査すべき動作 b は「HTTP通信で外部（インターネット上）のサーバとやり取りできるか」である。
5. 以上より解答は「HTTPを用いて、インターネット上のサーバと通信」となる。

誤りやすいポイント

• 「C&Cサーバとの通信」とだけ書き、通信手段の「HTTP」を落とす。
• 「ダウンロード」や「実行」など項番4,5の動作を繰り返し書き、項番6で求められた“通信”を見落とす。
• 「外部サーバ」を「内部サーバ」と誤記し、マルウェアのボット活動の本質を外す。

FAQ

解答の論理構成

1. 原因の特定
   • 検査結果で「TCPポート2323が開いていた」「TELNETで接続できた」と判明。
   • 開発部調査により「委託先が開発時に使ったデバッグ用プログラムとその起動スクリプトが、出荷版のファームウェアにそのまま残されていた」ことが原因と分かる。
2. 出荷済み製品への影響
   • 「既に出荷済みのZカメラがあることに配慮し、②対策を関係部署に依頼」したと記載されている。
   • 出荷後に現場で物理作業を行うのは非現実的であるため、ネットワーク経由での修正が必須。
3. 有効な対策の導出
   • 不要なデバッグ用プログラムと起動スクリプトを除去したファームウェアを新規に作成。
   • Zシステムの仕組みでは「ファームウェアを配信」できるため、これを利用して各カメラへ配布する。
4. まとめ
   以上より、出荷済みZカメラにも適用可能で、脆弱性を根本から排除できる具体策は「修正版ファームウェアのリモート配信」である。

誤りやすいポイント

• 脆弱なポートを閉じる設定変更だけと誤記しやすい
  → デバッグ用スクリプトの削除も必須。
• 物理回収を提案してしまう
  → 問題文で回収コストを避ける意図が示唆されている。
• ファームウェア配布経路を示さない
  → Zクラウド経由の自動配信機能があることを見落としやすい。

FAQ

解答の論理構成

1. 表4の項番1には
   「cによる暗号通信の盗聴」
   と書かれています。さらに検査方法として「TLS終端装置1)の付いたプロキシサーバを用いて、ZカメラとZクラウド間のHTTPS通信の内容を復号して確認できるか検査する。」とあります。TLS通信を途中で終端し内容を盗聴・改変する典型的な攻撃は「中間者攻撃」です。したがって
   c：カ（中間者攻撃）
   となります。
2. 表4の項番2には
   「攻撃者によるdを使った偽Zクラウドへの誘導」
   と書かれています。検査方法では「偽Zクラウド上で…」「偽カメラIFにZカメラを接続させて…」とあり、偽サーバへ誘導するために名前解決を攻撃することが示唆されています。DNSのキャッシュを書き換えて正規ドメインを偽IPアドレスに対応付ける手口は「DNSキャッシュポイズニング攻撃」です。したがって
   d：ア（DNSキャッシュポイズニング攻撃）
   となります。

誤りやすいポイント

• 「暗号通信の盗聴」から辞書攻撃やサイドチャネル攻撃を連想してしまう。TLSを途中で終端するという説明を見落とすと誤答になります。
• 「偽Zクラウドへの誘導」からフィッシングを思い浮かべ、セッション固定攻撃や水飲み場型攻撃と混同しやすい。DNSを書き換えて誘導する点に注目する必要があります。
• HTTPS が使われているため「暗号化されているから安全」と早合点し、中間者攻撃で証明書を悪用するシナリオを想像できないことがあります。

FAQ

解答の論理構成

1. 【問題文】には次の記述があります。
   「B主任は、カメラIF通信は、eによって暗号化されているので、通信内容を盗聴されるおそれがないことを説明した。」
   ここで e は “暗号化の手段” を示す語句です。
2. 同じ段落より前のカメラIF通信の仕様には、 「・インターネットからWebサーバへの接続は、HTTP over TLS（以下、HTTPSという）だけが許可されている。」
   「・Zカメラ及びZアプリはWebサーバにHTTPSのPOSTメソッドを用いて通信する。」
   と明示されています。
3. つまり Zカメラと Zクラウド間の通信路（カメラIF通信）は “HTTPS” で保護されているため盗聴リスクが低い、という説明になります。
4. 以上より e に入る適切な字句は「HTTPS」となります。

誤りやすいポイント

• TLS と HTTPS の混同
  「TLS」と書いてしまうと“プロトコル階層での暗号化方式”の名前になり、問題が求めている「通信方式（HTTP over TLS）」とはズレます。
• 無線LANの暗号方式（WPA2 など）と勘違いする
  カメラIF通信はインターネット上のアプリケーション層通信であり、無線区間の暗号化方式ではありません。
• SSL と記述してしまう
  現行仕様で強調されているのは「HTTPS」であり、旧称「SSL」は原文に登場しません。

FAQ

解答の論理構成

• 【問題文】には「③プライベート認証局のルート証明書を、テスト対象のZカメラに、信頼されたルート証明機関のものとして登録していない」とあります。
• 目的は、Zカメラが提示されたサーバ証明書の真正性を検証できるかを試験することです。
• もしプライベートCAのルート証明書を“信頼済み”として登録してしまうと、攻撃者側で発行した偽サーバ証明書でも検証が成功します。
• その結果、Zカメラがサーバ証明書の検証（証明書パス・CN一致など）を正しく行っているか判別できません。
• したがって「証明書パスの検証が行われているかを確認できなくなるから」が理由となります。

誤りやすいポイント

• 「自己署名証明書だから危険」とだけ考え、パス検証の可否という本質を見落とす。
• CN不一致の検証とルート証明書検証を混同し、両者が独立したチェックであることを忘れる。
• “登録しない”理由を「盗聴を防ぐため」と誤解し、試験目的（検証可否の確認）を答え損ねる。

FAQ

解答の論理構成

1. 【問題文】表5の整理番号A2には「管理者アカウントのなりすまし」を防ぐ対策として、 「④第三者による不正アクセスを防止するため、利用者認証に加えて、アクセス元の端末を制限しており」と記載されています。
2. ここで求められているのは「アクセス元の端末を制限する具体的方法」です。
3. 管理者だけが所持する端末であることを通信レイヤで証明する最も代表的な手段が、TLSハンドシェイク時に端末固有の証明書を提示させるクライアント証明書方式です。
4. クライアント証明書方式は
   ・サーバが信頼する認証局で署名された証明書を端末に格納
   ・TLS接続時にサーバが証明書を検証
   という流れで、第三者端末からの接続を排除できます。
5. 以上より、Zシステムに適した端末制限方法は「クライアント証明書を用いた端末認証」となります。

誤りやすいポイント

• IPアドレス制限だけではモバイル回線や在宅勤務時に対応できず、なりすましも防ぎ切れません。
• SSH鍵やVPNと答えると「利用者認証に加えて端末を識別する」要件を完全には満たさない点があります。
• 端末管理ソフト（MDM）導入は有効ですが、問題文が求める「通信時に端末を認証する仕組み」への言及にならない場合があります。

FAQ

解答の論理構成

1. 対象となる事象の確認
   会話文には

   「ZクラウドのWebサーバ上にあるコンテンツの予期せぬ変更の原因としては、表5の整理番号fの脅威が考えられます。」
   とあります。したがって、“Webサーバ上のコンテンツを誰が・どのように書き換えられるか”を軸に整理番号を抽出します。

2. 変更を実行できる主体の抽出
   Webサーバのコンテンツは管理者権限が無ければ書き換えられません。表5の脅威のうち、 ・「利用者アカウントのなりすまし」（A1）は利用者権限であり、通常はコンテンツ更新権限を持ちません。
   ・「DDoS 攻撃」（B1）は可用性を狙う攻撃であり、改ざんとは無関係です。
   したがって A1 と B1 は除外します。
3. 管理者権限またはシステム権限を奪取・誤用する脅威の特定
   表5から該当する脅威は次の四つです。

   整理番号	該当理由（原文引用付き）
   A2	「管理者アカウントのなりすまし」―管理者が不正に乗っ取られればコンテンツ変更が可能。
   C2	「OS やミドルウェアなどのシステム基盤の脆弱性を突いた攻撃」―Webサーバをホストする基盤が破られれば改ざん可能。
   D1	「業務委託先を含めた従業員・役員（以下、内部者という）による犯行」―権限を持つ内部者が故意に改ざんするケース。
   D2	「内部者の過失」―運用ミスにより意図せず内容が書き換わるケース。

4. C1 を除外する理由
   C1 には

   「Web アプリケーションサーバ上のアプリケーションプログラムの脆弱性を突いた攻撃」
   とありますが、これは “アプリケーションプログラム” 自体を標的にしたものです。Webサーバ上の静的コンテンツ変更とは直接結び付かないことから f には含めません。

5. 結論
   以上より、f には「A2, C2, D1, D2」を並記します。

誤りやすいポイント

• C1 を含めてしまう
  “脆弱性を突いた攻撃” という言葉に引きずられ Web サーバ改ざんも連想しやすいですが、対象はアプリケーションプログラムであり静的コンテンツではありません。
• A1 を選んでしまう
  利用者アカウントでは Web サーバのファイル配置に直接アクセスできない点を見落としがちです。
• B1 を選んでしまう
  DDoS は可用性の阻害であって整合性（改ざん）には直結しません。
• “内部者” を忘れる
  内部者による故意・過失（D1, D2）は技術的対策だけでは検出しにくいため見落としやすい項目です。

FAQ

解答の論理構成

1. 【問題文】では、不正ログイン対策の議論中に
   「⑤リバースブルートフォース攻撃やリスト型攻撃は、ログイン制限では防ぐのが難しい」
   とあり、リバースブルートフォース攻撃がブルートフォース攻撃とは異なる手法であることが示されています。
2. 同じ会話で E 君が提案した追加認証策に対し、B 主任は
   「⑦Zクラウドと各利用者だけが知っていて、利用者以外が入手するのが困難な情報で追加認証すれば」
   と述べ、攻撃の本質が“共通のパスワードを多数の ID へ試す”点にあることを示唆しています。
3. 以上より、リバースブルートフォース攻撃とは「複数の利用者 ID に対して、よく使われる（または推測しやすい）単一のパスワードを次々に試すことで、不正ログインを狙う攻撃」と整理できます。
4. これを 40 字以内で端的に表現した模範解答は
   「利用者IDを変更しながら、よく用いられるパスワードでログインを試行する」
   となります。

誤りやすいポイント

• ブルートフォース攻撃と混同し、｢1つの ID に多数のパスワードを試す｣と説明してしまう。
• リスト型攻撃と同義だと勘違いし、｢ID とパスワードの組を順番に試す｣と書いてしまう。
• ｢複数の端末を使う｣など、手法の本質でない要素を盛り込んでしまう。
• ｢総当たりである｣だけを述べ、ID を変更していく点を明記しない。

FAQ

解答の論理構成

1. 【問題文】ではログイン制限について
   「認証に失敗するごとに、その利用者IDでログインできない期間を5秒間から最大24時間まで指数関数的に長くしていき」と説明されています。
2. この仕組みは「その利用者ID」で失敗した回数を基準にロック時間を決定します。
3. 一方、リバースブルートフォース攻撃・リスト型攻撃は
   ・攻撃者が多数の利用者IDに対して
   ・各IDへは1回またはごく少数しか試行しない
   という特徴があります。
4. したがって、各利用者IDで失敗回数が増えず、上記のログイン制限が発動しません。
5. 以上より「一つの利用者IDあたりの試行回数が少ないため、ログイン制限が有効に働かないこと」が理由となります。

誤りやすいポイント

• ログイン制限は「アカウント単位」であり「IPアドレス単位」ではない点を見落としがちです。
• ロック時間が指数関数的に延びる仕組みを「試行回数そのものの制限」と誤解しやすいです。
• ブルートフォース攻撃とリスト型攻撃の違い（同一IDに多数試行か、多数IDに単発試行か）を混同しやすいです。

FAQ

解答の論理構成

1. 問題文はリスト型攻撃を次のように説明しています。
   引用：「ほかのWebサイトから漏えいした利用者IDとパスワードのリストを悪用した、いわゆるリスト型攻撃が増えているそうです。」
   リスト型攻撃の本質は “漏えい済み情報の再利用” です。
2. E君は追加認証として「電話番号や電子メールアドレス」を提案しました。
   引用：「利用者IDとパスワードに加えて、ほかの利用者情報、例えば電話番号や電子メールアドレスも使って認証するように変更すれば、防げるのではないでしょうか。」
3. しかしB主任は下線⑥で次のように指摘しています。
   引用：「リスト型攻撃については、防げない場合があります」
4. その理由は、攻撃者が参照する漏えいリストの項目に「電話番号や電子メールアドレス」が含まれていれば、追加認証も突破されるからです。
   したがって、解答は「ほかのWebサイトから漏えいした情報に電話番号や電子メールアドレスが含まれていた場合」となります。

誤りやすいポイント

• 「追加で質問項目を増やせば万能」と思い込み、漏えい範囲まで考慮しない。
• リスト型攻撃とブルートフォース攻撃を混同し、対策を誤る。
• 電子メールアドレスを“秘密情報”と誤認し、公開性の高さを見落とす。

FAQ

解答の論理構成

1. 追加認証で満たすべき要件
   本文中の下線⑦では、 ― “Zクラウドと各利用者だけが知っていて、利用者以外が入手するのが困難な情報で追加認証すれば”
   と明示されています。すなわち①Zクラウド側に登録済み、②利用者本人しか把握できず、③第三者が取得しにくい情報が必要です。
2. 候補情報の洗い出し
   ユーザ関連情報の中で上記①～③を同時に満たすものを本文から探します。利用者登録時の記述に、 ― “登録時には自動的に10進数12桁の利用者番号が付与される。利用者番号は、Web IFの利用者登録完了画面上に表示される。また、利用者登録完了通知書に記載され、登録した住所に郵送される。”
   との記載があります。
3. 利用者番号が最適な理由
   ・Web画面に一度表示されるだけで、以後は郵送された書面にしか書かれていません。
   ・Zカメラのシリアル番号や初期設定用パスコードと異なり、本体を譲渡・転売しても新所有者には引き継がれません。
   ・郵送という物理経路により、攻撃者がオンラインで大量取得することは困難です。
4. 追加認証手段の決定
   以上より、追加認証では “利用者番号” を入力させる方法が要件を満たし、リスト型攻撃やリバースブルートフォース攻撃に対する有効な追加要素になります。
5. 実際の解答
   「利用者番号の入力を求める。」

誤りやすいポイント

• シリアル番号や初期設定用パスコードを選ぶ
  → 本体に印字・同梱されているため、譲渡先にも知られてしまい要件②③を満たさない。
• 電子メールアドレスや電話番号を追加要素にする
  → ソーシャルエンジニアリングや公開情報から取得しやすく、“利用者以外が入手するのが困難” とは言えない。
• 「カメラ登録台数」や「UUID」など端末依存情報を使う
  → 端末買替え・複数端末利用時に正当利用者がロックアウトされるおそれがある。

FAQ

解答の論理構成

• 【問題文】には、平常時のログイン頻度として「平均すると利用者1人当たり、年1回程度」とあります。したがって通常は認証失敗も極めて少ない状態です。
• 一方、攻撃時は「リバースブルートフォース攻撃やリスト型攻撃は、ログイン制限では防ぐのが難しい」【⑤】と指摘されており、この種の攻撃では多量のIDに対して短時間にログイン試行が繰返されます。
• 【⑧】では「平常時と異なる状況が発生していると判断される場合」に追加認証を行うとしています。平常時との違いを可視化する最も分かりやすい指標が“認証失敗の急増”です。
• したがって、システム全体で「単位時間当たりの認証失敗数」を監視し、想定したしきい値を超えたときに平常時と異なる状況と判断し追加認証を発動する設計が適切となります。

誤りやすいポイント

• 「利用者IDごとの失敗回数」だけを監視すると、攻撃者がIDを変えながら試行するリバースブルートフォース攻撃を見逃します。
• 認証成功が早期に得られる場合でも攻撃が継続中かどうかを見落としやすい点に注意が必要です。
• 平均ログイン頻度（年1回程度）を無視してしきい値を高く設定し過ぎると、実際の攻撃を検知できません。

FAQ

解答の論理構成

1. まず設問は、契約書に追加すべき「必要な条項」を問うています。
2. 本文には、契約追加の目的が示されています。
   • 「表5の整理番号C1については、開発委託先との契約に⑨必要な条項を追加することにした上で、納品時にWebアプリケーションプログラムの脆弱性検査を実施することが決まった。」
3. ここから分かるゴールは、納品物が「脆弱性検査に合格していること」を発注側が保証させることです。
4. したがって、委託契約に盛り込むべき条項は「脆弱性検査に合格しなければ受け取らない（支払わない）」という受入条件であると導けます。
5. これを25字以内で具体化すると「脆弱性検査合格を要件とする。」が妥当です。

誤りやすいポイント

• 「検査を実施する」だけでは不十分です。実施しても“不合格のまま納品可”では意味がありません。
• 「定期的な脆弱性検査」などスケジュール面に着目して条項を挙げると、納品時合格という本質を外す恐れがあります。
• テスト種別（静的解析・動的解析など）に踏み込みすぎて条項が冗長になりがちです。設問は追加すべき“条項”であり、実施方法の詳細までは求めていません。

FAQ

解答の論理構成

1. 問題文では、運用統括部の現状として
   「V社が毎年、年度末にセキュリティ専門業者の脆弱性検査を受けている。」
   「重大な問題が指摘された場合、定期メンテナンス時に…修正プログラムを適用する。」
   と記載されており、対応タイミングが“年度末”“定期メンテナンス”に限定されています。
2. しかし D社からは
   「⑩構成管理を導入した脆弱性対応の仕組みを構築する必要がある」
   という指摘がありました。ここでいう構成管理は、システムに導入済みの OS・ミドルウェア・パッケージのバージョンを常時把握し、公開された脆弱性情報と即時に照合できる状態を指します。
3. 構成管理がない場合、公開された新たな脆弱性が自システムに影響するかどうかを確認するためには、都度、人手で各サーバの状態を調査するか、脆弱性診断の実施を待たなければなりません。
4. その結果、影響有無の判定に時間を要し、攻撃までの“隙”が生じます。
5. 以上より、構成管理を導入していない問題点は
   「脆弱性がZ社のシステムに影響するかを短時間で判断できない。」
   となります。

誤りやすいポイント

• 「検査頻度が低い」だけを書くと、脆弱性の影響判定という核心が抜けるため減点対象です。
• 「対応が遅れる」とだけ述べると抽象的で理由が不明瞭になりがちです。
• 構成管理＝資産管理と誤解し、在庫把握の欠如を書くと論点ずれになります。

FAQ

解答の論理構成

1. 内部者（特に管理者）に動画を見られないようにするには、クラウドに到達する前に暗号化する必要があります。
   本文には「動画は、暗号化されずに保管される。」とあり、暗号化場所をZクラウドより前に置くべきと分かります。
2. 暗号化は撮影機器側で行うのが最も自然です。Zカメラは「撮影した動画はZクラウドに送信され、大容量ストレージに保管される。」とあるため、送信前に暗号化を担当します。
3. 共通鍵の生成・復号は利用者が操作できる要素に集約すると安全で利便性も高いです。Zアプリは「Zアプリは、モバイル端末にインストールされる」とあり、利用者操作の中心です。生成した鍵を保持し、動画閲覧時の復号にも使えます。
4. 鍵をZカメラに安全に渡す経路として、本システムには管理者が関与しない「Zアプリは、BluetoothのシリアルポートプロファイルでZカメラに接続し、Zカメラの無線LAN接続の設定を行う。」という既存チャネルが存在します。Bluetoothは近接通信で盗聴リスクが低く、既にペアリングを前提としているため鍵共有に適切です。

誤りやすいポイント

• 共通鍵をZクラウドで生成すると内部者から守れません。
• 動画暗号化をZアプリ側で行うと、送信中の帯域と端末性能に負荷が集中しやすく、カメラ単体動作が阻害されます。
• 鍵共有にインターネット経由のHTTPSを選ぶと、クラウド側で鍵を扱うことになり目的と矛盾します。

FAQ