問1 CSIRT 構築とセキュリティ設計
CSIRT 構築とセキュリティ設計に関する次の記述を読んで，設問 1〜6 に答えよ。
A 社は，従業員数 3,000 名の独立系ソフトウェア開発会社である。受託開発業務が中心であるが，一部の部署で展開しているサービス事業が拡大傾向にある。
〔A 社の組織〕
A 社には，公共事業部，製造事業部，開発事業部，管理統括の四つの組織がある。公共事業部と製造事業部は，それぞれの業種の顧客システムの開発が事業の中心である。開発事業部には，公共及び製造以外の業種の顧客システムの開発を行う部署と，A 社独自のサービス事業を行う部署とがある。後者のうち，ソリューションサービス部（以下，SS 部という）は，国内の人材をデータベース化し，顧客企業に紹介する Web サービス（以下，高度人材サービスという）を提供している。管理統括は，人事部，総務部，情報システム部（以下，IT 部という）などで構成される。
A 社では，各事業部に事業部マネジメント（以下，事マネという）という組織があり，事業部の実務的な意思決定を行っている。A 社の組織図を図 1 に示す。
〔A 社のセキュリティポリシ〕
A 社のセキュリティポリシでは，セキュリティインシデント（以下，インシデントという）発生時の対応を図 2 のように定めているが，どのような事象がインシデントに該当するかは定義されていない。インシデントの報告を受け付けた際の，A 社 IRT の運用手順の概要を表 1 に示す。
〔A 社 IRT の現状〕
IT 部の部長を A 社 IRT 責任者とし，IT 部から選任した 2 名を A 社 IRT 担当者とする計 3 名が A 社 IRT のメンバであるが，3 名とも兼務である。A 社の従業員に対して，A 社 IRT の存在を積極的には周知しておらず，A 社 IRT に報告すべきインシデントの範囲についても明確には定義していない。
多くの従業員は，セキュリティポリシに規定された A 社 IRT の機能を知らなかった上に，社内 Web サイト上に，“マルウェア感染時の社内の連絡先”の表記があることから，A 社 IRT をマルウェア感染時の報告先だと認識していた。そのため，マルウェア感染以外のインシデントが事業部で発生した場合は，A 社 IRT ではなく事マネに報告していた。事マネは A 社 IRT にインシデントを報告せず，事業部内で対応や判断を行っていた。
〔インシデント発生〕
ある日，高度人材サービスの管理者である SS 部の P 主任が，見慣れないファイルが高度人材サービス用 Web サーバ上にあることを発見した。P 主任が，Web サーバのログを確認したところ，インターネットからサイバー攻撃を受け，攻撃者が不正に Web サーバにファイルをアップロードしていたことが分かった。しかし，攻撃者のその後のコマンドは全て失敗しており，実害はないと判断した。P 主任は，A 社 IRT の存在を知っていたので，電子メール（以下，メールという）で状況を報告した。A 社 IRT 担当者からの返事は数日を要した。P 主任は，その後も A 社 IRT 担当者と何度かメールでのやり取りを行ったが，他の業務の繁忙期であったので返信が滞り，さらに，A 社 IRT 担当者からのフォローもなかったので，本件はうやむやとなった。
その数か月後，総務部の担当者宛てに，A 社が出所と思われる，個人情報が含まれた名簿が出回っているとの問合せがあった。総務部の担当者が人事部に問い合わせたところ，数日後，“人事部が保有する情報ではない。どこかの事業部が作成した名簿ではないか”との回答があった。総務部の担当者は，その後も幾つかの部署に問い合わせてみたが，要領を得た回答が得られなかった。最終的には，IT 部に相談した際に A 社 IRT を紹介され，A 社 IRT に名簿を確認してもらうことになった。A 社 IRT 担当者は，名簿の内容から高度人材サービスに関するものと推測し，IT 部の業務の合間に P 主任にメールで問い合わせたところ，確かに高度人材サービス固有の情報を含む名簿であることが分かった。A 社 IRT 担当者が，P 主任と協力して調査を進めた結果，数か月前に高度人材サービスにサイバー攻撃があった時に，名簿情報が不正に持ち出された可能性があることが分かった。A 社 IRT 責任者は経営陣に状況を報告した。調査に時間を要したので，総務部の担当者が連絡を受けてから 2 か月が経過していた。経営陣は，漏えいした名簿に個人情報が含まれている各人に，おわびと，その時点までに確認された状況の説明を郵送でするよう指示を出した。
この事件はマスコミが大々的に採り上げ，A 社の情報セキュリティの組織的な取組みのまずさや情報公開の遅さが批判された。A 社の顧客や株主からの問合せは，経営陣の想定以上のものがあり，結果的に社長による謝罪会見にまで発展した。本業である受託ソフトウェア開発事業への影響も大きく，経営的にも極めて大きな打撃を受ける結果となった。経営陣は，A 社のインシデント対応には重大な問題があると考えた。
〔A 社 IRT の活動のアセスメントと改善〕
A 社の経営陣は，社外のセキュリティコンサルタント会社の T 社に，A 社のインシデント対応の現状のアセスメントを依頼し，問題点を洗い出してもらうことにした。T 社は，A 社内の様々な関係者へのヒアリングや，過去のインシデント対応の記録の調査，運用手順などのアセスメントを実施し，結果を報告書にまとめた。報告書には，A 社には多くの問題点が存在すること，及びその中で最も重要度が高い問題点は表 2 に示す A 社 IRT に関する問題点であることが明記されていた。
T 社は，現状の A 社 IRT の人員では，A 社 IRT の機能を適切に遂行することに無理があるので，A 社 IRT の人員を見直すよう経営陣に提言した。また，その他の問題点についてもそれぞれ改善策を提言した。
経営陣は，T 社の提言に従い，優先度が高い幾つかの改善策を実行することにした。最初に，A 社 IRT を IT 部から独立させて経営陣直属の組織とし，A 社 IRT 責任者には，経営陣の中から情報セキュリティに知見がある者を就任させた。また，①表 1 における対応指示は，A 社 IRT が直接行えるようにした。
次に，A 社 IRT 担当者には，情報セキュリティスペシャリスト資格をもつ，ベテランの U 課長と，その部下である Y さんを割り当て，専任とした。U 課長は，bの明確化や周知の改善などを行い，表 2 の問題点への対策を完了した。さらに，経営陣は，従業員の情報セキュリティの意識改革についても積極的に取り組み，A 社は，インシデント対応を適切に遂行できる組織となった。
〔A 社のネットワーク構成〕
A 社では，OA 用 PC，ネットワーク機器，サーバ，OS，ミドルウェア，アプリケーション（以下，情報機器という）を IT 部が管理している。また，それとは別に各部署が独自に管理する情報機器もある。ネットワークは，全て固定された IP アドレスで運用されている。各部署が独自にインターネット回線や情報機器を調達する際は，IT 部に届け出るルールになっている。その際，IT 部から，A 社に導入実績があるシステム構成を紹介されるケースが多いので，同一ベンダのサーバやミドルウェアが A 社では多く採用されている。A 社のネットワーク構成を図 3 に，情報機器の概要を表 3 に示す。
〔A 社のシステム運用〕
IT 部では，外部業者に委託している一部の運用保守を除き，DMZ やサーバ LAN のサーバなどの IT 部が管理している情報機器の運用保守は，IT 部の OA 用 PC から実施している。例えば，LDAP サーバの場合は，OA 用 PC から HTTP で管理画面にアクセスし，運用チームのメンバに付与された LDAP ID でログインした後，管理者昇格コマンドと管理者パスワードを入力すると，IT 部の運用チームだけに与えられている管理者権限が付与され，LDAP ID の追加，削除などを行うことができる。
IT 部以外の部署が管理する情報機器は，各部署のルールで管理しており，LDAP サーバとは連携していない。
〔マルウェア感染〕
A 社 IRT の再発足から半年たったある日，IT 部から A 社 IRT に，LDAP サーバのログに大量のサーバログイン失敗が記録されているとの報告が入った。システム障害の原因調査中に，偶然発見したものであった。U 課長が，運用手順に従って事実を確認したところ，サイバー攻撃の可能性が高いことが分かり，セキュリティ専門業者の R 社に調査を依頼した。
R 社が調査した結果，標的型攻撃メールを発端としたサイバー攻撃であることが確認された。この攻撃には，A 社で利用しているマルウェア対策ソフトでは検出できないマルウェアが使用されていた。図 4 は調査によって明らかになった攻撃の概要である。
A 社 IRT は，R 社からの報告を受け，K サーバへの通信の遮断に加え，マルウェアの駆除などの暫定処置を行った。A 社 IRT は社内外との連携も含め，運用手順どおりにインシデント対応を行った。
〔セキュリティ設計の見直し〕
経営陣は，今回の攻撃に対する A 社 IRT のインシデント対応には一定の評価を与えたが，A 社内のシステムのセキュリティ設計には改善すべき点が多いと考えた。そこで，以前，アセスメントを実施した T 社の提言に含まれていたものの，未対応であった“マルウェア感染を前提としたシステムのセキュリティ設計の見直し”を U 課長に指示した。U 課長から指示を受けた Y さんは，対策案を表 4 のようにまとめた。
Y さんは，各対策案について，IT 部やその他の関係する各部署と調整しながら検討を進めることにした。次は，Y さんが対策(1-1)を IT 部の H さんに説明した時の会話である。
- Y さん：運用管理セグメントの新設の検討をお願いします。運用管理セグメントとは，サーバ LAN 上のサーバを管理するために使用する PC（以下，運用管理 PC という）を設置するセグメントであり，SSH などの特定の管理用ポートを用いて，運用管理 PC からサーバ LAN の各サーバにアクセスします。利用者 LAN からサーバ LAN へのアクセスについては，管理用ポートへのアクセスを禁止し，他の PC から運用管理 PC へのアクセスも禁止します。
- H さん：現状でもサーバ LAN の各サーバの管理用ポートへのアクセスは，利用者 LAN の IT 部のセグメントからしか許可を与えておらず，実質的には，運用管理セグメントを新設することと同等のセキュリティが既に備わっているので，運用管理セグメントの設置は不要だと思います。
これを Y さんが U 課長に報告したところ，U 課長は，②運用管理セグメントを新設することによって，現状では防ぐことができない攻撃に対処できるようになることを Y さんに説明し，対策(1-1)の趣旨を IT 部に改めて正しく伝えるように指示した。
次は，対策(2-1)に関する Y さんと U 課長の会話である。
- Y さん：対策(2-1)についてですが，LDAP サーバにログインするための，パスワードに対するブルートフォース攻撃を検知するために，同一の LDAP ID による連続した認証失敗回数をカウントし，その回数が一定値を超過すると，アラートを発生させる仕組みを考えています。
- U 課長：今回の攻撃はブルートフォース攻撃であったが，次に攻撃を受けるときは，リバースブルートフォース攻撃を受けるかもしれない。リバースブルートフォース攻撃についても検知できる仕組みが必要だな。
- Y さん：ご指摘も踏まえ，更に検討を進めます。
Y さんはその後，連続した認証失敗回数をカウントして攻撃を検知する方法に加え，リバースブルートフォース攻撃も検知できるよう，A 社の LDAP サーバの運用管理を考慮した③新たな検知方法を考えた。
A 社 IRT は各部署との調整を進め，対策計画案を作成した。対策計画案は経営陣の承認の上，実行されることになった。
〔脆弱性情報ハンドリング〕
IT 部は，IT 部が管理する情報機器の脆弱性情報を，インターネット上にあるベンダの Web サイトや，脆弱性情報が記載された Web サイトなどから収集している。脆弱性修正プログラムは，重要度に応じて適宜適用している。一方，各部署が独自に管理する情報機器の脆弱性情報の収集や脆弱性修正プログラムの適用は，部署ごとに対応が異なっており，多忙なときは，漏れてしまったり，遅くなってしまったりするケースもある。
最近，A 社では，各部署が独自に管理する情報機器の脆弱性修正プログラムの適用漏れに起因するインシデントが増加傾向にあった。U 課長は，A 社 IRT が各部署の脆弱性管理を支援すること（以下，脆弱性情報ハンドリングという）によって，この状況を改善できると考えた。具体的には，次のようにする。
- SS 部独自 LAN など，部署独自 LAN の管理を各部署だけに任せるのではなく，A 社 IRT が，各部署の重要な脆弱性修正プログラムの適用状況を把握する。
- A 社が保有する情報機器の脆弱性情報を A 社 IRT が収集し，各部署に発信することによって，各部署が脆弱性情報を収集する負担を低減し，A 社全体で効率化する。
U 課長は，A 社 IRT に“脆弱性情報ハンドリング”機能をもたせるための，現状の課題は図 5 の 3 点であると分析した。
課題 1 については，短期的な対応は困難なので，当面はこれまでに各部署が作成した情報資産台帳を入手することにした。長期的には，各部署の構成管理情報を自動的に収集する仕組みを導入し，A 社 IRT が各部署の構成管理情報を把握することを目指す。
課題 2 については，長期的には A 社 IRT を増員することによって対応する。短期的には増員せず，④A 社の各部署の取組みと連携して対応することによって，工数の発生を最小限に抑える。
課題 3 については，汎用的で定量的な評価手法を用いた共通脆弱性評価システムのバージョン 3（以下，CVSS という）を参考にする。CVSS は，三つの基準で脆弱性を評価する手法である。一つ目は“基本評価基準”であり，機密性などのセキュリティの特性や，ネットワークから攻撃が可能かといった攻撃元の特性からスコアを算出する。この基準は，時間の経過や環境の違いによるスコアの変化はない。どこから攻撃可能であるかを評価する攻撃元区分を表 5 に示す。
二つ目は“現状評価基準”であり，攻撃コードの出現有無や対策情報が利用可能であるかどうかを基にした評価基準である。ベンダなどの脆弱性への対策状況に応じ，時間の経過によって変化し，脆弱性を公表する組織が，脆弱性の現状を表すために評価する基準である。
三つ目は“環境評価基準”であり，ネットワーク環境やセキュリティ対策状況を含め，攻撃元区分の再評価などによって，組織にとっての最終的な脆弱性の深刻度を評価する基準である。
基本評価基準のスコアは脆弱性ごとに定まるが，環境評価基準は脆弱性が存在する情報機器ごとにスコアが異なる。例えば，図 3 の FW1 と FW2 に関する，ある脆弱性が公表された場合，この脆弱性の基本評価基準のスコアに対して，評価時点の現状評価基準のスコアを算出し，最後に，環境評価基準として，FW1 と FW2 のそれぞれで最終的な深刻度のスコアを算出する。U 課長は実際に，FW1 と FW2 に存在する，ある脆弱性の深刻度を算出してみた。この脆弱性は，FW のポリシ更新のコマンド発行において，特定のパラメタを組み合わせると管理者権限がなくても不正にポリシを更新できるというものである。環境評価基準において，FW1 の攻撃元区分は c であり，FW2 の攻撃元区分は d であることから，e のスコアがより高い値を示した。
A 社 IRT が各部署に発信する脆弱性情報について，該当する情報機器を保有していた場合には，各部署で深刻度を算出してもらい，一定値を超えた場合は，A 社 IRT に脆弱性の対応計画を提出する仕組みにする。
U 課長の脆弱性情報ハンドリングに関する提案は，A 社 IRT 責任者及び経営陣によって承認され，A 社 IRT は，A 社全体の情報セキュリティを担う，より高度な組織となった。
出題趣旨（IPA）
近年，公共機関，金融機関を中心にCSIRTを設立する組織が急増している。インシデントハンドリングは，CSIRTの主要な機能の一つと言える。多くの組織では，CSIRTを設立する以前から，情報システム部門などがインシデントハンドリングに類する活動を行っているが，組織内の役割や権限などが不明確であるため，有効に機能していないケースも散見される。そのような組織では，CSIRT設立時に，既存のインシデントハンドリングのどのような点を改善するのかを明確にすることが重要である。本問は，CSIRTの構築とセキュリティ設計を題材に，インシデントハンドリングの問題点を検出して改善する能力，及び脆弱性情報に関する評価能力を問う。
採点講評（問全体・IPA）
問1では，CSIRT構築とセキュリティ設計について出題した。
設問と解答例
表 1 中の a に入れる，A 社 IRT が決定すべきことを，10 字以内で答えよ。
〔a〕解答例
- 対応の要否
解説
本文の根拠
表1 番号2 トリアージ
A 社 IRT は，受け付けた内容の事実確認を行った上で，あらかじめ定めた基準に従い，重要度や優先度を考慮して，aを判断する。
表1 番号2 次の手順の番号
aに応じて，番号 3 又は番号 6 に進む。
表1 番号6 完了
A 社 IRT は，当該インシデントに関する記録を整理し，対応を完了する。
トリアージは，受け付けた報告を重要度や優先度で振り分ける手順である。表 1 では，a の判断結果によって番号 3（調査依頼検討）へ進むか，番号 6（完了）へ飛ぶかが分かれる。番号 3〜5 は調査・状況報告・対応指示という“対応”の手順なので，a はインシデントに対応する必要があるかどうか，すなわち“対応の要否”である。
本文の〔インシデント発生〕では，P 主任の報告が“実害はない”として扱われ，そのままうやむやになった。対応が要るのか要らないのかを A 社 IRT が基準に従って決めていれば，番号 3 以降に進めて調査できた場面である。
字数は 10 字以内で，解答例は 5 字である。“対応するかしないか”のように同じ意味の言い方でもよいが，番号 3 と番号 6 のどちらに進むかを決める二択の判断であることが伝わる語にする。“重要度”や“優先度”は判断の材料として作業内容に書かれているので，a に入れる語ではない。
表 2 中及び本文中の b に入れる適切な字句を，〔A 社 IRT の現状〕の内容を踏まえ，20 字以内で答えよ。
〔b〕解答例
- 報告すべきインシデントの範囲
解説
本文の根拠
〔A社IRTの現状〕
A 社の従業員に対して，A 社 IRT の存在を積極的には周知しておらず，A 社 IRT に報告すべきインシデントの範囲についても明確には定義していない。
〔A社のセキュリティポリシ〕
どのような事象がインシデントに該当するかは定義されていない。
表2 （省略）
bが不明確である。
〔A 社 IRT の現状〕には問題が二つ書かれている。A 社 IRT の存在を積極的に周知していないことと，A 社 IRT に報告すべきインシデントの範囲を明確に定義していないことである。前者は表 2 の“周知”の行が受け持っているので，残る“（省略）”の行の b は後者の“報告すべきインシデントの範囲”である。
この不明確さのために，従業員は A 社 IRT をマルウェア感染時の報告先だと思い込み，それ以外のインシデントは事マネに報告していた。U 課長が“b の明確化や周知の改善”を行ったという本文とも，b が範囲の定義であれば話がつながる。
字数は 20 字以内で，解答例は 14 字である。“報告すべき”と“範囲”の両方を残す。“インシデントの定義”だけでは，A 社 IRT に何を報告するのかという点が抜けてしまう。
本文中の下線①について，この改善策の目的は何か。40 字以内で述べよ。
解答例
- インシデントがA社全体に与える影響度に基づいた対応を指示するため
解説
本文の根拠
表2 対応指示手順
表 1 の運用手順における“対応指示”手順と異なり，現状はインシデントを発見した事業部が独自に影響度を判断し，事業部の都合を優先させた対応を行っている。
表1 番号5 対応指示
A 社 IRT は，あらかじめ定めた基準に従い，インシデントの全社への影響度に基づいて，インシデントの対応内容を決定し，必要な対応指示を行う。
〔A社IRTの活動のアセスメントと改善〕
また，①表 1 における対応指示は，A 社 IRT が直接行えるようにした。
表 2 の“対応指示手順”の問題点は，インシデントを発見した事業部が独自に影響度を判断し，事業部の都合を優先した対応をしていたことである。表 1 の対応指示は，本来“全社への影響度に基づいて”A 社 IRT が対応内容を決める手順である。下線①で A 社 IRT が直接指示できるようにしたのは，事業部の都合ではなく全社の影響度で対応を決めるためである。解答例は“インシデントがA社全体に与える影響度に基づいた対応を指示するため”である。
〔インシデント発生〕の名簿の件では，事業部の判断で対応がうやむやになり，A 社全体が謝罪会見や受託事業への打撃を受けた。A 社 IRT は経営陣直属になったので，事業部に対して直接指示を出せる立場にもなっている。
字数は 40 字以内で，解答例は 32 字である。“A 社全体（全社）の影響度”という判断の基準と，“対応を指示する”という目的の両方を残す。“迅速に対応するため”だけでは，表 2 の問題点（事業部の都合を優先）を直すことにならない。
本文中の下線②について，どのような攻撃に対処できるようになるか。攻撃のシナリオを 70 字以内で具体的に述べよ。
解答例
- IT部のOA用PCに攻撃メールが送信され，PCがマルウェアに感染し，起動したマルウェアがサーバLANに不正アクセスする攻撃
解説
本文の根拠
〔セキュリティ設計の見直し〕 Hさん
現状でもサーバ LAN の各サーバの管理用ポートへのアクセスは，利用者 LAN の IT 部のセグメントからしか許可を与えておらず，
〔セキュリティ設計の見直し〕 Yさん
利用者 LAN からサーバ LAN へのアクセスについては，管理用ポートへのアクセスを禁止し，他の PC から運用管理 PC へのアクセスも禁止します。
〔A社のシステム運用〕
DMZ やサーバ LAN のサーバなどの IT 部が管理している情報機器の運用保守は，IT 部の OA 用 PC から実施している。
表3 OA用PC
各従業員に 1 台ずつ貸与され，資料作成，Web 閲覧，メール送受信などに利用される。
現状では，サーバの管理用ポートに IT 部のセグメントからアクセスでき，運用保守は IT 部の OA 用 PC から行っている。OA 用 PC はメール送受信や Web 閲覧にも使うので，今回の Z 主任と同じように標的型攻撃メールでマルウェアに感染するおそれがある。IT 部の OA 用 PC が感染すれば，マルウェアは許可された経路のまま管理用ポートにアクセスでき，現状の制限では止められない。運用管理セグメントを設けて管理用ポートへのアクセスを運用管理 PC だけに絞り，利用者 LAN（IT 部を含む）からの管理用ポートへのアクセスを禁止すれば，この攻撃を防げる。解答例は“IT部のOA用PCに攻撃メールが送信され，PCがマルウェアに感染し，起動したマルウェアがサーバLANに不正アクセスする攻撃”である。
H さんは“IT 部のセグメントからしか許可していない”ので同等だと考えたが，制限の単位がセグメントで，その中の PC がメールや Web 閲覧に使われていることが抜けている。Y さんの案は，運用管理 PC へのアクセスを他の PC から禁止しており，感染した OA 用 PC を踏み台にされることも防いでいる。
字数は 70 字以内で，解答例は 61 字である。講評は，シナリオがあいまいなまま“OA 用 PC が感染する”だけを書いた解答や，新設しても防げない攻撃の解答が多かったと指摘している。“IT 部の OA 用 PC”が感染の起点になること，感染の経路（攻撃メール），マルウェアが“サーバ LAN に不正アクセスする”ことを，この順に書く。
採点講評（IPA）
設問3は，正答率が低かった。(1)は，運用管理セグメントを新設すれば防げるが，現状の構成では防げない具体的な攻撃のシナリオを問うたが，攻撃のシナリオが不明確なままOA用PCがマルウェアに感染するという状況だけを説明した解答や，運用管理セグメントを新設しても防げない攻撃のシナリオについての解答が散見された。(2)は，リバースブルートフォース攻撃の検知方法を問うたが，A社のLDAPサーバの運用管理への考慮がない解答や，単にリバースブルートフォース攻撃を説明した解答が散見された。
本文中の下線③について，どのような検知方法か。40 字以内で具体的に述べよ。
解答例
- IT部運用チームのメンバのLDAP ID以外によるログイン要求の検知
解説
本文の根拠
〔セキュリティ設計の見直し〕 Yさん
同一の LDAP ID による連続した認証失敗回数をカウントし，その回数が一定値を超過すると，アラートを発生させる仕組みを考えています。
表3 LDAPサーバ
HTTP でアクセスできる管理画面があり，運用チーム 4 名の LDAP ID でだけログインできる。
〔セキュリティ設計の見直し〕
A 社の LDAP サーバの運用管理を考慮した③新たな検知方法を考えた。
リバースブルートフォース攻撃は，パスワードを一つに固定し，ID のほうを次々に変えてログインを試す攻撃である。ID ごとの失敗は 1 回ずつにしかならないので，Y さんの“同一の LDAP ID による連続した認証失敗回数”を数える方法では検知できない。そこで LDAP サーバの運用管理に目を向けると，管理画面にログインできるのは運用チーム 4 名の LDAP ID だけである。それ以外の LDAP ID で管理画面にログインしようとする要求は，正規の利用ではあり得ないので，攻撃の兆候として検知できる。解答例は“IT部運用チームのメンバのLDAP ID以外によるログイン要求の検知”である。
図 4 でも，攻撃者は複数の LDAP ID の認証情報で管理画面へのログインを試みて失敗している。この方法なら，ID を変えながら試すたびに検知できる。
字数は 40 字以内で，解答例は 34 字である。講評は，LDAP サーバの運用管理への考慮がない解答や，攻撃そのものを説明しただけの解答が多かったと指摘している。“運用チームのメンバ以外の LDAP ID”という条件と，それが“管理画面へのログイン要求”であることを残す。
採点講評（IPA）
設問3は，正答率が低かった。(1)は，運用管理セグメントを新設すれば防げるが，現状の構成では防げない具体的な攻撃のシナリオを問うたが，攻撃のシナリオが不明確なままOA用PCがマルウェアに感染するという状況だけを説明した解答や，運用管理セグメントを新設しても防げない攻撃のシナリオについての解答が散見された。(2)は，リバースブルートフォース攻撃の検知方法を問うたが，A社のLDAPサーバの運用管理への考慮がない解答や，単にリバースブルートフォース攻撃を説明した解答が散見された。
A 社 IRT の脆弱性情報ハンドリングにおいて，各部署の情報機器の現状が示された構成管理情報を活用することによる効果を，35 字以内で述べよ。
解答例
- A社IRTが収集すべき脆弱性情報を把握するため
解説
本文の根拠
図5 課題1
情報機器の現状の構成情報を正しく把握していない部署がある。
〔脆弱性情報ハンドリング〕
A 社が保有する情報機器の脆弱性情報を A 社 IRT が収集し，各部署に発信することによって，各部署が脆弱性情報を収集する負担を低減し，A 社全体で効率化する。
〔脆弱性情報ハンドリング〕
長期的には，各部署の構成管理情報を自動的に収集する仕組みを導入し，A 社 IRT が各部署の構成管理情報を把握することを目指す。
脆弱性情報ハンドリングでは，A 社 IRT が“A 社が保有する情報機器の脆弱性情報”を収集して各部署に発信する。そのためには，A 社のどこにどの製品・バージョンの情報機器があるかが分かっていなければならない。構成管理情報を使えば，A 社 IRT が集めるべき脆弱性情報の対象が分かる。解答例は“A社IRTが収集すべき脆弱性情報を把握するため”である。
課題 1 のとおり構成情報を正しく把握していない部署があると，その部署の機器に関する脆弱性情報を集め損ね，修正プログラムの適用漏れにつながる。最近増えていたのは，まさにこの適用漏れに起因するインシデントだった。
字数は 35 字以内で，解答例は 23 字である。“収集すべき脆弱性情報（の対象）が分かる”ことを中心に書く。“情報機器を把握できる”だけでは，脆弱性情報ハンドリングにとっての効果になっていない。
A 社 IRT が各部署の構成管理情報を把握しておくと，インシデントハンドリングにおいても有効に活用することができる。どのように活用できるか。45 字以内で具体的に述べよ。
解答例
- A社IRTが，各部署のインシデント発生時や対策時の，影響範囲の特定に活用する。
解説
本文の根拠
図2 インシデントハンドリング
A 社 IRT はインシデント報告を受け付けると，情報セキュリティの専門的な知見を基に，定められた運用手順に従って活動し，該当する部署又は事マネに対して対応の指示を行う。
表1 番号5 対応指示
インシデントの全社への影響度に基づいて，インシデントの対応内容を決定し，
〔脆弱性情報ハンドリング〕
長期的には，各部署の構成管理情報を自動的に収集する仕組みを導入し，A 社 IRT が各部署の構成管理情報を把握することを目指す。
インシデントハンドリングでは，A 社 IRT が全社への影響度に基づいて対応内容を決め，該当する部署に指示を出す。あるインシデントの原因となった機器や脆弱性が分かったとき，同じ製品・構成の機器がどの部署にあるかが分かれば，影響が及ぶ範囲をすぐに特定できる。解答例は“A社IRTが，各部署のインシデント発生時や対策時の，影響範囲の特定に活用する。”である。
〔インシデント発生〕の名簿の件では，どの部署の情報かを突き止めるのに時間が掛かった。また本文のとおり，A 社では同一ベンダのサーバやミドルウェアが多く採用されているので，一つの部署で見つかった問題が他部署にも及ぶ可能性が高い。
字数は 45 字以内で，解答例は 39 字である。“影響範囲の特定”を中心に，“インシデント発生時や対策時”という使う場面を添える。
図 5 中の課題 2 について，本文中の下線④の各部署の取組みとどのように連携して対応すべきか。連携方法を 30 字以内で述べよ。
解答例
- 各部署が収集している脆弱性情報の提供を受ける。
解説
本文の根拠
図5 課題2
情報機器の脆弱性情報を，ベンダの Web サイトや，脆弱性情報が記載された Web サイトから収集するには多くの工数が必要だが，現状の要員では対応ができない。
〔脆弱性情報ハンドリング〕
IT 部は，IT 部が管理する情報機器の脆弱性情報を，インターネット上にあるベンダの Web サイトや，脆弱性情報が記載された Web サイトなどから収集している。
〔脆弱性情報ハンドリング〕
短期的には増員せず，④A 社の各部署の取組みと連携して対応することによって，工数の発生を最小限に抑える。
課題 2 は，脆弱性情報を一から収集するには工数が掛かり，A 社 IRT の要員では足りないことである。ところが本文によると，IT 部は自部署の管理する情報機器の脆弱性情報をすでに収集しており，各部署も独自に管理する機器の脆弱性情報を（対応にばらつきはあるものの）集めている。これらの部署が収集している情報を A 社 IRT が提供してもらえば，新たな収集の工数を抑えられる。解答例は“各部署が収集している脆弱性情報の提供を受ける。”である。
A 社では同一ベンダの製品が多く採用されているので，ある部署が集めた情報は他部署にもそのまま役立つことが多い。集めた情報を A 社 IRT がまとめて各部署に発信すれば，本文の“A 社全体で効率化する”という狙いにも合う。
字数は 30 字以内で，解答例は 23 字である。“各部署が（すでに）収集している脆弱性情報”を“提供してもらう”という連携の向きを書く。
CVSS について，ゼロデイ攻撃が可能な脆弱性か否かは，どの評価基準に最も反映されるか。基準名を答えよ。
解答例
- 現状評価基準
解説
本文の根拠
〔脆弱性情報ハンドリング〕
二つ目は“現状評価基準”であり，攻撃コードの出現有無や対策情報が利用可能であるかどうかを基にした評価基準である。
〔脆弱性情報ハンドリング〕
この基準は，時間の経過や環境の違いによるスコアの変化はない。
ゼロデイ攻撃は，脆弱性の修正プログラムなどの対策がまだ提供されていない段階で行われる攻撃である。本文の説明では，現状評価基準は“攻撃コードの出現有無や対策情報が利用可能であるかどうか”を基にし，ベンダの対策状況に応じて時間とともに変化する。攻撃が可能か，対策があるかという状態を反映するのはこの基準なので，答えは“現状評価基準”である。
基本評価基準は脆弱性そのものの特性で決まり，時間の経過では変わらない。環境評価基準は利用者の組織のネットワーク環境や対策状況を反映するもので，対策がまだ無いかどうかは扱わない。
字数制限は無いが，本文に出てくる基準名“現状評価基準”をそのまま書く。基本評価基準と取り違えやすいので，“時間の経過で変わるかどうか”で見分ける。
採点講評（IPA）
設問6は，正答率が高かった。ファイアウォールに関する脆弱性をA社のケースについて評価する設問であったが，CVSSについてよく理解されているようであった。
本文中の c〜e に入れる適切な字句を答えよ。c，d は表 5 中の区分名から選び，e は“FW1”又は“FW2”のどちらかで答えよ。
〔c〕解答例
- ネットワーク
〔d〕解答例
- ローカル
〔e〕解答例
- FW1
解説
本文の根拠
表3 FW1
ポリシ変更の際は，IT 部が外部業者に指示を出し，外部業者の担当者が遠隔地からインターネットを経由し，SSH クライアントソフトを用いて更新作業を行っている。
表3 FW2
ポリシ変更は，FW2 のコンソールポートに常時接続された MPC からだけ許可されている。
表3 MPC
普段は OS の認証機能によってロックされており，SS 部の一部の担当者だけがロック解除できる。
〔脆弱性情報ハンドリング〕
この脆弱性は，FW のポリシ更新のコマンド発行において，特定のパラメタを組み合わせると管理者権限がなくても不正にポリシを更新できるというものである。
この脆弱性を突くには，FW にポリシ更新のコマンドを発行できなければならない。FW1 のポリシ更新は外部業者がインターネット経由の SSH で行っているので，インターネットから FW1 にコマンドを発行できる。表 5 の“ネットワーク経由でリモートから攻撃可能”に当たり，c は“ネットワーク”である。FW2 のポリシ更新はコンソールポートに常時接続された MPC からだけ許可されており，MPC にログインできなければコマンドを発行できない。表 5 の“ローカルアクセス権限での攻撃が必要”に当たり，d は“ローカル”である。攻撃できる範囲が広い FW1 のほうが深刻度は高くなり，e は“FW1”である。
二つは同一ベンダのアプライアンスなので，基本評価基準のスコアは同じである。違いが出るのは環境評価基準で，本文の“攻撃元区分の再評価”によって機器ごとの設置・運用の違いがスコアに反映される。講評は，この設問は正答率が高く，CVSS がよく理解されていたと述べている。
d を“物理”としないこと。MPC はコンソールポートに常時接続されているので，攻撃者は FW2 本体に物理的に触れなくても，MPC にログインできればコマンドを発行できる。
採点講評（IPA）
設問6は，正答率が高かった。ファイアウォールに関する脆弱性をA社のケースについて評価する設問であったが，CVSSについてよく理解されているようであった。
出典：平成28年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
