インシデントから復旧したら、もう安全？——初動・封じ込め・根絶・復旧・再発防止を午後の問われ方で読む｜支援士解説4の3

この記事の重要度：Sランク（午後で繰り返し主役になる最重要の分野）

この記事で分かること：

• 初動・トリアージ・封じ込め・根絶・復旧・再発防止が、それぞれ何を変えるための仕事か
• アカウントの停止と既存のセッション、バックアップの時点、再開の条件など、午後で問われる判断の分かれ目
• 解答欄に書く「原因」と「対策」の型

シラバスとの対応：小項目4-3「情報セキュリティインシデントへの対応」。CSIRTの体制は支援士解説4の1、ログの読み方は支援士解説3の4、マルウェアの動きと解析は支援士解説3の2、証拠保全とフォレンジックは支援士解説4の4、社外への公表は支援士解説1の7で扱います。

---

午後の問題では、インシデントが起きた場面から「まず何をするか」「何を調べるか」「どうなったら再開してよいか」がよく問われます。感染した端末をどう切り離すか、不正に使われたアカウントをどう止めるか、被害を受けた利用者をどう特定するか、どの時点のバックアップから戻すか。どれも、止める・取り除く・戻すという目的の違う仕事を、混同せずに進められるかが試されています。

この記事では、インシデント対応を目的ごとの仕事に分け、それぞれで何を確かめれば次へ進めるかを整理します。

1. 対応を、目的の違う仕事に分ける

インシデント対応の流れ

インシデント対応は、起きる前の準備から始まっています。連絡体制と手順を決め、調査に必要なログを取得・保存しておかなければ、いざというときに動けません。起きたときは、おおむね次の流れで進みます。

1. 検知・受付：監視の仕組みや、職員・利用者・外部からの連絡で事象を把握する
2. トリアージ：対応が必要か、どれから対応するか、誰が担当するかを決める
3. 封じ込め：進行中の被害や、ほかへの広がりを止める。あわせて影響の範囲を調べ、証拠を保全する
4. 根絶：原因となった不正なプログラムや、侵入口を取り除く
5. 復旧：安全を確かめながら、システムと業務を再開する
6. 報告・再発防止：関係者への報告と、対応の振り返り

ただし、一つずつ順番に終わらせるものではありません。原因の究明よりも、封じ込めによる被害の拡大防止を優先し、調査と並行して進めます。優先するといっても、証拠を捨ててよいわけではありません。再起動や初期化をすると消える情報は、封じ込めと並行して保全します。

封じ込め、根絶、復旧は何を変えるのか

封じ込めとは、進行中の不正な操作や他のシステムへの波及を抑えることです。感染が疑われる端末の通信を制限する、不正利用されたアカウントを止める、危険な機能を一時停止する、といった対応が候補になります。

根絶とは、インシデントを引き起こした不正な要素や、再び悪用される原因を取り除くことです。不正プログラムの除去、侵害された環境の再構築、悪用された脆弱性の修正などが含まれます。脆弱性は、攻撃に利用され得るソフトウェアや設定などの弱点です。

復旧とは、影響を受けたシステムや業務を、必要な安全性と機能を確かめながら再開することです。単に機械が起動する状態へ戻すだけではありません。正しいデータを扱え、必要な利用者が使え、不正なアクセスを受けない条件を整えます。

例えば、ファイルを勝手に書き換える端末があるとします。ネットワークから隔離するのは、共有先への書換えを抑えるためです。端末を信頼できる状態から作り直し、侵入に使われた弱点を修正するのは、根絶に当たります。業務データを確認して利用を再開するのが、復旧です。

同じ操作でも、目的や時点によって役割が重なる場合があります。アカウントを無効化する操作は、今の不正アクセスを止める封じ込めにも、不要な侵入経路を取り除く根絶にも関係します。操作名だけを暗記するより、何を防ぎ、どの状態まで変えるための操作かを読み取ると整理できます。

NIST SP 800-61 Rev.3は、封じ込め・根絶をRS.MI、復旧をRC.RPで扱います。2025年4月のRev.3は、サイバーセキュリティのリスク管理の枠組みであるCSF 2.0に沿って整理されています。古いRev.2の四段階モデルを、現行版そのものの構成として説明しないようにします。NIST「SP 800-61 Rev.3」、RS.MI・RC.RP

調査が終わってから、すべての対応を始めるわけではない

原因調査には時間がかかります。不正な操作が進んでいるのに、攻撃者や全被害の特定が終わるまで待つと、守れたはずの情報まで失うかもしれません。

一方、急いで初期化すれば、何が起きたかを示す情報が消えます。調査ができなくなると、同じ問題が他にも残っているか、安全な再開条件は何かという判断も難しくなります。

そこで、実務では調査・保全・業務調整・報告を並行して進め、新しい事実で判断を更新します。本稿では、次のように整理します。

• 技術担当は、危険な通信や操作を制限し、必要な記録を保全しながら影響範囲を調べます。
• 業務担当は、停止の影響、優先して守る業務、使える代替手段を整理します。
• CSIRTは、情報を集約し、担当間の作業と判断の順序を調整します。
• 責任者は、権限に応じて停止・費用・再開などを判断します。
• 法務や個人情報保護の担当、広報担当は、報告・通知・公表の要否と内容を確認します。

CSIRTは、組織のインシデント対応を調整するチームです。すべての操作や対外説明を一人で担う意味ではありません。体制が小さい組織で役割を兼ねる場合も、誰の判断として何を決めたかは分けて記録します。

対応計画は、作業一覧に判断条件を加える

例えば「共有機能を止める」だけでは、担当者によって止める範囲が変わります。「対象フォルダの外部共有を一時停止する。業務担当へ利用不可の機能を伝える。停止後に既存の共有リンクでも取得できないことを確認する」とすれば、実施と確認が具体的になります。

計画には、目的、対象、実行者、承認者、実施時刻、期待する結果、業務への影響、失敗した場合の次の手段を入れます。再開や解除の条件も必要です。時間がたったから自動的に元へ戻すのではなく、危険が残っていないかを判断します。

一度決めた計画も、新しい事実が出れば更新します。ただし、各担当が別々に変更してはいけません。変更理由と影響を共有し、例えば一方が通信を遮断している間に別の担当が試験のため接続を戻す、といった衝突を防ぎます。

準備：起きる前に決めておくこと

• 連絡体制：報告先、夜間・休日の連絡先、外部からの通報を受ける窓口、委託先や専門家への依頼の方法
• 手順と権限：誰が、どの条件で端末を切り離し、サービスを止められるか
• ログ：どの機器で、どの種類のログを、どれだけの期間保存するか。機器の時刻を合わせ、タイムゾーンをそろえる
• 業務の代替手段：止めたときに、どの業務をどう続けるか

午後での問われ方

• 平成30年度秋期 午後II問2：インシデント対応の準備と調査が題材でした。ログの取得方針で決める事項として「ログを取得する機器」「取得するログの種類」「保存期間」、ログに記録する時刻について「タイムゾーン」を「統一」することが、解答例に示されています。

採点講評で指摘されたつまずき

• 平成30年度秋期 午後II問2では、タイムゾーンを問う設問の正答率が低かったとされています。ログの間で時刻のタイムゾーンが異なると、認識の違いによって調査が難航する場合があります。

【図1】対策は、何を変えるためのものか

2. 初動：見つけた人が動き、受け付けた人が判断する

事象・アラート・インシデントを分ける

• 情報セキュリティ事象：ログインの失敗、権限の変更、大量のファイル取得など、セキュリティに関係する出来事。通常の業務でも起きるので、それだけでは不正とは限らない
• アラート：監視の仕組みが、決めた条件に当てはまったと知らせる警告
• インシデント：情報や業務の安全を脅かし、組織として対応が必要な事態。被害が確定したものだけでなく、侵害のおそれがあるものも含めて判断する

アラートは結論ではなく、調べる入口です。正しく検知されても、承認された作業による正当な操作だった、ということもあります。逆に、アラートが出ていないことは、安全を確かめたことにはなりません。監視していない範囲や、記録していない操作があるからです。

見つけた人が行うこと

警告が出た、ファイルが開けなくなった、身に覚えのない操作の通知が来た。こうしたとき、気付いた職員が感染の有無を自分で確かめる必要はありません。

• 不審なファイルの再実行や、普段どおりの利用を止める
• 決めておいた連絡先へ、分かる範囲の事実を速やかに報告する。端末、利用者、時刻、画面の表示、直前の操作、すでに行った対処など。すべてを調べ終えるまで報告を待たない
• 手順で決めていれば、ネットワークから切り離す。有線のケーブルを抜いても、無線LANがつながっていれば切断したことにならない
• 電源を切る、ファイルを削除する、初期化する、といった操作を自分の判断で行わない。メモリ上の情報など、調査に必要な証拠が失われる
• 不審なファイルを同僚へ転送したり、公開の解析サービスへ送ったりしない

端末が侵害されている可能性を考え、電話など別の連絡手段も用意しておきます。

順番を機械的に待つのではなく、報告と被害拡大防止を速やかに進めます。職員は再実行・通常利用を止め、手順で定めた通信切断を行います。担当者は対象と隔離結果を確認し、残る通信や進行中の被害、周辺端末・アカウントも調べます。責任者は、専門家と証拠保全を調整し、停止範囲と代替業務、復旧・再開の条件を判断します。電源断・削除・初期化を、独断の一律対応にしません。隔離不能や破壊継続などの例外も、被害と証拠を踏まえて事前に手順化しておきます。確証を待って、報告を遅らせないことも大切です（図2）。

【図2】感染の疑いが出たら、事前手順で動く

ランサムウェアの初動

ランサムウェアの疑いでは、共有フォルダやバックアップへの暗号化の広がりを止めることを急ぎます。感染した端末の切り離しに加え、共有フォルダへの接続の切断、バックアップの保管先の保護を確かめます。暗号化と並行して情報が盗み出されている可能性もあるので、外部への通信の記録も保全します。身代金の支払いや攻撃者との交渉を、個人の判断で進めてはいけません。

電源の扱いにも理由があります。ランサムウェアの種類によっては、暗号化に使った共通鍵がメモリ上に残っていることがあり、電源を切ると失われます。

報告を受ける側の準備

報告を受ける側は、受け付けた時刻、報告者、内容を記録し、確認済みの事実と推測を分けて整理します。必要なら、報告者に追加の操作をさせる前に、何を残すべきかを伝えます。報告した職員を責める運用では、次から報告が遅れます。早い段階で相談してよいことを、日頃から伝えておきます。

トリアージ：何から対応するか

トリアージは、受け付けた事案を評価し、対応が必要か、どれを優先するか、誰が担当するかを決めることです。すべての事案に同じ力をかけることはできないので、判断の基準を前もって決めておきます。優先度は、次の観点を分けて考えます。

• 影響：どの情報や業務に、どのような被害があるか（機密性・完全性・可用性）
• 緊急性：被害が今も進んでいるか、対象や権限が広がっているか
• 確度：その見立てを、どれだけ確かな情報が支えているか

例えば、管理者アカウントが不正に使われている疑いは、確度がまだ低くても、影響が大きいので急いで調べます。監視製品が付ける「Critical」などの重大度は、そのまま組織の対応の優先度ではありません。最初の評価は、新しい事実が分かるたびに見直します。

組織の中では、ログや通信を監視して異常を見つけるSOC、対応全体を調整するCSIRT、自組織が提供する製品の脆弱性に対応するPSIRTなどが役割を分けます。体制は支援士解説4の1で扱います。

午後での問われ方

• 令和3年度秋期 午後I問3：サーバへのログインの失敗が多数記録されていたPCについて、マルウェアの感染拡大を防ぐ初動として、解答例は「LANから切り離す」です。デジタルフォレンジックスのために取得する情報は「ディスクイメージ」とされています。切り離したPCは、別のPCでダウンロードした最新のマルウェア定義ファイルを保存したDVD-Rで定義ファイルを更新してから、フルスキャンします。追加調査の範囲は「Q社内の全てのPC及びサーバからのアクセス」です。
• 令和3年度秋期 午後II問2：化学分野のコンソーシアムに加盟する会員（研究機関・大学・企業）にもマルウェアが広がったテレワークのインシデントが題材でした。対処の優先度を上げる会員を絞り込むための記録として、解答例は「連携端末以外のIPアドレスを送信元とする通信記録」です。連携用の端末以外の機器にまで感染が広がった会員を、先に対処します。

• 令和元年度秋期 午後I問3：監視サービスからC&Cサーバへの通信の通知を受けたときの手順が題材でした。PCの電源が入っていれば入れたままにし、LANケーブルを抜いて切り離し、C&CサーバのIPアドレスへの通信をファイアウォールで拒否し、通信のデータサイズから情報漏えいのおそれを判断し、EDRの記録でマルウェアを特定してハッシュ値で実行を禁止します。電源を入れたままにする理由は「メモリ上の情報が失われないようにするため」です。
• 平成29年度秋期 午後I問1：ランサムウェアの感染が題材でした。暗号化に使った共通鍵をメモリ上から消去しない種類のランサムウェアについて、PCをハイバネーション機能で休止状態にして保管する理由として、通常どおり電源を切ると「PC内で一時的に作成されたメモリ上の共通鍵が消えてしまうため」が問われています。復号のツールが後で提供されたときに、復号できる場合があるからです。

採点講評で指摘されたつまずき

• 令和3年度秋期 午後II問2では、対処の優先度を上げるべき会員を絞り込む条件を明示できていない解答が散見されたとされています。最終的には被害対象に漏れなく対処しますが、被害の拡大を防ぐために、優先度を付けて対処することが重要です。

記述の型

• 感染が疑われる端末の初動：「ネットワークから切り離す（無線LANも含めて）。電源は切らない」
• 電源を切らない理由：「メモリ上の情報が失われないようにするため」
• 優先度を付ける観点：「影響の大きさ、被害が進行しているか、情報の確度」

3. 封じ込め：何を止めたかまで確かめる

端末を隔離すると、どの被害を抑えられるのか

端末のネットワーク隔離は、他の端末への感染拡大、共有ファイルへの不正な操作、外部への通信などを抑えるために行います。物理的に接続を外す方法、ネットワーク機器で通信を制限する方法、端末の監視・対応製品で隔離する方法などがあります。

EDRは、端末で起きる活動を記録・検知し、調査や対応を支援する仕組みです。EDRの隔離機能を使う場合も、管理用の通信が残るのか、どの通信を制限するのかは製品と設定によって確認します。「隔離」という表示だけで、あらゆる経路が止まると決めつけないようにします。

例えば、LANケーブルを抜いてもWi-Fiが接続されたままなら、その経路が残る可能性があります。また、端末の外部通信を止めても、既に端末内で動く不正プログラムによるローカルファイルの破壊まで止まるとは限りません。

この違いは重要です。隔離は対処の手段であって、あらゆる被害を止める一つの万能操作ではありません。止めたい行為を先に特定し、その行為に使われる経路を制限します。

アカウントと接続を分けて考える

クラウドサービスでは、職員の端末を隔離しても、盗まれた認証情報を使う別の端末からアクセスが続く可能性があります。認証情報とは、パスワードや認証に使う鍵など、利用者やシステムがアクセスを許されるための情報です。本稿では、これらを資格情報とも呼びます。

また、パスワード変更後も、既に成立したセッションや発行済みのトークンが使えるかは、サービスの設計で異なります。セッションは、ログイン後の利用状態を継続する仕組みです。トークンは、認証やアクセス権限などを表してサービスとのやり取りに使うデータです。

確認する対象は、少なくとも次のように分かれます。

• 新しいログインを止める操作。
• 既存のセッションやトークンを無効にする操作。
• パスワード、鍵、APIキーなど、悪用された可能性がある情報の更新。
• 攻撃者が追加した認証方法、アプリ連携、共有設定などの確認と除去。

APIキーは、プログラムからサービスを利用する際の認証等に使われる値です。職員のログイン用パスワードとは別に管理されている場合があるので、片方を変えても、もう片方が無効になるとは限りません。

Microsoftのアクセス取消しの説明でも、認証基盤が発行するトークンとアプリ独自のセッションを区別し、取消しの開始から実際に効くまでの差を説明しています。これは一つの製品例であり、すべてのサービスに同じ有効時間や操作を当てはめるものではありません。Microsoft Learn「Revoke user access in Microsoft Entra ID」、Access tokens and refresh tokens・Session tokens、2026年9月21日確認

通信先を一つ止めただけでは、全体を止めたことにならない

マルウェアが指示の受信や情報の送信に使う通信を、C&C通信（C2通信とも）と呼びます。C&CはCommand and Controlの略です。確認された宛先への通信遮断は有効な対策になり得ますが、別の宛先、別のアカウント、既に侵害された内部の機器が残っている可能性もあります。

遮断リストの追加は、その時点で確認した経路への対処です。影響範囲の調査を続け、遮断後にどの通信が減り、どの活動が残ったかを確認します。共有基盤のIPアドレスを広く止めれば、無関係の正当なサービスまで使えなくなる場合もあるため、遮断範囲と業務影響を合わせて判断します。

電源を切るかどうかは、状況と手順で判断する

電源を切ると、メモリ上の情報など、後で取り戻せない情報が失われる場合があります。だからといって、被害が進んでも絶対に切らないという覚え方も適切ではありません。

人の安全に関わる危険、破壊の進行、隔離できる手段、保全に必要な時間を考慮します。一般の利用者は、定められた緊急手順に従って報告・対処し、不審なファイルの再実行や独自の解析は行わないようにします。専門担当は、可能な範囲で揮発性情報の保全と拡大防止を調整します。

CISAのランサムウェア対応ガイドでは、感染拡大防止のための切断を扱い、他の手段で切り離せない場合の電源断について、揮発性の証拠を失う点と合わせて説明しています。特定の状況への指針であり、すべてのインシデントで一律に電源を切るという意味ではありません。CISAほか「#StopRansomware Guide」2023年9月、Part 2の初期対応

実行後に確認する四つのこと

本稿では、封じ込めの確認を次の四つに分けます。

• 指示した操作が対象へ反映されたか。端末がオフラインで命令を受け取っていない、といった状態を区別します。
• 止めたかった操作が実際に止まったか。新規ログインだけでなく既存接続も確認します。
• 別の経路や対象に同じ活動が残っていないか。
• 正当な業務にどの影響が出たか。代替手段と次の判断時刻を担当へ伝えます。

実施後の確認では、有線以外の接続経路や隔離手段の違い、既知の宛先以外の通信、別経路での同じ活動も見ます。操作の成功通知は一つの証拠ですが、それだけでは目的達成の証拠にならないことがあります。制御の状態と、実際の活動の両方を見るのがポイントです。

証拠を保全する

封じ込めと並行して、調査に必要な情報を、消える前に保全します。

• 揮発性の高い情報：メモリの内容、実行中のプロセス、ネットワークの接続の状態。電源を切ったり再起動したりすると失われるので、先に取得する（メモリダンプ）
• ディスク：ディスクイメージを取得し、原本ではなく複製で調べる
• ログ：端末・サーバ・ネットワーク機器・クラウドのログを、保存期間で消える前に確保する。委託先やクラウド事業者には、保存を早めに依頼する
• 記録：取得した日時・担当者・方法と、ハッシュ値を残し、取得後に改変されていないことを示せるようにする

証拠保全の手順とフォレンジックは支援士解説4の4で扱います。

【図3】封じ込めは、対象・経路・効果を確かめる

午後での問われ方

• 令和6年度秋期 午後問1：ソフトウェア開発会社で、マルウェアに感染した仮想PCが見つかった場面が題材でした。感染の拡大とファイルの送信を防ぐ暫定対策として、ドメインサーバで、マルウェアがRDP接続に使っていたドメインのアカウント「ad01\user019」を「無効化」すること、プロキシサービスで、全てのドメインユーザーに対して攻撃者のサーバのURLを管理者拒否リストに登録することが、解答例に示されています。マルウェアは、つながらない接続先から別の接続先へ切り替える動作をしていたので、確認した通信先を一つ止めるだけでは足りません。
• 平成30年度秋期 午後II問2：マルウェアが検知されたPCを、すぐにネットワークから切り離す場面が題材でした。切り離すと失われる情報として「問題PCのネットワークインタフェースや通信の状態についての情報」、それを補う措置として「メモリダンプを取得する」が、解答例に示されています。

採点講評で指摘されたつまずき

• 平成30年度秋期 午後II問2では、マルウェアが検知されたPCをすぐに切り離すことの長所と短所を問う設問の正答率が低く、それを正しく理解したうえで、検知時の初動を設計してほしいとされています。

記述の型

• 不正利用されたアカウントへの対応：「アカウントを無効化し、既存のセッションやトークンも無効にする」
• 外部への通信の遮断：「プロキシやファイアウォールで、攻撃者のサーバへの通信を拒否する」
• 切り離す前の保全：「メモリダンプを取得する」
• 封じ込めの確認：「止めたかった操作が実際に止まり、別の経路に同じ活動が残っていないかを確認する」

4. 原因と影響の範囲を調べる

何を知るために、どの記録を調べるのか

調査では、まず知りたいことを具体化します。「すべてのログを調べる」では、何を確認できたら次の判断へ進めるかが曖昧です。

例えば、不正なファイル取得が疑われる場合は、いつ、どのアカウントと端末から、どの経路を使い、何へアクセスしたかを確認します。さらに、認証方法や権限が変更されていないか、他のシステムへ接続していないか、取得以外の書換えや削除がないかを調べます。

対象ごとに、見える情報が違います。

• システム・端末：プロセスの起動、ログイン、権限変更、ファイルの生成・変更、サービスや自動起動設定。
• ネットワーク：通信元と宛先、時刻、許可・拒否、接続の状態、通信量、名前解決やアドレス割当て。
• ソフトウェア・業務サービス：アプリの操作履歴、API要求、処理結果、対象データ、出力や取得の記録。
• クラウドの管理面：管理者操作、認証方法、アプリへの権限付与、共有設定、監査ログ設定の変更。
• 業務上の記録：承認済み作業、担当者の説明、委託先の作業履歴、当日の業務予定。

プロセスは、実行中のプログラムです。名前が正当なソフトウェアと同じでも、それだけで安全とは判断できません。保存場所、実行主体、親プロセス、起動時刻、実際の通信などを合わせます。親プロセスは、そのプロセスを起動した側を示し、何をきっかけに動いたかを考える手掛かりになります。

例えば、文書閲覧ソフトの操作直後に、想定していないプログラムが起動して外部へ通信した記録があれば、関連を調べる理由になります。ただし、それだけで文書が原因だったと確定はできません。正当な連携機能や別の起動要因も含めて照合します。

時系列と影響範囲を、途中で広げ直す

調査の結果には、情報源・期間・確認範囲・不明点を記録し、確認済み・疑い・未調査を区別します。作業予定や担当者の説明と照合することも、背景を知る手掛かりになります。

検知された時刻は、攻撃が始まった時刻とは限りません。9時に暗号化を見つけても、その前日に不正なログインや情報取得が起きていた可能性があります。調査開始時の範囲を固定せず、新しい記録を起点に過去や関連システムへ広げます。

時刻はタイムゾーン、時計のずれ、発生時刻と収集時刻を区別します。アカウントとIPアドレスだけで人物を確定しないことも、前回と同じです。結果には、調べた期間、ログの種類、取得できなかった部分、判断の根拠を添えます。

見つからない理由も大切です。監査対象に含まれていなかった、保存期間を過ぎた、設定が変更された、委託先からまだ届いていない、といった状態を「不正操作なし」と書き換えてはいけません。

調査範囲は、同じ弱点、同じ資格情報、同じ管理者、同じネットワーク経路などを手掛かりに広げます。すべてを同じ深さで調べる必要があるとは限りませんが、除外する場合にも理由が必要です。

被害と損失を、件数だけで表さない

機密性の被害は、情報が許可されない相手へ知られることです。完全性の被害は、情報や処理が不正に変更され、正しさを損なうことです。可用性の被害は、必要なときに情報や機能を使えなくなることです。

例えば、申請情報を扱うサービスが半日止まった場合、停止時間だけを報告しても、影響は十分に伝わりません。受付期限に間に合わない人がいるのか、代替受付ができるのか、未処理案件を後で処理できるのかを業務担当と確認します。

損失には、調査・復旧にかかる費用、追加の人件費、代替サービス費用、再入力や問合せ対応の負担などがあります。推計する場合は、単価、人数、時間、未確定の費用を明示します。職員の時間を費用へ換算した値と、実際に外部へ支払う金額は分けて示す方が、予算担当者が必要な支出を判断しやすくなります。

信頼低下や住民への不利益は、根拠なく金額へ置き換えません。確認された困りごと、追加の手続、待機や再来庁の負担など、具体的な内容を説明します。同じ対象者が複数のファイルに含まれることもあるため、ファイル数、レコード数、人数も区別します。

発生したことと、発生し得ることを分ける

マルウェアに情報送信機能があると判明しても、自組織から実際に情報を送ったとは限りません。一方、その機能を今回の解析で観測できなかったからといって、情報流出がなかったとも言えません。

調査結果は、例えば次のように分けます。

• 確認済み：対象サービスで、指定フォルダの出力と取得完了を示す記録がある。
• 可能性：取得物に機微な相談内容が含まれる可能性があり、内容を照合中。
• 未確認：別の共有経路からの取得の有無は、提供待ちのログで確認する。

「影響は最大で何件」と表す場合も、その範囲に入る条件を示します。単なるアクセス権の範囲と、実際に取得された範囲を一つの数字へまとめないようにします。

根本原因は、最初に見つかった弱点だけではない

不正なログインを可能にした直接の原因が、ある資格情報の窃取だったとします。それだけでは、再発防止策は「パスワードを変える」で止まりがちです。

さらに、なぜその情報で重要な操作ができたのか、不要な権限が残っていなかったか、異常を検知できる設定だったか、例外の期限を管理していたかを確認します。根本原因を探る目的は、個人を責めることではなく、同じ条件が残らないようにすることです。

ただし、証拠のない推測を原因として書いてはいけません。例えば「教育不足」と決める前に、実際の操作、画面表示、業務上の制約、利用できた安全な方法、承認や設定の状態を調べます。原因が複数ある場合は、無理に一つへまとめません。

FIRSTのCSIRT Services Framework v2.1の6.2.4も、弱点の存在や悪用を可能にした条件を調べることを根本原因分析として扱っています。FIRST「CSIRT Services Framework v2.1」、6.2.4

マルウェアの解析は、調査の問いに答えるために

検体の解析は、マルウェアの名前を当てることが目的ではありません。どの条件で動くか、何を変更するか、どこへ通信するか、再起動後も動く仕掛けがあるか、ほかの端末へ広がるか、情報を取得・送信する機能があるか。その結果を、調査の範囲と対策の候補へ変えます。例えば「自動起動の設定を残す」と分かれば、ほかの端末にも同じ設定がないかを調べます。

解析は、業務環境から切り離した管理された環境で行います。短時間の解析で通信が見えなかったことは、通信の機能がないことの証明ではありません。静的な解析と動的な解析の違い、解析環境を見抜くマルウェアは支援士解説3の2で扱います。

【図4】調査を、被害と原因の判断へつなげる

午後での問われ方

• 令和6年度秋期 午後問3：ECサイトの決済の画面が改ざんされ、入力したクレジットカード情報が外部へ送られていた事案が題材でした。攻撃者がクレジットカード情報を手に入れる方法として、解答例は「Webサーバのアクセスログのリクエスト URIから情報を取得する」です。カード情報は攻撃者のWebサーバへの要求のURIに含めて送られ、そのサーバのアクセスログに残ります。影響を受けた利用者の候補を、影響のあった期間のアプリケーションログから抽出するときの対象は「配送先・支払方法選択画面にアクセスしたアカウント名」です。
• 令和6年度秋期 午後問1（3.と同じ問題）：感染したPCから別のPCへのRDP接続が成功していた記録から、そのPCにも同じ調査を行うこと、プロキシサービスのログで、ほかに感染しているホストがないかを調べることが、追加調査として示されています。

攻撃の痕跡（ここでは改ざんされた画面へのアクセス）を、ログから全件探すのが、影響範囲を特定する基本です。その際、改ざんや侵入が始まった時点と、封じ込めた時点の間のログを調べること、痕跡があっても実際に情報を入力・送信したとは限らないこと、ログが残っていない期間があればそのことを明らかにすることに注意します。ログの読み方は支援士解説3の4で扱います。

記述の型

• 影響範囲の特定：「影響のあった期間のアプリケーションログから、該当する画面にアクセスしたアカウントを洗い出す」
• 調査の期間：「侵入や改ざんが始まった時点から、封じ込めた時点までのログを調べる」
• ログが見つからないとき：「記録の対象外か、保存期間を過ぎたかを確かめ、被害なしとは判断しない」

5. 根絶：攻撃者が戻る手段を残さない

攻撃者が戻るための手段を残さない

不正なプログラムを削除しても、再び実行させる仕掛けや、別のアクセス手段が残っていると再発する可能性があります。再起動やログアウト後もアクセスや実行を維持する仕掛けを、永続化と呼びます。

調べる対象は、例えば不審な自動起動設定、追加されたアカウントや鍵、権限の変更、不正なアプリ連携などです。どの対象を確認すべきかは、侵害された環境と調査結果から決めます。「マルウェアを検出しなくなった」という結果だけで、すべての不正な要素が除去されたとは判断しません。

また、入口が残れば、同じ攻撃を再度受ける可能性があります。悪用された脆弱性、公開範囲、不要な機能、資格情報の扱いなどを是正します。パッチを適用しても、既に作られた不正アカウントや盗まれた情報が自動的に元へ戻るわけではありません。

修復するか、再構築するか

既存環境から不正な要素を取り除く方法と、信頼できる基盤から作り直す方法があります。選択には、侵害の深さ、調査の確度、構成情報の有無、復旧に使える資源、業務への影響が関わります。

例えば、管理者権限まで侵害され、何が変更されたか十分に確認できない環境なら、一つずつ削除して安全を確かめることが難しくなります。その場合は、信頼できる構成からの再構築を検討します。

ただし、再構築も、それだけで完了ではありません。元と同じ弱点を含むイメージや設定を戻せば、再び侵入される条件が残ります。移すデータ、設定、鍵、アプリの版を確認し、必要な修正を反映します。旧環境の調査用情報を保全する段取りも必要です。

NIST SP 800-61 Rev.3のRS.MI-02は、永続化や侵入口、悪用された脆弱性の除去を扱います。本稿では、それを実行する際の問いとして、何を除去したか、どの関連環境を調べたか、何がまだ不明かを記録することを勧めます。NIST「SP 800-61 Rev.3」、RS.MI-02

資格情報は、安全な環境から更新する

侵害された疑いのある端末で新しいパスワードや鍵を入力すれば、新しい情報まで取得されるおそれがあります。更新操作は、信頼できる管理端末と経路から行い、対象サービスでの失効や権限変更が反映されたことを確認します。

業務用の連携アカウントを更新する場合には、その情報を使う処理を把握します。夜間バッチ、データ連携、バックアップなどが古い情報を持っていれば、次の実行時に止まるかもしれません。更新先、更新の順序、動作確認、旧情報の失効を一緒に計画します。

すべてのアカウントを無条件に同じ手順で変更するのではなく、漏えいや悪用の可能性、権限、共有・依存関係を調べて範囲を決めます。広く侵害された可能性がある場合は範囲も広がりますが、その理由と業務影響を判断者へ伝えます。

暫定対策には、期限と恒久対応を結び付ける

すぐにパッチを適用できない場合、一時的な接続制限や機能停止で悪用条件を狭めることがあります。ただし、使えない機能をそのまま放置したり、制限の解除だけを先に行ったりすれば、別の問題が生まれます。

暫定対策の記録には、対象、守る条件、残るリスク、期限、担当、恒久対策への移行条件を入れます。例えば「管理画面を指定した管理経路からだけ利用可能にする。修正後の試験完了まで継続し、一般公開へ戻す必要性も再検討する」という形です。

再開に必要な技術上の原因修正と、時間をかけて行う組織的な再発防止は、完了時期が違う場合があります。後者が残っているから何も再開できないと決めるのでも、前者が済んだから改善は不要とするのでもなく、作業と判断を分けて管理します。

【図5】根絶は、不正ファイルの削除だけではない

午後での問われ方

• 令和4年度秋期 午後I問2：Javaのログ出力ライブラリの脆弱性を悪用され、予約サーバから外部へ不正な通信が発生した事案が題材でした。対応として、予約サーバはOSと必要なソフトウェアをクリーンインストールしてバックアップデータから復旧し、予約サーバと会員サーバに脆弱性修正プログラムを適用しています。再発防止策として、予約サーバからインターネットへの通信をプロキシサーバ経由に限定し、URLフィルタリングで接続先を絞ります。修正までの攻撃の条件の読み方は支援士解説3の6で扱います。

記述の型

• 根絶の注意点：「パスワードの変更は、侵害されていない端末から行う」
• 再構築の注意点：「元と同じ脆弱性を含むイメージや設定を戻さない」
• パッチだけでは足りない理由：「既に作られた不正なアカウントや、盗まれた認証情報は元に戻らない」
• 資格情報の更新の注意：「信頼できる管理環境から行い、その情報を使う処理と依存先も更新する」
• 暫定対策の管理：「期限と解除条件を決め、恒久対策へ移す」

6. 復旧：システムが動くことと、業務が正しいことを分ける

バックアップから戻せば、安全なのか

バックアップは、復旧の重要な材料です。しかし、取得に成功していることだけで、事故後に使えるとは判断できません。ファイルの破損や不足、侵害の痕跡、復元に必要な鍵や設定、復元先の安全性を確認します。

例えば、9月21日に暗号化を発見し、20日のバックアップが残っていたとします。それでも、19日から侵入されていた可能性があれば、20日のバックアップが安全な状態を保存しているとは限りません。「暗号化前」と「侵害前」は異なることがあります。

古いバックアップを選ぶ場合も、その時点以降の正当な更新をどう扱うかが問題になります。事故の調査と復元用データの評価を結び付け、必要なデータをどこまで回復でき、何を別に補うかを確認します。

NIST SP 800-61 Rev.3のRC.RP-03・05は、復元に使う資産の完全性と、復元した資産の確認を扱っています。バックアップの検査と、戻した後のシステムの検査は両方必要です。NIST「SP 800-61 Rev.3」、RC.RP-03・05

システムが動くことと、業務が正しいことを分ける

技術担当がログインと画面表示を確認しても、それだけで業務担当が安心して処理を再開できるとは限りません。

例えば、申請は保存されるが承認結果が連携されない、二重に通知される、復元前後のデータが混在している、といった問題があれば、業務の完全性を損ないます。認証・権限・検索・更新・出力・連携など、実際に必要な一連の流れを確認します。

復旧後に一般利用者が他人の情報を見られないこと、必要な監査ログが残ること、監視担当へ異常が届くことも重要です。セキュリティ機能を止めているから画面が動く、という状態を正常と判定しないようにします。

ランサムウェアからの復旧

ランサムウェアからの復旧では、次を分けて確かめます。

• バックアップそのものが暗号化・削除されていないか。復元に必要な鍵や設定、手順がそろっているか
• 復元する時点が侵入より前か。その時点以降のデータを、紙の控えや別の記録からどう補うか
• 盗まれた可能性のある認証情報を、侵害されていない環境から変更したか
• ファイルを戻せたことと、情報が持ち出されたかどうかは別。流出の有無と範囲の調査は、復旧と並行して続ける

再開してよい条件

復元用データの完全性と侵害痕跡を確かめ、復元した後は、データの欠落・重複・不正な変更を確認します。再開は、対象機能・利用者・残る制限を決め、異常時の停止と連絡、停止中の代替受付の戻し方も用意します。本稿では、再開の条件を次のように整理します。

• 調査で分かった不正な設定や侵入手段を取り除き、悪用された認証情報や権限を是正している
• 侵入口となった脆弱性を修正している。古いバックアップに戻すと、修正前の状態に戻ることがある
• 正規の利用者が、正しくデータを扱える（他人の情報が見える、二重に処理される、といった問題がない）
• 再開後の操作を監視でき、同じことが起きたときの停止と連絡の担当が決まっている
• 業務担当が確認し、責任者が再開を承認している

再開する単位と順序を決める

すべての機能を一斉に戻す必要があるとは限りません。例えば、業務上許される範囲で、確認済み資料の閲覧を先に戻し、外部共有や一括出力の再開は後にすることが考えられます。

これは単に復旧を細分化するという意味ではありません。各段階で、使える機能、対象利用者、残る制限、監視する事象、問題が出たときの停止条件を決めます。依存する認証・ネットワーク・データベースなどが準備できていなければ、その上の業務を戻せないこともあります。

再開判断では、技術担当が安全性や動作の確認結果を、業務担当が処理の正しさや影響を提示し、定められた責任者が承認します。「ベンダーが復旧したと言ったから」だけで、発注側の業務確認を省かないことが大切です。

停止中に処理した業務を、どう戻すか

代替手段にも、元へ戻す手順が必要です。例えば、オンライン受付の停止中に紙で受け付けた申請を、再開後に入力するとします。受付番号、時刻、入力担当、確認担当を残し、既にオンラインで受け付けたものと二重にならないよう照合します。

仮に、復元したデータが午前0時時点で、その後に受け付けた18件が戻っていない場合、18件は別の記録との照合対象です。紙の控えから補うのか、別の受付記録から回復できるのか、利用者へ連絡が必要かを業務担当が判断します。バックアップ復元作業だけでは、この問題は解消しません。

RTOは、業務やシステムをいつまでに復旧させたいかという目標時間です。RPOは、どの時点までのデータを回復するかという目標です。いずれも計画のための目標であり、設定した数字そのものが復旧の成功や安全性を保証するわけではありません。バックアップの方式は支援士解説3の3で扱います。

用語は、NIST用語集「Recovery Time Objective」と「Recovery Point Objective」のSP 800-34 Rev.1に基づく定義も参照できます（2026年9月21日確認）。

復旧後の監視と終了判定

監視では、再び現れる不審なログイン、権限変更、共有設定、既知の不正な挙動などを確認します。単に一定の日数を過ぎたから終えるのではなく、調査結果や攻撃の特徴、業務の実行周期を考慮します。毎日動く処理と月次処理では、確認できるタイミングが違います。

復旧完了、詳細調査の完了、法定報告や本人への対応の完了、長期的な改善の完了は、同じ時刻になるとは限りません。それぞれの残件を記録し、引継ぎ先を明確にします。サービス再開の連絡を「事案のすべてが解決した」と誤解されないようにすることも大切です。

【図6】復旧は、環境・データ・業務を確認して進める

午後での問われ方

• 平成30年度秋期 午後I問3：公開サーバの脆弱性を突かれた場面で、被害の拡大を防ぎつつサービスを続ける措置として、解答例は「Eサーバをネットワークから切り離して、待機サーバを公開する」です。切り離した機器は調査に回し、待機系で業務を続けます。
• 令和7年度秋期 午後問4：製造業のサプライチェーンでのセキュリティ管理が題材で、マルウェアなどの被害が起きたときに、早く復旧するための仕組みと手順が問われました。解答例の一つは、工作機械を制御するプログラムを「バックアップ／リストアするための媒体とソフトウェア」と、それを「リストアする手順」です（本文の状況に沿った仕組みと手順であれば、この例に限らないとされています）。

採点講評で指摘されたつまずき

• 令和7年度秋期 午後問4の設問4では、被害に至る攻撃を阻止する手段を書く解答が散見されたと指摘されています。早い復旧には、バックアップの取得など平常時に何を行うかが重要です。講評は、組織によっては、被害に至る経緯の解明よりも事業の復旧を優先する場合があることも挙げています。

記述の型

• バックアップの選び方：「侵入より前の時点のバックアップから復元し、侵入口の脆弱性を修正してから再開する」
• 再開の条件：「業務担当が処理の正しさを確認し、責任者が再開を承認する」
• 早期復旧の備え：「平常時にバックアップと、復元の手順・媒体を用意しておく」
• 終了の判断：「復旧完了、調査終了、情報被害への本人対応、改善完了を分けて、残件と引継ぎ先を記録する」

7. 報告：相手が判断できる情報にする

連絡の目的は、一つではない

内部の判断者には、被害と業務への影響、対応案の効果・不利益・期限を伝えます。制度に基づく報告では、速報・続報と、必要な本人対応を管理します。

インシデントの連絡先は、上司だけではありません。技術支援を受ける相手、影響を受ける人、法令等に基づく報告先、業務上の連携先などがあります。目的によって、伝える内容や経路、時期が変わります。

• 組織内の責任者：被害の状況、停止や費用の判断、支援が必要な事項。
• 委託先・サービス提供者・外部専門家：対象環境、必要なログや調査、実施してほしい措置、期限。
• 顧客・住民・取引先：影響するサービスや情報、利用上の注意、代替手段、問合せ先。
• 監督官庁等：法令や制度に基づき求められる内容、報告主体、期限、続報。
• 報道機関・一般への公表：確認された概要、対応状況、利用者への案内、更新予定。

技術相談をしたことは、法定報告をしたことと同じではありません。委託先へ連絡したことで、発注側の報告・通知に関する検討がすべて終わるわけでもありません。各連絡について、誰が何の責任で行うかを整理します。

JPCERT/CCの「インシデント対応マニュアルの作成について」は、告知の要否、相手、手段を分けて検討することを示しています。JPCERT/CC、2021年11月30日、7ページ

外部組織には、確認したい問いを渡す

例えば、クラウド提供者へ「不正アクセスを調べてください」とだけ依頼すると、認証ログの確認だけで回答が返るかもしれません。一方、知りたいのがファイルの取得範囲なら、別の監査ログや処理記録が必要です。

依頼では、対象サービス・契約・事案ID、対象期間とタイムゾーン、アカウントや要求の識別子、確認したい操作、既に実施した措置を示します。ログの保存期限が迫る場合は、調査の完了を待たずに保存の依頼を行います。

取得できる情報、取得できない情報、いつ回答できるかも確認します。大事なのは「異常なし」という短い結論ではなく、どの期間・対象・記録を確認して、何が見つからなかったのかです。

提供する情報は、調査に必要な範囲に限定し、安全な経路を使います。認証トークンや個人情報を広い宛先へそのまま送らないようにします。相手が正規の支援窓口であることも、確認済みの連絡先で確かめます。

確認済み、調査中、予定を混ぜない

初報では、全容が分からない場合があります。そこで、いつの時点の情報かを示した上で、次を分けます。

• 確認済みの事実：どのサービスで何を確認したか。
• 未確認事項：対象者、情報の内容、原因など、まだ調べていること。
• 実施した措置：停止、制限、調査依頼など。
• 利用者への案内：使えない機能、代替手段、必要な行動。
• 続報：更新先、問合せ先、次に伝える予定。

原因の推測を確定事項として公表すると、後から訂正が必要になります。一方、調査中という一言だけでは、利用者が自分の手続を進めてよいか判断できません。言える範囲を具体的に伝えることが重要です。

一般向けの案内では、内部アカウントやセッションの識別子をそのまま列挙する必要は通常ありません。利用者に関係する機能、影響、案内へ置き換えます。ただし、内部向けと外部向けで事実関係が食い違わないよう、共通の記録から作ります。

公表する情報にも、安全性の判断が必要

公表文には、被害を受けた人をさらに特定できる情報や、悪用に直結する未対処の詳細を安易に載せません。ただし、技術情報を出せないという理由で、利用者に必要な影響や対処方法まで曖昧にするのも適切ではありません。

CSIRT、業務担当、法務・個人情報保護担当、広報担当で内容を確認し、承認者と版を記録します。問合せ窓口には、答えられる事項、調査中として扱う事項、追加の相談を引き継ぐ先を伝えます。

公表後も、対象範囲や原因が変われば更新が必要です。訂正する場合は、何が変わり、なぜ変わったかを説明します。最初の公表を守るために、後から判明した被害を無視しないことが大切です。

記述の型

• 外部の提供者への依頼：「対象期間・タイムゾーン・アカウントを示し、確認したい操作のログを、保存期限が来る前に保全してもらう」
• 初報の書き方：「確認済みの事実、未確認事項、実施した措置、利用者への案内、続報の予定を分けて伝える」

法令上の報告と、一般への公表を区別する

個人情報の漏えい等では、対象となる情報や事態の性質に応じて、行政機関への報告や本人への通知が必要かを確かめます。Webサイトへの掲載は、それだけで報告や通知を終えたことにはなりません。制度の詳細は支援士解説3の11、社外への公表の進め方は支援士解説1の7で扱います。

【図7】報告・通知・公表は、相手と目的を分ける

8. 再発防止と、対応の進め方の改善

再発防止策は、確認した原因に対応させる

「職員に注意喚起する」「監視を強化する」だけでは、何を変えれば同じ事故が起きにくくなるかが分かりません。原因と対策を具体的につなげます。

例えば、使わなくなったアカウントが有効なままだったなら、当該アカウントを停止するだけでなく、業務終了や契約終了と権限の失効を結び付けます。定期確認だけでは終了から確認日まで時間が空くため、終了時の手続と定期的な検出の両方を考えます。

脆弱性情報を受け取っても対象システムを特定できなかったなら、資産や構成の管理、責任者への割当て、適用期限、例外の承認と見直しを整えます。製品を追加購入するだけで、その運用上の問題が解消するとは限りません。

なお、原因がまだ十分に特定できていない場合もあります。その場合は、確認済みの条件への対策と、仮説に基づく暫定対策を分け、追加調査を残します。分からないことを隠すために「人的ミス」と一括りにしないようにします。

対応の進め方にも、改善点がある

再発防止が事故の発生条件へ向かうのに対し、対応改善は、事故を見つけ、判断し、被害を抑え、業務を戻す過程へ向かいます。

例えば、対象アカウントの操作を早く見つけても、既存セッションを止める方法が分からず対応が遅れたなら、手順と訓練の改善が必要です。連絡先が見つからない、ログ取得に契約上の制約がある、代替業務の情報がない、といった問題も対象です。

評価では、発見、報告、判断、措置、効果の確認、再開という時点を整理します。時間がかかった場所を見つけたら、何を待っていたかを調べます。人数が足りないのか、権限がないのか、情報がないのかによって、改善策は変わります。

単に平均対応時間を短くするだけでは、急いで誤った停止を行う問題を見落とすかもしれません。例えば、初報までの時間、措置が実際に効くまでの時間、判断のやり直し、業務影響、必要な記録の欠落などを組み合わせて評価します。

対策に担当・期限・完了条件を付ける

本稿では、改善を次の形で記録することを勧めます。

• 課題：新規ログイン禁止と既存セッション失効の違いが、手順に書かれていなかった。
• 対策：対象サービスごとに停止操作と反映確認を整理し、緊急対応手順へ追加する。
• 担当：認証・サービス運用の責任者。外部提供者に仕様確認を依頼する。
• 期限：組織が決めた日までに改訂・確認する。完了までの暫定連絡先を周知する。
• 完了条件：手順を更新しただけでなく、許可されたテスト環境で新規と既存のアクセスの両方について、停止と確認を実施できること。

これは、文書を作ったことと対処できることを分けるためです。改訂が終わっても、夜間担当者が読めない場所に保存されていれば、有事に使えません。

期限までに完了しない場合は、理由、残るリスク、暫定措置、次の期限を判断者へ報告します。長期対策を事故対応の記録から切り離す場合も、引継ぎ先と追跡方法を残します。

教育・訓練は、役割ごとの判断を試す

利用者には、疑わしい操作を見つけたときの連絡と、再実行しないこと、停止中の業務手順を確認します。技術担当には、隔離、ログ保全、既存接続の失効、復元後の確認を試します。管理職には、止める範囲、追加費用、代替業務、再開承認の判断を行ってもらいます。

机上演習でも、途中で条件を変えると判断の弱点を確認できます。例えば、担当者が不在、提供者の回答が遅れる、復元用データに不審な変更がある、といった追加情報を与えます。正解を読み上げるだけでなく、誰へ何を依頼し、どの根拠で判断するかを確かめます。

訓練で危険な検体を本番環境へ持ち込む必要はありません。模擬のログや事案情報を用い、実際に操作を試す部分は許可された範囲で実施します。結果を手順へ反映し、変更した部分をもう一度確認します。

【図8】教訓を、次に使える手順と対策へ変える

例えば、既存セッションの失効手順を追加したら、役割別の訓練で反映の確認まで試します。期限未達なら、残るリスク・暫定措置・次の期限を報告します。必要な資源の確保も計画に含めます。教育の設計は支援士解説3の9で扱います。

午後での問われ方

• 令和4年度秋期 午後II問2：EDRを使った未知のマルウェアへの対策と、インシデント対応の事後評価が題材でした。対応の修正案として、「社外向けの通報窓口を設置する」ことと、体制を決めるレベルの判定を「最初の判定に加え、影響の大きさ又は影響の広がりについての事実が見つかるたびに、再判定を行う」ことが、解答例に示されています。

採点講評で指摘されたつまずき

• 令和4年度秋期 午後II問2では、インシデント対応のどこで無駄に時間が過ぎているかに注目する設問の正答率が低かったとされています。講評は、インシデント対応のガイドラインを参照して、全体像を理解してほしいとしています。

記述の型

• 再発防止策：「確認した原因（侵入口・権限・検知できなかった理由）に対応させる」
• 対応の改善：「通報を受ける窓口を設ける」「新しい事実が見つかるたびに、対応のレベルを判定し直す」
• 改善の完了条件：「手順を更新するだけでなく、訓練で実際に対処できることを確かめる」

9. 午前II（科目A-2）で正誤を見分けるポイント

• 「インシデント対応では、原因を特定してから封じ込めに着手する」→ 誤り。被害の拡大防止を優先し、調査と並行して進める
• 「感染が疑われるPCは、すぐに電源を切る」→ 誤り。メモリ上の証拠が失われる。原則はネットワークからの切り離し
• 「アカウントを無効化すれば、既存のセッションも必ず終了する」→ 誤り。既存のセッションやトークンを別に無効化する必要がある場合がある
• 「トリアージは、受け付けた事案の対応の要否と優先度を決めることである」→ 正しい
• 「バックアップから復元すれば、根絶も完了する」→ 誤り。侵入より後のバックアップには攻撃者の仕掛けが含まれることがあり、侵入口も直す必要がある
• 「根絶は、インシデントの原因となった不正なプログラムや侵入口を取り除くことである」→ 正しい
• 「パスワードの変更は、感染した端末から速やかに行う」→ 誤り。侵害されていない安全な端末から行う
• 「ログに記録がなければ、不正な操作はなかったと判断できる」→ 誤り。記録の対象外や保存期間切れの可能性がある
• 「CSIRTは、組織のインシデント対応を調整するチームである」→ 正しい
• 「監視製品の重大度がLowの警告は、対応の優先度も常に低い」→ 誤り。影響・緊急性・確度で組織が判断する
• 「揮発性の高い情報から先に保全する」→ 正しい。メモリやネットワークの接続の状態は、電源を切ると失われる
• 「バックアップからファイルを復元できれば、情報漏えいの調査は不要になる」→ 誤り。持ち出された情報は戻らない

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　アカウントの封じ込め

クラウドサービスで、職員のアカウントが不正に使われていることが分かった。アカウントを無効化したが、その後も同じセッションから操作が続いている。最も適切な対応はどれか。

• ア：無効化したので、追加の対応は不要である
• イ：既存のセッションやトークンを無効にし、操作が拒否されることを確認する
• ウ：職員に、パスワードを感染した端末から変更させる
• エ：ログを削除して、操作の記録を残さないようにする

正解：イ。新しいログインを止めることと、成立済みのセッションを止めることは別です。ウは、新しいパスワードまで盗まれるおそれがあります。

問2　感染が疑われる端末の初動

職員のPCでマルウェアの感染が疑われる。職員に指示する初動として、最も適切なものはどれか。

• ア：電源を切り、再起動して様子を見る
• イ：不審なファイルを削除し、初期化する
• ウ：手順に従ってネットワークから切り離し（無線LANも含む）、電源は入れたまま速やかに報告する
• エ：不審なファイルを同僚にメールで送り、意見を聞く

正解：ウ。拡大を防ぎつつ、調査に必要な証拠を残します。ア・イは証拠を失い、エは被害を広げるおそれがあります。

問3　バックアップの時点

21日にファイルの暗号化を発見した。調査の結果、19日から侵入されていたことが分かった。20日と18日のバックアップがある。最も適切な判断はどれか。

• ア：最新の20日のバックアップから戻し、すぐに再開する
• イ：侵入より前の18日のバックアップから戻し、その後のデータの扱いを決め、侵入口の脆弱性を修正してから再開する
• ウ：バックアップは使わず、身代金を支払う
• エ：暗号化されていないファイルだけ使い、原因は調べない

正解：イ。20日のバックアップには攻撃者の仕掛けが含まれているおそれがあります。古いバックアップに戻す場合は、それ以降のデータの扱いも決めます。

問4　影響を受けた利用者の特定

ECサイトの決済の画面が改ざんされ、入力したカード情報が外部へ送られていた。影響を受けた利用者を特定する方法として、最も適切なものはどれか。

• ア：全会員を影響ありとして、理由を示さずに通知する
• イ：改ざんの期間に、改ざんされた画面へアクセスしたアカウントを、アプリケーションログ（画面へのアクセスとアカウントの記録）から洗い出す
• ウ：問合せがあった利用者だけを影響ありとする
• エ：改ざんされた画面を元に戻せば、特定は不要である

正解：イ。攻撃の痕跡をログから全件探すのが基本です。期間と、実際に入力・送信したかも確かめます。

問5　トリアージ

監視製品から、重大度「Critical」の警告と「Low」の警告が同時に届いた。Lowの警告は、管理者アカウントが普段と異なる場所からログインしたという内容だった。最も適切な判断はどれか。

• ア：Criticalの警告だけを対応し、Lowは無視する
• イ：製品の重大度に関係なく、影響・緊急性・確度で優先度を判断し、管理者アカウントの件も急いで確認する
• ウ：両方とも、確度が高まるまで何もしない
• エ：警告の件数が多いほうから対応する

正解：イ。製品の重大度は、そのまま組織の優先度ではありません。管理者アカウントの不正利用は、確度が低くても影響が大きいので急ぎます。

実務と国・自治体では

実務では、「インシデント時に協力する」という契約の一文だけでは、いざというときに動けません。ログを取得できる対象・期間・形式、緊急時の連絡先と受付時間、提供者側でしかできない操作（アカウントの停止、既存接続の失効、共有の停止）、復旧作業と再開判定に必要な報告の内容を、委託やクラウドの利用条件で具体化します。提供者が基盤を正常化しても、自組織のデータや権限が正しいかは、別に確認が必要です。

政府機関等の統一基準は、CSIRTによる応急措置・復旧の指示、ほかのシステムでの同様の事案の検討、記録、原因調査と再発防止策の報告を求めています。自治体向けのガイドラインも、ネットワークの切断やシステムの停止、ログと現状の保存、経過の記録、復旧後の監視、再発防止計画を例文で示しています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 止める・取り除く・戻すは、目的が違う。 封じ込め、根絶、復旧を分け、原因の究明より被害の拡大防止を優先する。証拠の保全は並行して行う。
• 初動は、見つけた人と受け付けた人で役割が違う。 職員は操作を止めて報告し、手順に従って切り離す。受け付けた側が、影響・緊急性・確度でトリアージする。
• 封じ込めは、止めたかまで確かめる。 アカウントは新しいログインと既存のセッションの両方を止める。通信先は一つ止めても切り替えられる。
• 復旧は業務が正しく動くかで判断する。 バックアップは侵入より前のものかを確かめ、侵入口を直してから段階的に再開する。

さらに深く学ぶなら

この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。

• 実践 CSIRTプレイブック（Jeff Bollingerほか／オライリー・ジャパン）：監視からインシデント対応までの計画（プレイブック）の作り方を学べる

関連記事

• 前提：CSIRTがあれば、インシデントに対応できる？｜支援士解説4の1（体制と連絡）
• あわせて読む：ログを取るだけで攻撃に気付ける？｜支援士解説3の4（痕跡の読み方）
• あわせて読む：ウイルス対策ソフトだけで防げるのか｜支援士解説3の2（侵入後の動き）
• 次に読む：コピーしたら、証拠になる？｜支援士解説4の4（証拠保全とフォレンジック）

2026年10月改訂：午後の出題例と記述の型を加え、初動とトリアージの節を新設し（3-2・4-2から寄せた内容）、マルウェアの解析は3-2へ、公表の詳細は1-7へ移して、構成を見直しました。