インシデント発生時の初動対応。最初の1時間で何をするか

「ランサムウェアの画面が出ている」「見覚えのない管理者アカウントが作られている」「取引先から不審なメールがうちのドメインで届いたと連絡があった」。こうした第一報が入った瞬間から、インシデント対応は始まります。そして対応の成否は、技術力よりもむしろ、最初の1時間でどれだけ落ち着いて正しい順序を踏めるかで大きく分かれます。慌てて感染端末の電源を引き抜く、安易に再起動する、よかれと思ってウイルス対策ソフトで即座に駆除する。これらはいずれも、後で原因や影響範囲を追えなくする「証拠の破壊」につながりかねません。

初動でやってはいけないのは、調査の前に現場を上書きしてしまうことです。一方で、判断を先延ばしにして被害が広がるのも避けたい。つまり初動対応とは、「被害の拡大を止める」ことと「後で真相を追えるよう現場を保全する」ことを、限られた情報の中で同時に成立させる作業です。この記事では、その難しいバランスを取るための順序を、検知・トリアージ・封じ込め・証拠保全という流れに沿って具体的に整理します。

扱うのは特定製品の操作手順ではなく、どんな組織でも応用できる判断の型です。NIST SP 800-61 Rev.3 や JPCERT/CC のインシデントハンドリングの枠組みを下敷きにしつつ、最初の1時間で「何を確認し、何を記録し、何を我慢すべきか」に焦点を当てます。

早見表: 初動の4フェーズと「やること・やってはいけないこと」#

まず全体像です。インシデント対応のライフサイクルは枠組みによって表現が異なりますが、現場の初動に落とすと次の4つに整理できます。JPCERT/CC のインシデントハンドリングでは検知・連絡受付、トリアージ、インシデントレスポンス、報告・情報公開という流れで整理されています。NIST SP 800-61 Rev.3 はインシデント対応を CSF 2.0 の6つの機能（Govern・Identify・Protect・Detect・Respond・Recover）全体に組み込むコミュニティプロファイルで、平時の備え（Govern・Identify・Protect）から検知（Detect）・対応（Respond）・復旧（Recover）までを通して扱います。本記事はそのうち、初動に直結する Detect と Respond を中心に説明します。呼び方は違っても、最初の1時間でやるべきことは共通しています。

この4つは厳密な直列ではなく、状況により行き来します。たとえば封じ込めと証拠保全はせめぎ合うことが多く、「隔離する前にメモリを取得しておくべきか」といった判断が初動の山場になります。以下、フェーズごとに掘り下げます。

検知・受付。まず「事故かどうか」を冷静に確認する#

初動はアラートや通報の受付から始まります。ここで大事なのは、第一報を鵜呑みにせず、かといって軽視もしない態度です。実際にはアラートの多くは誤検知や正常な運用に起因します。逆に、利用者からの「PCが急に重い」「変なポップアップが出た」といった曖昧な報告の裏に重大な侵害が隠れていることもあります。最初にやるのは、断片的な事実を集めて「本当にインシデントか」を見極めることです。

このとき確認したいのは、いつ・どこで・何が・どう異常なのか、という素朴な事実です。いつから症状が出ているか、対象は1台か複数か、外部公開サーバか内部端末か、影響を受けているのは特定アカウントか全社か。これらを最初に押さえると、次のトリアージで深刻度を見積もる土台ができます。

そして検知の瞬間にもう一つ必ずやるべきことがあります。対応開始時刻の記録です。「何時何分に、誰が、どの事象を認知したか」を最初に書き留める。この一行が、後で「いつ気づき、いつ何をしたか」というタイムラインの起点になります。初動の混乱の中では時刻感覚が失われやすく、後から再構成しようとすると記憶が曖昧で正確に書けません。記録は最初の瞬間から始めるのが鉄則です。

トリアージ。深刻度と優先度を見積もる#

トリアージは医療の言葉で、限られた資源をどの患者に優先配分するかを判断することです。インシデント対応でも意味は同じで、「これはどれだけ深刻で、どれを先に対応すべきか」を見積もる工程です。すべてを最優先で抱え込むと判断も人手も詰まります。逆に深刻なものを後回しにすれば被害が広がります。だから優先度づけが要ります。

優先度は大きく2軸で考えると整理しやすくなります。一つは影響の大きさ（どれだけ重要な資産・データ・業務に関わるか）、もう一つは緊急度（被害がどれだけ速く拡大しうるか）です。たとえば外部公開サーバでの侵害や、横展開しているように見えるランサムウェアは、影響も緊急度も高く最優先です。一方、単一端末のアドウェア感染で外部通信もない場合は、相対的に優先度を下げて段階的に対応できます。

ここで誤解しやすいのが、「確実に分かるまで対応を始めない」という考え方です。初動の段階では情報が不完全なのが普通で、完璧な見立てを待つと手遅れになります。トリアージは確定診断ではなく、現時点の情報での暫定的な優先度づけです。新しい事実が出るたびに見直す前提で、まず動き出すことが大切です。

攻撃者が組織内でどう動こうとするか（初期侵入から横展開、権限昇格まで）の戦術段階を頭に入れておくと、トリアージで「次に何が起こりうるか」を予測しやすくなります。攻撃の振る舞いを体系的に整理した枠組みとしては

封じ込め。「シャットダウン」ではなく「隔離」する#

被害の拡大を止めるのが封じ込めです。ここで初心者が最もやりがちな誤りが、「感染したらすぐ電源を切る」「とりあえず再起動する」「ウイルス対策ソフトで即駆除する」という反射的な対応です。気持ちは分かりますが、いずれも証拠を失わせ、場合によっては被害を悪化させます。

なぜ電源断が問題なのか。理由は揮発性にあります。コンピュータの状態には、電源を切ると消えてしまう情報（メモリ上で動いているプロセス、確立中のネットワーク接続、復号鍵、暗号化前の平文など）が大量にあります。後述する証拠保全の観点でも、これらは最も価値が高く、最も早く失われます。電源を切った瞬間に、攻撃の核心的な手がかりが永久に取れなくなることがあるのです。さらにランサムウェアの一部は、シャットダウンや再起動をトリガーに暗号化を進めたり痕跡を消したりする挙動を持つため、安易な電源操作はかえって危険です。

封じ込めの基本は「シャットダウンではなく隔離」です。具体的には、電源は入れたまま、ネットワークから切り離します。

証拠保全。揮発性の高いものから残す#

封じ込めと並んで初動の核心が証拠保全です。なぜここまで証拠にこだわるのか。理由は3つあります。第一に、原因と侵入経路を特定しないと、封じ込めても同じ穴から再侵入されます。第二に、影響範囲（どのデータが漏れたか、どこまで広がったか）を確定しないと、関係者への報告も復旧の範囲も決められません。第三に、インシデントが報告義務や訴訟、保険請求に発展した場合、証拠の完全性が問われます。慌てた初動で証拠を壊すと、これらすべてが後で行き詰まります。

証拠保全で決定的に重要なのが「揮発性の順序（order of volatility）」という考え方です。証拠は消えやすいものから先に集める、というのが大原則です。RFC 3227「Guidelines for Evidence Collection and Archiving」は、収集すべき情報を揮発性の高い順に並べています。要点を実務向けに整理すると次のようになります。

この順序が、初動で電源を切ってはいけない最大の根拠です。メモリやネットワーク接続といった最も価値が高い情報は、最も早く消えます。だから、可能であれば隔離後・電源保持の状態でメモリイメージや揮発情報を取得してから、ディスクの保全に進みます。なお RFC 3227 は、ディスクと「リモートのログ・監視データ」を別の項目として並べています。ログは一見「残るもの」に見えても、ローテーションや保持期限、攻撃者による改ざんで失われることがあり、ローカルだけでなくリモートに集約したログや監視データも別途保全対象として意識しておくと安全です。

証拠は揮発性の高いものから収集するという「order of volatility」の原則は、RFC 3227「Guidelines for Evidence Collection and Archiving」で具体的な収集順序とともに示されています。メモリやプロセス情報を最優先に置く根拠として、初動の判断に直接効いてきます。

ディスクを保全する際は、原本をそのまま使わず、ビット単位の複製（イメージ）を取り、解析は複製に対して行うのが原則です。原本に変更を加えると証拠としての価値が損なわれます。取得したイメージにはハッシュ値を付与し、後から「保全時点から改ざんされていないこと」を示せるようにします。こうした保全と解析の詳しい流れは

もう一つ、技術的な証拠と同じくらい重要なのが対応記録（タイムライン）です。誰が・何時何分に・何を観測し・何を実施したかを時系列で残します。「ケーブルを抜いた時刻」「メモリを取得した時刻」「アカウントを無効化した時刻」を記録しておくと、後の分析で「この変化は攻撃によるものか、自分たちの対応によるものか」を切り分けられます。初動の記録は、技術的な証拠を正しく解釈するための文脈そのものです。

技術対応と並走する「人と連絡」の初動#

初動は技術作業だけでは完結しません。むしろ最初の1時間でつまずきやすいのは、エスカレーションと連絡体制です。誰に報告し、誰が意思決定し、いつ外部（専門機関・取引先・監督官庁・公的窓口など）へ連絡するか。これらが決まっていないと、現場が技術対応に追われる一方で、報告や意思決定が空白になります。

実務では、最初の1時間で次のような「人の動き」も同時に立ち上げます。第一報を受けた人がCSIRTや責任者へエスカレーションする、対応の指揮を執る人（インシデントコマンダー的な役割）を一人決める、技術対応班と連絡・調整班を分ける、といった体制です。これらは事前に手順書として整えておくのが理想で、JPCERT/CC の CSIRT マテリアルや IPA の中小企業向けの手引きは、こうした体制づくりと対応手順の整備に具体的な雛形を提供しています。

体制や人手が限られる組織でも回せるインシデント対応の考え方や手引きは、IPA の中小企業向け情報セキュリティ対策のページに整理されています。机上演習の教材なども提供されており、平時の備えとして有用です。

ここで強調したいのは、初動の混乱の最中に連絡先や手順を探し始めるのでは遅い、ということです。「誰に・どの順で・どの手段で連絡するか」を平時に決めておく。連絡網が電子メールやチャットに依存している場合、それらが侵害下で使えない事態（攻撃者にメールを見られている、システムが暗号化されているなど）も想定し、代替の連絡手段を用意しておく。こうした準備（NIST の枠組みで言えば Govern や Protect に当たる平時の活動）が、初動の質を最終的に決めます。

よくある質問#

まとめ#

インシデント対応の最初の1時間は、技術力の勝負である前に、順序と落ち着きの勝負です。被害の拡大を止めることと、後で真相を追えるよう現場を保全すること。この一見相反する2つを、限られた情報の中で両立させるのが初動の核心です。慌てて電源を切らない、再起動しない、即駆除しない。代わりに、記録を始め、深刻度を見積もり、電源を保ったまま隔離し、揮発性の高いものから証拠を残す。そして技術対応と並行して、人の連絡とエスカレーションを動かす。この型を平時から共有しておくことが、有事の混乱を最小化します。

初動で得た証拠をどう解析し、原因と影響範囲を確定していくかという次の段階、そして平時にどんなログや備えを整えておくべきかは、攻撃者の振る舞いを段階で捉える