令和3年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問題 問1 ECサイトの不正アクセス対応とインシデント対応体制の構築

パスワードリスト攻撃とは、あるサイトから漏えいした（または外部で入手した）利用者IDとパスワードの組み合わせのリストを用いて、別のサイトに対して連続してログインを試行するサイバー攻撃です。利用者が複数のサービスで同じIDとパスワードを使い回している傾向を悪用しています。

高得点のポイント

• 外部から入手した（漏えいした） 利用者IDとパスワードのリスト（組み）を利用していることを明記する
• リストを用いて ログインを試行する 攻撃であることを示す
• 総当たり攻撃（ブルートフォース攻撃）やパスワードスプレー攻撃とは異なり、入手済みの正しいIDとパスワードの組みを利用していることを明確にする

図5「判明した被害状況及び対応の概要」の(2) 対応には、「②パスワードリスト攻撃の被害を防ぐ上で必要な、パスワードの安全な設定方法を全会員に案内した。」とあります。
パスワードリスト攻撃は、利用者が複数のサービスで同じID・パスワードを使い回すことを前提とした攻撃です。したがって、この攻撃を防ぐための「安全な設定方法」は、他のサービスと同じパスワードを設定しないこと（使い回しをしないこと）です。パスワードリスト攻撃は他所で漏えいした正しいパスワードを使う攻撃であるため、パスワードを複雑なものにしたり定期的に変更したりするだけでは根本的な対策になりません。

高得点のポイント

• 他のサービスで利用しているパスワードとは 別のものを設定する （使い回さない）という内容を明記する

図5「判明した被害状況及び対応の概要」の(2)には、「③ログインが普段と異なる環境から行われた場合、会員が事前に登録した電子メールアドレスにその旨を通知する」仕組みを導入したとあります。
システムが「普段と異なる環境」を技術的に判定する代表的な手法としては、以下のようなものが挙げられます。

1. IPアドレスによる判定: 接続元のIPアドレスから推定される地理的位置情報を取得し、過去のログイン時の位置情報と比較して、大きく異なる（あるいは非現実的な移動速度である）場合に異常と判定する。
2. Cookieによる判定: 正常にログインした際のWebブラウザに特定のCookieを発行しておき、次回のログイン時にそのCookieの有無や内容を確認することで、過去にログインしたことのない未知の端末やブラウザからのアクセスであるかを判定する。

高得点のポイント

• 判定の基準となる技術的要素（IPアドレス や Cookie）を挙げる
• それを用いて過去のログイン情報（地理的位置の違い や 過去の端末か）とどのように比較・判定するかを明記する

図5(3)「対応を通じて顕在化した課題」において、「N社が提供したログの大半は、記録されていた時刻情報の[ a ]が日本標準時であり、協定世界時に対し時刻情報が[ b ]時間進んだ値で記録されていた。しかし、協定世界時で記録されていたログや、[ a ]を示す情報が記録されていなかったログも存在した。」とあります。
日本標準時（JST）や協定世界時（UTC）のように、共通の標準時を用いる地域や区分のことを タイムゾーン（Time Zone）と呼びます。ログの分析において、各機器のタイムゾーン設定が統一されていないと、時系列の相関分析に支障をきたします。

高得点のポイント

• 日本標準時や協定世界時などの時刻の基準を示す用語として タイムゾーン を解答する

図5(3)「対応を通じて顕在化した課題」の文脈で、「日本標準時であり、協定世界時に対し時刻情報が[ b ]時間進んだ値」とあります。
日本標準時（JST）は、協定世界時（UTC）に対して 9 時間進んでいます（UTC+9）。したがって空欄bには「9」が入ります。

表1の項番2で、「④店舗管理システムは社内LANと分離されているが、社内LANにマルウェアが侵入した場合、店舗管理サーバにもマルウェアが侵入するリスクがある。」と指摘されています。
図2の「注記2」を確認すると、「店舗管理システムと社内LANとは、ネットワークが分離されている。N社の関係部門は、管理用PCを操作して店舗管理サーバを利用する。また、店舗管理システムと社内LANとの間でデータの受渡しが必要な場合は、USBメモリを用いる。」とあります。
したがって、社内LANがマルウェアに感染した場合、データの受渡しに利用されるUSBメモリがマルウェアに感染し、そのUSBメモリを店舗管理システム内の管理用PCに接続することで管理用PCに侵入、さらにそこからネットワーク的に繋がっている店舗管理サーバへとマルウェアが侵入する経路が想定されます。

高得点のポイント

• データの受渡しに用いられる USBメモリ を介して侵入することを明記する
• 接続先である 管理用PC に侵入し、さらに 店舗管理サーバ へ侵入するという順序・経路を示す

表2「N-CSIRTの構成部門」において、空欄cの役割は「基本方針の策定やN社インシデント対応ポリシの承認を担当する。」とされています。
本文の「インシデント対応体制の整備に関する次の記述」の段落に、「N社は、情報セキュリティ委員会を設置している。同委員会は、経営陣が委員となり、情報セキュリティについての基本方針（以下、基本方針という）及び重要な課題を取り扱う。」と記述されています。
また、図6「N社インシデント対応ポリシ案（抜粋）」の(3)や(5)において、「N-CSIRT長は、情報セキュリティ委員会の承認を得る」「事前に情報セキュリティ委員会の承認を得る」とあり、ポリシなどの重要事項の承認機関であることがわかります。
したがって、空欄cには「情報セキュリティ委員会」が入ります。

各選択肢の解説

• ア (IPA): 社外の独立行政法人であり、N-CSIRTの構成部門ではありません。
• イ (JIPDEC): 社外の一般財団法人であり、N-CSIRTの構成部門ではありません。
• ウ (JPCERT/CC): 社外のインシデント対応支援組織であり、N-CSIRTの構成部門ではありません。
• エ (財務経理部): 図1の組織図に存在しますが、基本方針の策定やセキュリティの承認を行う部門としての記述はありません。
• カ (総務部): 図1の組織図に存在しますが、基本方針の策定や承認を担当する記述はありません。
• キ (内部監査室): 図1の組織図に存在し監査を担いますが、基本方針の策定や承認の主体ではありません。

図7はNIST SP 800-61 Rev. 2に基づくインシデント対応のライフサイクルです。このガイドラインが定義するインシデント対応のライフサイクルは、大きく分けて「準備」→「検知と分析」→「封じ込め、根絶、復旧」→「事後活動」の4つのフェーズで構成されています。
図7において「準備」の次のフェーズにある空欄dおよび空欄eは、「検知」と「分析」が入ります。公式解答例ではd・eは順不同なので二つ選ぶ形式にしており、イ（検知）とカ（分析）の両方を選んだときに正解となります。

各選択肢の解説

• ア (開示): ライフサイクルのフェーズ名ではありません。
• イ (検知): d・eに入る正解です。
• ウ (根絶): 「封じ込め」「復旧」と同じフェーズ（空欄f）に入る項目です。
• エ (トレーニング): 「準備」フェーズに含まれる活動の一つです。
• オ (復習): 「事後活動」フェーズ（教訓の学習など）に該当する内容です。
• カ (分析): d・eに入る正解です。
• キ (レビュー): 「事後活動」フェーズで行われる活動です。

図7「インシデント対応のライフサイクル」はNIST SP 800-61 Rev. 2に基づくものです。
「検知と分析」の次に行われるフェーズは、「封じ込め、根絶、復旧」です。図7の3番目の箱には「封じ込め」「復旧」と並んで空欄fがあるため、ここには「根絶」が入ります。攻撃者をシステムから完全に排除する（マルウェアの削除や不正アカウントの無効化など）活動を指します。

各選択肢の解説

• ア (開示): ライフサイクルのフェーズ名ではありません。
• イ (検知): 前段のフェーズ（空欄d, e）に入る項目です。
• エ (トレーニング): 「準備」フェーズで行うべき活動です。
• オ (復習): 「事後活動」フェーズで行う活動です。
• カ (分析): 前段のフェーズ（空欄d, e）に入る項目です。
• キ (レビュー): 「事後活動」フェーズでの活動です。

図8の調査結果より、不正ログインに関する以下の条件が判明しています。

• AC-X（不審な利用者アカウント）の作成と不正ログインは、N社でもV社でもない複数のIPアドレスからSSH接続で行われた。
• N社およびV社からの通信は正規のものだけであった。

図2の注記4より、N社とV社に割り当てられているIPアドレス帯は以下の通りです。

• N社: x1.y1.z1.0/28 (x1.y1.z1.0 〜 x1.y1.z1.15)
• V社: x2.y2.z2.128/30 (x2.y2.z2.128 〜 x2.y2.z2.131)

図9のFW2のインバウンド通信において、サービスが「SSH」である通信を抽出し、接続元IPアドレスがN社およびV社のものであるかを確認します。

1. x2.y2.z2.130 (SSH 320kバイト) : V社の範囲内（正規）
2. x2.y2.z2.129 (SSH 232kバイト) : V社の範囲内（正規）
3. x1.y1.z1.100 (SSH 112kバイト) : N社でもV社でもない（N社の範囲x1.y1.z1.0〜15の外）
4. x2.y2.z2.60 (SSH 48kバイト) : N社でもV社でもない（V社の範囲外）
5. x1.y1.z1.240 (SSH 37kバイト) : N社でもV社でもない（N社の範囲外）
6. x2.y2.z2.58 (SSH 12kバイト) : N社でもV社でもない
7. a2.b2.c2.d2 (SSH 6kバイト) : N社でもV社でもない

これら7つのSSH通信のうち、N社（x1.y1.z1.0/28）とV社（x2.y2.z2.128/30）に該当する2つのIPアドレス（x2.y2.z2.130, x2.y2.z2.129）を除外した残りのIPアドレスが、不正ログインを行った接続元IPアドレスと推測されます。
したがって、該当するIPアドレスは、x1.y1.z1.100、x2.y2.z2.60、x1.y1.z1.240、x2.y2.z2.58、a2.b2.c2.d2 の 5つ です。

表3「脆弱性Lと脆弱性Mの概要」によると、脆弱性Mは「開発支援ツールJ」の脆弱性であり、悪用すると「開発支援ツールJを実行している利用者アカウントの権限で任意のコマンドを実行できる」とあります。
図3「開発用システムの概要」(2)で、「開発支援ツールJは、OSの一般利用者権限を割り当てた利用者アカウントで動作する」と記載されています。つまり、脆弱性Mだけを悪用しても、取得できるのは「一般利用者権限」です。
一方で、“/etc/shadow”ファイルにはパスワードのハッシュ値などの認証情報が格納されており、システムのセキュリティ上、このファイルを閲覧するためには「管理者権限」が必要です。
したがって、一般利用者権限しか得られない脆弱性Mだけでは、“/etc/shadow”ファイルを参照することはできません。そのため攻撃者は、脆弱性L（一般利用者権限から管理者権限での起動が可能になる脆弱性）を組み合わせて悪用し、管理者権限を取得した上で参照したと考えられます。

高得点のポイント

• 脆弱性Mの悪用によって得られる権限が 一般利用者権限 であることを明記する
• “/etc/shadow” ファイルを参照するには 管理者権限が必要である という性質を明記する
• これら2つの理由から、権限が不足しているため参照できないという論理構成にする

図10(2)において、「⑦R1サーバをインターネット経由で操作するために設定を変更した。」とあり、直後に「AC-Xを利用してSSH接続でR1サーバにログインした。」と続いています。
図3(3)「R1サーバへの接続制御」には、「R1サーバの“/etc/hosts.allow”ファイルの設定において、SSH接続の接続元をN社とV社に限定している。このファイルの変更には、管理者権限が必要である。」と記載されています。
攻撃者は、管理者権限で利用者アカウントAC-Xを作成した後、N社やV社以外の外部（インターネット上）からSSH接続を行うために、アクセス制限を行っている “/etc/hosts.allow” ファイルを書き換え、攻撃者の接続元IPアドレスを許可するように設定を変更したと考えられます。

高得点のポイント

• 変更対象のファイルが “/etc/hosts.allow” ファイル であることを明記する
• 変更内容が 攻撃の接続元IPアドレス（インターネット経由のIPアドレス）を追加・許可する ことであることを明記する

図10(3)に、「F1ファイルはフォレンジック調査によって復元でき、サイズは320kバイトであった。F1ファイルには、ツールXが8個のIPアドレスをスキャンした結果が格納されており、IPアドレスごとの出力結果は固定長であった。」と記載されています。
ここから、1個のIPアドレスあたりのスキャン結果のデータサイズは、320kバイト ÷ 8個 = 40kバイト と計算できます。

図9のアウトバウンド通信の表を確認すると、R1サーバから外部へのHTTP通信として以下の2つの大きな通信が記録されています。

• 宛先 a2.b2.c2.d2：通信量 960kバイト
• 宛先 a1.b1.c1.d1：通信量 320kバイト

F1ファイルは、IPアドレス「a1.b1.c1.d1」のサーバにアップロードされたことが分かっています。図9のアウトバウンド通信でも、a1.b1.c1.d1への通信量が320kバイトとなっており、F1ファイルのサイズと一致します。
したがって、残るもう一つの大きなファイル「F2ファイル」は、宛先「a2.b2.c2.d2」にアップロードされた通信量 960kバイト のファイルであると推測されます。

ツールXのスキャン結果はIPアドレスごとに固定長（1個あたり40kバイト）であるため、F2ファイルに格納されているIPアドレスの数は、
960kバイト ÷ 40kバイト = 24個 となります。

下線⑨は、「SSH接続及びHTTP接続を使った攻撃から開発用システムを保護するための措置」を指しています。
図3(1)「開発用システムの接続制御」によると、「インターネットからのインバウンド通信は、FW2において、各サーバへのSSH接続及びHTTP接続を許可し、その他の通信を遮断している。」とあります。つまり、現在のFW2の設定では、インターネット上のどのIPアドレスからのSSH・HTTP接続も許可されてしまっています。（サーバ側の /etc/hosts.allow で制限していても、ネットワークの入り口であるFW2では制限されていません）。

これを防ぐためには、開発用システムを利用する正当な利用者（N社およびV社）からの接続のみを、ネットワークの入り口であるファイアウォール（FW2）で許可する設定に変更する必要があります。

高得点のポイント

• 対策を実施する機器が FW2 であることを明記する
• インターネットからの インバウンド通信 に対して制限をかけることを示す
• 許可する通信元を正規の利用者である N社とV社からの通信だけ に限定することを明記する

下線⑩では、脆弱性管理プロセス（図4のイ・ウ）における「悪用される可能性」または「影響」の評価において、観点が不足していたことが指摘されています。
インシデントQの事例（表3および図10）を振り返ると、以下のような過小評価がありました。

1. 悪用される可能性の過小評価: 脆弱性L単独では「R1サーバにSSH接続してログインする必要があり，脆弱性Lが悪用される可能性は低い」と評価していましたが、実際には脆弱性M（HTTP接続で任意のコマンドが実行可能）と同時に悪用されました。つまり、「複数の脆弱性が同時に悪用される可能性」を考慮していませんでした。
2. 影響の過小評価: 脆弱性Mは一般利用者権限で動作するため影響は小さいと評価されていましたが、対応を見送った脆弱性L（一般利用者権限から管理者権限でプログラムを起動できる）が残っていたため、組み合わせで管理者権限を取られ、/etc/shadow の参照・AC-X の作成・hosts.allow の変更・外部へのスキャンにつながりました。つまり、「対応を見送った脆弱性の影響の観点」が不足していました。

これらのいずれかの観点を記述します。

高得点のポイント

以下のいずれかの観点を含めること。

• 悪用される可能性の観点：単独ではなく 複数の脆弱性が同時に悪用される可能性
• 影響の評価の観点：対応を見送って残っている脆弱性と組み合わさった場合の影響を考える 対応を見送った脆弱性の影響の観点