セキュリティインシデントとは
セキュリティインシデントとは、組織の情報システムの機密性・完全性・可用性を損なう事象のことです。マルウェア感染・不正アクセス・情報漏洩・DDoS 攻撃・フィッシング被害など、形態は多岐にわたります。
インシデントが発生した際、「何をすべきか」が事前に定まっていない組織では、担当者が混乱して適切な対応が遅れ、被害が拡大します。本記事では、NIST SP 800-61（コンピュータセキュリティインシデント対応ガイド）のフレームワークを基に、実務で使える対応手順を整理します。
インシデント対応の6フェーズ
NIST SP 800-61 では、インシデント対応を以下の6フェーズで定義しています。
| フェーズ | 名称 | 主な目的 |
|---|---|---|
| 1 | 準備（Preparation） | 事前にチーム・手順・ツールを整備する |
| 2 | 検知・分析（Detection & Analysis） | インシデントを検知し深刻度を評価する |
| 3 | 封じ込め（Containment） | 被害の拡大を止める |
| 4 | 根絶（Eradication） | 攻撃者の足場・マルウェアを完全に除去する |
| 5 | 復旧（Recovery） | システムを安全な状態で業務再開する |
| 6 | 事後活動（Post-Incident Activity） | 原因分析・再発防止策の実施 |
フェーズ1：準備（Preparation）
インシデントが発生してから「誰が何をするか」を考えるのでは遅いです。準備フェーズはインシデント対応の成否を最も左右します。
整備しておくべきもの
- インシデント対応ポリシー・手順書: 対応フロー・エスカレーションルート・外部連絡先（CISA・IPA・警察サイバー犯罪相談窓口）をドキュメント化します。
- CSIRT（インシデント対応チーム）の設置: 専任チームがなくてもよいですが、「誰がインシデント対応のリードを取るか」を事前に決めておきます。
- コミュニケーション手段の確保: 社内メール・Slackがインシデントで使えなくなる場合を想定し、帯域外（OOB）の連絡手段（携帯電話・別チャットシステム）を用意します。
- ログの保全体制: SIEM・EDR・ファイアウォールログが適切に保存されているか確認します。ログがなければ後の分析ができません。
- バックアップの整備と定期テスト: 3-2-1 ルール（3つのコピー・2種類のメディア・1つをオフサイト）を実践し、定期的に復元テストを行います。
- 外部ベンダーの連絡先リスト: セキュリティベンダー・法律事務所・フォレンジック会社の連絡先を事前に把握します。
フェーズ2：検知・分析（Detection & Analysis）
インシデントは「検知できている」とは限りません。多くの侵害は発生から発見まで数週間〜数ヶ月かかります（業界平均200日以上という調査もあります）。
インシデントの検知経路
- SIEM・EDR などのセキュリティ製品のアラート
- 利用者・社員からの報告（「変なメールが届いた」「PCが重い」）
- 取引先・外部研究者からの通報
- 外部脅威インテリジェンスサービスからの通知
- 公的機関（警察・IPA・NISC）からの連絡
トリアージ：深刻度の評価
検知したらまず「これはインシデントか、誤検知か」「深刻度はどのくらいか」を評価します（トリアージ）。
| 深刻度 | 定義例 | 対応スピード |
|---|---|---|
| Critical | 基幹システム停止・大量の個人情報流出・ランサムウェア感染 | 即時（24時間365日） |
| High | 重要サーバーへの不正アクセス・マルウェア感染（拡散前） | 数時間以内 |
| Medium | フィッシングメール開封・端末1台の感染 | 翌業務日以内 |
| Low | スパムメール・誤検知の可能性が高いアラート | 通常業務内 |
フェーズ3：封じ込め（Containment）
インシデントを確認したら、被害の拡大を止めることが最優先です。ただし「すぐに感染端末の電源を切る」という直感的な行動は、場合によって逆効果になることがあります。
封じ込め前に必ず実施：証拠保全
電源を切る前に、可能な限り証拠を保全します。 メモリ上にのみ存在するマルウェアや通信ログは、電源オフで消滅します。
- メモリダンプの取得（Volatility・WinPmem 等）
- ネットワーク接続の記録（
netstat -an・プロセスリスト） - ログのバックアップ（SIEM / イベントビューア / syslog）
- ディスクイメージのコピー（可能な場合）
封じ込めの選択肢
| 手段 | メリット | 注意点 |
|---|---|---|
| ネットワーク隔離（VLAN切り替え・スイッチポート遮断） | 電源を入れたままログ収集可能・業務影響が限定的 | 攻撃者に気づかれる前に実施する |
| エンドポイント隔離（EDR の自動隔離機能） | 迅速・遠隔から実施可能 | EDR が侵害されていないことが前提 |
| アカウント無効化・パスワードリセット | 認証情報の悪用を止める | 管理者アカウントも漏れなく対処する |
| 電源オフ | 攻撃を物理的に止める | メモリ証拠の消滅・ランサムウェアの暗号化処理を中断する場合あり |
フェーズ4：根絶（Eradication）
封じ込め後、攻撃者の足場を完全に除去します。「マルウェアを削除したから終わり」ではなく、初期侵入経路・持続化の仕組み・横展開で到達した全端末を洗い出して対処します。
- 初期侵入経路の特定: フィッシングメール・脆弱性・盗まれた認証情報のどれが使われたかを特定し、同じ経路からの再侵入を防ぎます。
- マルウェアの完全削除: EDR・フォレンジックツールを使い、全感染端末からマルウェア・バックドア・Web シェルを除去します。疑わしい端末は OS を再インストールする方が確実な場合が多いです。
- 全認証情報のリセット: 感染端末でパスワードを入力したことがある全アカウントのパスワードを変更します。Active Directory 環境では KRBTGT アカウントのリセットも検討します。
- パッチ適用・脆弱性修正: 悪用された脆弱性にパッチを当てます。パッチが出ていない場合はワークアラウンドを適用します。
フェーズ5：復旧（Recovery）
根絶が完了したら、システムを安全な状態で本番環境に戻します。復旧は「元通りに戻す」ではなく「より安全な状態で再開する」という意識が重要です。
- クリーンなバックアップからの復元（バックアップ自体が感染していないことを確認してから）
- システムの段階的な復旧（最初は監視下で限定的に起動し、異常がなければ本番復帰）
- 復旧後の強化監視（通常より詳細なログ収集・アラートしきい値を下げる）
- 利害関係者への状況報告（経営層・顧客・規制当局）
個人情報漏洩時の報告義務
個人情報の漏洩が判明した場合、日本では個人情報保護委員会への報告が義務付けられています。期限は速報が「速やかに」（ガイドライン上の目安は概ね3〜5日以内・土日祝を含む）、確報が30日以内（不正の目的による行為が疑われる場合は60日以内）です。「72時間以内」はEUのGDPRの規定であり、日本の個人情報保護法の期限ではありませんので注意してください。
対象となるのは、要配慮個人情報を含む場合、財産的被害のおそれがある場合、不正の目的による行為が疑われる場合、1,000人を超える場合の4類型で、いずれか1つでも当てはまれば報告が必要です。ランサムウェア感染は件数にかかわらず対象になる点が実務上重要です。詳細は 個人情報が漏えいしたときの報告義務 にまとめています。
フェーズ6：事後活動（Post-Incident Activity）
復旧後に「なぜ起きたのか」「次はどう防ぐか」を整理します。事後活動を省略すると同じインシデントが繰り返されます。
ポストモーテム（振り返り）
関係者が集まり、インシデントのタイムラインを振り返ります。「誰かを責める場」ではなく「何が起きたかを事実として整理し、プロセスを改善する場」として運営することが重要です（ブレームレス・ポストモーテム）。
- 検知から対応完了までのタイムライン整理
- 根本原因（技術的・組織的）の特定
- 「うまくいったこと」「改善が必要なこと」の整理
- 再発防止策の立案とオーナー・期限の設定
ランサムウェアインシデント対応の特殊な注意点
ランサムウェアは通常のインシデントと異なる考慮が必要です。
- 身代金を払わない: 支払っても復号できないケースがあります。支払いがランサムウェアビジネスを支援し、次の攻撃を誘発します。二重恐喝（データ公開の脅迫）は支払いで止まらない場合があります。
- バックアップがオンラインに接続されていないか確認する: ランサムウェアはバックアップも暗号化するため、オフライン・オフサイトのバックアップが唯一の復旧手段になる場合があります。
- 暗号化前のデータ窃取を前提とする: 現代のランサムウェアは暗号化前にデータを盗み出しています（二重恐喝）。「ファイルを復元できた」だけでは漏洩リスクが残ります。
- 復号ツールを確認する: No More Ransom プロジェクト（nomoreransom.org）では、一部のランサムウェアの無料復号ツールが公開されています。身代金を払う前に確認します。
インシデント報告書テンプレート
インシデント収束後に作成する報告書の基本構成を示します。経営層・規制当局・顧客向けに状況を説明するために使います。
| セクション | 記載内容 |
|---|---|
| エグゼクティブサマリー | 何が起きたか・影響範囲・対応完了状況を1〜2段落で要約 |
| インシデント概要 | 発生日時・検知日時・対応完了日時・インシデントの種類 |
| 影響範囲 | 影響を受けたシステム・データ・ユーザー数・業務への影響 |
| 攻撃の経緯（タイムライン） | いつ・何が起きたかを時系列で記載 |
| 根本原因 | 技術的な原因（脆弱性・設定ミス）・組織的な原因（プロセス不備） |
| 対応措置 | 実施した封じ込め・根絶・復旧の措置 |
| 再発防止策 | 技術的対策・組織的対策・実施担当者と期限 |
| 教訓 | よかった点・改善が必要な点 |
CSIRTの構築を検討する
大企業では専任の CSIRT（Computer Security Incident Response Team）を設置することが推奨されます。CSIRTの主な機能は以下の4つです。
- 検知・分析: SIEM・脅威インテリジェンスを使ったインシデントの早期発見
- 対応調整: 各部門・外部ベンダーとの連携調整
- 情報共有: ISAC（情報共有・分析センター）や IPA・NISC への情報提供・受信
- 教育・訓練: 社員へのセキュリティ教育・机上演習（タブルトップ演習）の実施
小規模な組織では専任チームを持てない場合も多いです。その場合は「インシデントが発生したら誰に連絡し、誰が何を担当するか」を書いたインシデント対応計画書（IRP）を作成しておくだけでも、発生時の混乱を大幅に減らせます。
実体験：secutilsが侵害されたらどうするかを考えてみた
もし secutils 自体が万が一侵害された場合は、まず「何が起きたのかを確認すること」と「被害をこれ以上広げないこと」を優先すると思います。例えば、まずデプロイ履歴やアクセスログ、GitHub などの変更履歴を確認して、いつ頃から何が起きていたのかを調べます。同時に、もし API キーや環境変数などの認証情報が漏れている可能性があれば、それらを無効化して再発行することも優先すると思います。その後、改ざんされたファイルや不正なコードが入っていないか確認して、原因となった経路を特定してから復旧するという流れになると考えています。
この記事を書きながら改めて考えると、個人開発では「侵害されないようにする」ことはかなり意識していても、「実際に侵害された場合にどう調査するか」という準備はまだ十分ではないと感じました。特にログの保存や監視については、個人開発だとどうしても後回しになりやすいので、今後改善したい部分だと思っています。
よくある質問
セキュリティインシデントが発生したら最初に何をすればよいですか？
まず「切断か継続か」を判断します。被害拡大防止のためにネットワーク切断が基本ですが、ログが消える・業務停止になるなどのリスクも考慮が必要です。切断する前にメモリ・ログの証拠保全を行い、対応チームへの連絡と経営層への報告を行います。
CSIRTとは何ですか？
CSIRT（Computer Security Incident Response Team）はインシデント対応を専門に行うチームです。専任チームがなくてもインシデント対応の役割と手順を事前に定めておくことで、発生時に素早く動けます。
ランサムウェアに感染した場合、身代金を払うべきですか？
支払いは推奨されません。支払っても復号できない場合があります。まず証拠保全・ネットワーク隔離を行い、バックアップからの復旧と No More Ransom の無料復号ツールを確認します。
インシデント対応の報告書には何を書けばよいですか？
①インシデントの概要 ②影響範囲 ③根本原因 ④対応タイムライン ⑤再発防止策の5項目が基本構成です。
インシデント発生時に外部機関に報告する義務はありますか？
個人情報が流出した場合は個人情報保護委員会への報告義務があります。速報は「速やかに」（目安は概ね3〜5日以内）、確報は30日以内（不正の目的による行為が疑われる場合は60日以内）です。重要インフラ事業者はサイバーセキュリティ基本法に基づく報告義務があります。
関連記事
- 個人情報が漏えいしたときの報告義務 — 速報・確報の期限と本人通知の実務
- MITRE ATT&CK入門 — 攻撃者の戦術・手順を体系化した知識ベース
- ランサムウェア2026の最新動向 — ランサムウェアの最新実態
- LOLBins・環境寄生型攻撃 — 検知が難しい攻撃手法
- インフォスティーラーとセッションCookie窃取 — 初期侵入経路の一つ
- ゼロトラストとは — インシデント被害を最小化する設計思想