情報処理安全確保支援士 2021年 春期 午後2 問01
インシデント対応体制の整備に関する次の記述を読んで、設問1~5に答えよ。
N社は、従業員800名のドラッグストアチェーンである。グローバルに事業を展開する海外の企業B社のブランドライセンスを取得し、同ブランドの下、国内80店舗の展開、及びN社Webサイト(以下、通販サイトという)での通信販売を行っている。N社は、消費者向けの会員制度を設けており、会員は商品購入時に特典を受けられる。N社の組織図を図1に示す。

N社は、情報セキュリティ委員会を設置している。同委員会は、経営陣が委員となり、情報セキュリティについての基本方針(以下、基本方針という)及び重要な課題を取り扱う。セキュリティ対策は主にシステム部が担っており、セキュリティインシデント(以下、インシデントという)が発生した場合は、対応チームを立ち上げて対応する。基本方針では、消費者に影響を与えるインシデントの場合、社外に向けて速やかに情報開示することを挙げている。
B社は、同社がブランドライセンスを提供する店舗運営会社を対象にしたインシデント対応ポリシ(以下、B社インシデント対応ポリシという)を定めている。B社インシデント対応ポリシは、インシデントによるB社ブランドの毀損を最小限にすることを目的として策定された。
N社は、B社インシデント対応ポリシを順守する契約をB社と締結しており、N社でインシデントが発生した場合は、B社のセキュリティ担当部署(以下、B社セキュリティ部という)に報告し、指示に基づき対応する。分析対象となるログは、N社のシステム部が取得し、インシデント発生時にはB社セキュリティ部に送信する。
通販サイトは、Z社が提供するクラウドサービス(以下、Zサービスという)上に構築し、設計、開発及び運用をV社に委託している。Zサービス上には開発用システムも構築している。また、各店舗の情報を一元管理し、運営を支援するためのシステム(以下、店舗管理システムという)をN社に設置しており、設計、開発及び運用の一部を外部に委託している。N社が利用するシステム及びネットワークの概要を図2に、開発用システムの概要を図3に、N社の脆弱性管理プロセスを図4に示す。



〔インシデントの発生と対応〕
ある日、複数の会員からN社のお客様相談室に、身に覚えのない商品購入を知らせる電子メールが届いたという連絡があった。N社は、対応チームを立ち上げて調査した結果、通販サイトが不正アクセスを受けたと判断した。N社は、直ちにこのインシデント(以下、インシデントPという)をB社セキュリティ部に報告した。N社とB社セキュリティ部が協力して対応したが、問題が幾つか発生し、対応を終えるまでに1か月掛かった。
インシデントPについて、判明した被害状況及び対応の概要を図5に示す。

〔インシデント対応方法の変更〕
インシデントPの対応が一段落した後、N社の経営陣は、N社で今後インシデントが起きた場合には、N社の基本方針に従って対応する契約に変更したいとB社に申し入れた。B社は、この申入れに対し、次の条件を満たすことを前提として了承した。
条件1:N社は、ISO/IEC27001を利用して、自社の情報セキュリティ対策を評価し、その結果と対策案について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/IEC27001附属書Aを基に評価し、指摘事項と対策案を表1のとおりに整理した。

N社は、T氏の対策案を参考に、N社としての対策をまとめ、B社の了承を得た。
〔条件2と条件3への対応〕
条件2と条件3に対応すべく、Hさんは、図6に示すN社インシデント対応ポリシ案を作成し、T氏のレビューを受けた。



次は、レビューの際のT氏とHさんの会話である。
T氏 :インシデント対応プロセスも整理すべきです。NISTの文書SP 800-61 Rev. 2に記載されているインシデント対応のライフサイクルを図7に示します。

Hさん:分かりました。図6の一部として整理します。ところで、今後のインシデント対応における技術面について不安があります。
T氏:インシデント対応サービスを提供し、登録セキスペが多数在籍する専門事業者が幾つかあります。そのような事業者に支援を依頼するとよいと思います。
Hさん:分かりました。表2に専門事業者とその役割を追加します。
N社は、検討結果を取りまとめ、B社の了承を得た。
〔新たなインシデントの発生と対応〕
N社インシデント対応ポリシの運用を開始してから約1か月後の11月22日、V社は、不審な利用者アカウント(以下、AC-Xという)がR1サーバに作成されていることを見付け、N-CSIRTに報告した。G部長は、インシデントであると判断し、初期調査をHさんに指示した(以下、このインシデントをインシデントQという)。Hさんは、V社と協力してインシデントQについて調査した。その結果を図8に示す。

図9は、FW2において、AC-Xが作成されてから発見されるまでの4日間、通信に成功した全てのパケットを対象とし、通信方向、接続元及び宛先のIPアドレス、サービスの組合せで通信量を集計し、降順に並べたものである。Hさんは、⑤図9を基に、不正ログインを行ったと推測される接続元IPアドレスを割り出した。

Hさんから調査結果について報告を受けたG部長は、R1サーバの隔離を指示した上で、インシデントQは重大なインシデントの可能性があると判断し、PTを発足させた。PTは専門事業者の支援を受けて調査を行い、R1サーバには、脆弱性L及び脆弱性Mが残っていることが判明した。脆弱性Lと脆弱性Mの概要、及びそれぞれの対応を見送った経緯とその理由を表3に、PTによる調査結果を図10に示す。



この報告を受けたG部長は、幸いにも被害が限定的であり、顧客への影響が全くないことから、インシデントQについて情報開示する必要はないと判断し、情報セキュリティ委員会に報告し承認を得た。
その後、G部長は、利用者アカウントのパスワード変更、R1サーバの復旧、脆弱性L及び脆弱性Mを解消する脆弱性修正プログラムの適用、⑨SSH接続及びHTTP接続を使った攻撃から開発用システムを保護するための措置などを指示した。
〔脆弱性管理プロセスの改善〕
インシデントPと比較してインシデントQの対応は迅速に行われ、N-CSIRTのインシデント対応は有効であると、N社の経営陣からもB社からも一定の評価を得た。一方、インシデントQでR1サーバが不正にログインされたことを考えると、⑩図4(イ)及び(ウ)において、悪用される可能性の評価についての観点の不足、又は影響の評価についての観点の不足があり、悪用される可能性又は影響を過小評価したのではないかという指摘があった。そのため、脆弱性管理プロセスを見直すことにした。
インシデントPの終息から1年後、表1の指摘事項及びインシデントQで明らかになった課題は全て解決できた。N-CSIRTは、関係者の訓練を進め、更に迅速かつ効果的なインシデント対応が可能になった。
設問1:〔インシデントの発生と対応〕について、(1)〜(5)に答えよ。
(1)図5中の下線①で示したパスワードリスト攻撃とは、一般にどのような攻撃か。45字以内で具体的に述べよ。
模範解答
外部から入手した利用者IDとパスワードの組み合わせのリストを使ってログインを試行する攻撃
解説
解答の論理構成
- 問題文の前提
図5には「・ログの調査から、①パスワードリスト攻撃と推定された。」とあります。ここで問われているのは「パスワードリスト攻撃とは何か」です。 - 攻撃手法の特徴整理
パスワードリスト攻撃は、既に漏えいした認証情報を他サービスへ転用して不正ログインを狙う手法であり、利用者側の「利用者ID」と「パスワード」がセットになったリストを攻撃者が所持している点が本質です。 - 設問に即した定義
上記特徴を踏まえ、「外部から入手した利用者IDとパスワードの組合せを使って次々とログインを試行する攻撃」であると定義できます。これが模範解答と合致します。
誤りやすいポイント
- 「総当たりで全パターンを試す」と誤ってブルートフォース攻撃の説明を書くケース。
- 「辞書攻撃」と混同して、単によく使われるパスワードを組み合わせて試すと説明してしまうケース。
- 漏えい元の説明に終始し、リストを転用して別サービスへアクセスする点を落としてしまうケース。
FAQ
Q: 盗んだIDだけを使い、パスワードは推測する攻撃もパスワードリスト攻撃ですか?
A: いいえ。IDとパスワードの“組合せリスト”を用いる点が定義上の重要要素です。パスワードを推測していれば辞書攻撃やブルートフォース攻撃に分類されます。
A: いいえ。IDとパスワードの“組合せリスト”を用いる点が定義上の重要要素です。パスワードを推測していれば辞書攻撃やブルートフォース攻撃に分類されます。
Q: 他の名称として何と呼ばれることがありますか?
A: 「クレデンシャルスタッフィング」とも呼ばれます。いずれも漏えい認証情報を再利用する点で同一の攻撃手法です。
A: 「クレデンシャルスタッフィング」とも呼ばれます。いずれも漏えい認証情報を再利用する点で同一の攻撃手法です。
Q: 防御策は多要素認証だけでしょうか?
A: 多要素認証が有効ですが、同時にパスワード設定の強化、異常ログイン試行の検知、パスワードリスト攻撃を前提にしたロックアウト設定など多層防御が推奨されます。
A: 多要素認証が有効ですが、同時にパスワード設定の強化、異常ログイン試行の検知、パスワードリスト攻撃を前提にしたロックアウト設定など多層防御が推奨されます。
関連キーワード: クレデンシャルスタッフィング、ブルートフォース、辞書攻撃、認証、不正ログイン
設問1:〔インシデントの発生と対応〕について、(1)〜(5)に答えよ。
(2)図5中の下線②について、パスワードの安全な設定方法とは何か。35字以内で具体的に述べよ。
模範解答
他のサービスで利用したパスワードとは別のものを設定すること
解説
解答の論理構成
- 図5(2)には、
「②パスワードリスト攻撃の被害を防ぐ上で必要な、パスワードの安全な設定方法を全会員に案内した」
と明記されています。 - 「パスワードリスト攻撃」は、攻撃者が他サービスから取得した「利用者IDとパスワードの組合せ」を流用し、一斉にログイン試行を行う手口です。
- よって、同一パスワードを複数サービスで使い回している利用者ほど成功率が高くなります。
- 逆に言えば、
・各サービスで異なるパスワードを用意する
という対策を取れば、他サービスで流出しても今回のサービスでは通用しません。 - したがって「パスワードの安全な設定方法」を具体化すると、
「他のサービスで利用したパスワードとは別のものを設定すること」
が最も直接的で効果的な答えになります。
誤りやすいポイント
- 「長いパスフレーズを使う」「定期的に変更する」などは一般論として有効ですが、本設問は「②パスワードリスト攻撃の被害を防ぐ上で必要な」点に絞っているため焦点がずれます。
- 多要素認証(MFA)は効果的でも「パスワードの設定方法」ではないため出題意図と異なります。
- 「辞書に載っていない文字列を使う」だけでは、流用を防ぐ記述になっていないので減点対象となります。
FAQ
Q: 強固な複雑性を持つパスワードでも、使い回していなければ安全ですか?
A: はい。パスワードリスト攻撃は「流用」が前提です。複雑性は別の攻撃(総当たりなど)に対する防御であり、設問の主眼は一サービス流出時の横展開を防ぐことにあります。
A: はい。パスワードリスト攻撃は「流用」が前提です。複雑性は別の攻撃(総当たりなど)に対する防御であり、設問の主眼は一サービス流出時の横展開を防ぐことにあります。
Q: 使い回し禁止だけで十分でしょうか?
A: 実務では多要素認証やログイン試行の監視も併用します。しかし設問は「パスワードの安全な設定方法」を尋ねているため、回答は設定ルールに絞るのが適切です。
A: 実務では多要素認証やログイン試行の監視も併用します。しかし設問は「パスワードの安全な設定方法」を尋ねているため、回答は設定ルールに絞るのが適切です。
Q: パスワードマネージャの利用を答えても良いですか?
A: パスワードマネージャは使い回し防止を助けますが、「設定方法」の直接的な表現ではなく、設問の意図から外れる可能性があります。
A: パスワードマネージャは使い回し防止を助けますが、「設定方法」の直接的な表現ではなく、設問の意図から外れる可能性があります。
関連キーワード: パスワードリスト攻撃、使い回し防止、認証強化、資格情報漏洩、クレデンシャルスタッフィング
設問1:〔インシデントの発生と対応〕について、(1)〜(5)に答えよ。
(3)図5中の下線③について、ログインが普段と異なる環境から行われたことを判定する技術的手法を、45字以内で具体的に述べよ。
模範解答
「IPアドレスから分かる地理的位置について、過去のログインのものとの違いを確認する。」
または
「WebブラウザのCookieを利用し、過去にログインした端末かを判定する。」
解説
解答の論理構成
- 図5の「対応」に「③ログインが普段と異なる環境から行われた場合、会員が事前に登録した電子メールアドレスにその旨を通知する仕組みを通販サイトに導入した。」とあります。
- ここでいう「普段と異なる環境」を機械的に判定するには、過去の正常ログイン情報と比較できる識別子が必要です。
- 代表例は
・IPアドレスに基づく位置情報(GeoIP)
・端末固有情報(Cookie や Device Fingerprint)
などです。 - 例えば GeoIP を用いる場合、現在の IP の推定位置を算出し、過去の正常ログイン位置と差異が大きいかを照合して「異常」と判断できます。
- 以上から、模範解答例のように「IPアドレスから分かる地理的位置を用いた判定」や「Cookie により端末を識別する」手法が根拠づけられます。
誤りやすいポイント
- 「普段と異なる環境」を単に“深夜帯”など時間的要素だけで判定すると設問の意図とずれます。
- 「VPN利用かどうか」で判断と書くと、VPN 経由でも普段と同一端末であれば正常となる場合があり不十分です。
- ブラウザの User-Agent だけでは簡単に偽装できるため、Cookie など履歴と結び付けた確実な識別が必要です。
FAQ
Q: IPアドレスは動的に変わる場合がありますが、精度は問題になりませんか?
A: 都市レベルの GeoIP 判定でも数百 km 単位の差は検知でき、普段のログイン地域と大幅に異なる場合の目安として十分機能します。
A: 都市レベルの GeoIP 判定でも数百 km 単位の差は検知でき、普段のログイン地域と大幅に異なる場合の目安として十分機能します。
Q: Cookie を削除されたら検知できなくなりませんか?
A: その通りです。Cookie ベースは端末変更・ブラウザ変更・プライベートモードで無効化されるため、GeoIP 判定など複数手法を組み合わせて精度を高めます。
A: その通りです。Cookie ベースは端末変更・ブラウザ変更・プライベートモードで無効化されるため、GeoIP 判定など複数手法を組み合わせて精度を高めます。
Q: 位置情報と端末情報のどちらを優先すべきですか?
A: 運用コストとリスクに応じて決定しますが、まず導入しやすい GeoIP 判定を実装し、重要取引では端末情報との併用が推奨されます。
A: 運用コストとリスクに応じて決定しますが、まず導入しやすい GeoIP 判定を実装し、重要取引では端末情報との併用が推奨されます。
関連キーワード: GeoIP, Cookie, Device Fingerprint, 異常検知、アクセスログ
設問1:〔インシデントの発生と対応〕について、(1)〜(5)に答えよ。
(4)図5中のaに入れる適切な字句を8字以内で答えよ。
模範解答
a:タイムゾーン
解説
解答の論理構成
- 問題文には次の記述があります。
――「N社が提供したログの大半は、記録されていた時刻情報のaが日本標準時であり、協定世界時に対し時刻情報がb時間進んだ値で記録されていた。」
ここで “日本標準時” と “協定世界時” という異なる時刻体系が比較されています。 - どちらの時刻体系を用いているかを示す情報は、一般に “タイムゾーン” と呼ばれます。したがって a に入る語は「タイムゾーン」と判断できます。
- 実際に、ログの誤解はタイムゾーンが混在していたことに起因しているため、最も適切な字句は「タイムゾーン」です。
誤りやすいポイント
- 「時差」「時刻形式」などの語を選んでしまう。問題文は “日本標準時” と “協定世界時” という“地域ごとの時間帯”を対比しているため「タイムゾーン」が正答です。
- b との混同。ここは数値(“9”など)が入る箇所で、文字列を入れるのは誤答になります。
- 「UTC」や「JST」をそのまま入れるケース。これらは具体的なゾーン名であり、設問は“何の情報か”を問うています。
FAQ
Q: 「時差」ではなぜ誤りですか?
A: 「時差」は時間の差を表す量であり、ログに記録されるメタ情報そのものではありません。設問は“何という情報が記録されていたか”を問うているため「タイムゾーン」が正しいです。
A: 「時差」は時間の差を表す量であり、ログに記録されるメタ情報そのものではありません。設問は“何という情報が記録されていたか”を問うているため「タイムゾーン」が正しいです。
Q: 「UTC」や「JST」と書いてはだめですか?
A: これらは特定のタイムゾーン名で、設問では「時刻情報のaが日本標準時であり」と既に日本標準時を示しているため、一般名詞「タイムゾーン」で答える必要があります。
A: これらは特定のタイムゾーン名で、設問では「時刻情報のaが日本標準時であり」と既に日本標準時を示しているため、一般名詞「タイムゾーン」で答える必要があります。
Q: ログ分析でタイムゾーンが混在すると何が問題になるのですか?
A: 異なるタイムゾーンのログを突き合わせると発生時刻の前後関係がずれ、原因究明やインシデントのタイムライン作成が困難になります。
A: 異なるタイムゾーンのログを突き合わせると発生時刻の前後関係がずれ、原因究明やインシデントのタイムライン作成が困難になります。
関連キーワード: ログ管理、タイムスタンプ、協定世界時、日本標準時
設問1:〔インシデントの発生と対応〕について、(1)〜(5)に答えよ。
(5)図5中のbに入れる適切な数値を答えよ。
模範解答
b:9
解説
解答の論理構成
-
問題文の該当箇所を確認
引用:
「記録されていた時刻情報のaが日本標準時であり、協定世界時に対し時刻情報がb時間進んだ値で記録されていた。」 -
日本標準時と協定世界時の差を確認
・日本標準時(Japan Standard Time:JST)は UTC(協定世界時)+9 時間である。
・すなわち JST で記録されたログは UTC に比べ「9 時間進んだ値」になる。 -
よって b に入る数値は「9」である。
誤りやすいポイント
- 「サマータイム」を想起して 8 時間や 10 時間と誤記する。日本標準時は年間を通じて UTC+9 時間で固定です。
- 「JST=UTC−9」と符号を取り違え、差の方向を逆に解釈する。
- 問題文に出てくる他の数値(「16名」「130万円」など)と混同してしまう。
FAQ
Q: 日本標準時と協定世界時の差を暗記していない場合、どう判断すれば良いですか?
A: 日本国内の試験では「JST は UTC+9 時間」が定番知識です。覚えていない場合でも、旅行や国際会議の日程調整経験を思い出すと UTC との時差 9 時間を連想できます。
A: 日本国内の試験では「JST は UTC+9 時間」が定番知識です。覚えていない場合でも、旅行や国際会議の日程調整経験を思い出すと UTC との時差 9 時間を連想できます。
Q: 他国のログでも同様に時差を考慮すべきですか?
A: はい。ログ解析では必ず「タイムゾーン」を明確にし、異なる拠点のログを突き合わせる際は UTC に統一するなどの前処理が欠かせません。
A: はい。ログ解析では必ず「タイムゾーン」を明確にし、異なる拠点のログを突き合わせる際は UTC に統一するなどの前処理が欠かせません。
Q: 時刻情報にタイムゾーンが明示されていない場合の対処は?
A: システム設計段階でタイムゾーンをメタデータとして保持する、もしくは UTC で統一して記録する運用ルールを定めることが推奨されます。
A: システム設計段階でタイムゾーンをメタデータとして保持する、もしくは UTC で統一して記録する運用ルールを定めることが推奨されます。
関連キーワード: UTC, JST, タイムゾーン、ログ解析、インシデント対応
設問2:
表1中の下線④について、社内LANから店舗PCを経由せずにどのようにマルウェアが侵入すると想定されるか。侵入方法を50字以内で具体的に述べよ。
模範解答
マルウェアに感染したUSBメモリを介して管理用PCに侵入し、さらに店舗管理サーバへ侵入する。
解説
解答の論理構成
- ④では「店舗管理システムは社内 LAN と分離されているが、社内 LAN にマルウェアが侵入した場合、店舗管理サーバにもマルウェアが侵入するリスクがある。」と記述されています。
- 「分離されている」という前提から、ネットワーク経由で直接感染するルートは遮断されていると分かります。
- それでもリスクが残るのは、オフライン媒体を使ったデータ受け渡しという“物理的バイパス”が存在するためです。
- 社内 LAN 側で感染した PC が可搬媒体(USB メモリなど)にマルウェアをコピーし、その媒体を店舗管理システム側の端末に接続すると、ネットワーク分離を迂回して店舗管理サーバへ到達できます。
- 以上より、社内 LAN → 可搬媒体 → 店舗管理サーバという流れが④のリスク内容を具体化する経路になります。
誤りやすいポイント
- 「分離」という言葉から完全無欠の隔離と誤解し、物理媒体経由の感染可能性を見落とす。
- 店舗 PC を経由するシナリオばかりを想定し、管理用端末やサーバへの直接接続に思い至らない。
- マルウェア感染=ネットワーク経由という先入観から、USB メモリや外付け HDD などのオフライン経路を軽視する。
FAQ
Q: ネットワークが分離されていれば安全ではないのですか?
A: 分離は「通信経路を限定する」対策にすぎません。USB メモリなどの物理媒体や人手による操作が介在すると、ネットワークを迂回して侵入する余地が残ります。
A: 分離は「通信経路を限定する」対策にすぎません。USB メモリなどの物理媒体や人手による操作が介在すると、ネットワークを迂回して侵入する余地が残ります。
Q: 店舗 PC を経由させなくても感染するのはなぜですか?
A: 社内 LAN の PC が感染済みの場合、その PC で使用した USB メモリがマルウェアを保持し、次に接続した端末(店舗管理システム側)に直接感染を広げるためです。
A: 社内 LAN の PC が感染済みの場合、その PC で使用した USB メモリがマルウェアを保持し、次に接続した端末(店舗管理システム側)に直接感染を広げるためです。
Q: 具体的な対策は何ですか?
A: 可搬媒体の使用禁止・スキャンの徹底、端末側の自動実行機能無効化、媒体利用履歴の記録といった多層的な管理策が有効です。
A: 可搬媒体の使用禁止・スキャンの徹底、端末側の自動実行機能無効化、媒体利用履歴の記録といった多層的な管理策が有効です。
関連キーワード: USBメモリ感染、エアギャップ、物理媒体、マルウェア侵入経路、可搬媒体管理
設問3:〔条件2と条件3への対応〕について、(1)、(2)に答えよ。
(1)表2中のcに入れる適切な字句を、解答群の中から選び、記号で答えよ。
解答群
ア:IPA
イ:JIPDEC
ウ:JPCERT/CC
エ:財務経理部
オ:情報セキュリティ委員会
カ:総務部
キ:内部監査室
模範解答
c:オ
解説
解答の論理構成
- 表2の該当行には
“基本方針の策定やN社インシデント対応ポリシーの承認を担当する。”
という役割が示されています。 - 問題文には、
“N社は、情報セキュリティ委員会を設置している。同委員会は、経営陣が委員となり、情報セキュリティについての基本方針…及び重要な課題を取り扱う。”
と明記されています。
ここで “基本方針” を所管する組織が “情報セキュリティ委員会” であることが分かります。 - よって、表2中の c に入る部門は “情報セキュリティ委員会” であり、解答群の記号は “オ” です。
誤りやすいポイント
- “基本方針” という語だけを見て 総務部 や 内部監査室 と結び付けてしまう。実際には経営層が直接関与する委員会が所管します。
- “委員会” という語感から JPCERT/CC のような外部機関を連想しがちですが、問題は社内組織について問うています。
- 表2では “システム部” など実部門名が並んでいるため、外部団体(IPA など)は候補から除外すべきです。
FAQ
Q: “情報セキュリティ委員会” は CSIRT とどう違いますか?
A: 委員会は経営層が中心となり方針と承認を行うガバナンス組織、CSIRT は実務を遂行するチームです。役割と権限の階層が異なります。
A: 委員会は経営層が中心となり方針と承認を行うガバナンス組織、CSIRT は実務を遂行するチームです。役割と権限の階層が異なります。
Q: “内部監査室” がセキュリティ方針を承認するケースはありますか?
A: 一般には監査部門は評価・検証を行う立場で、方針そのものの策定・承認は経営層または専任委員会が担当します。
A: 一般には監査部門は評価・検証を行う立場で、方針そのものの策定・承認は経営層または専任委員会が担当します。
Q: CSIRT の上位組織が方針を承認するメリットは?
A: 経営層の関与により全社的なリソース配分や優先度付けが明確になり、インシデント対応を迅速かつ組織的に行えます。
A: 経営層の関与により全社的なリソース配分や優先度付けが明確になり、インシデント対応を迅速かつ組織的に行えます。
関連キーワード: CSIRT, 基本方針、インシデント対応、ガバナンス、権限委譲
設問3:〔条件2と条件3への対応〕について、(1)、(2)に答えよ。
(2)図7中のd〜fに入れる適切な字句を、解答群の中から選び、記号で答えよ(dとeは順不同)。
解答群
ア:開示
イ:検知
ウ:根絶
エ:トレーニング
オ:復習
カ:分析
キ:レビュー
模範解答
d:イ
e:カ
f:ウ
解説
解答の論理構成
- 図7は “インシデント対応のライフサイクル” を示し、左から「準備」→四角形(小矩形が上下に2つ配置)→「封じ込め/f/復旧」→「事後活動」と並んでいます。
- NIST SP 800-61 Rev. 2 では、準備の次に “Detection & Analysis” が続き、その後 “Containment, Eradication & Recovery” となります。
- よって、準備の直後に位置し上下2段で構成される d と e は “検知” と “分析” の対になる工程です。
- 「封じ込め」と「復旧」に挟まれて 1 つだけ置かれている f は、Containment と Recovery をつなぐ工程であり “根絶” が該当します。
- 以上から
d:イ「検知」
e:カ「分析」
f:ウ「根絶」
となります。
誤りやすいポイント
- 「封じ込め」の前後を“分析”と“根絶”のどちらかで迷い、工程順序を逆転させやすい。
- “開示”“レビュー”など似た語を選びがちですが、図7は技術的プロセスの流れを示しているため、広報や振り返り系キーワードは該当しません。
- “事後活動” を “根絶” と読み違えて f に別語を当てはめてしまうミスが散見されます。
FAQ
Q: “検知” と “分析” の順序は解答に影響しますか?
A: 本問では「dとeは順不同」と明記されているため、どちらを d・e にしても正解です。
A: 本問では「dとeは順不同」と明記されているため、どちらを d・e にしても正解です。
Q: “根絶” と “復旧” は何が違いますか?
A: “根絶” はマルウェアや攻撃者の痕跡を完全に除去する工程、“復旧” はシステムを通常運用状態へ戻す工程です。根絶が不十分だと復旧後に再侵入を許す恐れがあります。
A: “根絶” はマルウェアや攻撃者の痕跡を完全に除去する工程、“復旧” はシステムを通常運用状態へ戻す工程です。根絶が不十分だと復旧後に再侵入を許す恐れがあります。
Q: “レビュー” はどの工程で実施されるのですか?
A: “レビュー” は図7で右端に示される “事後活動” に含まれ、対応後の振り返り・改善策立案などが行われます。
A: “レビュー” は図7で右端に示される “事後活動” に含まれ、対応後の振り返り・改善策立案などが行われます。
関連キーワード: インシデントライフサイクル、検知、分析、根絶、封じ込め
設問4:〔新たなインシデントの発生と対応〕について、(1)〜(5)に答えよ。
(1)本文中の下線⑤について、図9中の接続元IPアドレスのうち、不正ログインを行ったと推測される接続元IPアドレスは幾つか。個数を答えよ。
模範解答
5
解説
解答の論理構成
-
正規の接続元範囲を把握
【問題文】には「割り当てられたグローバルIPアドレスの範囲は、次のとおりである。 ・N社:x1.y1.z1.0/28 ・V社:x2.y2.z2.128/30」とあります。
したがって
・N社 ⇒ x1.y1.z1.0 ~ x1.y1.z1.15
・V社 ⇒ x2.y2.z2.128 ~ x2.y2.z2.131
が正規と判断できます。 -
不正ログインは SSH で行われた
図10(2)より「AC-X を利用して SSH 接続で R1 サーバにログインした」と記載されており、SSH のみを抽出する必要があります。 -
図9のインバウンド通信(SSH)を抽出
図9から SSH の行だけを抜き出すと次の8件です。- x2.y2.z2.130 SSH
- x2.y2.z2.129 SSH
- x1.y1.z1.100 SSH
- x1.y1.z1.240 SSH
- x2.y2.z2.60 SSH
- x1.y1.z1.240 SSH
- x2.y2.z2.58 SSH
- a2.b2.c2.d2 SSH
-
正規範囲に該当する IP を除外
- x2.y2.z2.130 と x2.y2.z2.129 は V社の範囲(x2.y2.z2.128/30)
- x1.y1.z1.10(SSH ではない)と同一ネットワーク内で x1.y1.z1.100, 240 は N社範囲外(0/28 でない)
従って除外できるのは x2.y2.z2.130 と x2.y2.z2.129 の2件のみです。
-
残った IP の個数
残る IP は- x1.y1.z1.100
- x1.y1.z1.240
- x2.y2.z2.60
- x2.y2.z2.58
- a2.b2.c2.d2
の5件となり、これが「不正ログインを行ったと推測される接続元IPアドレス」の個数です。
答え:5
誤りやすいポイント
- /28 の範囲(0〜15)を正しく計算せず、x1.y1.z1.100 や x1.y1.z1.240 を N社と誤認する。
- HTTP/HTTPS 行も含めてしまい、SSH 以外の IP をカウントする。
- x2.y2.z2.60 や x2.y2.z2.58 を V社と誤解して除外する(V社は /30 で128〜131のみ)。
- 図10で「SSH 接続でログイン」と明示されていることを見落とす。
FAQ
Q: x1.y1.z1.200 は除外してよいのですか?
A: はい。図9では HTTPS しか記録されておらず、SSH ログインには関係しません。
A: はい。図9では HTTPS しか記録されておらず、SSH ログインには関係しません。
Q: なぜ x1.y1.z1.100 と x1.y1.z1.240 を攻撃元と見るのですか?
A: N社の範囲は「x1.y1.z1.0/28」なので .100 や .240 は範囲外です。SSH で接続していることから不正と判断できます。
A: N社の範囲は「x1.y1.z1.0/28」なので .100 や .240 は範囲外です。SSH で接続していることから不正と判断できます。
Q: /30 の計算方法が分かりません。
A: /30 はサブネット長 30 ビット、ホスト部 2 ビットなので 4 アドレス(ネットワーク・ブロードキャストを除けば 2 つ)。「x2.y2.z2.128/30」の有効ホストは 128〜131 です。
A: /30 はサブネット長 30 ビット、ホスト部 2 ビットなので 4 アドレス(ネットワーク・ブロードキャストを除けば 2 つ)。「x2.y2.z2.128/30」の有効ホストは 128〜131 です。
関連キーワード: SSH, グローバルIPアドレス、ファイアウォール、インバウンド通信、ネットワークセグメント
設問4:〔新たなインシデントの発生と対応〕について、(1)〜(5)に答えよ。
(2)図10中の下線⑥について、脆弱性Mだけを悪用しても“/etc/shadow”ファイルを参照できない理由を、“/etc/shadow”ファイルの性質を含めて、70字以内で述べよ。
模範解答
脆弱性Mを悪用しても一般利用者権限での操作であるが、/etc/shadowファイルの閲覧には管理者権限が必要であるから
解説
解答の論理構成
- 問題文には、脆弱性Mは「開発支援ツールJの脆弱性である。細工されたHTTPリクエストを送信することによって、開発支援ツールJを実行している利用者アカウントの権限で任意のコマンドを実行できる。」とあります。
- さらに「開発支援ツールJは、OSの一般利用者権限を割り当てた利用者アカウントで動作する。」とも明記されています。
- 一方、“/etc/shadow” ファイルは Linux 系 OS でパスワードハッシュなどを格納し、読み取りには root などの管理者権限が必須という性質を持ちます。
- したがって、脆弱性Mだけを悪用しても得られる権限は「一般利用者権限」止まりであり、“/etc/shadow” にアクセスできません。
- よって、「脆弱性Mだけでは“/etc/shadow”ファイルを参照できない」という結論になります。
誤りやすいポイント
- 脆弱性Mで「任意のコマンドを実行できる」とあるため管理者権限も奪えると早合点する。実際は「利用者アカウントの権限」に限定される。
- “/etc/shadow” のアクセス制御を “/etc/passwd” と混同し、読み取り可能と誤解する。
- 脆弱性Lと脆弱性Mの役割分担を整理せず、どちらが権限昇格に寄与したかを取り違える。
FAQ
Q: 「任意のコマンドを実行できる」なら sudo を呼び出して root になれるのでは?
A: sudo 実行には sudoers 設定やパスワード入力が必要です。一般権限のみを獲得した時点では、すぐに root へ昇格できるわけではありません。
A: sudo 実行には sudoers 設定やパスワード入力が必要です。一般権限のみを獲得した時点では、すぐに root へ昇格できるわけではありません。
Q: “/etc/shadow” を読む以外に、パスワードハッシュを取得する方法はありますか。
A: 例えばメモリダンプやカーネル Exploit による権限昇格が成功すれば可能ですが、本設問では脆弱性M単独ではそれらを行えない前提です。
A: 例えばメモリダンプやカーネル Exploit による権限昇格が成功すれば可能ですが、本設問では脆弱性M単独ではそれらを行えない前提です。
Q: 脆弱性Lと脆弱性Mを連携させると何が起きますか。
A: まず脆弱性Mでコマンド実行し、続いて脆弱性Lで管理者権限を奪取する――この組み合わせにより “/etc/shadow” 参照やユーザ追加が可能となります。
A: まず脆弱性Mでコマンド実行し、続いて脆弱性Lで管理者権限を奪取する――この組み合わせにより “/etc/shadow” 参照やユーザ追加が可能となります。
関連キーワード: 権限分離、アクセス制御、パスワードハッシュ、権限昇格、侵入経路
設問4:〔新たなインシデントの発生と対応〕について、(1)〜(5)に答えよ。
(3)図10中の下線⑦について、攻撃者が行った設定変更の内容を、45字以内で具体的に述べよ。
模範解答
攻撃の接続元IPアドレスを/etc/hosts.allowファイルに追加する。
解説
解答の論理構成
- ⑦の記述
- 「⑦R1 サーバをインターネット経由で操作するために設定を変更した。」
ここでいう「設定」とは、攻撃者が自身の端末から SSH で R1 サーバを遠隔操作するために必要なアクセス制御を指しています。
- 「⑦R1 サーバをインターネット経由で操作するために設定を変更した。」
- R1 サーバの現行制限
- 「R1サーバの “/etc/hosts.allow” ファイルの設定において、SSH接続の接続元をN社とV社に限定している。」
よって、N社・V社以外の IP アドレスからは SSH 接続できません。
- 「R1サーバの “/etc/hosts.allow” ファイルの設定において、SSH接続の接続元をN社とV社に限定している。」
- 攻撃者の目的
- 図8より「N社でもV社でもない複数のIPアドレスからSSH接続があり、合計10回以上…不正ログイン」。
攻撃者は自組織 IP で R1 サーバへ SSH 接続する必要があります。
- 図8より「N社でもV社でもない複数のIPアドレスからSSH接続があり、合計10回以上…不正ログイン」。
- 管理者権限の取得
- 図10(2) に「管理者権限で AC-X を作成した。」とあるため、設定ファイルの編集が可能です。
- 結論
- アクセス制御を突破する最短手段は「/etc/hosts.allow に攻撃者の接続元 IP を追加し、許可リストに載せる」ことです。
したがって解答は「攻撃の接続元IPアドレスを/etc/hosts.allowファイルに追加する。」となります。
- アクセス制御を突破する最短手段は「/etc/hosts.allow に攻撃者の接続元 IP を追加し、許可リストに載せる」ことです。
誤りやすいポイント
- /etc/hosts.deny への追加・削除と取り違える。
- sshd_config の AllowUsers や ListenAddress を編集すると誤解する。
- FW2 のルール変更と混同し、ファイアウォール側を操作すると考えてしまう。
- 「N社・V社のアドレスに偽装する」と推測するが、図9で攻撃元が別 IP と示されている。
- 「HTTP 接続の制限解除」と勘違いし、SSH ではなく Web 側を答える。
FAQ
Q: /etc/hosts.allow はどのようにアクセス制御に関与しますか?
A: TCP Wrappers を利用するサービス(sshd など)は、接続元がリストに一致すると接続を許可します。よってファイルに IP を追加すれば即時許可されます。
A: TCP Wrappers を利用するサービス(sshd など)は、接続元がリストに一致すると接続を許可します。よってファイルに IP を追加すれば即時許可されます。
Q: ファイアウォール FW2 の設定変更では不十分ですか?
A: FW2 では元々 SSH を許可していますが、R1 サーバ自身が接続元 IP を制限しているため、サーバ側設定の変更が必須です。
A: FW2 では元々 SSH を許可していますが、R1 サーバ自身が接続元 IP を制限しているため、サーバ側設定の変更が必須です。
Q: 攻撃者が編集権限を得られたのはなぜですか?
A: 図10(1) に示す「脆弱性 L と脆弱性 M を悪用」し、/etc/shadow 参照後に権限昇格して管理者権限を取得したからです。
A: 図10(1) に示す「脆弱性 L と脆弱性 M を悪用」し、/etc/shadow 参照後に権限昇格して管理者権限を取得したからです。
関連キーワード: TCP Wrappers, SSH, アクセス制御リスト、権限昇格、ホストベース認証
設問4:〔新たなインシデントの発生と対応〕について、(1)〜(5)に答えよ。
(4)図10中の下線⑧について、F2ファイルには、幾つのIPアドレスをスキャンした結果が格納されていると考えられるか。図9中の値及び図10中の値を用いて求めよ。
模範解答
24
解説
解答の論理構成
-
固定長出力 1 件当たりのサイズを算出
- 図10より引用
- 「サイズは 320 k バイトであった。」
- 「ツール X が 8 個の IP アドレスをスキャンした結果が格納されており、IP アドレスごとの出力結果は固定長であった。」
- したがって 1 件当たりのサイズは
- 図10より引用
-
F2 ファイルの転送サイズを把握
- 図9より引用
- アウトバウンド通信欄「R1サーバ a2.b2.c2.d2 HTTP 960」
- R1 サーバから 960 k バイトが送信されている。
- 図10より引用
- 「F2 ファイルは一部しか復元できなかったが、F1 ファイルと同様の形式で…格納されていると考えられた。」
- よって 960 kB は F2 ファイル全体を送信したとみなせる。
- 図9より引用
-
F2 ファイルに含まれる IP アドレス数を計算
- 1 件当たり 40 kB、総量 960 kB なので
- 1 件当たり 40 kB、総量 960 kB なので
-
結論
- F2 ファイルには 24 個の IP アドレスをスキャンした結果が格納されていると推定できる。
誤りやすいポイント
- 「960 k バイト」は通信全体の量であり、HTTP プロトコルのオーバーヘッドを差し引くべきだと深読みしてしまう。問題では固定長出力と総通信量だけで十分に導ける。
- F1 と F2 のファイル形式が同じである前提を見落とし、直接比率計算を行わない。
- 図9のアウトバウンド通信に複数行ある場合、どの行が F2 の転送かを取り違える。
FAQ
Q: 通信量 960 kB には HTTP ヘッダも含まれますか?
A: 設問は「図9中の値」をそのまま用いるよう指示しており、細かなオーバーヘッド調整は不要です。
A: 設問は「図9中の値」をそのまま用いるよう指示しており、細かなオーバーヘッド調整は不要です。
Q: F2 ファイルが途中で欠損している可能性は考慮しなくてよいのですか?
A: 図10は「格納されていると考えられた」と示しており、設問も “幾つの IP アドレスをスキャンした結果が格納されているか” を求めています。転送量全体を用いて算出するのが適切です。
A: 図10は「格納されていると考えられた」と示しており、設問も “幾つの IP アドレスをスキャンした結果が格納されているか” を求めています。転送量全体を用いて算出するのが適切です。
Q: もし固定長でなかった場合はどうなりますか?
A: 固定長が前提にならなければ比例計算が成り立たず、設問の条件が崩れます。本問では図10が「固定長」と明記しているため比例計算が成立します。
A: 固定長が前提にならなければ比例計算が成り立たず、設問の条件が崩れます。本問では図10が「固定長」と明記しているため比例計算が成立します。
関連キーワード: 通信量解析、固定長レコード、脆弱性スキャン、ファイル転送、比率計算
設問4:〔新たなインシデントの発生と対応〕について、(1)〜(5)に答えよ。
(5)本文中の下線⑨について、措置を75字以内で具体的に述べよ。
模範解答
FW2において、インターネットからのインバウンド通信はN社とV社からの通信だけを許可する。
解説
解答の論理構成
-
攻撃経路の把握
- 図8より「複数のIPアドレスからSSH接続があり、…不正ログインが行われていた」と記載されています。
- これらの接続元は「N社でもV社でもない複数のIPアドレス」であり、攻撃者の経路はインターネット経由のSSH/HTTPでした。
-
現状のファイアウォール設定
- 図3には「インターネットからのインバウンド通信は、FW2において、各サーバへのSSH接続及びHTTP接続を許可し、その他の通信を遮断している。」とあり、現在は接続元を限定していません。
-
正規利用者の条件
- 同じく図3に「N社及びV社はインターネットを介して、HTTP…および…SSH接続を行い、開発業務を行う。」とあります。
- 正規に開発用システムへアクセスする主体は N社と V社 だけです。
-
必要な対策の導出
- 攻撃経路を遮断するには、FW2 が許可するインバウンド通信の接続元を正規の IP 範囲(N社・V社)に限定すればよい。
- これにより不正な IP からの SSH/HTTP が遮断され、「SSH接続及びHTTP接続を使った攻撃」そのものを防止できます。
-
解答
- 従って「FW2において、インターネットからのインバウンド通信はN社とV社からの通信だけを許可する。」となります。
誤りやすいポイント
- SSH だけを制限し HTTP を開放したままにする。攻撃者は HTTP の脆弱性経由でも侵入可能です。
- FW1(通販サイト側)や FW3(社内LAN側)で制御すればよいと誤解する。実際の攻撃経路は FW2 を通過して開発用システムに到達しています。
- 接続先ポートを制限するだけで十分と判断し、接続元 IP アドレスの限定を忘れる。
FAQ
Q: VPN での接続に切替える方が安全ではありませんか?
A: 長期的には VPN 方式も有効ですが、問題文は「SSH接続及びHTTP接続」を前提としており、設問は“措置”を一つ問うています。まずは FW2 の接続元制限が最小変更で即効性があります。
A: 長期的には VPN 方式も有効ですが、問題文は「SSH接続及びHTTP接続」を前提としており、設問は“措置”を一つ問うています。まずは FW2 の接続元制限が最小変更で即効性があります。
Q: ホストベースの ACL(/etc/hosts.allow)を強化するだけでは不十分ですか?
A: hosts.allow はサーバ単体の設定であり、FW2 で遮断すればサーバに到達する前に不正通信を除外できます。多層防御の観点からネットワーク境界での制御が優先です。
A: hosts.allow はサーバ単体の設定であり、FW2 で遮断すればサーバに到達する前に不正通信を除外できます。多層防御の観点からネットワーク境界での制御が優先です。
Q: WAF や IDS/IPS を導入すべきでは?
A: テスト環境で「WAFや改ざん検知の仕組みは…導入していない」と記載があり、導入が難しい前提です。まずは FW の設定変更で攻撃面を最小化することが求められています。
A: テスト環境で「WAFや改ざん検知の仕組みは…導入していない」と記載があり、導入が難しい前提です。まずは FW の設定変更で攻撃面を最小化することが求められています。
関連キーワード: アクセス制御リスト、ファイアウォール、接続元制限、インバウンド通信、多層防御
設問5:
本文中の下線⑩について、悪用される可能性を評価する際に加えるべき観点、又は影響を評価する際に加えるべき観点を、今回の事例を踏まえて30字以内で述べよ。
模範解答
「複数の脆弱性が同時に悪用される可能性の観点」
または
「対応を見送った脆弱性の影響の観点」
解説
解答の論理構成
- 事実確認
- 攻撃では「脆弱性L」と「脆弱性M」が併用され、“/etc/shadow” が読み取られたと【図10 (1)】に記載されています。
引用:「⑥脆弱性 L と脆弱性 M を悪用して、“/etc/shadow” ファイルを参照した。」
- 攻撃では「脆弱性L」と「脆弱性M」が併用され、“/etc/shadow” が読み取られたと【図10 (1)】に記載されています。
- 既存評価の問題点
- それぞれの脆弱性は個別に「影響は小さい」と判断しパッチ適用を見送っています(表3)。
引用:「脆弱性L…影響は小さい。」「脆弱性M…影響は小さい。」
- それぞれの脆弱性は個別に「影響は小さい」と判断しパッチ適用を見送っています(表3)。
- 実際の被害
- 二つの脆弱性を“組み合わせ”た攻撃により管理者権限取得に至り、アカウント作成・外部送信が行われた(図10)。
- 評価観点の不足
- 個別評価では見落とした「複数脆弱性の連鎖」こそが被害を拡大させたため、今後はその観点を組み込むべきだと結論付けます。
- よって回答は
- 「複数の脆弱性が同時に悪用される可能性の観点」
- もしくは「対応を見送った脆弱性の影響の観点」
誤りやすいポイント
- 脆弱性を“単体”でしか評価せず、連携攻撃のシナリオを想定しない。
- 「機密データを保持しないサーバだから影響は小さい」と早合点し、権限昇格や踏み台化のリスクを軽視する。
- 評価プロセス(図4)で(イ)と(ウ)を分離しすぎ、悪用可能性と影響の“相互作用”を検討しない。
FAQ
Q: 連鎖攻撃の想定はどの工程で行うのですか?
A: 【図4】の(イ)悪用可能性評価と(ウ)影響評価の双方で、「複数脆弱性の組合せ」や「権限昇格後の横展開」をシナリオとして追加します。
A: 【図4】の(イ)悪用可能性評価と(ウ)影響評価の双方で、「複数脆弱性の組合せ」や「権限昇格後の横展開」をシナリオとして追加します。
Q: 「影響は小さい」と判断したサーバでも通知は必要ですか?
A: 重要なのは踏み台や情報搾取の起点にならないかです。今回 R1 サーバは機密情報を持たなくても攻撃拠点にされました。影響評価に“踏み台化”を含めるべきです。
A: 重要なのは踏み台や情報搾取の起点にならないかです。今回 R1 サーバは機密情報を持たなくても攻撃拠点にされました。影響評価に“踏み台化”を含めるべきです。
Q: 月例メンテナンスでまとめてパッチ適用する運用は不適切ですか?
A: 重要度が高い脆弱性や連鎖で重大化し得る脆弱性は、月例を待たずに早期適用する方針を追加する必要があります。
A: 重要度が高い脆弱性や連鎖で重大化し得る脆弱性は、月例を待たずに早期適用する方針を追加する必要があります。
関連キーワード: 脆弱性評価、権限昇格、連鎖攻撃、パッチ管理、インシデントレスポンス


