セキュリティインシデント対応の流れ｜仕組み

不審な通信やマルウェア感染の疑いが上がったとき、対応は検知 → 初動（トリアージ）→ 封じ込め → 根絶 → 復旧 → 事後という決まった順で進みます。急いで直したくなりますが、この流れの要は「まず広がりを止める（封じ込め）」と「原因そのものを取り除く（根絶）」を分けて考えることです。分けないまま端末を初期化すると、攻撃の痕跡＝証拠まで一緒に消えて、どこまで漏れたのかが永久に分からなくなります。

先に押さえる

セキュリティ事故に対応する専門チームをCSIRT（シーサート）と呼びます。CSIRTは自分で全部を直す部隊ではなく、受け付け・状況把握・判断・調整をする司令塔です。日々の監視はSOC（監視部門）が担い、検知した事象をCSIRTへ渡す、という分担が一般的です。ここで言うインシデントとは「情報資産の機密性・完全性・可用性を損なう、または損なうおそれのある事象」で、まだ被害が確定していない疑いの段階も含みます。疑いの段階で動けるかどうかが、被害の大きさを分けます。

6段階の流れ

1検知から事後対応まで、順に担当が入れ替わる

① 検知監視機器の警告・利用者からの申告・外部からの通報

↓事象を1件として記録し、CSIRTへ連絡

② 初動（トリアージ）本物か誤検知か、影響範囲と緊急度の判定・優先順位付け

↓「対応する」と決めた事象だけが次へ進む

③ 封じ込め被害の拡大を止める（隔離・遮断・アカウント停止）

↓広がりが止まってから、原因の除去へ

④ 根絶侵入経路と残置物を取り除く（不正プログラム・不正アカウント・未修正の脆弱性）

↓安全を確認できたものから戻す

⑤ 復旧正常な状態へ戻し、再侵入がないか監視を強めて見届ける

↓記録を残し、原因を組織の対策へ反映

⑥ 事後（再発防止）経緯の整理・報告・恒久対策・手順の見直し

段階は前へ戻ることがあります。根絶の途中で「別の端末にも同じ痕跡が見つかった」となれば、範囲を広げて封じ込めをやり直します。一本道ではなく、調査で分かった範囲に応じて封じ込めと根絶を往復するのが実際の姿です。

CSIRTは誰と何をやり取りするか

設問では「この連絡は誰から誰へ、何のために行うか」がよく問われます。技術的な作業より、報告と調整の経路が答えになる場面が多いところです。

相手	向き	やり取りの中身
監視部門・利用部門	→ CSIRT	検知した事象・不審な挙動の第一報。疑わしい時点で上げるのが原則で、確証を待たせない。
経営層	CSIRT →	影響範囲の報告と判断を仰ぐ。サービス停止・公表・外部委託の可否は現場では決められない。
システム運用部門	CSIRT ⇄	隔離・遮断・修正の実作業を依頼し、結果を受け取る。手を動かすのは運用側という分担。
広報・法務	CSIRT ⇄	対外説明の内容と時期、法令上の届出義務の確認。窓口を一本化して情報の食い違いを防ぐ。
顧客・取引先	CSIRT →	影響の有無と講じた措置の連絡。自社が踏み台にされた場合は相手方への連絡が必須になる。
外部の調整機関・他社CSIRT	CSIRT ⇄	届出、攻撃情報の共有、同種被害の照会。単独では見えない攻撃の全体像を補う。

ここでの一貫した設計思想は「連絡経路と権限をあらかじめ決めておく」ことです。事故の最中に「誰に聞けばいいか」を探し始めると、その分だけ被害が広がります。

封じ込めと根絶の分かれ目

この2つは似て見えますが、目的も、失敗したときの症状も違います。

封じ込め＝広がりを止める

目的は被害の拡大防止。原因が分かっていなくても実施する。
手段：感染が疑われる端末をネットワークから切り離す、外部との不審な通信を遮断する、侵害された利用者アカウントを停止する、影響範囲のサービスを一時停止する。
この段階では端末の電源を落とすか迷う。落とすとメモリ上の情報が消えるため、通信の切断だけに留める判断がよく採られる。
失敗の症状：横展開（隣の端末・サーバへ次々と広がる）、情報の持ち出しが継続する。

根絶＝原因そのものを取り除く

目的は再侵入・再発の芽を断つ。原因を特定してから実施する。
手段：不正プログラムの削除または端末の再構築、攻撃者が作った不正アカウント・不正な設定の除去、悪用された脆弱性の修正、漏えいの疑いがある認証情報の全面変更。
調査が終わる前に始めない。侵入経路が未特定のまま初期化しても、同じ経路からまた入られる。
失敗の症状：復旧した直後に同じ事象が再発する、別の入口から再侵入される。

順番の理由は単純です。広がり続けている間は、いくら消しても追いつかない。だから止めるのが先。そして原因を特定しないまま消すと、消した瞬間に手掛かりが失われる。だから調べてから消す。この2つを守るだけで、対応の質は大きく変わります。

証拠を残しながら止める

ここが実務で最ももめる点であり、午後問題が繰り返し突いてくる点でもあります。業務を早く再開したい部門は「すぐ初期化して使わせてほしい」と言い、調査する側は「触る前に記録を取らせてほしい」と言う。両者は同じ事故に対して逆向きの要求を出します。

この対立を解く鍵は「消えやすいものから先に取る」という順序の考え方です。情報には残りやすさの差があります。

残りやすさ	対象	いつ消えるか
すぐ消える	メモリ上の内容、実行中のプロセス、現在の通信状態	電源を落とした瞬間に失われる。だから採取は最優先。
やや消えやすい	一時ファイル、上書きされうる作業領域	端末を使い続けるだけで上書きされていく。
しばらく残る	各種ログ（通信・認証・操作）	保存期間を過ぎると自動で消える。事故が古いほど追えない。
残る	ディスクの内容、保管済みのバックアップ	初期化・再構築で消える。作業前に複製を取れば守れる。

したがって現実的な手順は、①通信を切って広がりを止める（電源は落とさない）→ ②メモリと通信状態を採取 → ③ディスクの複製を取る → ④その複製を調べる → ⑤原本には触れず、端末は再構築して返すとなります。調べるのは複製で、原本は保管したままにする。こうすれば「早く返せ」と「証拠を残せ」は両立します。両立の道があるのに片方を切り捨てたという筋書きが、設問の穴になります。

あわせて押さえるのは記録の残し方です。いつ・誰が・何をしたかを時刻付きで残し、採取した資料を誰から誰へ渡したかの経緯も記録します。この経緯が途切れると、後から「途中ですり替わっていないと言えるのか」に答えられなくなり、証拠としての価値が落ちます。証拠保全とは、物を取ることではなく、取った物の来歴を説明できる状態を作ることです。

見抜きどころ

核は「封じ込めと根絶を混同しない」、そして「急いで消すと証拠が消える」。設問文に「他の端末への感染拡大を防ぐため」「不審な通信を止めるため」とあれば封じ込め、「侵入に使われた脆弱性を修正」「攻撃者が作成した利用者IDを削除」とあれば根絶です。そして「直ちに初期化した」「電源を切った」という記述が出てきたら、そこが間違いの置き場所だと疑ってください。問われるのは決まって「なぜその作業を行う前に別の作業が必要か」で、答えは調査に必要な情報が失われ、被害範囲と侵入経路を特定できなくなるから。業務再開を急ぐ現場の要求と、証拠を残したい調査側の要求が正面からぶつかる場面が描かれていたら、この論点だと考えて間違いありません。

つまずきやすい

「復旧＝対応完了」ではありません。サービスが動き出しても、侵入を許した穴がふさがっていなければ同じことが起きます。実際、復旧を急いだ現場が攻撃者の残した裏口を消し忘れたままネットワークに戻し、数日後に再び侵入される、という筋書きは典型的です。だから復旧の段階では、戻した後もいつもより強い監視を一定期間続けて「本当に消えたか」を見届けます。そして事後対応では、当該事象の記録だけでなく対応手順そのものの見直しまで行う。「連絡が遅れた」「判断できる人が捕まらなかった」といった運用上の詰まりは、次の事故でそのまま再現するからです。

似た流れとの違い