セキュリティインシデント発生時には、被害拡大防止、影響範囲の確認、復旧対応を迅速に進める必要があります。しかし、初動の判断を誤ると、情報漏えいや業務停止などの被害が拡大する可能性があります。本記事では、検知から初動対応、調査、復旧までの基本的な対応フローと判断ポイントを解説します。
インシデント管理の全体像については、以下の記事をご覧ください。
「セキュリティインシデント管理とは？企業が押さえるべき対応フローと体制の全体像」
サイバー攻撃や情報漏洩、不正アクセス、ランサムウェア感染などのセキュリティインシデントは、発生してから対応を考えていては間に合いません。インシデント発生時には、限られた時間の中で、被害拡大を防ぎ、影響範囲を確認し、復旧へ進める必要があります。
しかし実際の現場では、「まず何を止めるべきか」「端末を隔離してよいのか」「証拠保全を優先すべきか」「経営層や顧客へいつ報告するべきか」といった判断に迷うことが少なくありません。初動の判断が遅れれば、感染拡大、情報漏洩、業務停止、信用低下といった被害につながる可能性があります。
インシデント発生時に最初にやるべきこと
インシデント発生時に最初にやるべきことは、慌てて復旧作業に入ることではありません。まず必要なのは、発生している事象を正しく把握し、被害が拡大する可能性を見極め、対応体制を立ち上げることです。
たとえば、従業員の端末で不審な挙動が見つかった場合、すぐに端末を初期化したくなるかもしれません。しかし、初期化してしまうと、感染経路や攻撃者の操作履歴、情報漏洩の有無を確認するための証拠が失われる可能性があります。逆に、調査を優先しすぎてネットワーク接続を維持したままにすると、マルウェア感染や不正アクセスが広がるおそれがあります。そのため、初動対応では、被害拡大防止と証拠保全の両方を意識する必要があります。
最初に確認すべきなのは、何が起きているのか、どのシステムや端末が影響を受けているのか、情報漏洩や業務停止につながる可能性があるのか、外部への影響があるのかという点です。ここで大切なのは、すべてを完璧に把握してから動くのではなく、現時点で確認できている事実と未確認事項を分けて整理することです。また、インシデント発生時には、情報システム部門だけで判断しきれない場面があります。個人情報漏洩の可能性がある場合は法務や個人情報保護の担当部門、顧客影響がある場合は営業やカスタマーサポート、外部公表が必要な場合は広報、事業停止の判断が必要な場合は経営層との連携が必要になります。
初動対応の具体的な進め方や判断基準については、以下の記事で詳しく解説しています。
「セキュリティインシデント発生時の対応 ―初動から復旧まで解説―」
初動対応の判断ポイント
初動対応で最も避けたいのは、根拠のない切り分けや思い込みによって対応を誤ることです。インシデント発生直後は情報が少なく、現場には焦りが生じます。そのため、「この端末だけの問題だろう」「外部には漏れていないはずだ」「再起動すれば直るだろう」といった判断をしてしまいがちです。しかし、こうした安易な切り分けは、被害範囲の見落としにつながります。
特にランサムウェア感染や不正アクセスでは、最初に異常が見つかった端末やサーバだけが被害対象とは限りません。認証情報が窃取されていた場合、攻撃者が別のシステムへ横展開している可能性があります。VPN機器やリモートデスクトップ、クラウドサービスのアカウントが侵害されている場合も、目に見える被害より広い範囲で調査が必要になることがあります。
この段階では、安易に原因を決めつけず、まず被害拡大防止を優先します。対象端末のネットワーク隔離、不審なアカウントの一時停止、外部公開システムのアクセス制限、攻撃に悪用された通信経路の遮断など、状況に応じた封じ込め策を検討します。IPA「中小企業のためのセキュリティインシデント対応の手引き」でも、被害が広がる可能性がある場合には、ネットワーク遮断、情報や対象機器の隔離、システム停止などの初動対応が必要になることが示されています。
ただし、被害拡大防止を急ぐあまり、証拠を失う行動にも注意が必要です。端末の電源を落とす、初期化する、ログを上書きする、関係するファイルを削除する、といった操作は、後の調査を難しくする可能性があります。インシデント対応では、原因究明や情報漏洩の有無を確認するために、ログ、端末情報、通信記録、アカウント操作履歴などを保全することが重要です。
また、JPCERT/CCが公開しているガイドライン「インシデント対応マニュアルの作成について」でも、インシデント対応フローとして、発見および報告、初動対応、告知、抑制措置と復旧、事後対応といった流れが示されています。標的型攻撃の対応例では、ログとの照合、不審通信の確認、通信遮断、感染端末の隔離、外部組織と協力した分析などが挙げられています。初動対応の判断では、「止める」「調べる」「知らせる」のバランスが重要です。被害拡大を止めるための措置、原因と影響範囲を調べるための証拠保全、社内外の関係者へ知らせるための情報整理を、同時並行で進める必要があります。
対応フロー（実務）
インシデント対応は、検知、初動、調査、復旧という流れで進めると整理しやすくなります。実際には事案の内容によって順序が前後したり、同時並行で進んだりしますが、基本となる流れを定めておくことで、対応の抜け漏れを防ぎやすくなります。
検知
検知は、インシデント対応の入口です。セキュリティ製品のアラート、EDRやウイルス対策ソフトの検知、ログ監視、外部機関からの通報、顧客からの問い合わせ、従業員からの報告、Webサイトの異常、システム停止など、さまざまな経路で異常が発見されます。検知段階で重要なのは、異常を見つけた人が、どこに、どのような情報を、どの優先度で報告すればよいかを理解していることです。たとえば、不審なメールを受信した従業員が報告先を知らなければ、標的型メールの兆候が放置される可能性があります。外部からWebサイト改ざんの連絡を受けても、窓口部門で止まってしまえば、対応開始が遅れます。検知した時点では、まだインシデントであると確定していない場合もあります。それでも、重要な兆候を見逃さないためには、報告を受け付け、事実確認へ進める体制が必要です。
初動
初動では、確認された異常に対して、被害拡大を防ぐための措置を取ります。感染が疑われる端末をネットワークから隔離する、不正利用が疑われるアカウントを停止する、侵害された可能性のある認証情報を変更する、外部公開サーバへのアクセスを一時的に制限するなど、事案に応じた対応が必要です。
このとき、現場担当者だけで判断できる範囲と、経営層や責任者の判断が必要な範囲を分けておくことが重要です。たとえば、特定端末の隔離は現場判断で行えても、基幹システムの停止や顧客向けサービスの停止は、事業影響が大きいため、あらかじめ定められた責任者の判断が必要になる場合があります。また、初動対応では記録を残すことも欠かせません。いつ、誰が、何を検知し、どのような判断で、どの対応を行ったのかを記録しておくことで、後の調査、報告、公表、再発防止策の検討が進めやすくなります。記録が残っていないと、対応の妥当性を説明できず、関係者への報告にも支障が出ます。
調査
調査では、インシデントの原因、影響範囲、攻撃経路、情報漏洩の可能性を確認します。調査対象には、端末、サーバ、ネットワーク機器、クラウドサービス、メール、認証ログ、通信ログ、EDRやSIEMの記録などが含まれます。IPA「中小企業のためのセキュリティインシデント対応の手引き」では、調査・対応において、5W1Hの観点で状況を調査し、情報を整理することが示されています。いつ、どこで、誰が、誰に対して、何を、なぜ、どのように行ったのかを整理することで、被害状況や対応方針を判断しやすくなります。調査では、確定情報と推測を混同しないことが重要です。
たとえば、「外部送信の可能性がある通信ログを確認した」という事実と、「情報漏洩が発生した」と断定することは異なります。確定していない情報を社内外に伝えると、誤解や混乱を招く可能性があります。一方で、影響がある可能性を過小評価してしまうと、必要な報告や公表が遅れる可能性もあります。そのため、調査結果は、確認済みの事実、可能性がある事項、未確認事項、今後確認すべき事項に分けて整理することが望ましいです。必要に応じて、セキュリティ専門ベンダー、保守ベンダー、クラウド事業者、法律専門家、関係機関と連携することも検討します。
復旧
復旧では、影響を受けたシステムや業務を安全な状態に戻します。バックアップからのデータ復元、修正プログラムの適用、設定変更、アカウントの再発行、認証情報のリセット、侵害された端末の再構築、ネットワーク接続の再開などが含まれます。重要なのは、単にシステムを元に戻すことではなく、安全性を確認したうえで復旧することです。原因が残ったまま復旧すれば、再び侵害される可能性があります。たとえば、脆弱性を悪用されたサーバをバックアップから戻しても、脆弱性に対する修正を行っていなければ、同じ攻撃を受けるおそれがあります。認証情報が漏洩していた場合も、パスワード変更や多要素認証の見直しを行わなければ、再度不正アクセスされる可能性があります。復旧後には、関係者への報告も必要です。
IPA「中小企業のためのセキュリティインシデント対応の手引き」では、被害者や影響を及ぼした取引先・顧客に対して、対応状況や再発防止策を報告すること、個人情報漏洩の場合は個人情報保護委員会、犯罪性がある場合は警察、ウイルス感染や不正アクセスの場合はIPAなど、必要に応じた届出先が示されています。
よくある失敗
インシデント対応でよくある失敗の一つは、初動が遅れることです。異常を検知しても、「もう少し様子を見る」「担当者が不在なので待つ」「本当にインシデントか分からない」と判断が先送りされると、被害が拡大する可能性があります。特にランサムウェアや不正アクセスでは、数時間の遅れが被害範囲を大きく広げることがあります。初動遅れの背景には、判断基準の不足があります。どのような場合に端末を隔離するのか、どのレベルで責任者へ報告するのか、どの段階で外部専門家へ相談するのかが決まっていなければ、現場担当者は判断に迷います。結果として、対応が後手に回りやすくなります。
もう一つの失敗は、情報共有不足です。情報システム部門だけで対応を抱え込み、法務、広報、営業、経営層への共有が遅れると、顧客対応や外部公表の準備が間に合わなくなります。個人情報漏洩の可能性がある場合や、取引先に影響がある場合には、技術的な復旧だけでなく、説明責任を果たすための情報整理が必要です。情報共有不足は、社内だけでなく、委託先や外部サービスとの関係でも起こります。クラウドサービス、保守ベンダー、業務委託先が関係するインシデントでは、ログ取得や調査範囲、責任分界点、連絡窓口が曖昧だと、事実確認が進みません。インシデント発生後に契約内容や連絡先を確認しているようでは、初動のスピードを確保することが難しくなります。
また、復旧を急ぐあまり、原因調査や証拠保全を十分に行わないことも失敗につながります。システムを復旧できたとしても、侵入経路や情報漏洩の有無が分からなければ、再発防止策を適切に立てることができません。インシデント対応では、業務再開と原因究明のバランスを取りながら進める必要があります。
さらに、対応終了後の振り返りが行われないことも大きな課題です。インシデントが収束すると、現場は通常業務に戻りがちです。しかし、対応中に発生した課題を放置すれば、次のインシデントでも同じ問題が起きます。連絡体制の不備、ログ不足、判断基準の曖昧さ、委託先との連携不足、訓練不足などは、事後対応の中で改善しなければなりません。
まとめ
インシデント対応フローは、検知、初動、調査、復旧という流れで整理できます。ただし、実際の対応では、これらの工程が単純に一方向で進むわけではありません。調査の結果によって初動対応を追加することもあれば、復旧後に新たな影響範囲が判明することもあります。そのため、対応フローを固定的な手順としてではなく、状況に応じて判断するための基本枠組みとして活用することが重要です。
インシデント発生時に最初に求められるのは、被害拡大を防ぎながら、事実を整理することです。安易な切り分けや思い込みは避け、確認済みの事実、未確認事項、影響範囲、対応状況を分けて管理する必要があります。また、端末の隔離やアカウント停止などの封じ込め策を講じる際には、証拠保全や事業影響にも配慮しなければなりません。
よくある失敗は、初動遅れと情報共有不足です。これらは、担当者の能力不足というより、事前に判断基準や連絡体制が整っていないことによって起こります。インシデント対応を確実に進めるためには、平時から対応フロー、報告ルート、責任者、外部連携先、証拠保全の方法を決めておくことが欠かせません。
セキュリティインシデントは、技術的な問題であると同時に、企業の信用や事業継続に関わる経営課題です。発生時に慌てず対応するためには、手順書を作るだけでなく、実際に使える形で体制を整備し、訓練を通じて改善していくことが重要です。
こうした対応を確実に実行するためには、あらかじめ体制を整備しておくことが重要です。インシデント対応体制については、以下の記事で詳しく解説しています。
「セキュリティインシデントの再発防止策とは？体制強化と継続的改善のポイント」
【参考情報】
- 米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）「Incident Response Plan Basics」（https://www.cisa.gov/sites/default/files/publications/Incident-Response-Plan-Basics_508c.pdf）
- 経済産業省「中小企業のためのセキュリティインシデント対応の手引き」（https://www.meti.go.jp/policy/netsecurity/sme_incident.html）
編集責任：木下
サイバーインシデント緊急対応
ウェビナー開催のお知らせ
最新情報はこちら
