セキュリティインシデント対応手順書の作り方と初動対応

サイバー攻撃やマルウェア感染、不正アクセスといったセキュリティインシデントは、もはや大企業だけの問題ではありません。中小企業や自治体、教育機関に至るまで、あらゆる組織が標的となり得る時代になっています。実際にインシデントが発生した際、被害の大きさを左右するのは「発生後、最初の数十分から数時間でどのような対応を取ったか」です。

しかし、多くの現場では「何かあったらどうすればいいのか」が曖昧なまま放置されており、いざという時に担当者が右往左往してしまうケースが後を絶ちません。そこで重要になるのが、あらかじめ整備されたセキュリティインシデント対応手順書です。

本記事では、なぜ手順書が必要なのかという背景から、実際の作成手順、そして手順書を形骸化させないための運用のコツまで、体系的に解説していきます。情報システム部門の担当者はもちろん、経営層や現場責任者にとっても実践的な内容となるよう、具体的なステップに落とし込んで紹介していきます。

セキュリティインシデント対応手順書が必要な理由

セキュリティインシデントは「起きるかもしれない」ものではなく、「いつか必ず起きる」という前提で備えるべきリスクです。IPA（情報処理推進機構）が毎年公表している「情報セキュリティ10大脅威」を見ても、ランサムウェアや標的型攻撃、サプライチェーンを狙った攻撃など、手口は年々巧妙化しています。こうした攻撃に対して、事前に整備された対応手順書がなければ、組織は致命的な初動の遅れを招いてしまいます。

初動対応の遅れが招く被害拡大

セキュリティインシデントにおいて最も恐ろしいのは、発見の遅れそのものよりも「発見してから対応を開始するまでの空白時間」です。ランサムウェア攻撃を例に挙げると、感染が確認された時点で即座にネットワークを遮断できるかどうかで、被害範囲は数倍から数十倍にも変わってきます。

初動対応が遅れる典型的な原因は以下の通りです。

• 誰に報告すればいいのかわからず現場が混乱する
• 担当者が独断で判断してしまい対応がバラバラになる
• 証拠となるログやデータを誤って消してしまう
• 経営層への報告が遅れ、対外的な公表判断が遅れる

これらはすべて、「誰が」「何を」「どの順番で」行うかが明文化されていないことに起因します。手順書があれば、発見者は迷わず定められた連絡先に一報を入れ、初動対応チームは即座に被害拡大防止の措置に着手できます。

手順書がない現場が抱えるリスク

手順書が整備されていない組織では、インシデント発生時に次のようなリスクが顕在化します。

• 対応の属人化：特定の担当者しか対応方法を知らず、その人が不在の際に機能不全に陥る
• 情報の錯綜：関係者間で情報共有が行われず、同じ確認作業を何度も繰り返す
• 証拠保全の失敗：フォレンジック調査に必要なログやメモリダンプを消してしまう
• 法的・契約上の対応漏れ：個人情報保護法に基づく報告義務や、取引先への通知義務を見落とす

特に個人情報が絡む漏えい事案では、個人情報保護委員会への報告が法令上求められるケースもあり、対応の遅れがそのまま法令違反につながるリスクもあります。手順書がないことは、単なる「非効率」の問題ではなく、経営上の重大なリスクそのものなのです。

担当者が感じる不安の正体

情報システム担当者やセキュリティ担当者と話をすると、多くの人が「インシデントが起きたらどうしよう」という漠然とした不安を抱えていることがわかります。この不安の正体は、実は「対応手順が明文化されていないこと」にあります。

人は未知の状況に対して強いストレスを感じますが、逆に言えば「何をすればいいか」が明確であれば、たとえ緊急事態であっても冷静に対応できます。手順書はマニュアルであると同時に、担当者の心理的な安全網としての役割も果たしているのです。

また、手順書があることで新任担当者への引き継ぎもスムーズになり、組織全体のセキュリティ対応力の底上げにもつながります。

セキュリティインシデント対応手順書の作成手順

ここからは、実際に手順書を作成する際の具体的なステップを解説していきます。手順書は一度作って終わりではなく、組織の実情に合わせて継続的にブラッシュアップしていくものだという前提で読み進めてください。

発生時の報告体制を明確にする

まず最初に整備すべきは「誰が、誰に、どのように報告するか」という報告体制です。インシデントを発見した従業員が迷わず行動できるよう、以下の項目を明文化しておきましょう。

報告窓口の一本化

報告先が複数存在すると、情報が分散し初動が遅れます。原則として一次窓口を一本化し、そこから各関係部署へエスカレーションする仕組みを作ることが重要です。多くの組織では、情報システム部門内に「CSIRT（Computer Security Incident Response Team）」を設置し、そこを一次窓口としています。CSIRTの構築・運用については、JPCERT/CCが公開しているガイドラインが参考になります。

報告フォーマットの整備

報告時に必要な情報を事前にフォーマット化しておくと、初動対応チームが状況を正確に把握しやすくなります。フォーマットには以下のような項目を含めると良いでしょう。

• 発生日時・発見日時
• 発見の経緯（誰が、どのように気づいたか）
• 影響を受けている可能性のあるシステムやデータ
• 現在の状況（継続中か、収束しているか）
• すでに実施した対応（ある場合）

初動対応フローを整理する

報告を受けた後、初動対応チームがどのような順序で動くかをフローチャート形式で整理しておくことが重要です。一般的な初動対応の流れは以下の通りです。

1. トリアージ（優先度判定）：インシデントの深刻度を判定し、対応の優先順位を決める
2. 被害拡大防止措置：該当端末のネットワーク切断、アカウントの一時停止など
3. 証拠保全：ログやメモリダンプ、通信記録などを消去せず保全する
4. 関係者への一次連絡：経営層や関連部署への状況報告

特に重要なのが「証拠保全」です。焦って端末を再起動したり、ウイルス対策ソフトで即座に駆除してしまったりすると、後の調査に必要な痕跡が失われてしまいます。初動対応では「消す」より先に「保全する」を徹底することを手順書に明記しておきましょう。

影響範囲の調査方法を定める

初動対応が完了したら、次はインシデントの影響範囲を正確に把握するフェーズに移ります。ここでの調査が不十分だと、対応漏れや二次被害の見落としにつながります。

調査すべき項目の洗い出し

• 侵入経路（不正アクセスの起点となった脆弱性や認証情報）
• 影響を受けたシステム・サーバー・端末の範囲
• 漏えいまたは改ざんされた可能性のあるデータの種類と量
• 攻撃者が組織内で活動した期間（滞留期間）

外部専門家の活用

自組織だけで正確なフォレンジック調査を行うのが難しい場合は、外部のセキュリティベンダーやフォレンジック専門会社への依頼も選択肢に入れておくべきです。手順書には、どのような場合に外部専門家へ依頼するかの判断基準や、あらかじめ契約しておくべき緊急対応サービスの連絡先も記載しておくと、いざという時にスムーズです。

復旧と再発防止策を記載する

影響範囲の調査が完了したら、システムの復旧作業に移ります。復旧作業においても、以下の点を手順書に明記しておくことが重要です。

• 復旧作業を行う前に必ず承認プロセスを経ること
• 復旧後の動作確認・脆弱性の再チェックを行うこと
• 復旧完了後も一定期間の監視強化を継続すること

また、インシデントが収束した後は、必ず再発防止策を検討し、手順書や社内ルールに反映させる仕組みを作りましょう。再発防止策の検討にあたっては、内閣サイバーセキュリティセンター（NISC）が公開している資料や、各種セキュリティフレームワークを参照するのも有効です。

根本原因分析（RCA）の実施

再発防止策を検討する際は、表面的な現象だけでなく「なぜそのインシデントが発生したのか」という根本原因まで掘り下げることが重要です。技術的な脆弱性だけでなく、運用ルールの不備や従業員教育の不足といった組織的な要因も含めて分析しましょう。

関係部署への連絡手順を決める

セキュリティインシデントは情報システム部門だけで完結するものではありません。以下のような関係部署・関係者への連絡手順もあらかじめ定めておく必要があります。

• 経営層：重大インシデントの場合は即座にエスカレーション
• 法務部門：契約上の通知義務や法令上の報告義務の確認
• 広報部門：対外的な公表が必要な場合の情報発信
• 取引先・顧客：影響が及ぶ可能性がある場合の通知
• 監督官庁：個人情報漏えい等、法令に基づく報告義務がある場合

特に個人情報の漏えいが疑われる場合、個人情報保護委員会への報告や本人への通知が義務付けられているケースがあります。誰が、いつまでに、どのような内容を報告すべきかを事前に整理し、手順書に明記しておくことで、対応の遅れによる法令違反リスクを最小化できます。

手順書を定期的に見直す仕組み

手順書は一度作成したら終わりではありません。組織のシステム構成や体制は常に変化しますし、攻撃手法も日々進化しています。以下のようなタイミングで定期的に見直しを行いましょう。

• 年に1回以上の定期レビュー
• 組織改編やシステム更新のタイミング
• 実際にインシデントが発生した後の振り返り時
• 新たな脅威動向が報告された時

見直しの際は、手順書の内容だけでなく、記載されている連絡先や担当者名が最新の状態になっているかも必ず確認してください。担当者が異動しているにもかかわらず古い連絡先が記載されたままになっているケースは非常によくある落とし穴です。

訓練を通じて実効性を高める方法

手順書は「読むだけ」では実効性を発揮しません。実際のインシデント発生時に手順書通りに動けるかどうかは、定期的な訓練によってのみ検証できます。

机上訓練（テーブルトップエクササイズ）

関係者が一堂に会し、想定シナリオに沿って「もしこのようなインシデントが起きたら、誰が、何をするか」をシミュレーションする訓練です。実際にシステムを止めることなく実施できるため、比較的低コストで定期的に実施しやすい方法です。

実践的な模擬訓練

より実践的な訓練として、疑似的な標的型攻撃メールを送信して従業員の対応力を測るフィッシング訓練や、実際にシステムの一部を隔離してみる復旧訓練なども有効です。JPCERT/CCなどの公的機関も、インシデント対応演習に関する資料やガイドラインを公開しているため、これらを参考に自組織に合った訓練プログラムを設計すると良いでしょう。

訓練後の振り返りが最も重要

訓練を実施した後は、必ず振り返りの時間を設け、手順書通りに動けなかった点や、手順書自体に不備があった点を洗い出しましょう。この振り返りのプロセスこそが、手順書を「使える」ものへと磨き上げていく最も重要な工程です。

自組織だけでの訓練設計や手順書のブラッシュアップに不安がある場合は、セキュリティコンサルティング会社が提供するインシデント対応支援サービスや、CSIRT構築支援サービスの活用も検討してみると良いでしょう。専門家の知見を取り入れることで、より実効性の高い手順書へと仕上げることができます。

セキュリティインシデント対応手順書のまとめ

セキュリティインシデント対応手順書は、いざという時に組織を守るための生命線です。報告体制の明確化から初動対応フロー、影響範囲の調査、復旧と再発防止、関係部署への連絡手順まで、一つひとつを丁寧に整備することで、被害を最小限に抑えられます。そして何より大切なのは、作って終わりにせず、定期的な見直しと訓練を通じて「実際に使える手順書」へと育てていくことです。まずは自組織の現状を棚卸しし、できるところから整備を始めてみましょう。