インシデント対応｜「攻撃されたあと」に何をする？

どれだけ守っても、事故はゼロにできません。大事なのは「起きたあと、どう動くか」。それを決めるのがインシデント対応です。

対応の流れ

そして最後に教訓（振り返り）。同じ事故をくり返さないよう、原因と対応を記録・改善します。

誰が動く？＝CSIRT

組織のセキュリティ事故対応チームを**CSIRT（シーサート）**と呼びます。平時は備え（訓練・監視）、有事は司令塔として動きます。

報告義務も増えている

個人情報漏えいや重要インフラでは、当局への報告義務があります（日本の新制度でさらに強化）。

もう少し詳しく（背景と理論）

インシデント対応には確立されたフレームワークがあります。NIST SP 800-61 は「準備 → 検知と分析 → 封じ込め・根絶・復旧 → 事後活動」というライフサイクルを定義しています¹。SANS の PICERL（Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned）も広く使われる同型のモデルです²。実務で効くのは、事故が起きてから考えるのではなく事前準備——連絡体制、権限、Runbook、ログ保全の仕組みを平時に整えること。そして最後の**教訓化（ポストモーテム）を、個人を責めない非難なし文化（blameless）で回し、再発防止に繋げることです³。証拠保全（フォレンジック）では、対応の各手順を記録し証拠の連鎖（chain of custody）**を保つことが、後の法的対応でも重要になります。

つぎに読むなら

• 日本の能動的サイバー防御法
• ランサムウェア対策
• ゼロトラスト

Footnotes

1. NIST SP 800-61 "Computer Security Incident Handling Guide." 準備・検知分析・封じ込め/根絶/復旧・事後活動の4フェーズを定義。 ↩

2. SANS の PICERL は6段階のインシデント対応モデル。NIST とほぼ対応し、現場のプレイブック設計に使われる。 ↩

3. 事後レビューは個人非難を避ける blameless postmortem が有効。原因をシステム・プロセスに求め、再発防止と学習を促す。 ↩