平成30年度 秋期 午後Ⅱ（旧試験）

本文の根拠

本文 冒頭

日本，米国，欧州に事業を展開している従業員数 80,000 名の製造会社

本文 下線①

各国及び各地域の個人情報保護に関する法規制

2018 年 5 月 25 日に適用が開始された欧州連合の規則は，GDPR（General Data Protection Regulation，一般データ保護規則）である。EU 域内の個人データの取扱いと域外への移転を定める規則で，正式には Regulation (EU) 2016/679 という。

X 社は欧州にも事業を展開しており，基本要件の一つに“各国及び各地域の個人情報保護に関する法規制”への準拠が挙がっている。欧州に事業所や従業員がある以上，この法規制には EU の個人情報保護の規則が含まれる。

英字 4 字の指定なので，略称の GDPR だけを書く。日本の個人情報保護法のような国内法の名前や，正式名称の和訳を書かないこと。解答例は 4 字である。

採点講評（IPA）

設問1は，正答率が低かった。欧州だけでなく，日本における個人情報保護にも影響を与える規則であるので，知識として知っておいてほしい。

本文の根拠

本文 基本要件の具体的内容

R&D 情報は，物理的な入退室管理が行われているプロジェクトルーム内に配置されたプロジェクト専用サーバに保管する。

〔クラウド環境への移行に関する検討〕 条件 2

条件 2 プロジェクト専用サーバ

基本要件のうちプロジェクト専用サーバに直接関わるのは，“R&D 情報を，入退室管理が行われているプロジェクトルーム内のプロジェクト専用サーバに保管する”という保管場所の要件である。IaaS C に移行すると，サーバは H 社のデータセンタ内の仮想マシンになり，X 社のプロジェクトルームの外に置かれる。そのため，プロジェクトルームの物理的な入退室管理の下に置く，という要件が満たせなくなる。

本文の基本要件には“プロジェクト専用サーバには，プロジェクトルーム内のプロジェクト専用 PC からだけアクセスさせる”という要件もあるが，これは通信経路の制限で，クラウドに移しても FW などで実現しうる。移行によって満たせなくなる点として問われているのは，サーバを置く場所に関する要件の方である。

解答例は基本要件の文をほぼそのまま用いて 56 字で，60 字以内に収まる。要件の文を自分の言葉で言い換えると，“物理的な入退室管理”や“プロジェクトルーム内”の語が抜けやすいので，原文の語を残す。

本文の根拠

本文 基本要件の具体的内容

生産関連サーバは，X 社の工場及びデータセンタに配置する。

本文 基本要件の具体的内容

生産関連サーバは，重要インフラ設備の製造の事業継続のために，バックアップを他の工場又はデータセンタに配置する。

本文 基本要件の具体的内容

同じ重要インフラ設備を製造する工場及び生産関連サーバは同一の国又は地域内の 2 か所以上に配置する。

本文 IaaS C のサービス仕様

日本国内のデータセンタが被災した場合はシンガポールのデータセンタでサービスが継続される。

基本要件のうち生産関連サーバを取り上げた箇条は三つある。(a) X 社の工場及びデータセンタに配置する，(b) バックアップを他の工場又はデータセンタに配置する，(c) 同じ重要インフラ設備を製造する工場及び生産関連サーバは同一の国又は地域内の 2 か所以上に配置する。生産関連サーバを IaaS C に移行すると，(a) の配置先は X 社の工場やデータセンタではなく H 社のデータセンタになり，(b) のバックアップの置き場所も X 社の工場・データセンタでなくなる。解答例は三つとも，この三つの箇条をほぼそのまま挙げており。三つの異なる箇条を答える設問なので，書く順序は問わない。

サービス仕様の側で理由になるのは，“日本国内のデータセンタが被災した場合はシンガポールのデータセンタでサービスが継続される”という内容である。IaaS C の日本国内のデータセンタは 1 か所だけで，その被災時に生産関連サーバが動くのは国外のシンガポールである。このため (c)“同一の国又は地域内の 2 か所以上”の要件が満たせなくなる（国内の拠点が 1 か所，もう一つが国外）。

要件ごとの字数は 50 字以内で，解答例は 28 字，33 字，48 字である。サービス仕様の内容は 44 字（50 字以内）で，“被災したらシンガポールで継続”という条件と結果の両方を書く。講評でも，要件や仕様を言葉で正確に表現できていない解答が多かったと指摘されている。

採点講評（IPA）

設問2(2)は，正答率は高かったが，要件や仕様を言葉で正確に表現できていない解答が多く見受けられた。文書において，要件や仕様を言葉で正確に表現する能力を身につけてほしい。

本文の根拠

本文 基本要件の具体的内容

X 社のシステムの機器には，プライベート IP アドレスを割り当てる。

本文 IaaS C のサービス仕様

あらかじめ予約されているプライベート IP アドレスがあり，利用者はそれらを使うことができない。

〔クラウド環境への移行に関する検討〕

FW の NAT 機能を用いて一部のアドレスを変換することにした。

X 社のシステムの機器にはプライベート IP アドレスを割り当てる，と基本要件で決まっている。一方，IaaS C にはあらかじめ予約されているプライベート IP アドレスがあり，利用者はそれらを使えない。X 社の機器が，その予約されたアドレスと同じアドレスを既に使っていると，IaaS C 側に同じアドレスの機器が現れたり，X 社の機器と IaaS C の予約アドレスが区別できなくなったりして，通信できない。

この衝突を避けるために，FW の NAT 機能で一部のアドレスを別のアドレスに変換する。問われているのは“IaaS C のサービス仕様の制約から起こる問題”なので，X 社社内のアドレスの付け方の問題ではなく，IaaS C の予約アドレスとの重複を書く。

解答例は 65 字（70 字以内）で，“割り当てているアドレス”“IaaS C で予約されているプライベートアドレス”“重複する可能性”の三点を含む。“アドレス不足”のような別の理由を書かないこと。

本文の根拠

〔ID 管理及び利用者認証の検討〕

認証サーバ B1 をバージョンアップし，新バージョンで提供された SPNEGO プロトコルによって，認証サーバ B1 が認証サーバ A1 と通信し，認証サーバ A1 が発行するトークンを用いて利用者認証を行うようにする。

〔ID 管理及び利用者認証の検討〕

SaaS Q 及び SaaS S は，認証サーバ B1 と SAML 2.0 プロトコルで通信し，認証サーバ B1 が発行するトークンを用いて利用者認証を行う。

SPNEGO（RFC 4178，GSS-API の認証方式を交渉するための仕組み）と SAML 2.0（認証結果などを XML で受け渡す OASIS の仕様）で認証サーバどうしや SaaS が連携すると，ある認証サーバが利用者を認証して発行したトークンを，ほかのシステムが受け取って認証済みとして扱える。したがって従業員は，各システムで別々にログオンしなくても，一度のログインで全システムを利用できる。いわゆるシングルサインオン（SSO）の利便性である。

本文では，認証サーバ A1 が発行するトークンを B1 が用い，B1 が発行するトークンを SaaS Q，SaaS S が用いる，という連鎖になっており，オンプレミスの Windows 用，Linux 及び商用 UNIX 用，クラウドの SaaS がつながる。

30 字以内なので，“一度のログインで”“全システムにアクセスできる”の二点を書く。解答例は 27 字である。“パスワードを覚えなくてよい”のような別の利点の書き方にそれてしまうと，認証連携の効果が答えになっていない。

本文の根拠

図1 凡例

Linux 及び商用 UNIX 上で稼働する Web アプリケーションにアクセスする際の利用者認証に用いるリバースプロキシ型の認証サーバ

〔ID 管理及び利用者認証の検討〕 案 2

案 2 認証サーバ B1 を IaaS C に移行する。

図2 記号の説明

㋗は IPS，㋘は FW1 を指す矢印の記号である

認証サーバ B1 は，Linux 及び商用 UNIX の業務サーバにアクセスするときの利用者認証に使う，リバースプロキシ型の認証サーバである。リバースプロキシ型なので，認証後の通信も B1 を経由する。案 1 では B1 がオンプレミスの東日本データセンタにあり，社内 PC から同じデータセンタの Linux（㋑）・商用 UNIX（㋒）の業務サーバへの通信は，B1 を含めて内部で完結する。案 2 で B1 を IaaS C に移すと，この通信は，IPS（㋗），FW1（㋘），インターネット（㋙），FW2（㋚）を通って IaaS C の B1 に行き，再び戻ってくる。業務サーバは㋑，㋒，負荷が高くなる構成要素は㋗，㋘，㋙，㋚である。

Windows の業務サーバ（㋐）は認証サーバ A1 を使うので，B1 の移行の影響を受けない。IaaS C の Linux 業務サーバ（㋔）は，B1 が IaaS C 内に移る案 2 の方が認証の経路が短くなり，Windows の㋓は A2 を使うので，どちらも負荷が高くなる側ではない。

間違えやすい点：負荷が上がるのは社内 PC から“B1 を使う業務サーバ”への通信に限る。㋐（Windows）は A1 を使うので含めない。

本文の根拠

〔エンドポイント管理の検討〕 下線②

フレームワークインプリメンテーションティア（以下，ティアという）1 からティア 4 までの段階を定義しており，ティア 4 が最も高い段階である。

NIST Cybersecurity Framework（バージョン 1.1）のフレームワークインプリメンテーションティアは，次の 4 段階である。ティア 1 は Partial（部分的である：リスク管理が定型化されておらず，場当たり的），ティア 2 は Risk Informed（リスク情報を活用している：リスク管理策が経営層に承認されているが組織全体の方針にはなっていない），ティア 3 は Repeatable（繰返し適用可能である：正式な方針として定められ，定期的に見直される），ティア 4 は Adaptive（適応的である）。したがってティア 1＝イ，ティア 2＝ウ，ティア 3＝ア。

本文は“ティア 4 が最も高い段階である”と書いているので，解答群に無い Adaptive（適応的）がティア 4 に当たることも分かる。

間違えやすい点：Repeatable（繰返し）が最上位に見えるが，繰返し適用できるのはティア 3 であり，ティア 2 の Risk Informed（リスク情報を活用）の方が下位。名前の字面で順番を決めず，Partial → Risk Informed → Repeatable → Adaptive の順で覚える。

本文の根拠

〔エンドポイント管理の検討〕

サーバ及び PC で使用するソフトウェア（以下，標準ソフトウェアという）の一覧を運用サービス契約時に取り決めた上で，次の運用サービスを提供できるという回答があった。

〔エンドポイント管理の検討〕 運用サービス 1

運用サービス 1 標準ソフトウェアに関する脆弱性情報を日次で収集する。

J 社の運用サービスは，契約時に取り決めた標準ソフトウェアの一覧を対象にしている。運用サービス 1 は“標準ソフトウェアに関する”脆弱性情報を収集し，運用サービス 2 の製品 D は，その情報を用いて“標準ソフトウェア”のパッチ適用状況とセキュリティ設定を監視する。標準ソフトウェア以外のソフトウェアが導入されていると，その脆弱性情報は集められず，パッチ適用状況も監視されない。つまり，そのソフトウェアは脆弱性管理の対象外になる。

改定 3“脆弱性管理の実施”が求めるのは，使用しているソフトウェアの脆弱性情報が公開されたら重要度を評価して期限内にパッチを適用することだが，標準外のものはその仕組みに乗らず，X 社の標準に沿った管理にならない。

40 字以内なので，“標準ソフトウェア以外のソフトウェア”と“脆弱性管理がされない”をそろえる。解答例は 35 字である。講評でも，不都合の内容を言葉で正確に表現できていない解答が多かった（正答率は低かった）とされているので，“管理しきれない”などの曖昧な書き方にせず，何の管理が行われないのかを書く。

採点講評（IPA）

設問4(2)は，正答率が低かった。この設問においても，不都合の内容を言葉で正確に表現できていない解答が多く見受けられた。文書において，言葉で正確に表現する能力を身につけてほしい。

本文の根拠

製品 D の仕様

同様に，セキュリティ設定パラメタの設定値が指定した値と異なるサーバ及び PC の一覧を表示することができる。

製品 D の仕様

1 回の操作で，選択したサーバ又は PC のセキュリティ設定パラメタの設定値を指定した値に変更することができる。

製品 D のエージェントがサーバ・PC の設定値を自動で収集し，管理画面が指定値と異なるものを一覧表示する。手作業と目視によるチェックと比べると，(1) 機械が収集・比較するので，見落としや読み違いが少なく，結果が正確になる，(2) 1 回の操作で一覧から選んだ台数分の設定値を指定値に変更できるので，多数の機器でも作業が速く終わる，の二つの利点がある。解答例は“正確である。”（6 字）と“作業が速くできる。”（9 字）である。

製品 D の仕様には“日次で監視する”こともあるが，この設問は“チェックする方法”の比較なので，確認と変更を 1 回の操作で行える点と，機械による一覧表示の点を，それぞれ 15 字以内で書く。

コスト削減や“セキュリティ設定が強制できる”などは，本文の製品 D の仕様からは読み取れない（強制は製品 F の対策 1 の説明にある語である）。15 字以内なので，名詞か短い文で言い切る。

採点講評（IPA）

設問4(3)は，正答率が低かった。運用管理ツールの効果を正しく理解し，ツールを有効に活用する能力を身につけてほしい。

本文の根拠

〔モバイル環境の検討〕 案 C

新たに IaaS C に認証サーバ B1 と同じ製品を用いた認証サーバ B2 を配置し，従業員が IaaS C に配置された Linux の業務サーバ上で稼働する Web アプリケーションにアクセスする際の利用者認証に用いる。

〔モバイル環境の検討〕 対策 2

モバイル端末が，X 社のデータセンタに接続した後，認証サーバ B1 による利用者認証が行われ，トークンが発行される。

図3 記号の説明

インターネットには SaaS Q（Ⓔ），SaaS S（Ⓕ），スマートフォン（Ⓗ），モバイル PC（Ⓘ）も接続されている。

案 C は，IaaS C の Linux 業務サーバ（Ⓓ）の利用者認証を IaaS C 内の B2 で行い，オンプレミスの Linux 業務サーバ（Ⓑ）の認証は従来どおり B1（オンプレミス）で行う構成で，どちらも認証を行う場所と業務サーバが同じ側にある。

案 A は B1 だけがオンプレミスにあるので，IaaS C の Linux 業務サーバ（Ⓓ）にアクセスするとき，利用者認証もその後の通信（B1 はリバースプロキシ型）もオンプレミスの B1 を経由する。社内 PC（Ⓖ）からのアクセスは，案 C でもオンプレミス→ IaaS C の経路を通るので増えず，増えるのは，案 C ならインターネットから IaaS C に直接入れるスマートフォン（Ⓗ）とモバイル PC（Ⓘ）からの通信で，対策 2 によりいったん X 社のデータセンタで認証を受けてから IaaS C に行くことになる。したがって案 A は（Ⓗ，Ⓓ），（Ⓘ，Ⓓ）の 2 組。

案 B は B1 が IaaS C にあるので，オンプレミスの Linux 業務サーバ（Ⓑ）への通信は，Ⓖ，Ⓗ，Ⓘのどれからも IaaS C の B1 を経由することになり，案 C より経路が長くなる。（Ⓖ，Ⓑ），（Ⓗ，Ⓑ），（Ⓘ，Ⓑ）の 3 組。

間違えやすい点：Windows の業務サーバ（Ⓐ，Ⓒ）は認証サーバ A1・A2 を使うので B1 の配置に影響されない。クライアントと業務サーバの順（クライアント，業務サーバ）を入れ替えない。

本文の根拠

図4 シーケンス

スマートフォンから SaaS Q へのアクセス要求（トークンなし），空欄 a，スマートフォン内の処理「認証サーバ B1 へのアクセスに必要な VPN クライアントの起動」，空欄 b，空欄 c，空欄 d，VPN サーバ内の処理「クライアント証明書の検証」

〔モバイル環境の検討〕 対策 2

VPN サーバでクライアント証明書を用いた端末認証が行われる。

図4 シーケンス

認証サーバ B1 から認証サーバ A1 への利用者 ID，パスワードの検証要求

a：トークンなしでアクセスしたスマートフォンに，SaaS Q が“認証サーバ B1 が発行したトークン要求”（カ）を返す。これを受けて，B1 に届くための VPN クライアントが起動する。b〜d：VPN サーバへの接続要求（ウ，b），VPN サーバからのクライアント証明書の要求（イ，c），スマートフォンからのクライアント証明書の送付（ア，d）の順で端末認証が進み，VPN サーバが証明書を検証して接続 OK（IP アドレスを割り当て）を返す。e〜g：VPN の接続後に，スマートフォンが B1 にトークン発行要求（オ，e）を出し，B1 が利用者 ID 及びパスワードの入力要求（ク，f）を返し，利用者が入力した利用者 ID，パスワード（キ，g）を B1 に送る。B1 はそれを認証サーバ A1 に検証させ，パッチ適用状況の確認を行った後，h：B1 がトークンを発行（エ，h）し，スマートフォンはそのトークンを付けて SaaS Q にアクセスする。

本文は VPN サーバで端末認証，B1 で利用者認証と書いているので，端末認証（b〜d）が先で，利用者認証（e〜g）が後になる。

間違えやすい点：イ（要求）とア（送付）は矢印の向きが逆，ク（入力要求）とキ（入力）も向きが逆である。エ（トークンの発行）は最後にスマートフォンへ返すもので，オ（要求）が先。

本文の根拠

図4 2

インシデント対応チームが提供するサービスの例として，NIST SP 800-61 Rev. 2 は，a，脆弱性や脅威についてのアドバイザリの配信，b，及び社内外での情報共有の推進を挙げている。

NIST SP 800-61 Rev. 2 の 2.5 節（Incident Response Team Services）は，インシデント対応チームが提供しうるサービスの例として，Intrusion Detection（侵入検知），Advisory Distribution（脆弱性や脅威についてのアドバイザリの配信），Education and Awareness（教育と意識向上），Information Sharing（情報共有）の四つを挙げている。図 4 は，このうち 2 番目と 4 番目を文章で書いているので，a と b には残りの“侵入検知”（エ）と“教育と意識向上”（イ）が入る。

解答群のほかの語は，この節に挙がっていない。ISO/IEC 15408 の PP の作成（ア），情報セキュリティポリシの管理（ウ），内部統制基準の作成（オ），ネットワーク機器の保守（カ）は，インシデント対応チームが提供するサービスの例として挙げられているものではない。

間違えやすい点：解答例の備考は a，b を順不同としているが，a にイ，b にエと入れ替えて答えてもよいという意味で，エとイを両方答える必要がある。

本文の根拠

図5

・cの責任表明。

図5

・dと関連用語の定義。

図5

・dについてのe又は深刻度評価。

NIST SP 800-61 Rev. 2 の 2.3.1 節（Policy Elements）は，インシデント対応ポリシに含める主な要素として，Statement of management commitment（マネジメント層の責任表明），Purpose and objectives of the policy（目的と目標），Scope of the policy（適用範囲），Definition of computer security incidents and related terms（インシデントと関連用語の定義），組織構造と役割・責任・権限レベルの定義，Prioritization or severity ratings of incidents（インシデントの優先順位付け又は深刻度評価），Performance measures（パフォーマンス測定），Reporting and contact forms（報告と連絡の様式）を挙げている。図 5 の項目と順に対応するので，c＝ケ（マネジメント層），d＝ウ（インシデント），e＝コ（優先順位付け）となる。

図 5 の d は 2 か所とも同じ語が入るので，“インシデントと関連用語の定義”と“インシデントについての優先順位付け又は深刻度評価”のどちらの文も通る語を選ぶ。

誤りの選択肢：ア CVSS v3 基本値（脆弱性の評価指標），イ SIEM（ログの集約・相関分析の仕組み），オ 個人情報，カ 情報公開，キ 情報システム部門，ク ポリシ，サ ログと証跡は，図 5 のこれらの位置にある語としては，いずれも項目の意味が通らない。

本文の根拠

〔インシデント対応能力の向上への取組み〕

ログ管理ポリシでは図 3 中の(6) d に挙げられたログに関わる課題を解決できるように，次の要件を定める。

図3 (6) d

d. ログが少なく調査が難航した。開発部はログ取得を定めた規程をもたず，開発部が管理する機器のうちログを取得していたものは少数だった。また，取得していたログの種類や保存期間にはばらつきがあった。

ログ管理ポリシの要件は，図 3 (6) d の課題を解決するためのものである。課題 d は三つに分けられる。ログを取得していた機器が少数だった（要件 1 の f＝ログを取得する機器），取得していたログの種類にばらつきがあった（要件 1 の g＝取得するログの種類），保存期間にばらつきがあった（要件 2 の h＝保存期間）。要件 1 が“取得するログ”，要件 2 が“取得したログ”についてなので，種類は取得する側（g），期間は取得したログの扱い（h）になる。

要件 2 には，h のほかに“バックアップの作成”“アクセス制御”が並んでおり，保存したログを守る要件が並ぶ中に“保存期間”が入るのは自然である。

解答例の備考は f，g，h を順不同とする。12 字以内なので，9 字，9 字，4 字の解答例のように，名詞で簡潔に書く。“ログの保管場所”のような，課題 d に無い語を書かない。

本文の根拠

〔インシデント対応能力の向上への取組み〕 要件 3

要件 3 各機器の時計を同期するとともに，各機器が出力するログに記録する時刻情報の i を j するという要件

図6 ログの行

[04/Sep/2018:14:23:34 +0900]

各機器の時計を同期するだけでは，ログの時刻が同じ基準で読めるとは限らない。機器ごとにログに記録される時刻のタイムゾーン（協定世界時からの差）が異なると，同じ時刻のように見える記録が実際には別の時刻になる。そこで，ログに記録する時刻情報のタイムゾーンを統一する（i＝タイムゾーン，j＝統一）。図 6 のプロキシサーバのログの時刻は“+0900”が付いた日本時間で，ほかの機器のログも同じ表記・基準にそろえていれば，後でログを突き合わせて経緯をたどれる。

講評でも，この設問の i は正答率が低かったと述べられている。ログ間でタイムゾーンが異なると，認識違いによって調査が難航する場合があり，各ログに記録された時刻が正しいこと，及び時刻のタイムゾーンが同じであることが重要だとされている。

8 字以内なので，i は 6 字の“タイムゾーン”，j は 2 字の“統一”。i に“形式”“時刻”のような語を書くと，ログに残る時刻情報そのものと区別できず，何を統一するのかが不正確になる。

採点講評（IPA）

設問2(2)iは，正答率が低かった。インシデント発覚時には，様々な機器が出力したログを見比べて，経緯などを調査する必要が生じる。各ログに記録された時刻が正しいこと，及び，時刻のタイムゾーンが同じであることが重要である。ログ間でタイムゾーンが異なると，認識違いによって，調査が難航する場合がある。

本文の根拠

〔インシデント対応能力の向上への取組み〕 下線①

管理する機器について，通常時のネットワークトラフィック量や日，週，月，年の中でのその推移などの情報（以下，通常時プロファイルという）の把握に努める

通常時プロファイルは，平常時のネットワークトラフィック量と，日・週・月・年の中での推移を記録した情報である。これを持っておけば，現在のトラフィック量と比較して，普段と違う急な増加や通常より外れた時間帯の通信を異常として検知できる。マルウェアが外部のサイトと頻繁に通信する（図 6 のような繰返しのアクセス）場合や，大量のデータを送り出す場合は，通常時との差としてあらわれる。

問われているのは“利用方法”なので，取得して終わりではなく，“通常時のトラフィック量と比較して異常を検知する”まで書く。

35 字以内で，解答例は 26 字である。“ログを保存する”“監視する”だけでは，通常時プロファイルをどう使うかが書けていない。

本文の根拠

〔マルウェアについての通知〕

サイト M のログに残っていたアクセス元の IP アドレスは A 社のプロキシサーバのものだった。

〔ネットワーク構成〕

業務 PC-LAN に接続された PC は，プロキシサーバを介してインターネットにアクセスできる。プロキシサーバは直近 60 日分のログを保存している。

サイト M のログに残っているアクセス元は A 社のプロキシサーバの IP アドレスで，どの PC かは分からない。業務 PC-LAN の PC のインターネット通信はプロキシサーバを経由し，そのログは直近 60 日分が残っている。9 月 4 日のアクセスは，通知のあった 10 月 10 日の約 36 日前なので，60 日分のログに含まれる。そこで，プロキシサーバのログから，アクセス先がサイト M の IP アドレスのエントリを抽出し，そのエントリに記録されている送信元の IP アドレスから，サイト M にアクセスした PC（PC-A）を特定した。

図 6 は，このように送信元 PC-A で絞り込んだログである（行 6 と 7 がサイト M の IPm へのアクセス）。

60 字以内で，解答例は 55 字。“プロキシサーバのログ”“サイト M へのアクセス先で抽出”“送信元の IP アドレス”の三点を書く。サイト M 側のログは使えない（アクセス元がプロキシサーバの IP アドレスになっている）ので，A 社側のログを用いる点が要である。

本文の根拠

〔マルウェアについての通知〕 下線③

PC-A が特定のサイトにアクセスし，その後頻繁に同じサイトにアクセスを繰り返す

表1 new3.exe

遠隔操作の機能をもつマルウェア K である。実行されると，IPn のサイトにアクセスして，そのレスポンスに従って動作する。

new3.exe（マルウェア K）は，遠隔操作の機能をもち，IPn のサイトにアクセスして，そのレスポンスに従って動作する。IPn のサイトは攻撃者が用意した C&C（コマンド & コントロール）サーバである。HTTP リクエストでは，マルウェアが C&C サーバへコマンドを要求し，又は，実行結果などを応答する。HTTP レスポンスでは，マルウェアが C&C サーバから攻撃者の指示（コマンド）を受信する。社内の PC からインターネットへの通信は，プロキシサーバを介した HTTP の形でしか出られないので，マルウェアは HTTP の要求を繰り返して指示を待つ形になる。

図 6 の 8 行目以降が，この繰返しのアクセスに当たる。

リクエストは 30 字以内，レスポンスは 20 字以内。解答例は 18 字と 15 字で，“要求又は応答”と“受信”の向きの違いを書き分ける。講評でも，この設問は正答率が低く，マルウェアが C&C サーバと通信して攻撃者の指示を受け取り，それに従って動作する，という動作を正しく理解しておくことが重要だとされている。

採点講評（IPA）

設問3(2)及び(3)は，正答率が低かった。社内に侵入した遠隔操作機能をもつマルウェアは，攻撃者が準備したC&Cサーバと通信して攻撃者の指示を受け取り，これに従って動作する場合が多い。この動作を正しく理解しておくことは，侵入の検知や被害の未然防止のために重要である。マルウェアが検知されたPCをネットワークから即座に切り離すことには長所と短所がある。これを正しく理解した上で，マルウェア検知時の初動活動を設計してほしい。

本文の根拠

〔マルウェアについての通知〕 下線④

PC-A をネットワークから切断して回収した

表1 new3.exe

実行されると，IPn のサイトにアクセスして，そのレスポンスに従って動作する。

PC-A をネットワークから切断すると，マルウェアと攻撃者との通信が止まり，被害の拡大を防げる。しかし調査の観点では，切断した時点で，PC のネットワークインタフェースや通信の状態（確立している接続など）についての情報が変化し，失われる。どのサイトとどの接続をしていたかを後から確かめにくくなる，という問題がある。

この問題を軽減するには，切断する前に，メモリダンプを取得する（解答例）。メモリには実行中のプロセスや通信状態に関する情報が残っているので，切断前に取得しておけば，後で解析できる。

40 字以内の問題は“通信の状態などの情報が失われる”こと。解答例は 36 字で，30 字以内の措置は 12 字の“メモリダンプを取得する。”。“感染が拡大する”のような，切断しない場合の問題を書くと，調査の観点という条件に合わない。

採点講評（IPA）

設問3(2)及び(3)は，正答率が低かった。社内に侵入した遠隔操作機能をもつマルウェアは，攻撃者が準備したC&Cサーバと通信して攻撃者の指示を受け取り，これに従って動作する場合が多い。この動作を正しく理解しておくことは，侵入の検知や被害の未然防止のために重要である。マルウェアが検知されたPCをネットワークから即座に切り離すことには長所と短所がある。これを正しく理解した上で，マルウェア検知時の初動活動を設計してほしい。

本文の根拠

〔マルウェアについての通知〕

マルウェア K がほかの機器にも感染している可能性を簡易的に確認した

表1 new3.exe

実行されると，IPn のサイトにアクセスして，そのレスポンスに従って動作する。

マルウェア K は，実行されると IPn のサイトにアクセスする。PC-A のほかにも同じマルウェアに感染した機器があれば，その機器も IPn のサイトにアクセスしているはずである。業務 PC-LAN の PC はプロキシサーバを経由してインターネットに出るので，プロキシサーバのログから，IPn のサイトにアクセスした機器がほかにないかを調べれば，ほかの感染機器の有無を簡易的に確認できる。

全機器のディスクを調べるより，プロキシサーバのログ 1 か所を検索する方が簡易である。

40 字以内で，解答例は 36 字。“どのログを”“何の通信先を”調べるのかをそろえる。サイト M へのアクセスではなく，IPn のサイト（マルウェア K 実行後の通信先）にする点が要である。

本文の根拠

図7 (2) PC-B について

last はログイン履歴を，lastb はログイン失敗の履歴を出力するコマンドである。

図8

d0325 pts/0 192.168.70.131 Wed Sep 5 10:41 - 10:43 (00:01)

図9

同 Wed Sep 5 10:40 - 10:40 (00:00)

図 7 によると，D さんの利用者 ID でのログイン試行は 9 月 5 日 10 時 35 分から 45 分までのものである。lastb（図 9）の失敗は，9 月 5 日の 10:35，10:36，10:36，10:37，10:37，10:37，10:40，10:43，10:44，10:44 の 10 件と，9 月 3 日 09:34 の 1 件がある。last（図 8）では，9 月 5 日の最初のログイン成功は 10:41 で，D さんがオフィスにいなかった 9 月 5 日の，攻撃者による最初の成功である。この前に記録されている失敗は 10:35，10:36，10:36，10:37，10:37，10:37，10:40 の 7 件である。

9 月 3 日 09:34 の失敗は，直後の 09:35 の成功（図 8 の最下行）と合わせると D さん本人の打ち間違いと考えられ，10:43 以降の 3 件は 10:41 の成功の後のものなので，数えない。

数え間違いやすい点：lastb の 11 行全部（11 回）や，10:41 以降を含めた 10 回を答えない。時刻が“最初の成功”より前かどうかで切り分ける。解答例は 7 回である。

本文の根拠

〔マルウェアについての通知〕

C さんは，D さんが利用している機器について，フォレンジックツールを用いて，ファイル A のファイルサイズと l をキーにしてファイルを検索した。

〔マルウェアについての通知〕

ファイル名は異なっていたものの，ファイル A と同じ内容のファイルが作成されていたことが分かった。

ファイル名が変えられていても，内容が同じなら同じ値になるものをキーにすれば検索できる。それがハッシュ値である。ファイルサイズだけで探すと，サイズが偶然一致した別のファイルが混ざるので，ファイルのハッシュ値を併せて照合し，同じ内容のファイルかどうかを確かめる。

本文は，ファイル名が同じとは限らない，削除されている可能性もある，と G 部長が述べて調査を続けさせた経緯を示している。名前，作成日時，場所のように変えられやすい属性をキーにしても見つからない。

8 字以内で，解答例は 5 字の“ハッシュ値”。“ファイルの内容”のような語では，ツールの検索キーとして書けていない。

本文の根拠

表1 new3.exe

指定されたファイルを，HTTP の POST メソッドを用いて IPn のサイトに送信する機能をもつ。

図6 (続き)

28: [08/Sep/2018:03:39:04 +0900] "POST http://IPn/admin/g.php HTTP/1.1" 200 35618

図6 注記2

要求元 PC に送信したレスポンスメッセージのサイズ

マルウェア K は，指定されたファイルを HTTP の POST で IPn のサイトに送信する機能をもつ。ファイル A と同じ内容のファイルが PC-A に作成された時刻は 9 月 8 日 3 時 35 分である。図 6 でこの時刻の後にあって IPn に POST しているのは，28 行目（9 月 8 日 03:39:04，POST http://IPn/admin/g.php）だけである。ほかの POST（9，10，21，26 行目）は，いずれもファイル作成より前の記録である。

ただし図 6 の“200 35618”の数値は，注記 2 のとおり，要求元 PC に送信したレスポンスメッセージのサイズで，PC-A から送信したデータのサイズではない。ファイルが実際に送られたかを判断するには，この行の時刻の前後で，プロキシサーバがインターネットに送信したデータのサイズが，ファイルのサイズと合うかを見る。

35 字以内で，解答例は 27 字。送信元の IP アドレスと図 6 に示された情報は対象外とあるので，図 6 のレスポンスのサイズ以外の，“プロキシサーバがインターネットに送信したデータのサイズ”を書く。行番号は“28行目”。

本文の根拠

図6 4 行目

4: [04/Sep/2018:14:31:15 +0900] "GET http://yyyy/dl/samplebun.zip HTTP/1.1" 200 89331

図6 8 行目

8: [04/Sep/2018:14:37:06 +0900] "GET http://IPn/news.php HTTP/1.1" 200 5429

図8

d0325 pts/0 192.168.70.131 Wed Sep 5 10:41 - 10:43 (00:01)

ア（No.1）は，D さんが PC-A の Web ブラウザで ZIP 形式のファイルをダウンロードした日時で，図 6 の 4 行目（samplebun.zip の GET，9/4 14:31:15）から 9/4 14:31。表 2 の他の行が分単位なので，分までを書く。イ（No.5）は，マルウェア K（o）が IPn のサイトと頻繁な通信を開始した日時である。図 6 の 6，7 行目は IPm（サイト M）への接続とダウンロード（No.3 の 14:35 に当たる），8 行目が最初の IPn へのアクセスで 9/4 14:37。ウ（No.7）は，攻撃者が PC-B へのログインに初成功した日時で，図 8（last）の 9 月 5 日の最初の成功 10:41 から 9/5 10:41。

図 7 によると，9 月 5 日の D さんはオフィスにいなかったので，この 10:41 のログインは攻撃者によるものである。

間違えやすい点：イにサイト M へのアクセス（14:34，14:35）を，ウに失敗の履歴の最初（9/5 10:35。これは No.6 の“ログインの試行を開始”）を書かない。解答例は 9/4 14:31，9/4 14:37，9/5 10:41。

本文の根拠

表1 ファイル W

ダウンローダの機能をもつマルウェア L である。サイト M からプログラムをダウンロードし，実行する。

〔マルウェアについての通知〕

ファイル名は異なっていたものの，ファイル A と同じ内容のファイルが作成されていたことが分かった。

会話

PC-A が攻撃者によって遠隔操作されたことは間違いないと思います。

表 2 を行ごとに読む。No.2 は D さんがファイル W（＝マルウェア L）を実行（m＝タ）。No.3 は，マルウェア L が，サイト M（n＝コ）にアクセスして new3.exe をダウンロードする（表 1 のとおり，ファイル W はサイト M からプログラムをダウンロードして実行する）。No.4 は，マルウェア L が，ダウンロードした new3.exe＝マルウェア K（o＝ソ）を実行する。No.5 は，マルウェア K が IPn のサイトとの通信を始め，攻撃者による遠隔操作（p＝ケ）が始まったと推測される（C さんが“PC-A が攻撃者によって遠隔操作された”と述べている）。

No.8 は，漏えいが疑われるファイルのコピーとファイル A（q＝シ）を，PC-B（r＝カ。図 7 のとおり PC-B の /tmp/20xx/ に置かれていた）のローカルディスクに作成する。No.9 は，ファイル A と同じ内容のファイルを PC-A（s＝オ）のローカルディスクに作成する（本文：9 月 8 日 3 時 35 分に PC-A で作成）。

誤りやすい点：サ“総当たり攻撃”は No.6 のログイン試行にあたり，p ではない。ス“フィッシング”，キ“SQL インジェクション”，ク“WHOIS サービス”は，表 2 の事象と対応する記述が本文にない。

本文の根拠

図3 (6)

b. インシデント対応についての作業手順が明確になっておらず，手探りの作業となった。このため，掲示板事業者への要請といった措置の着手が遅れた。

〔インシデント対応能力の向上への取組み〕

インシデント対応ポリシでは，A-CSIRT 及び各部の役割，責任及び権限レベルを規定した。

〔インシデント対応能力の向上への取組み〕

メンバのスキルを高めるため，定期的に勉強会を開催し，外部の研修などにも積極的に参加してもらう方針を立てた。

図 3 (6) の課題 a〜d に対する，本文の取組みを順に見る。a（各部の責任や役割が曖昧）は，インシデント対応ポリシで A-CSIRT 及び各部の役割，責任及び権限レベルを規定したので対応済み。c（経験・スキルをもつ者がいない）は，勉強会の開催と外部研修への参加の方針を立てたので対応済み。d（ログが少なく調査が難航）は，ログ管理ポリシの作成で対応済み。b（作業手順が明確になっていない）に対応する取組みは，本文に書かれていない。インシデント対応ポリシは基本的な方針であり，具体的な作業の手順を定めたものではない（図 4 の取り組む事項にも手順書の作成は挙がっていない）。したがって未対応の課題は b。

措置は，b を解決するための“インシデント対応の作業手順書を作成する。”（解答例，20 字）。25 字以内なので，“作業手順書の作成”を中心に書く。

間違えやすい点：課題 a の“役割”は，ポリシと A-CSIRT の編成で対応済みであり，措置に“役割の明確化”を書かないこと。インシデント対応ポリシの“策定”は作業手順書の作成の代わりにならない。