N 社は，従業員数 5,000 名の化学メーカであり，総務部，営業部，製造部及び情報システム部（以下，情シスという）がある。また，国内に工場がある。N 社の LAN 構成を図 1 に示す。
図 1 N 社の LAN 構成
N 社では，全従業員に一つずつ利用者 ID が割り当てられ，その利用者 ID とパスワードが認証サーバに登録される。タブレット PC，問合せ用 PC 及び D-PC（以下この三つを併せて，社内 PC という）へのログオン時並びに内部メールサーバ及びファイルサーバへのアクセス時には，認証サーバを使用して認証が実施される。イントラポータルサーバは，認証サーバと連携して，ベーシック認証を使用している。
総務部では，無線 LAN 接続型のタブレット PC を導入している。無線 LAN の暗号化では，WPA2 を使用している。W-AP では，不正な端末の接続を防ぐための対策として，次の機能を使用している。
登録済み MAC アドレスをもつ端末だけを接続可能とする接続制御
総務部に所属する従業員の利用者 ID だけに接続を許可する IEEE 802.1X 認証
IEEE 802.1X 認証では，認証サーバと連携して，利用者 ID とパスワードを使用している（EAP-PEAP）。
プロキシサーバでは，各機器からの全てのアクセスについて，アクセスログを取得している。
N 社では，クラウドサービスを利用して，会社情報や製品情報を公開する Web サイトを運用している。Web サイトには，訪問者からの問合せを受け付けるためのフォームが用意されており，訪問者が問合せ内容を入力すると，その内容が電子メール（以下，メールという）で N 社の特定のメールアドレス宛てに送信される。フォームにはファイルを添付する機能はないので，問合せメールにファイルが添付されることはない。万一，このフォーム以外から，この特定のメールアドレス宛てにメールが届いた場合は，そのメールは破棄される。問合せ用 PC は，問合せメールを受信するための専用の D-PC で，他の用途には使用していない。また，問合せメールを他の社内 PC で受信することはない。問合せ用 PC から回答メールを返信する場合，回答メールの送信元メールアドレスには送信専用のメールアドレスを使用している。
4 月 12 日 13:00 頃，セキュリティ情報共有団体から，“ある C&C（Command and Control）サーバを調査していたところ，そのサーバに対する N 社からの通信記録を発見した。”との連絡が届き，その通信に関して，表 3 の情報が提供された。
表 3 提供された情報（抜粋）
情報提供を受けて，N 社の CSIRT メンバが招集された。N 社の CSIRT のリーダである R 課長は，メンバの P 君に対して，情報処理安全確保支援士（登録セキスペ）である W 主任の支援を受けながら，直ちに状況を確認するよう指示した。P 君は，表 3 の情報の真偽を確かめるために，まず a のログを確認して N 社から当該通信が発信されていたとの確証を得た後，通信を開始した端末を特定するために b のログを確認した。その結果，問合せ用 PC から C&C サーバに向けて HTTPS と思われるセッションが確立していたことが確認できた。
〔問合せ用 PC の調査〕
状況の報告を受けた R 課長は，問合せ用 PC の調査を指示した。P 君は，決められたインシデント対応手順に従い，まず問合せ用 PC の HDD のコピー（以下，複製 HDD という）を作成した。コピーは①ファイル単位ではなくセクタ単位で全セクタを対象とした。原本である HDD はそのまま保全した。次に，予備の D-PC を新たな問合せ用 PC として設定して，問合せメールへの回答業務を継続できるようにした。
〔感染経路の調査〕
P 君が，複製 HDD の中に残っていた直近 6 か月分の問合せメールについて調査したところ，本文に URL が記載されたメールが幾つかあった。その全ての URL のサイトを調査したが，どのサイトも改ざんの報告はなく，閲覧したとしてもマルウェアに感染するおそれがないサイトだった。
問合せメールによるマルウェア感染が C&C サーバとの通信の原因である可能性は低いと考えた P 君は，調査方針を W 主任に相談し，複製 HDD 内のログ及び関連機器内のログを調査することにした。その結果，図 2 の調査結果が得られた。
図 2 調査結果
この調査結果から，P 君は，攻撃者が B さんの利用者 ID とパスワードを入手し，それらを利用して無線 LAN 経由で問合せ用 PC に不正にログオンしたと判断した。
そこで，W 主任は，不正な PC を W-AP に接続させないための対策として，IEEE 802.1X 認証の方式を EAP-TLS に変更する案を提案した。
P 君は，総務部の W-AP は，MAC アドレスによる接続制御をしているのに，攻撃者がなぜ接続できたのか疑問に思い，W 主任に聞いてみた。W 主任は，②WPA2 を使用していても，無線 LAN の通信が傍受されてしまうと B さんが利用しているタブレット PC の MAC アドレスを攻撃者が知ることができることと，③攻撃者が，自分の無線 LAN 端末を総務部の W-AP に接続可能にする方法を P 君に説明した。
また，IEEE 802.1X 認証で使用する B さんの利用者 ID とパスワードを攻撃者が入手する方法について，次のように話した。
CTR モードでは，暗号ブロックは，d と e の排他的論理和である。無線 LAN の場合，攻撃者は暗号化されたパケットを入手可能であるので，その暗号化されたパケットに対応する d が推測できた場合，e は容易に算出できる。これらを踏まえると CTR モードでは，初期カウンタ値の再利用の強制によって，同一の e を使用して異なるパケットの暗号文を作成してしまう可能性がある。
ここまで調べた P 君は，イントラポータルサーバへのアクセスは HTTP であり，かつ，ベーシック認証を使用しているので，WPA2 の通信を解読されると利用者 ID とパスワードの流出に直結してしまうことに気付いた。
〔不審な W-AP の発見と対策〕
無線 LAN 経由で侵入された可能性のある時期には，タブレット PC は KRACKs への対策がされていなかったので，P 君は，KRACKs による攻撃を受けた可能性を調査する必要があると考えた。そこで P 君は，W 主任に相談して，攻撃者が不正な W-AP を設置していないか，N 社の周囲の無線状況を調査した。その結果，総務部の W-AP と同一の SSID が設定された不審な W-AP が，N 社敷地外にあることを発見し，KRACKs による攻撃を受けたと結論付けた。
一方，R 課長は，FW1 には L7FW 機能があることを思い出した。しかし，今回のインシデントでは，FW1 が，マルウェアによる通信を不正な通信として検出した形跡はなく，通過させていた。この件について，R 課長は P 君に調査を指示した。
P 君が，b のログを分析したところ，4 月 10 日の 10:00 以降，問合せ用 PC が発信元である HTTPS と思われる通信が，通常よりも大幅に増加していた。これらの通信の大半は，表 3 の C&C サーバの IP アドレスを含む不審な IP アドレスへの通信であったことから，マルウェアによるものと推測された。一方，問合せ用 PC が発信元である HTTP 通信は，ほとんどなかった。
続いて P 君が，FW1 の機能の設定状態を確認したところ，L7FW 機能は有効化されていたが，HTTPS 通信によって送受信されるデータを復号する機能（以下，HTTPS 復号機能という）はライセンスがないので有効化されていなかった。この状態では，HTTPS 通信に対して L7FW 機能は効果がないことも分かった。P 君は，これら一連の内容を R 課長に報告した。
R 課長は，インシデントの調査を終了し，W-AP の IEEE 802.1X 認証の方式を EAP-TLS に変更する案と，イントラポータルサーバへのアクセスを HTTPS に変更する案を実施するとともに，残りの対策の検討に移ることにした。
〔未知マルウェア対策の改良〕
R 課長は，今後，HTTPS 通信を利用するマルウェアが増えると思われるので，社内 PC について，何らかの対策を打つ必要があると考え，W 主任に検討を指示した。
W 主任は，追加の費用が発生しない範囲で実施できる対策として，プロキシサーバがもつ，特定の URL への接続を禁止するブラックリスト機能の適用を検討した。HTTP 通信の場合，プロキシサーバでは内容を f ことができる。しかし，HTTPS 通信の場合，社内 PC からプロキシサーバに CONNECT メソッドによって接続要求を送る時点では平文で Web サーバの g 名とポート番号が渡されるが，社内 PC と Web サーバの間で TLS セッションが成立して暗号通信路が確立した後は，プロキシサーバでは内容を f ことはできない。そのため，HTTPS 通信の場合，実質的にブラックリストに登録できるのが，URL の g 部とポート番号部だけであり，h 部は指定できないことや，そもそもブラックリストに登録すべき URL 情報が必要なタイミングで入手できないことから効果が期待できないとの結論となった。
P 君は，これらの制約の回避方法を運用手順に含めることにした。表 5 の項番 1 の場合は，FW1 の HTTPS 復号機能の例外リストに外部 Web サーバを追加することにした。例外リストに Web サーバを追加すると，例外的に復号機能を適用せず社内 PC と Web サーバの間で直接 HTTPS 通信を行うことができる。例外とする場合には，業務上の必要性があること，及び正当な Web サーバであることを所定の手順で確認することにした。表 5 の項番 2 及び 3 の場合も，必要な内容を運用手順に含めた。
WPA2 を使用していても，無線 LAN の通信が傍受されてしまうと B さんが利用しているタブレット PC の MAC アドレスを攻撃者が知ることができる
〔LAN 構成〕
W-AP では，不正な端末の接続を防ぐための対策として，次の機能を使用している。
〔LAN 構成〕
登録済み MAC アドレスをもつ端末だけを接続可能とする接続制御
W-AP は，登録済み MAC アドレスをもつ端末だけを接続可能にしている。攻撃者がその接続制御を破るには，登録されている MAC アドレスを知る必要があり，下線②は，WPA2 を使っていても通信を傍受すれば B さんのタブレット PC の MAC アドレスを知られる，という指摘である。理由は，MAC アドレスが暗号化されず平文で送信されるから，である。採点講評も，WPA2 であっても MAC アドレスが含まれるイーサネットフレームのヘッダ部は暗号化されないことを理解しておいてほしい，と述べている。
本文の無線 LAN 暗号化（WPA2）は通信の中身を保護するもので，端末や W-AP の宛先として使われる MAC アドレスまでは隠さない，と読める。傍受した電波から，登録済みの端末がどの MAC アドレスで通信しているかが分かる。
P 君は，総務部の W-AP は，MAC アドレスによる接続制御をしているのに，攻撃者がなぜ接続できたのか疑問に思い
W-AP は登録済み MAC アドレスの端末だけを通す。攻撃者は設問 3(1) のとおり，傍受によって登録済みの MAC アドレス（B さんのタブレット PC のもの）を知っているので，自分の無線 LAN 端末のポートの MAC アドレスをその値に変更すれば，W-AP からは登録済みの端末に見える。これが下線③の具体的な方法である。
これで MAC アドレスによる接続制御は通るが，総務部の従業員の利用者 ID だけに接続を許可する IEEE 802.1X 認証は別の仕組みで，攻撃者は B さんの利用者 ID とパスワードを KRACKs などで入手して通過した（〔無線 LAN の脆弱性〕の W 主任の説明）。つまり MAC アドレスの変更は接続制御を破る方法であり，認証を破る方法とは分けて考える。
字数は 55 字以内で，解答例は 48 字である。“端末の MAC アドレスを”“総務部の W-AP に登録済みの MAC アドレスに”“変更する”の三つを残し，“なりすます”だけでは具体的な方法にならないので，何をどう変えるのかまで書く。
設問4(1)40字以内
本文中の下線④について，TCP/IP パケットの特徴を，40 字以内で述べよ。
解答例
IPヘッダ部及びTCPヘッダ部は，同一のバイト列であることが多いこと
解説
本文の根拠
〔暗号モード〕
一般的なブロック暗号のブロック長は，64〜128 ビット程度なので
〔暗号モード〕
暗号化のため TCP/IP パケットをヘッダも含めて平文ブロックに分割すると
〔暗号モード〕
同一端末間の異なるパケットにおいて，同一の平文ブロックが繰り返して現れる
ブロック長が 64〜128 ビット（8〜16 バイト）なので，パケットの先頭から順にブロックに分けると，先頭のブロックは IP ヘッダの先頭部分，その次は IP ヘッダの続き，という具合にヘッダの内容がブロック単位で切り出される。IP ヘッダは最小でも 20 バイト（RFC 791 は IHL の最小値を 5 語としている），TCP ヘッダも最小で 20 バイトある（RFC 9293）ので，それぞれ複数のブロックにまたがる。同一端末間では，送信元・宛先の IP アドレスやポート番号，プロトコルなど，ヘッダの多くの欄が毎回同じ値になるため，異なるパケットでも同じ平文ブロックが現れる。解答例は“IPヘッダ部及びTCPヘッダ部は，同一のバイト列であることが多いこと”である。
無線 LAN の場合，攻撃者は暗号化されたパケットを入手可能であるので，その暗号化されたパケットに対応する
c は，ECB モードで同じ平文ブロックが繰り返して現れた場合に繰り返して現れるもの，つまり同一の暗号ブロックである。ECB モードは図 3 のとおり各ブロックを同じ鍵で独立に暗号化するので，同じ平文ブロックは必ず同じ暗号ブロックになる。パケットのヘッダが毎回ほぼ同じなら，暗号文にも同じブロックが並び，平文の推測の手掛かりになる。
CTR モードの暗号ブロックは，図 3 の右のとおり，平文ブロックと“カウンタ値を暗号化した値”との XOR である。したがって d は平文ブロック，e はカウンタ値を暗号化した値である。XOR は，結果と片方の値が分かれば他方が求まる演算なので，攻撃者が暗号文を入手し，対応する平文ブロック（d）を推測できれば，暗号文と d の XOR で e が算出できる。初期カウンタ値の再利用を強制されると，同じ e が別のパケットの暗号化に使われるため，その e を知った攻撃者はほかのパケットの暗号文も解読できる。
字数はどれも 15 字以内で，解答例は c が 9 字，d が 6 字，e が 12 字である。d と e は入れ替えると意味が通らなくなる。“暗号ブロックは d と e の XOR”の式に図 3 の右を当てはめ，XOR の相手が平文ブロック（m）であることから d を決めるとよい。
設問5(1)解答欄1つ
本文中のfに入れる適切な字句を，10 字以内で答えよ。
〔f〕解答例
読み取る
解説
本文の根拠
〔未知マルウェア対策の改良〕
HTTP 通信の場合，プロキシサーバでは内容を
〔未知マルウェア対策の改良〕
社内 PC と Web サーバの間で TLS セッションが成立して暗号通信路が確立した後は，プロキシサーバでは内容を
W 主任が検討したのは，プロキシサーバがもつ，特定の URL への接続を禁止するブラックリスト機能である。これを使うには，プロキシサーバが通信の中の URL を見られなければならない。HTTP 通信は暗号化されていないので，プロキシサーバは要求の内容を読み取ることができる。一方，HTTPS では TLS セッションが成立した後の内容は暗号化されていて，プロキシサーバは読み取れない。同じ空欄 f が“できる”と“できない”の両方につくので，答えは読み取る（見る）である。
FW1 は，作成したディジタル証明書及び対応する秘密鍵を利用して社内 PC と FW1 の間で TLS セッションを確立する。
図 5 のとおり，HTTPS 復号機能では FW1 が外部 Web サーバとして社内 PC と TLS セッションを確立する。そのために FW1 は，外部 Web サーバ向けのディジタル証明書と秘密鍵を自分で作る。社内 PC のブラウザなどはサーバ証明書を検証するので，FW1 が作った証明書が信頼されるためには，その証明書を発行した FW1 の自己署名証明書を，信頼する CA のディジタル証明書（信頼されたルート CA の証明書）として全ての社内 PC に登録しておく必要がある。登録しなければ，社内 PC は証明書の検証に失敗する。
ここでの“自己署名証明書”は FW1 自身が署名した，いわば FW1 が CA の役割をするための証明書である。社内 PC にとっては，外部 Web サーバのものに見える証明書を FW1 が正しく発行したと信じるための根拠になる。
字数は 20 字以内で，解答例は 15 字である。“信頼する CA の”と“ディジタル証明書”の二つを残す。“ルート証明書”のような近い言い方でも意味は通るが，信頼するという条件が抜けると，登録の目的が伝わらない。
採点講評（IPA）
設問6は，全体的に正答率が低かった。プロキシ経由の場合も含め，HTTPS（HTTP over TLS）のセッション確立までの手順と，その手順の中でディジタル証明書が果たす役割について理解しておいてほしい。また，HTTPS復号機能は，外部との間でHTTPS通信を行うマルウェアへの対策として有効であるが，一方で制約もあることも理解しておいてほしい。
設問6(2)解答欄1つ
表 5 中のjに入れる適切な字句を，40 字以内で述べよ。
〔j〕解答例
クライアント証明書の提示が必要な外部Webサーバにアクセスする。
解説
本文の根拠
表 5 項番 1
図 4 の流れの中で，FW1 は，社内 PC がもっているクライアント証明書に対応した秘密鍵を利用することができない。
図 4
(6) FW1 から外部 Web サーバへ TLS ハンドシェイク開始。
図 5
FW1 は社内 PC との TLS セッションの確立とほぼ同時に，クライアントとして外部 Web サーバとの TLS セッションも確立する。
表 5 の項番 1 の原因は，FW1 が社内 PC のクライアント証明書に対応した秘密鍵を利用できないことである。図 4 のとおり，社内 PC と外部 Web サーバの間には FW1 が入り，FW1 が TLS ハンドシェイクを二つに分けて終端する。外部 Web サーバがクライアント証明書の提示を求めると，その相手は FW1 であって社内 PC ではなく，FW1 は，社内 PC がもつクライアント証明書の秘密鍵を持たないので応じられない。したがって j は，クライアント証明書の提示が必要な外部 Web サーバにアクセスする通信である。
この種の通信は HTTPS 復号機能を適用せず，P 君が運用手順に含めたとおり，FW1 の例外リストに外部 Web サーバを追加して，社内 PC と外部 Web サーバの間で直接 HTTPS 通信をさせる。
字数は 40 字以内で，解答例は 32 字である。“クライアント証明書の提示が必要な外部 Web サーバ”と“にアクセスする”の二つを残す。単に“クライアント認証”と書くだけでは，通信の種類として書けていない。
採点講評（IPA）
設問6は，全体的に正答率が低かった。プロキシ経由の場合も含め，HTTPS（HTTP over TLS）のセッション確立までの手順と，その手順の中でディジタル証明書が果たす役割について理解しておいてほしい。また，HTTPS復号機能は，外部との間でHTTPS通信を行うマルウェアへの対策として有効であるが，一方で制約もあることも理解しておいてほしい。
FW1 には，FW1 の製造元によって安全性が確認された CA のディジタル証明書だけが，信頼されたルート CA のディジタル証明書としてインストールされている。
図 5
FW1 は社内 PC との TLS セッションの確立とほぼ同時に，クライアントとして外部 Web サーバとの TLS セッションも確立する。
図 5
片方の TLS セッションの確立に失敗した場合は，もう片方の TLS セッションも終了する。
FW1 は，外部 Web サーバに対してはクライアントとして TLS セッションを確立し，そのとき外部 Web サーバのサーバ証明書を検証する。表 5 の項番 3 の原因は，FW1 に信頼されたルート CA として入っているのが，FW1 の製造元が安全性を確認した CA のものだけであることである。よって，その範囲に入らない CA が発行したサーバ証明書を使っている外部 Web サーバに対しては，FW1 は証明書の検証ができず，外部 Web サーバとの TLS セッションの確立に失敗する。図 5 の(6)により，もう片方の社内 PC との TLS セッションも終了するので，その外部 Web サーバにはアクセスできなくなる。
通常の社内 PC のブラウザは自分が信頼する CA のリストで検証するが，HTTPS 復号機能では FW1 が代わりに検証するため，PC 側では信頼している CA の証明書でも FW1 が信頼していなければ通らない。
字数は 65 字以内で，解答例は 57 字である。“FW1 の製造元によって安全性が確認されていない CA”と“サーバ証明書を使用した外部 Web サーバにアクセスする”の二つを残し，“未登録の CA”のような略した言い方にしない。
採点講評（IPA）
設問6は，全体的に正答率が低かった。プロキシ経由の場合も含め，HTTPS（HTTP over TLS）のセッション確立までの手順と，その手順の中でディジタル証明書が果たす役割について理解しておいてほしい。また，HTTPS復号機能は，外部との間でHTTPS通信を行うマルウェアへの対策として有効であるが，一方で制約もあることも理解しておいてほしい。
出典：平成31年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
問2 情報セキュリティ対策の強化
情報セキュリティ対策の強化に関する次の記述を読んで，設問 1〜7 に答えよ。
A 社は，従業員数 200 名の金型加工業者である。新潟市内の同じ敷地に本社と工場が，大阪市に営業拠点がある。本社には，管理部，設計部及び製造部がある。管理部には，総務係，営業係及びシステム係がある。営業係は，営業拠点を管理する。製造部は，工場を管理する。
A 社の金型加工技術は，評価が高く，大企業から金型加工を請け負うことがある。請け負うときは，金型加工に必要な情報を収めたファイル（以下，設計情報ファイルという）を，DVD-R 又は電子メール（以下，メールという）を使って，発注元との間でやり取りする。
A 社では，最新技術の情報収集を目的として，取引先が参加している複数のメーリングリストに，営業係員及び設計部員が参加している。
〔営業秘密の取扱い〕
A 社では，自社の営業秘密が不正競争防止法で保護されるようにするために，不正競争防止法及び経済産業省が公表している営業秘密管理指針（平成 27 年 1 月 28 日全部改訂）を参考にして，表 1 に示す営業秘密に関する管理規則を定めている。
表 1 営業秘密に関する管理規則（概要）
〔A 社のネットワーク構成〕
A 社では，デスクトップ PC（以下，DPC という）を，全ての従業員に貸与している。DPC の社外への持出しは，禁止されている。
A 社は，クラウドサービス T を利用している。クラウドサービス T の機能と A 社での利用方法の概要を表 2 に示す。
表 2 クラウドサービス T の機能と A 社での利用方法の概要（抜粋）
A 社のネットワーク構成を図 1 に，A 社のネットワーク一覧を表 3 に示す。
図 1 A 社のネットワーク構成表 3 A 社のネットワーク一覧
〔A 社の情報システム〕
DMZ 上のサーバには，グローバル IP アドレスを割り当てている。DMZ 上のサーバの概要を表 4 に示す。
表 4 DMZ 上のサーバの概要（抜粋）
内部システム LAN 上のサーバの概要を表 5 に示す。
表 5 内部システム LAN 上のサーバの概要（抜粋）
A 社では，全ての従業員に個別のメールアドレスを割り当てており，従業員は，メールサービスを用いてメールを送受信している。従業員のメールアドレス以外に同報用のメールアドレスがあり，このアドレスに届いたメールは，登録された従業員のメールアドレスに同報される。
6 月 7 日，金型加工業者 B 社の L 氏から，設計情報管理サーバの管理者である設計部の J さんに，A 社の情報が漏えいしているおそれがあると連絡があった。J さんは，設計部長及び管理部の E 部長に報告した。J さんの報告内容を，次に示す。
L 氏が，検索サイトで金型技術情報を検索したところ，A 社と B 社が共同で展示会に出品する金型（以下，共同出品金型という）の設計情報ファイル（以下，ファイル S という）と同じ名称のファイルが，ある Web ページに掲載されていることを発見した。
ファイル S は，DVD-R に保存し，6 月 1 日に J さんから L 氏に手渡している。（以下，当該 DVD-R を DVDS という）
L 氏が，掲載されていた Web ページを確認したところ，ファイル S と同じ名称をもつファイルの更新日付は 6 月 4 日と表示されていた。
L 氏は，掲載されていたファイルがファイル S と同一であるかどうかの確認及び B 社における設計情報ファイルの管理状況の調査を，B 社のセキュリティ担当者に依頼した。
B 社のセキュリティ担当者は，同一ファイルであることを確認するためファイルの i を調べた。その結果，DVDS 中のファイル S の i と同じであったので，同一ファイルであることが確認された。
B 社では，全ての設計情報ファイルを，設計室の閉じたネットワークにだけ接続された PC 及びサーバで利用しており，インターネットに漏えいする可能性は低い。
B 社では，DVD-R などの外部記録媒体の持込み，持出し及び使用を管理している。管理記録によれば，DVDS に関する記録は，設計室内への持込み及び設計室内での使用だけであった。
L 氏は，A 社から漏えいした可能性があるとして，A 社に調査を求めてきた。
E 部長は事態を重くみて，ファイル S の漏えいについての調査，及び必要であればその対処，並びに A 社全体としての情報セキュリティ対策強化案の検討をシステム係の F さんに指示した。さらに，A 社の情報システムの導入及び運用を支援しているシステム会社と一緒に調査することにし，システム会社の G 氏が協力することになった。
F さん及び G 氏は，まず，情報漏えいの調査及び一時的な対処を実施し，その後に，A 社全体としての情報セキュリティ対策強化案を検討することにした。
〔情報漏えいの調査及び一時的な対処〕
F さんは G 氏の協力を受けて，FW，DMZ 上のサーバ及び内部システム LAN 上のサーバの調査を開始した。F さんと G 氏は，設計情報管理サーバからファイル S が取り出された可能性が高いと考え，設計情報管理サーバのアクセスログを調査した。その結果，ファイル S を作成するために J さんが設計情報管理サーバに登録した利用者 ID kyoudou@a-sha.co.jp（以下，ID-K という）による不審なアクセスが 6 月 1 日に発生していたことが判明した。設計情報管理サーバの 6 月 1 日のアクセスログのうち，利用者 ID が ID-K のものを表 6 に示す。
さらに，圧縮ファイル中のマルウェアが検知されなかったことについて，F さんは，平常時も圧縮ファイルをフルスキャンの対象とすべきかを G 氏に相談した。G 氏は，平常時の運用では，圧縮ファイルをフルスキャンの対象にしなくても DPC がマルウェアに感染するリスクは変わらないと答え，⑤その理由を F さんに説明した。F さんは，圧縮ファイルをフルスキャンの対象外とするという設定は変えないことにした。
営業秘密として不正競争防止法の保護を受けるための要件は，秘密管理性・有用性・非公知性の三つである。表 1 はそれぞれの管理規則を挙げている。一つ目の規則は，文書に A 社秘密情報と記載し，閲覧できる者を制限するもので，秘密として管理していることを明らかにする規則なので a は秘密管理である。二つ目は，事業に必要な金型加工技術の情報を営業秘密にするもので，事業活動に有用な情報であること，つまり b は有用である。三つ目は，刊行物に掲載して一般に知られる状態にしないもので，c は非公知である。
サーバのログに残るのは，接続元 IP アドレス，日時，利用者 ID，操作内容である（表 6）。ログの利用者 ID は“その ID でログインした”ことを示すだけで，操作した人物が ID の持ち主かどうかは分からない。ID-K は共同出品担当メンバ 3 名が共用しており，パスワードも初期パスワードのままだったので，メンバ以外がなりすましてログインしていてもログ上は区別できない。つまり，なりすましによるアクセスの場合，操作した人物とログに記録された利用者 ID の利用者は異なる，というのが理由である。
K さんの DPC には，運送会社を装った ZIP 形式の添付ファイル付きメールが届き，展開した PDF ファイルがマルウェア X だった。同じ内容のメールは他の従業員にも届いている可能性がある。ふだんのフルスキャンは圧縮ファイルが対象外なので，ZIP のまま保存されたマルウェア X は，最新の定義ファイルがあっても検知されない。F さんは，圧縮ファイルを対象に含めて最新の定義ファイル（マルウェア X 対応のものは 5 月 28 日にリリース済み）でフルスキャンさせ，マルウェア X を含む圧縮ファイルを保存している他の DPC がないか確認したのである。解答例は，“マルウェアXを含む圧縮ファイルを保存しているDPCの有無を確認するため”である。
圧縮ファイルの中のマルウェアは，展開しなければ実行されず，感染もしない。ZIP から取り出して展開したファイルは，ファイルを書き出すときに，リアルタイムスキャンによってマルウェアスキャンされる（図 3 の(2)では 6/5 に展開したとき，リアルタイムスキャンで PDF ファイルがマルウェア X として検知された）。したがって，圧縮ファイルをフルスキャンの対象にしなくても，展開してから使う限り感染のリスクは変わらない。解答例は“圧縮ファイルを展開すると，展開したファイルに対してリアルタイムスキャンが実行されるから”である。
このため，圧縮ファイルを対象外にして CPU の負荷を減らしている現在の設定を変えなくてよい，という F さんの判断になる。
接続元の IP アドレスによってアクセスを制限する。アクセスを許可する IP アドレスには，A 社で利用するプライベート IP アドレスを登録する。
〔A 社の情報システム〕
設計情報管理サーバの利用者は，設計部員及び製造部員である。
表 3
設計部 LAN：192.168.19.0/24。製造部 LAN：192.168.21.0/24。
設計情報管理サーバのアクセス制限機能は接続元 IP アドレスで制限するが，現状は A 社のプライベート IP アドレス全てが許可されている。このため，設計情報管理サーバの利用者でない営業拠点の拠点 LAN（192.168.64.0/24）にある K さんの DPC（192.168.64.3）からも，ID-K でのログインが成功してしまった（表 6 の項番 4〜9）。利用者は設計部員と製造部員だけなので，許可する IP アドレスを設計部 LAN（192.168.19.0/24）と製造部 LAN（192.168.21.0/24）だけに絞れば，拠点 LAN などからの接続を防げる。
採点講評は，A 社の内部システム LAN 上のサーバの機能と利用方法を理解した上で解答してほしかった，と述べている。表 5 の“A 社で利用するプライベート IP アドレスを登録する”という現在の設定が，利用者の範囲より広い，と読み取るのが要点である。
字数は 50 字以内で，解答例は 41 字である。“許可する IP アドレスを”“設計部 LAN 及び製造部 LAN だけ”“登録する”の三つを残す。“アクセス元を制限する”だけでは具体的な設定変更の内容になっていない。
