conducting-post-incident-lessons-learned

インシデント後の教訓の振り返り

使用するタイミング

• セキュリティインシデントが完全に解決され、復旧が完了した後
• 机上演習やIRシミュレーションの実施後
• 重大なニアミス事案の発生後
• 蓄積されたインシデントの傾向を四半期ごとに確認するとき
• 実際の経験に基づいてIRプレイブックを更新する必要があるとき

前提条件

• インシデントが完全に解決されていること（封じ込め、根絶、復旧が完了している）
• インシデントのタイムラインとドキュメントを収集していること
• すべてのインシデント対応者がレビューセッションに参加できること
• 共同で議論するための会議スペースがあること
• 指標分析に使用するインシデントチケット管理システムのデータがあること

ワークフロー

ステップ 1：インシデントデータを収集する

# Export incident timeline from ticketing system
curl -s "https://thehive.local/api/v1/case/$CASE_ID/timeline" \
  -H "Authorization: Bearer $THEHIVE_API_KEY" | jq '.' > incident_timeline.json

# Extract detection and response metrics from SIEM
index=notable incident_id="IR-2024-042"
| stats min(_time) as first_alert, max(_time) as last_alert,
  count as total_alerts, dc(src) as unique_sources

# Compile all responder actions and timestamps
grep -E "timestamp|action|analyst" /var/log/ir/IR-2024-042/*.json | \
  python3 -m json.tool > compiled_actions.json

ステップ 2：責任追及をしない事後検証会議を実施する

Structured Agenda (90 minutes):
1. Incident summary (5 min) - Factual overview
2. Timeline walkthrough (20 min) - Chronological events
3. What worked well (15 min) - Positive outcomes
4. What needs improvement (15 min) - Gaps and failures
5. Root cause analysis (15 min) - 5 Whys or fishbone
6. Action items (10 min) - Specific improvements with owners
7. Playbook updates (10 min) - Changes to IR procedures

Blameless Principles:
- Focus on systems and processes, not individuals
- Assume best intentions with available information
- Seek to understand, not to blame

ステップ 3：根本原因分析を実施する

# 5 Whys analysis example:
# Why 1: Why did ransomware encrypt production servers?
#   Answer: Attacker had domain admin credentials
# Why 2: Why did attacker have domain admin credentials?
#   Answer: Kerberoasted a service account and cracked it
# Why 3: Why was the service account password crackable?
#   Answer: Used a 12-character dictionary-based password
# Why 4: Why was the service account password weak?
#   Answer: No enforcement of service account password policy
# Why 5: Why was there no service account password policy?
#   Answer: PAM was not implemented for service accounts
# ROOT CAUSE: Lack of privileged access management

ステップ 4：対応指標を算出する

from datetime import datetime
events = {
    'compromise': '2024-01-10 14:00:00',
    'detection': '2024-01-15 08:30:00',
    'triage': '2024-01-15 08:45:00',
    'containment': '2024-01-15 09:30:00',
    'eradication': '2024-01-16 14:00:00',
    'recovery': '2024-01-18 16:00:00',
    'closure': '2024-01-25 10:00:00',
}
fmt = '%Y-%m-%d %H:%M:%S'
times = {k: datetime.strptime(v, fmt) for k, v in events.items()}
print(f"Dwell Time: {times['detection'] - times['compromise']}")
print(f"MTTD: {times['triage'] - times['detection']}")
print(f"MTTC: {times['containment'] - times['detection']}")
print(f"MTTR: {times['recovery'] - times['eradication']}")
print(f"Total Duration: {times['closure'] - times['detection']}")

ステップ 5：調査結果を文書化し、アクションアイテムを作成する

# Create tracked action items in project management
curl -X POST "https://jira.local/rest/api/2/issue" \
  -H "Authorization: Bearer $JIRA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "fields": {
      "project": {"key": "SEC"},
      "summary": "Implement PAM for service accounts (IR-2024-042)",
      "issuetype": {"name": "Task"},
      "priority": {"name": "High"},
      "assignee": {"name": "security_engineer"},
      "duedate": "2024-03-15"
    }
  }'

ステップ 6：プレイブックと検知ルールを更新する

# New Sigma detection rule based on incident learnings
title: Kerberoasting Activity Detected
status: stable
description: Detects Kerberoasting based on IR-2024-042 lessons
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
  condition: selection
level: high
tags:
  - attack.credential_access
  - attack.t1558.003

主要な概念

概念	説明
責任追及をしない事後検証	個人を責めるのではなく、システムに焦点を当ててインシデントを振り返ること
根本原因分析	インシデントが発生した根本的な理由を特定すること
5 Whys	根本原因を見つけるための反復的な質問手法
MTTD	平均検知時間 — 侵害から検知までの時間
MTTC	平均封じ込め時間 — 検知から封じ込めまでの時間
MTTR	平均復旧時間 — 根絶から完全復旧までの時間
継続的改善	実際のインシデントデータに基づいてIRプロセスを反復的に改善すること

ツールとシステム

ツール	目的
TheHive/ServiceNow	インシデントのタイムラインとドキュメント
Jira/Azure DevOps	アクションアイテムの追跡
Confluence/SharePoint	教訓の文書化
Splunk/Elastic	インシデント指標と検知の改善
Sigma	検知ルールの開発

よくあるシナリオ

1. ランサムウェアの事後検証：初期アクセスから暗号化までの一連の攻撃経路を振り返ります。検知の抜け漏れとバックアップの失敗を特定します。
2. フィッシングキャンペーンのレビュー：ユーザーがクリックした理由、メールフィルターが見逃した理由、トレーニングを改善する方法を分析します。
3. クラウドの設定ミスによるインシデント：IaC パイプライン、CSPM のカバレッジ、変更管理プロセスを振り返ります。
4. 内部脅威のレビュー：DLP の有効性、アクセス制御の不備、ユーザー監視機能を調査します。
5. サードパーティ侵害の影響：ベンダーリスク評価プロセスとデータ共有契約を振り返ります。

出力形式

• インシデント後レビュー会議の議事録
• 根本原因分析ドキュメント
• インシデント指標レポート（MTTD、MTTC、MTTR）
• 担当者と期限を記載したアクションアイテム一覧
• 更新済みのIRプレイブックと検知ルール
• 経営陣向けのエグゼクティブサマリー