令和3年度 秋期 午後Ⅱ（旧試験）

本文の根拠

図4 診断用 URL1

description=<script>alert('XSS!')</script>

図3 (3)

図 5 から，description パラメタの値を画面 B の備考に出力する際には，エスケープ処理が正しく行われており，XSS 脆弱性は認められない。

図 4 の診断用 URL1 は，description に <script>alert('XSS!')</script> を入れて送るものである。出力時のエスケープ処理が正しければ，このスクリプトは文字として画面に表示されるだけで，実行されない。HTML では，タグの開始・終了を表す < と > を，文字参照の &lt;（less than）と &gt;（greater than）に置き換える処理がエスケープ処理に当たる。

図 5 では，備考の欄に“ascriptbalert('XSS!')a/scriptb”と出ている。<script> が ascriptb になっているので，a は < の文字参照 &lt;，b は > の文字参照 &gt; である。図 3 の(3)も，この箇所は“エスケープ処理が正しく行われており，XSS 脆弱性は認められない”としている。

字数は 4 字ずつなので，“&lt;”と“&gt;”をそのまま書く。< と > の対応（lt が小さい側の <）を取り違えて a と b を逆にしない点が間違えやすい。

本文の根拠

図3 (4)

診断用 URL2 を入力した時に表示された画面 B 上で，参考 URL のリンクをクリックすると，“XSS!”という内容のダイアログボックスが表示された。

図7 診断用 URL2 の HTTP レスポンス

参考 URL：<a href="c">c</a>

図 7 では，c が <a> タグの href 属性の値とリンクの文字列の両方に，そのまま出力されている。図 3 の(4)では，このリンクをクリックするとダイアログボックスが表示されたので，c は“リンクをクリックしたときにスクリプトが実行される URL”である。

それに当たるのは，javascript スキームの URL である javascript:alert('XSS!')（エ）である。ブラウザは javascript: で始まる URL をたどると，その後ろのスクリプトを実行する。しかも，図 9 の結果から，二重引用符（"）は &quot; にエスケープされている。つまり，属性値から抜け出す方法ではなく，URL の中身そのものを使う方法が必要で，エがそれに合う。

アは，イベントハンドラ属性の書き方で，href の値に入れても URL として扱われるだけであり，しかもマウスを重ねる操作（mouseover）がなければ動かない。イは，二重引用符で属性を閉じて <script> を差し込む方法だが，二重引用符がエスケープされるので属性の外に出られない。ウは，http: で始まる文字列なので URL として扱われ，クリックしてもスクリプトとしては実行されない。クリックだけで動き，しかも引用符のエスケープを受けないものを選ぶ点が間違えやすい。

本文の根拠

図3 (6)

XSS を防ぐための基本的な処理はしているが，HTML タグの属性値の出力時に必要な処理が行われていない。

図9 診断用 URL3 の HTTP レスポンス

参考 URL：<a href="&quot; onmouseover=alert('XSS!') foo=&quot;">

図 3 の(6)は，原因を“XSS を防ぐための処理を一切していない”か“基本的な処理はしているが，HTML タグの属性値の出力時に必要な処理が行われていない”かのどちらかとしている。図 9 では，診断用 URL3 に含めた二重引用符が &quot; に変わっている。つまり，基本的なエスケープ処理はされており，原因は後者である。

それでも図 7 のように javascript: で始まる値がリンクとして出力され，クリックでスクリプトが実行された。href 属性に入れる URL は，文字をエスケープしただけでは防げず，URL としての正しさを確かめる必要がある。そこで，参考 URL は http:// 又は https:// で始まるものだけをリンクとして出力するようにし，javascript: などそれ以外のスキームは出力しない。

45 字以内なので，“http://又は https://で始まる URL だけを出力する”という中身を残し，文末を“ようにする”で整える。

本文の根拠

〔D システムの脆弱性対策〕

Content-Security-Policy: script-src 'self';

〔D システムの脆弱性対策〕

指定したスクリプトファイルの実行だけを許可する

Content-Security-Policy は，Web ブラウザに，実行してよいスクリプトの読込み元を伝えるヘッダである。script-src の 'self' は，W3C の Content Security Policy Level 3 で“現在の URL のオリジンに一致する”と定められている。ここでの現在の URL は，D システムのページの URL である。

したがって，実行が許可されるのは，ページの URL と同じオリジン（スキーム，ホスト，ポートが同じ）から読み込むスクリプトファイルだけである。ほかのオリジンのスクリプトファイルは許可されない。

40 字以内なので，“URL と同じオリジンである”という条件と“スクリプトファイル”を残す。“どのような”と問われているので，読込み元の条件を書く。

採点講評（IPA）

設問2(2)及び(3)では，CSPがクロスサイトスクリプティング（XSS）脆弱性を防ぐ仕組みを理解できていないと思われる解答が一部に見られた。従来型のコンテンツにCSPを適用するためにはコンテンツの修正が必要ではあるが，XSSによって被害が発生する可能性は著しく低くなる。CSPの適用は，有効な手段であるので，この仕組みを理解しておいてほしい。

本文の根拠

〔D システムの脆弱性対策〕

実行が制限されてしまうスクリプトの有無を確認し，もしあれば，当該箇所の呼出し方法を変更する

〔D システムの脆弱性対策〕

Content-Security-Policy: script-src 'self';

script-src 'self' だけを指定すると，'unsafe-inline' やナンス，ハッシュを指定していない限り，HTML ファイルの中に直接書かれたスクリプト（インラインのスクリプト）は実行されない（W3C の Content Security Policy Level 3 のインライン動作の判定による）。そのため，D システムの正規の画面で，HTML ファイル中にスクリプトを書いている箇所が動かなくなる。

変更後の呼出し方法は，そのスクリプトを別のファイルとして D システムと同じオリジンに保存し，HTML ファイルから <script src="…"> のように呼び出す形にする。同一オリジンのファイルなので，設問 2(2) のとおり実行が許可される。

“スクリプト”は 30 字以内，“呼出し方法”は 50 字以内なので，前者は“HTMLファイル中に記載されたスクリプト”，後者は“別ファイルとして同一オリジンに保存し，HTML ファイルから呼び出す”の 2 点（別ファイル化と同一オリジン）を残す。

採点講評（IPA）

設問2(2)及び(3)では，CSPがクロスサイトスクリプティング（XSS）脆弱性を防ぐ仕組みを理解できていないと思われる解答が一部に見られた。従来型のコンテンツにCSPを適用するためにはコンテンツの修正が必要ではあるが，XSSによって被害が発生する可能性は著しく低くなる。CSPの適用は，有効な手段であるので，この仕組みを理解しておいてほしい。

本文の根拠

〔項目 1 の検討〕 T さんの発言

クラウドサービスのための d の実践の規範である ISO/IEC 27017 に基づく認証

〔項目 1 の検討〕 T さんの発言

パブリッククラウドにおける e の実践の規範である ISO/IEC 27018 に基づく認証

ISO/IEC 27017 は，クラウドサービスのための情報セキュリティ管理策の実践の規範である。したがって d は“情報セキュリティ管理策”（ウ）。ISO/IEC 27018 は，パブリッククラウドにおける個人情報保護（PII の保護）の実践の規範である。したがって e は“個人情報保護”（ア）。本文でも，27018 は“D システムとは直接関係がない”とされており，D システムが個人情報を扱わないことと合う。

イの“システム監査”と，エの“審査及び認証”は，どちらも規範の対象を表す語ではない。“審査及び認証”は，本文の“認証”という手続そのものを指す語であり，規範が実践を求める内容にはならない。

番号と内容（27017＝クラウドサービスの情報セキュリティ管理策，27018＝パブリッククラウドの個人情報保護）を対にして覚えておく点が間違えやすい。

本文の根拠

表2 項目 1 の検討結果

ファイルを G サービス上のストレージに保存するときの暗号化：G サービスの機能として，自動的に暗号化され，暗号鍵は G 社が管理するので可。

〔項目 1 の検討〕 T さんの発言

F 国内に保存されているデータを，F 国政府に強制的に提出させる国内法が存在する

G サービスは，ファイルを自動的に暗号化するが，暗号鍵は G 社が管理している。F 国政府がデータの提出を強制したとき，G 社は鍵をもっているので，復号した内容を渡せてしまう。F 国の法律に従った提出から，ファイルの内容を守るには，G 社が鍵をもたない状態にしなければならない。

そこで，U 社と協力会社が，ファイルを G サービスにアップロードする前に，U 社が管理する鍵で暗号化しておく。G 社には暗号化されたファイルしか渡らず，鍵は U 社側にあるので，提出されても内容は読まれない。

40 字以内なので，“U 社が管理する鍵で”“暗号化してから”“アップロードする”の 3 点を，G サービス上の保存とは別に，U 社の側で行うと分かるように書く。

本文の根拠

表4 項番 1

利用者 ID を固定して，パスワードを総当たりする。

表3 提供しているログ

ログには，操作対象，実行された操作とともに，日付，時刻，実行した利用者 ID，アクセス元 IP アドレス，及び結果（成功又は失敗）が記録される。

項番 1 の不正アクセスは，利用者 ID を固定して，パスワードを総当たりするものである。このとき，ログには，同じ利用者 ID に対するログインの失敗が短い時間に多数記録される。ログには利用者 ID，アクセス元 IP アドレス，成功又は失敗の結果が記録されるので，利用者 ID ごとのログインの失敗回数を数えれば検知できる。

したがって f は“同一利用者IDでのログイン失敗”。項番 2 の検知方法（同一 IP アドレスからの異なる利用者 ID でのログイン失敗の回数）と対にして，数える対象が利用者 ID と IP アドレスのどちらなのかを読み分ける。

20 字以内なので，“同一利用者 ID での”と“ログイン失敗”を残す。“回数”は空欄の後ろにすでに書かれている。

本文の根拠

表4 項番 2

一定時間当たりの同一 IP アドレスからの異なる利用者 ID によるログイン失敗の回数がしきい値を超えたら，不正アクセスとして検知する。

〔項目 2 の検討〕

いずれの不正アクセスもゆっくりと実行された場合には見逃すことがある

項番 2 の検知方法は，同一の IP アドレスからの，異なる利用者 ID によるログイン失敗の回数がしきい値を超えたかどうかで判断する。つまり，ログインを試す側の IP アドレスが同じであることを前提にしている。

ゆっくり実行する場合（時間当たりの回数が減る）のほかに，攻撃者がアクセス元の IP アドレスを次々に変えながら試すと，1 つの IP アドレスあたりの失敗回数がしきい値に届かず，見逃してしまう。

40 字以内なので，“アクセス元 IP アドレスを変えながら”と“不正アクセスを続けた場合”の 2 点を残す。“ゆっくり”とは別の場合なので，時間の長短には触れない。

本文の根拠

図10 注記

オリジン b は Web ブラウザがアクセスしている Web サイトのオリジン

図10 (5)

認証サーバは“オリジン b が K サービスのものであることの確認”と“(5)の正当性確認，署名 M の検証”を行う。

〔IDaaS との連携による多要素認証の実現方式の検討〕

何らかの方法で被害者をそのサーバに誘導し，認証情報を不正に入手して悪用するという攻撃

オリジン b は，Web ブラウザが実際にアクセスしている Web サイトのオリジンである。図 10 の(3)で H（オリジン b || 乱数 c'）がスマートフォンに渡され，署名 M はこれに対するディジタル署名として，(5)で認証サーバに届く。認証サーバは，オリジン b が K サービスのものかを確認し，署名 M を検証する。

攻撃者が用意した特別なサーバに被害者を誘導して認証させようとしても，被害者のブラウザがアクセスしているのは攻撃者のサーバなので，オリジン b は K サービスのものにならない。攻撃者が K サービスとの間でメッセージを中継し，被害者の認証をそのまま K サービスに通そうとしても，認証サーバが“オリジン b が K サービスのものであること”の確認で拒否できる。したがって g は“メッセージをKサービスとの間で中継”，すなわち，被害者と K サービスの間に入って認証メッセージを中継する偽サーバである。

20 字以内なので，“メッセージを”“K サービスとの間で”“中継”の 3 点を残す。“盗む”ではなく，“中継して認証を通す”という目的を書く。

本文の根拠

表5 FIDO 認証器の仕組み

USB 接続外部認証器：USB ポート経由，なし，できない，限定されない。

表5 FIDO 認証器の仕組み

スマートフォン：Bluetooth 経由，スマートフォンに組み込まれた生体認証装置による生体認証，できない，限定されない。

表7 運用上のリスクと対策

退職者による不正なアクセスを防ぐために，個人所有のスマートフォンを利用していた場合も想定して，退職時又は退職後直ちに，iでは，jする必要がある。

h は，スマートフォンと OS 内蔵の生体認証機能に共通する，認証器の使用時の利用者確認である。表 5 では，どちらも“生体認証”が利用者確認（User Verification）になっているので，紛失・盗難に遭っても，生体認証が必要で，第三者による不正利用の可能性は低い。

i・j は，個人所有のスマートフォンが認証器になっている場合の退職時の対策である。退職者の手元にスマートフォンが残るので，K サービス（i）では，その従業員のアカウントを削除（j）する。そうすれば，スマートフォンに登録された認証器では認証できなくなる。k は，USB 接続外部認証器の紛失・盗難時の対策である。表 5 の利用者確認が“なし”なので，拾った人がそのまま使えてしまう。第三者の不正利用を防ぐために，直ちに該当のアカウントを無効にする。

各 10 字以内なので，“生体認証”“Kサービス”“アカウントを削除”“アカウントを無効に”のように，語句だけを書く。j（削除）と k（無効に）は，退職と紛失という場面の違いに合わせて使い分けられている点に注意する。

採点講評（IPA）

設問5(2)は，全体的に正答率が高かったが，FIDO認証器の利用状況を想定できていないと思われる解答が一部に見られた。リスク分析は，対象となる情報システムの利用状況に基づいて行うものであり，あらかじめよく整理しておくことを心掛けてほしい。

本文の根拠

〔セキュリティインシデントの発生〕

また，D システムには，ファイル受渡し用 PC からだけアクセスすることを求めている。

表2 項目 1 の検討結果

協力会社以外からのアクセス禁止：G サービスで，送信元 IP アドレスの制限を行うことができないので否。

表5 FIDO 認証器の仕組み

OS 内蔵の生体認証機能：OS 内部処理，OS に内蔵された生体認証機能による生体認証，OS の利用者 ID 間で可能，限定される。

D システムの利用規約は，D システムへのアクセスをファイル受渡し用 PC からだけにすることを求めている。G サービスは送信元 IP アドレスの制限ができない（表 2）ので，アクセス元の PC を絞るには，別の方法が要る。

表 5 の“組合せ”は，K サービスにアクセスする PC と認証器の組合せのことで，スマートフォンは“限定されない”が，OS 内蔵の生体認証機能は“限定される”。OS 内蔵の生体認証機能では，ファイル受渡し用 PC が認証器を兼ねるので，認証に使えるのはその PC だけになる。この技術的な仕組みで，G サービスへのアクセスをファイル受渡し用 PC からのアクセスだけに限定できる。

50 字以内なので，“G サービスへのアクセスを”“ファイル受渡し用 PC からのアクセスだけに”“限定できる”の 3 点を残し，PC と認証器が一体になる点は，“限定される”の理由として解説の側で補う。

本文の根拠

図5 テレワークセキュリティ規程

経営者：組織のあるべき姿を検討し，テレワークセキュリティ全般を考え，必要なリソースを確保する。

図5 テレワークセキュリティ規程

システム管理者：情報システムへの不正アクセス，マルウェア感染などのインシデント発生時の対処のルールを定める。

図5 テレワークセキュリティ規程

テレワーク勤務者：定められたルールを遵守し，データを安全に扱う。

図 5 は，冒頭で経営者，システム管理者，テレワーク勤務者の 3 つの役割を定め，[詳細] の 1〜4 で，各項目をどの役割が行うかを空欄にしている。役割の説明に照らして割り当てる。

1 は，人材・資源を確保するための予算の割当てなので，必要なリソースを確保する経営者（a＝ア）。2 は，情報セキュリティポリシに従った技術的対策と実施状況の点検なので，システム管理者（b＝イ）。3 は，社内システムに強度の低いパスワードが用いられないよう，システム側に制限を掛けるので，システム管理者（c＝イ）。4 は，パスワードの使い回しを避け，12 桁以上の推測されにくいパスワードを設定するので，定められたルールを守り，データを安全に扱うテレワーク勤務者（d＝ウ）。

3 と 4 は，どちらもパスワードの話だが，“制限を掛ける”のはシステムを管理する側，“設定する”のは利用する側であるという違いで分ける点が間違えやすい。同じ役割（イ）が b と c の 2 か所に入ってもよい。

本文の根拠

図5 [詳細] 5

その際，電子政府における調達の際にも参照されるe暗号リストを参照し，暗号化には危殆化していない暗号アルゴリズムを採用するものとする。

“電子政府における調達の際にも参照される暗号リスト”は，“CRYPTREC 暗号リスト”（電子政府推奨暗号リストなどを含む）である。政府機関などが暗号を選ぶときに参照され，危殆化していない（安全性が損なわれていない）暗号アルゴリズムを選ぶ根拠になる。

英字 8 字という指定なので，“CRYPTREC”を大文字で書く。“暗号リスト”は空欄の後ろに既に書かれているので含めない。

本文の根拠

図6 新 NW の内容

ただし，（下線①）B サービスへのアクセスだけ，拠点 VPN サーバから，DC を経由させずに支社に敷設したインターネット接続回線を経由させる。

下線①は，B サービスへのアクセスだけ，DC（UTM）を通さず，支社に敷設したインターネット接続回線から直接インターネットに出す構成である。本社が UTM の処理能力を超過するのを避けるための構成で，インターネット向けの通信を，中央の拠点を通さず，各拠点から直接インターネットへ出す方式を，ローカルブレイクアウト（エ）という。

アの OpenFlow は，ネットワーク機器の転送を外部から制御するためのプロトコルである。イの Software-Defined Networking は，ネットワークの構成や制御をソフトウェアで行う考え方で，ここで示された“通信を拠点から直接出す”という構成そのものを指す語ではない。ウのゼロトラストネットワークは，ネットワークの内外を問わず信頼せず，通信のたびに検証する考え方である。

“通信の経路をどこから出すか”を指す語を選ぶ点が間違えやすい。

本文の根拠

表1 構成要素の説明

アクセス制限機能によって，アクセス元 IP アドレスが UTM のグローバル IP アドレスの場合だけアクセスが許可される。

図8 タイムライン

4 月 1 日：情報システム部が新 NW のテストでのトラブル解消のために，B サービスの設定を変更した。

B サービスは，アクセス制限機能によって，アクセス元 IP アドレスが UTM のグローバル IP アドレスの場合だけアクセスを許可している。従来は，テレワークの通信も VPN サーバを経由して UTM から B サービスに出ていたので，アクセス元は UTM のグローバル IP アドレスだった。

新 NW のテストでは，B サービスへのアクセスだけを，DC を経由せず支社に敷設したインターネット接続回線から出した。アクセス元 IP アドレスが支社の回線のものになり，B サービスのアクセス制限機能に許可されず，通信が拒否された。インターネットにはアクセスできたのに B サービスだけ接続できなかったことと合う。図 8 の 4 月 1 日に，この拒否を解消するため B サービスの設定を変更したと読める。

35 字以内なので，“B サービスのアクセス制限機能によって”“通信が拒否された”の 2 点を残す。

本文の根拠

〔インシデントへの対策の検討〕 G さんの発言

その IP アドレス，及びその FQDN の DNS の正引き結果の IP アドレスの二つを併せた IP アドレスのリスト（以下，IP リストという）を手作業で作成しておき，IP リストに登録された IP アドレスへの通信を UTM で拒否します。

IP リストは，マルウェアに埋め込まれていた C&C サーバの IP アドレスと，FQDN の DNS の正引き結果の IP アドレスを，作成した時点でまとめたものである。FQDN の正引き結果は DNS の設定で決まり，攻撃者が管理するものなので，いつでも変えられる。

したがって，攻撃者が行う設定変更とは，マルウェア内に FQDN で指定した C&C サーバの IP アドレスを，DNS の設定を変えて別の IP アドレスに変更することである。変更後の IP アドレスは IP リストに載っていないので，UTM での拒否の対象にならず，マルウェアは C&C サーバと通信できてしまう。

40 字以内なので，“FQDN で指定した C&C サーバの IP アドレスの変更”と，“マルウェア内”の指定を残す。IP リストが作成時点のもので，あとから変わる点を押さえる。

本文の根拠

〔インシデントの発生〕

マルウェア α 及びマルウェア β のどちらにも A 社を標的にしたと思われる識別文字列，A 社固有のファイルパス，並びに C&C サーバの IP アドレス及び FQDN のリストが埋め込まれていた。

表1 DNS シンクホール機能

DNS クエリをチェックし，危険リストに登録されている FQDN の場合は，正規の名前解決を行わずに A 社があらかじめ用意した IP アドレスを応答する。

DNS シンクホール機能は，DNS クエリをチェックして，危険リストに登録された FQDN の名前解決に対し，A 社が用意した IP アドレスを応答する。つまり，マルウェアが DNS に問い合わせた場合にだけ効く。

ところが，マルウェアには C&C サーバの IP アドレスも FQDN とともに埋め込まれていた。IP アドレスを直接指定して C&C サーバと通信する場合には，DNS への問合せが発生しないので，シンクホール機能では止められない。そこで UTM での通信拒否（IP リストの IP アドレス宛の拒否）も必要になる。

40 字以内なので，“DNS への問合せを実行しない場合があるから”に“C&C サーバとの通信時に”を添える。“マルウェアの解析結果を踏まえて”とあるので，IP アドレスが埋め込まれていた点が根拠になる。

本文の根拠

図8 攻撃者の活動の特徴

一部の業務 PC では，全てのイベントログが消去された痕跡があった。全てのイベントログが消去された後，イベントログにイベントログの消去を示すログが記録されていた。

表4 項番 1

中のイベントログに，α ログ，β ログ又はfが存在するかどうか。

確認ツールは，イベントログに α ログ又は β ログがあるかどうかを調べる。しかし図 8 のとおり，攻撃者は一部の業務 PC で全てのイベントログを消去していた。消去すると，α ログや β ログも一緒に消えるので，確認ツールは感染を見逃す。

ただし，全てのイベントログが消去されると，その後のイベントログに“イベントログの消去を示すログ”が記録される。このログがあれば，攻撃者が痕跡を消した可能性があるので，感染の疑いが強い。したがって f は“イベントログの消去を示すログ”。表 4 の調査 1 は，この f が存在した場合もグループ A（感染の疑いが強い）とする項目である。

20 字以内なので，“イベントログの消去を示すログ”の 14 字でよい。

本文の根拠

表2 マルウェア β

いずれかの機能を，あらかじめ定められた確率でランダムに実行する。この実行は，1 週間の間隔を置いて繰り返され，遠隔操作機能の実行に成功すると，繰り返しの実行を停止する。

表2 マルウェア β (3)

このとき，イベントログにマルウェア β の実行を示すログ（以下，β ログという）が記録される。

表2 マルウェア β (2)

感染した PC 又はサーバから到達可能なネットワーク内の機器をスキャンし，OS の脆弱性がある機器を発見すると，自身に感染させる。

β ログが記録されるのは，遠隔操作機能（3）を実行したときだけである。待機機能（1）は何もせず，横展開機能（2）はスキャンや感染を行うが，β ログは記録されない。1 週間ごとにランダムに機能を選ぶので，遠隔操作機能を一度も実行していない期間は，β ログが無く，確認ツールで“問題がない”と判定される。

その間に横展開機能を実行していれば，到達可能な機器に自身を感染させ，共有フォルダに細工したファイルも置くので，別の PC やサーバに感染を拡大させている。したがって，問題がないと判定されるのは，“横展開機能と待機機能だけを実行していた場合”である。

25 字以内なので，“横展開機能と待機機能だけを実行していた場合”の 21 字でよい。遠隔操作機能を実行していないという条件を，α ログではなく β の機能の名前で書く。

採点講評（IPA）

設問3(4)は，正答率が高かった。本文中に示された確認ツールの仕様及びマルウェアの特徴を正しく理解し，遠隔操作機能が実行されていない挙動を適切に解答できていた。

本文の根拠

表1 UTM

IDS 機能：全てのインバウンド通信をチェックし，不審な通信を検知した場合は，システム管理者に通知する。

図3 の後

連携サーバは，研究部が管理する連携 FW を経由してインターネットに接続されている。

連携サーバは，現在，研究部が管理する連携 FW を経由してインターネットに接続されている。連携 FW には，IDS 機能が書かれていない（FW として，会員から伝えられたグローバル IP アドレス及び研究部セグメントからの通信だけを許可している）。

DC の DMZ に移設すると，インターネットからの通信は，DC の UTM を通る。UTM は IDS 機能を有効にしていて，全てのインバウンド通信をチェックし，不審な通信を検知するとシステム管理者に通知する。連携サーバへの攻撃も UTM で検知でき，システム管理者に連絡がされるので，迅速な対応が可能になる。

45 字以内なので，“UTM の IDS 機能によって攻撃が検知でき”と“システム管理者に連絡がされる”の 2 点を残す。連携 FW に IDS 機能がない点が対比になる。

本文の根拠

図8 タイムライン

7 月 14 日：攻撃者は，D さんのアカウントを使って研究部の F さん宛にマルウェア α を添付したメールを送信した。

図8 タイムライン

同日中に，攻撃者の遠隔操作によって同業務 PC がマルウェア β にも感染した。

図4 [情報連携の手順]

連携サーバの共有フォルダは研究部セグメントの業務 PC から認証なしでアクセス可能になっている。

連携サーバの共有フォルダには，研究部セグメントの業務 PC から認証なしでアクセスできる。マルウェア β の横展開機能は，アクセス可能な共有フォルダに細工された文書ファイルを置く。したがって，細工されたファイルが連携サーバに置かれていた可能性のある最も早い日付は，研究部の F さんの業務 PC がマルウェア β に感染した日である。

図 8 のタイムラインでは，その日は 7 月 14 日（α に感染し，同日中に β にも感染した日）である。7 月 9 日は，攻撃者が D さんのアカウントで B サービスに不正ログインした日で，業務 PC への感染はまだ起きていない。連携サーバのログファイルの最古は 7 月 19 日で，60 日保存のため，それ以前の記録は残っていない。表 4 の対象期間の開始日（7 月 19 日）は，7 月 14 日にさかのぼる必要がある。

日付だけを答えるので，“7月14日”と書く。

本文の根拠

〔インシデントへの対策の検討〕 G さんの発言

IP リストに登録された IP アドレスへの通信を UTM で拒否します。

表5 調査 2

対象期間中の会員 FW のログに，次に該当する送信元から宛先への通信記録が存在するかどうか。

調査 2 は，会員 FW のログに，ある送信元から宛先への通信記録があるかどうかを調べる。マルウェア β が会員の中で感染を広げていれば，会員内の PC やサーバが C&C サーバと通信する記録が，会員 FW に残る。C&C サーバの IP アドレスは，G さんの作成した IP リストに載っている。

したがって，宛先は“IPリストに登録されたIPアドレス”になる。送信元は任意の IP アドレスなので，連携端末以外が C&C サーバと通信した記録も拾える。

25 字以内なので，“IPリストに登録されたIPアドレス”の 17 字でよい。

本文の根拠

表5 調査 2

送信元：任意の IP アドレス

再レビュー時の会話

連携端末からほかの PC やサーバへの感染拡大が明らかな会員に絞るのであれば，調査 2 に使う通信記録から絞ることができる

調査 2 の送信元は“任意の IP アドレス”であり，連携端末も含む。連携端末が C&C サーバと通信した記録だけなら，連携端末が感染したことしか分からない。連携端末からほかの PC やサーバへの感染拡大が明らかな会員とは，連携端末以外の機器が C&C サーバと通信している会員である。

したがって，絞込みの条件は，調査 2 に使う通信記録のうち，連携端末以外の IP アドレスを送信元とするものがあるかどうかである。講評でも，この絞込みの条件が書けていない解答が目立った点が指摘されている。

30 字以内なので，“連携端末以外の”“IP アドレスを送信元とする”“通信記録”の 3 点を残す。“連携端末の通信記録を除く”とだけ書くのではなく，送信元を条件にする。

採点講評（IPA）

設問4(3)は，正答率が低かった。対処の優先度を上げるべき会員は，連携端末以外の機器へ感染が広がっている会員であるが，それを絞り込むための条件を明示できていない解答が散見された。マルウェア感染においては，最終的には被害対象について漏れなく対処すべきであるが，被害拡大を防ぐためにも優先度をつけて対処することが重要であることを理解してほしい。

本文の根拠

〔連携サーバ経由の感染状況の確認と感染拡大防止〕

化学コンの全会員に連携端末を一時的にネットワークから切り離してもらうように連絡し，全ての会員で対応が完了したことを即日確認した。

再レビュー時の会話

グループ A と判定された会員企業であっても，この通信記録がなかった会員は，⑧既に行っている対応から考えて，感染を拡大させるリスクは相対的に低いと考えることができます。

E さんは，連携サーバの感染状況の確認の初めに，化学コンの全会員に，連携端末を一時的にネットワークから切り離してもらい，全ての会員で完了したことを即日確認した。感染の可能性のある連携端末が，ほかの機器と通信できない状態に既にしてある。

この対応により，連携端末から別の PC やサーバへの感染拡大は止まっている。グループ A でも，連携端末以外が C&C サーバと通信した記録（設問 4(3)）がなければ，ほかの機器への感染拡大は起きていないと考えられるので，リスクは相対的に低い。

30 字以内なので，“連携端末を”“一時的にネットワークから切り離した”の 2 点を残す。全会員に依頼し，完了を確認した点まで書き込む必要はない。