N 社は，従業員 800 名のドラッグストアチェーンである。グローバルに事業を展開する海外の企業 B 社のブランドライセンスを取得し，同ブランドの下，国内 80 店舗の展開，及び N 社 Web サイト（以下，通販サイトという）での通信販売を行っている。N 社は，消費者向けの会員制度を設けており，会員は商品購入時に特典を受けられる。N 社の組織図を図 1 に示す。
図1 N 社の組織図
N 社は，情報セキュリティ委員会を設置している。同委員会は，経営陣が委員となり，情報セキュリティについての基本方針（以下，基本方針という）及び重要な課題を取り扱う。セキュリティ対策は主にシステム部が担っており，セキュリティインシデント（以下，インシデントという）が発生した場合は，対応チームを立ち上げて対応する。基本方針では，消費者に影響を与えるインシデントの場合，社外に向けて速やかに情報開示することを挙げている。
B 社は，同社がブランドライセンスを提供する店舗運営会社を対象にしたインシデント対応ポリシ（以下，B 社インシデント対応ポリシという）を定めている。B 社インシデント対応ポリシは，インシデントによる B 社ブランドの毀損を最小限にすることを目的として策定された。
N 社は，B 社インシデント対応ポリシを順守する契約を B 社と締結しており，N 社でインシデントが発生した場合は，B 社のセキュリティ担当部署（以下，B 社セキュリティ部という）に報告し，指示に基づき対応する。分析対象となるログは，N 社のシステム部が取得し，インシデント発生時には B 社セキュリティ部に送信する。
通販サイトは，Z 社が提供するクラウドサービス（以下，Z サービスという）上に構築し，設計，開発及び運用を V 社に委託している。Z サービス上には開発用システムも構築している。また，各店舗の情報を一元管理し，運営を支援するためのシステム（以下，店舗管理システムという）を N 社に設置しており，設計，開発及び運用の一部を外部に委託している。N 社が利用するシステム及びネットワークの概要を図 2 に，開発用システムの概要を図 3 に，N 社の脆弱性管理プロセスを図 4 に示す。
図2 N 社が利用するシステム及びネットワークの概要図3 開発用システムの概要（抜粋）図4 N 社の脆弱性管理プロセス
〔インシデントの発生と対応〕
ある日，複数の会員から N 社のお客様相談室に，身に覚えのない商品購入を知らせる電子メールが届いたという連絡があった。N 社は，対応チームを立ち上げて調査した結果，通販サイトが不正アクセスを受けたと判断した。N 社は，直ちにこのインシデント（以下，インシデント P という）を B 社セキュリティ部に報告した。N 社と B 社セキュリティ部が協力して対応したが，問題が幾つか発生し，対応を終えるまでに 1 か月掛かった。
インシデント P について，判明した被害状況及び対応の概要を図 5 に示す。
図5 判明した被害状況及び対応の概要
〔インシデント対応方法の変更〕
インシデント P の対応が一段落した後，N 社の経営陣は，N 社で今後インシデントが起きた場合には，N 社の基本方針に従って対応する契約に変更したいと B 社に申し入れた。B 社は，この申入れに対し，次の条件を満たすことを前提として了承した。
条件 1：N 社は，ISO/IEC 27001 を利用して，自社の情報セキュリティ対策を評価し，その結果と対策案について B 社の了承を得る。
条件 2：N 社は，B 社の支援なしにインシデント対応を行う体制を整備し，その体制について B 社の了承を得る。
条件 3：N 社は，インシデント対応後，B 社に事後報告を行う。ただし，両社で別途定める基準によって，B 社ブランドを著しく毀損するインシデントと判断された場合は，直ちに B 社に報告し，対応を協議する。
N 社は，条件 1～3 を含め，包括的なインシデント対応体制を実現するプロジェクトを発足させた。システム部の G 部長を責任者に，システム部の H さんを担当者にそれぞれ任命するとともに，情報セキュリティ分野でコンサルティングサービスを展開する E 社に支援を依頼した。E 社のコンサルタントである情報処理安全確保支援士（登録セキスペ）の T 氏が N 社を支援することになった。
〔条件 1 への対応〕
条件 1 に対応すべく，H さんは，情報セキュリティ対策の評価を T 氏に依頼した。T 氏は，ISO/IEC 27001 附属書 A を基に評価し，指摘事項と対策案を表 1 のとおりに整理した。
図 9 は，FW2 において，AC-X が作成されてから発見されるまでの 4 日間，通信に成功した全てのパケットを対象とし，通信方向，接続元及び宛先の IP アドレス，サービスの組合せで通信量を集計し，降順に並べたものである。H さんは，⑤図 9 を基に，不正ログインを行ったと推測される接続元 IP アドレスを割り出した。
図9 FW2 での通信量の集計
H さんから調査結果について報告を受けた G 部長は，R1 サーバの隔離を指示した上で，インシデント Q は重大なインシデントの可能性があると判断し，PT を発足させた。PT は専門事業者の支援を受けて調査を行い，R1 サーバには，脆弱性 L 及び脆弱性 M が残っていることが判明した。脆弱性 L と脆弱性 M の概要，及びそれぞれの対応を見送った経緯とその理由を表 3 に，PT による調査結果を図 10 に示す。
表3 脆弱性 L と脆弱性 M の概要，及びそれぞれの対応を見送った経緯とその理由図10 PT による調査結果図10 PT による調査結果（続き）
この報告を受けた G 部長は，幸いにも被害が限定的であり，顧客への影響が全くないことから，インシデント Q について情報開示する必要はないと判断し，情報セキュリティ委員会に報告し承認を得た。
その後，G 部長は，利用者アカウントのパスワード変更，R1 サーバの復旧，脆弱性 L 及び脆弱性 M を解消する脆弱性修正プログラムの適用，⑨SSH 接続及び HTTP 接続を使った攻撃から開発用システムを保護するための措置などを指示した。
〔脆弱性管理プロセスの改善〕
インシデント P と比較してインシデント Q の対応は迅速に行われ，N-CSIRT のインシデント対応は有効であると，N 社の経営陣からも B 社からも一定の評価を得た。一方，インシデント Q で R1 サーバが不正にログインされたことを考えると，⑩図 4（イ）及び（ウ）において，悪用される可能性の評価についての観点の不足，又は影響の評価についての観点の不足があり，悪用される可能性又は影響を過小評価したのではないかという指摘があった。そのため，脆弱性管理プロセスを見直すことにした。
インシデント P の終息から 1 年後，表 1 の指摘事項及びインシデント Q で明らかになった課題は全て解決できた。N-CSIRT は，関係者の訓練を進め，更に迅速かつ効果的なインシデント対応が可能になった。
パスワードリスト攻撃が成功するのは，他のサービスで使っているものと同じ利用者 ID とパスワードの組みを，通販サイトでも使っているからである。OWASP も，多くの利用者が同じパスワードを再利用することを，この攻撃が成り立つ理由に挙げている。他のサービスから漏えいしたとしても，通販サイトで別のパスワードにしていれば，リストの組みではログインできない。
一つは，接続元 IP アドレスから分かる地理的位置を，過去のログインのものと比べる方法である。もう一つは，ログインに成功した端末の Web ブラウザに Cookie を保存しておき，次回以降のログインでその Cookie があれば過去にログインした端末，無ければ初めての端末と判定する方法である。解答例は二つ挙げており，どちらでも正解である。
“準備”，二つの欄 d と e を縦に並べた箱，“封じ込め”・欄 f・“復旧”を縦に並べた箱，“事後活動”の 4 つの箱がある。
NIST SP 800-61 Rev. 2 の図 3-1 は，インシデント対応のライフサイクルを，準備（Preparation），検知と分析（Detection & Analysis），封じ込め・根絶・復旧（Containment, Eradication & Recovery），事後活動（Post-Incident Activity）の四つの段階で示している。図 7 は，準備の次の箱が二つの欄 d・e をもつので“検知と分析”に当たり，d と e は検知（イ）と分析（カ）である。解答例では d と e は順不同で，どちらの欄にどちらを入れてもよい。
三つ目の箱は“封じ込め”と“復旧”の間に欄 f がある。原文の Containment, Eradication, and Recovery の真ん中，Eradication（原因の除去）に当たり，f は根絶（ウ）である。矢印が封じ込め・根絶・復旧から検知・分析へ戻るのは，対応の途中で新たな事実が分かると，分析をやり直すためである。
脆弱性 M を悪用すると，開発支援ツール J を実行している利用者アカウントの権限でコマンドが実行できる。そのアカウントは OS の一般利用者権限である。一方“/etc/shadow”は，ログインのための認証情報（ソルト値とハッシュ値など）を格納するファイルで，Linux の man（shadow(5)）にも，パスワードの安全のために一般利用者が読めない状態にしておかなければならない，とある。このファイルを読めるのは管理者権限である。
よって脆弱性 M だけでは，一般利用者権限で許された操作しかできず，“/etc/shadow”を参照できない。図 10(1) が“脆弱性 L と脆弱性 M を悪用して”参照したと書くのは，脆弱性 L（OS コマンド A で，一般利用者権限から管理者権限でプログラムを起動できる）と組み合わせて管理者権限を得たからである。
70 字以内なので，“脆弱性 M を悪用しても一般利用者権限の操作しかできない”と“/etc/shadow の閲覧には管理者権限が必要”の二点を書く。解答例は 61 字である。
設問4(3)45字以内
図 10 中の下線⑦について，攻撃者が行った設定変更の内容を，45 字以内で具体的に述べよ。
解答例
攻撃の接続元IPアドレスを“/etc/hosts.allow”ファイルに追加する。
解説
本文の根拠
図3 (3) R1 サーバへの接続制御
R1 サーバの“/etc/hosts.allow”ファイルの設定において，SSH 接続の接続元を N 社と V 社に限定している。このファイルの変更には，管理者権限が必要である。
図10 (2)
管理者権限で AC-X を作成した。
図10 (2)
R1 サーバをインターネット経由で操作するために設定を変更した。
R1 サーバは，SSH 接続の接続元を“/etc/hosts.allow”で N 社と V 社に限定している。攻撃者は，脆弱性 L・M の悪用で管理者権限を得て AC-X を作成したが，自分の接続元からも SSH で接続できなければ，AC-X でログインできない。そこで，このファイルに攻撃の接続元 IP アドレスを追加したと考えられる。変更に管理者権限が必要なファイルであり，管理者権限を得ていた点ともつながる。
両方の攻撃に効く一つの措置は，FW2 で接続元を制限することである。開発業務やテストで接続するのは N 社と V 社だけなので，インターネットからのインバウンド通信を，N 社と V 社からの通信だけに許可する。FW2 は R1 サーバの外にある機器なので，R1 サーバが乗っ取られて設定を書き換えられても，この制限は残る。
75 字以内なので，“どの機器で（FW2）”“何を（インバウンド通信）”“どうするか（N 社と V 社からの通信だけを許可）”の三つを書く。解答例は 45 字である。
図 4 の（イ）は悪用される可能性の評価，（ウ）は悪用されたときの影響の評価である。表 3 では，脆弱性 L は SSH ログインが必要なので悪用される可能性が低いと，脆弱性 M は一般利用者権限で動作するので影響が小さいと評価され，どちらも対応が見送られた。しかし実際には，L と M が組み合わされ，“/etc/shadow”が参照された（図 10(1)）。それぞれを単独で評価したことが，過小評価につながった。
CEO は，顧客満足度と従業員満足度の向上を目指して，次期 IT に関して次のような方針を示している。
次期 IT の方針 1：サービスを更に向上させるために積極的に IT を活用する。特に SaaS を活用する。
次期 IT の方針 2：働き方改革及びパンデミック対策の観点から，テレワーク環境を整備する。
C 社では，経営管理部内の総務グループ（以下，総務 G という）の 5 名が情報システムの管理を担当している。
C 社の現在の情報システム概要は，図 1 のとおりである。
図1 C 社の現在の情報システム概要
UTM は，ステートフルパケットインスペクション型ファイアウォールに複数のセキュリティ機能を統合したものである。DHCP サーバの機能も備えており，AP に接続する機器に 192.168.1.20～192.168.1.240 の範囲の IP アドレスを配布している。
C 社内 LAN のネットワークセグメントは一つだけである。有線で L2SW に接続している機器には固定の IP アドレスを割り当てている。無線 LAN は WPA2 パーソナルで運用しており，SSID 及び事前共有鍵を従業員に開示している。
C 社は，従業員に 1 人 1 台の C-PC を貸与している。OS のドメインコントローラは導入しておらず，従業員は貸与された C-PC にローカルログインする。C-PC は AP に接続し，インターネットへのアクセスが可能である。事業部及び企画部では，顧客への提案や企画の立案時にインターネット上にある多くの情報を収集，取捨選択，加工することによって付加価値を生み出すことが不可欠であると認識している。その他の部門では，取引先などの企業情報検索と出張先への経路の検索にインターネットを利用している。
PC，スマートフォンなどの個人所有の機器（以下，個人所有機器という）の C 社内 LAN への接続は統制しておらず，多くの従業員は，個人所有機器を AP に接続して使用している。また，業務で新たに SaaS を利用する際，会社で統一された承認ルールはなく，各部の判断で SaaS の利用契約を締結している。
〔一つ目のトラブル〕
新入社員が配属されたある日，C-PC で障害が発生しているという連絡が総務 G に入った。総務 G の A さんが調査したところ，次のような状況であった。
朝の時点では，C-PC や個人所有機器の利用について特に異常を感じた従業員はいなかった。
営業部の U さんが 13 時に出張から戻り C-PC を起動したところ，C-PC へのローカルログインはできたが，業務サーバにアクセスできず，メールの送受信もインターネット上の Web サイトの閲覧もできなかった。
A さんは，障害が発生していた C-PC のネットワーク設定を調べたところ，①上位 2 オクテットが 169.254 に設定された IP アドレスで動作していることに気付いた。C 社は雑居ビルの中にあって誰でも C 社オフィスに近づくことが可能なので，偽の DHCP サーバが立ち上げられたなど，何らかのサイバー攻撃を受けているのではないかと心配になり，経営管理部の E 部長に報告した。E 部長は，専門家の助言が必要と考え，C 社内 LAN の構築で支援を受けた D 社に依頼した。
D 社のセキュリティコンサルタントである情報処理安全確保支援士（登録セキスペ）の K さんは，A さんから説明を受け，次のようにコメントした。
コメント 1：障害が発生した C-PC の IP アドレスは，DHCP サーバが正常に動作していない場合にしばしば確認される。偽の DHCP サーバの設置ではなく，②C 社内 LAN での個人所有機器の利用が原因で問題が引き起こされた結果である。個人所有機器の利用が原因であれば，DHCP サーバの設定変更で当面の障害に対処し，C 社内での個人所有機器の利用を見直していくのがよい。
状況 1：企画部の部員がサービス R に開設したチャットエリアにおいて，模造サングラス販売の不正サイトに誘導するチャットが，部員の V さんのアカウントから連続して書き込まれた。V さん本人は，身に覚えがないとのことだった。
状況 2：企画部では，以前からサービス W という SNS を使って公開情報を発信している。V さんを含む部員の数名は，会社のメールアドレスをサービス R とサービス W の利用者 ID として登録し，両方のサービスで同じパスワードを設定していた。サービス W では，パスワード漏えいの事故があり，企画部の部員は全員がサービス W のパスワードを変更したが，誰もサービス R のパスワードは変更しなかった。
状況 3：外部の何者かがサービス R 内の情報に不正にアクセスし情報を持ち出していないかを調査するため，サービス R の提供会社にアクセスログを提供してもらえないかと問い合わせたが，無料のサービスについては提供できないという回答だった。
状況 1～3 から，A さんは，サービス R のアカウントが乗っ取られている可能性が高いので全員のパスワードをすぐに変更すべきであることと，サービス R でどのような情報にアクセスされたかはログが入手できないので調査が困難であることを E 部長に報告した。E 部長は，状況 3 について，仮に情報漏えいがあった場合，最大でどの程度の被害となり得るかを判断するために，④アクセスログの調査以外に実施できる調査を指示した。A さんは，総務 G のほかの部員にも協力を仰ぎ，指示された調査を実施して結果をまとめた。
E 部長は，調査の結果を確認し，今回は大きな被害はなかったと判断したが，情報セキュリティ対策の強化が急務であると感じた。そこで，業務における個人所有機器及び SaaS の利用を統制すべきと CEO に提言した。CEO は，統制の必要性に合意したが，一方で，過剰に統制すると従業員のビジネスマインドを阻害しかねないので，統制レベルを慎重に検討するよう指示した。
〔次期 IT のセキュリティ要件〕
E 部長は，トラブル 1 及びトラブル 2 の再発防止策，並びに次期 IT の方針を踏まえて，統制の実現に向けた次期 IT のセキュリティ要件を表 1 のように整理した。
表1 次期 IT のセキュリティ要件
〔要件 1 の検討〕
AP への接続方式を WPA2 エンタープライズにし，AP への接続時に IEEE 802.1X（以下，802.1X という）でのディジタル証明書による認証を行う。
802.1X のシーケンスを図 2 に示す。
図2 802.1X のシーケンス（概要）
図 2 中のサプリカントには図 1 中の a が，図 2 中の認証装置には図 1 中の b が該当する。C-PC の IP アドレスは，図 2 中の c ，DHCP サーバから割り当てられる。
C 社の各部と議論を重ねた結果，幾つかの SaaS を総務 G で契約し，管理して提供すれば，ほとんどの業務が行えることが分かった。これらの SaaS は全て SAML 認証に対応しており，サービス Q と連携できることも確認できた。また，ディジタル証明書だけで認証することもでき，従業員がパスワードを管理する負担の軽減につながるので，サービス Q を採用することにした。
C 社オフィス外での業務については，モバイル PC を追加で購入し，モバイル PC を持ち出し用の C-PC（以下，持出 C-PC という）として貸与することにした。
〔要件 4 及び 5 の検討〕
要件 4 を満たすためには，総務 G が契約した SaaS へのアクセスについてサービス Q での認証を必須にするだけでなく，総務 G が契約していない SaaS やインターネット上の様々な Web サイトへのアクセスも制御する必要がある。しかし，総務 G が契約した SaaS，企業情報検索，出張先への経路検索及び C 社の情報システムへのアクセスだけを許可し，それ以外へのアクセスを全て遮断すると，⑤支障が出る業務がある。
調査を更に進めた結果，要件 4 及び 5 の実現に利用できそうなサービスがあることが分かった。機器からインターネットへの通信を中継するプロキシ型のクラウドサービスである。その一つにサービス N がある。サービス N を利用するには，機器からインターネットへの通信を全てサービス N 経由で行うなどの制御を行う端末制御エージェントソフトウェア（以下，P ソフトという）を機器に導入する必要がある。管理者は，P ソフトを，一般利用者権限では動作の停止やアンインストールができないように設定することができる。
サービス N の機能を表 3 に示す。
表3 サービス N の機能（抜粋）
要件 4 及び 5 は，サービス Q とサービス N を組み合わせて実現する。サービス Q とサービス N を利用した場合の動作の概要を図 3 に示す。
図3 サービス Q とサービス N を利用した場合の動作の概要
図 3 において，⑥総務 G が管理していない機器からのサービス要求があった場合は，シーケンスが途中で遮断される。
調査の結果，サービス Q とサービス N を利用することで要件 4 及び 5 を実現できると判断し，サービス N を採用することにした。
乗っ取られたのは V さんを含む企画部のアカウントで，書き込みがあったのは企画部の部員がアクセスできるチャットエリアである。そこで，このチャットエリアで共有されている情報を調べれば，最大の被害を判断できる。アクセスログが“実際にアクセスされたもの”を調べるのに対し，これは“アクセスされ得たもの”を調べる点が違う。
許可するのは，総務 G が契約した SaaS，企業情報検索，出張先への経路検索，C 社の情報システムの四つである。これ以外を全て遮断すると支障が出るのは，この四つに含まれない，インターネット上の様々な Web サイトを使う業務である。本文で，そのような使い方を不可欠と認識しているのは，事業部と企画部である。他の部門は，企業情報検索と経路検索にインターネットを使うだけで，許可の範囲に収まる。
業務で利用する SaaS は，総務 G が契約した SaaS だけに制限する。また，業務に不要な Web サイトへのアクセスを制限する。
表3 番号2
サービス N が中継する際に，アクセス可能な URL を制限する。
要件 4 は，業務で使う SaaS を総務 G が契約したものに限り，業務に不要な Web サイトへのアクセスも制限することである。アクセスしてよい URL を絞るのは，表 3 の番号 2 の URL フィルタリング機能である。ベンダが分類した URL のリストから管理者が選び，追加や削除もできるので，SaaS と不要な Web サイトの制限を設定できる。
よって 2 である。
間違えやすい点：番号 1 の利用者 ID によるフィルタリングは，SaaS へのログインに使う ID を制限するもので，要件 5 に対応する。番号 3 は通信の監視とログの提供，番号 4 は保管ファイルの暗号化で，アクセスを制限する機能ではない。
設問4(3)
要件 5 は，表 3 中のどの機能で実現できるか。表 3 中の番号で一つ答えよ。
解答例
1
解説
本文の根拠
表1 要件5
総務 G が契約した SaaS には，総務 G が管理するアカウントでアクセスする。C-PC からは，従業員が個人で管理するアカウントでのアクセスができないようにする。
表3 番号1
P ソフトで，SaaS へのログイン時に，許可された利用者 ID の場合だけ通信を許可し，その他の利用者 ID の場合は通信を遮断する。
要件 5 は，総務 G が管理するアカウントだけでアクセスでき，従業員が個人で管理するアカウント（サービス R のような無料の SaaS の個人アカウントなど）ではアクセスできないようにすることである。SaaS へのログイン時に，許可された利用者 ID の場合だけ通信を許可し，その他の ID は遮断するのが，表 3 の番号 1 の利用者 ID によるフィルタリング機能である。許可する利用者 ID は，管理者が SaaS ごとに設定できる。
機器からインターネットへの通信を全てサービス N 経由で行うなどの制御を行う端末制御エージェントソフトウェア（以下，P ソフトという）を機器に導入する必要がある。
要件 4 と 5 は，サービス Q とサービス N を組み合わせて実現する。サービス N のフィルタリングは，機器に導入した P ソフトが通信を全てサービス N 経由にすることで成り立つ。従業員が P ソフトを停止したりアンインストールしたりできると，サービス N を経由しないアクセスができ，要件 4 と 5 の制限が回避される。
そこで，管理者が P ソフトを，一般利用者権限では変更（動作の停止やアンインストール）できないように設定する。本文が，従業員には一般利用者権限だけを与えると述べているので，この設定で従業員は変更できなくなる。
