はじめに
前回の記事では、Threat Modelling（脅威モデリング） を通じて、システム設計段階での「予防」について紹介しました。
しかし、どれだけ対策を講じても 100％の防御は不可能 です。
攻撃や事故は発生する前提で、被害を最小化し、迅速に復旧する対応力 が重要となります。
それが Incident Response（インシデント対応） です。
インシデントとは？
「インシデント」とは、組織の情報資産やシステムに悪影響を及ぼすセキュリティ上の出来事 のことです。
例：
- 不正アクセス
- マルウェア感染
- 情報漏洩
- サービス拒否攻撃（DoS/DDoS）
- 内部不正（従業員によるデータ持ち出し など）
これらは事前に完全に防ぐのは難しいため、「起きた後の対処フロー」が必要になります。
Incident Response のライフサイクル
代表的なフレームワーク（NIST SP 800-61 など）では、次の6ステップに整理されます。
① Preparation（準備）
- インシデント対応ポリシー策定
- CSIRT（Computer Security Incident Response Team）の設置
- ログ収集や監視体制の整備
② Detection & Analysis（検知・分析）
- IDS/IPS、SIEM、ログ監視で異常を検知
- アラートを精査し、インシデントかどうか判定
③ Containment（封じ込め）
- 攻撃範囲を広げないための一時対応
- 感染端末のネットワーク隔離、攻撃元IPのブロック
④ Eradication（根絶）
- 攻撃の痕跡や原因を排除
- マルウェア削除、不正アカウントの無効化、脆弱性パッチの適用
⑤ Recovery（復旧）
- システムを安全な状態で再稼働
- 再発しないことを確認してからサービス再開
- 顧客や関係者への通知も含まれる
⑥ Lessons Learned（改善・教訓化）
- 事後レビュー（Post-Incident Review）
- 原因分析（Root Cause Analysis）
- 運用や設計の改善にフィードバック
実際のシナリオ例
例：WebアプリでSQLインジェクション攻撃を受けた場合
- 検知：WAFアラートで不審なSQLクエリを発見
- 封じ込め：対象アプリを一時停止、攻撃元IPを遮断
- 根絶：脆弱なクエリを修正、パッチ適用
- 復旧：テスト後にサービス再開、ユーザへ通知
- 改善：開発プロセスにセキュリティレビューを導入
Threat Modelling との関係
- Threat Modelling = 予防（前段階でのリスク削減）
- Incident Response = 対応（発生後の被害最小化）
この2つを組み合わせることで、
セキュリティのライフサイクル（予防＋対応） を回すことが可能になります。
図解フロー（Threat Modelling → Incident Response）
-
左の「Threat Modelling」で 予防策 を準備
-
右の「Incident Response」で 発生後の対応 を実行
-
Lessons Learned → Threat Modelling で改善サイクルを回す
まとめ
- Incident Response は「事故後の最小化と復旧」に特化したプロセス
- NIST SP 800-61 の 6ステップが広く採用されている
- Threat Modelling と組み合わせることで強固な体制を構築できる
- 教訓化（Lessons Learned）を通じて、次の Threat Modelling にフィードバックすることが重要