incident-response

インシデント対応

初期トリアージからフォレンジック収集、重大度の宣言、エスカレーションの振り分けまで、インシデント対応の全ライフサイクルを対象とするスキルです。これは脅威ハンティング（threat-detection を参照）でも、インシデント発生後のコンプライアンスマッピング（governance/compliance-mapping を参照）でもありません。宣言されたセキュリティインシデントの分類、トリアージ、管理を対象とします。

---

目次

• 概要
• インシデントトリアージツール
• インシデントの分類
• 重大度フレームワーク
• 誤検知のフィルタリング
• フォレンジック証拠の収集
• エスカレーション経路
• 規制上の通知義務
• ワークフロー
• アンチパターン
• 相互参照

---

概要

このスキルでできること

このスキルでは、インシデントのトリアージと対応の手法とツールを提供します。セキュリティイベントを種類ごとのインシデントに分類し、重大度を評価し、誤検知をフィルタリングし、エスカレーション経路を判断するとともに、証拠保全の管理下でフォレンジック証拠の収集を開始します。

他のセキュリティスキルとの違い

スキル	対象	アプローチ
incident-response（このスキル）	進行中のインシデント	事後対応 — 分類、エスカレーション、証拠収集
threat-detection	インシデント発生前のハンティング	先行対応 — アラートが発報される前に脅威を発見
cloud-security	クラウドのセキュリティ態勢評価	予防 — IAM、S3、ネットワークの設定ミス
red-team	攻撃シミュレーション	攻撃 — 検知・対応能力をテスト

前提条件

トリアージの前に、セキュリティイベントを取り込む必要があります。イベントの発生元には、SIEM アラート、EDR の検知、脅威インテリジェンスのフィード、ユーザーからの報告があります。トリアージツールは JSON 形式のイベントペイロードを受け付けます。以下の入力スキーマを参照してください。

---

インシデントトリアージツール

incident_triage.py ツールは、イベントを分類し、誤検知を確認して重大度を評価し、エスカレーションを判断するとともに、フォレンジックの事前分析を行います。

# Classify an event from JSON file
python3 scripts/incident_triage.py --input event.json --classify --json

# Classify with false positive filtering enabled
python3 scripts/incident_triage.py --input event.json --classify --false-positive-check --json

# Force a severity level for tabletop exercises
python3 scripts/incident_triage.py --input event.json --severity sev1 --json

# Read event from stdin
echo '{"event_type": "ransomware", "host": "prod-db-01", "raw_payload": {}}' | \
  python3 scripts/incident_triage.py --classify --false-positive-check --json

入力イベントスキーマ

{
  "event_type": "ransomware",
  "host": "prod-db-01",
  "user": "svc_backup",
  "source_ip": "10.1.2.3",
  "timestamp": "2024-01-15T14:32:00Z",
  "raw_payload": {}
}

終了コード

コード	意味	必要な対応
0	SEV3/SEV4 または問題なし	標準的なチケットベースの対応
1	SEV2 — 高	1 時間以内にブリッジコールを実施し、非同期で連携
2	SEV1 — 重大	直ちに 15 分間の緊急対応会議を開催し、全員が参加

---

インシデントの分類

セキュリティイベントは 14 種類のインシデントに分類されます。分類により、デフォルトの重大度、MITRE の手法との対応付け、対応 SLA が決まります。

インシデント分類体系

インシデントの種類	デフォルトの重大度	MITRE の手法	対応 SLA
ransomware	SEV1	T1486	15 分
data_exfiltration	SEV1	T1048	15 分
apt_intrusion	SEV1	T1566	15 分
supply_chain_compromise	SEV1	T1195	15 分
domain_controller_breach	SEV1	T1078.002	15 分
credential_compromise	SEV2	T1110	1 時間
lateral_movement	SEV2	T1021	1 時間
malware_infection	SEV2	T1204	1 時間
insider_threat	SEV2	T1078	1 時間
cloud_account_compromise	SEV2	T1078.004	1 時間
unauthorized_access	SEV3	T1190	4 時間
policy_violation	SEV3	N/A	4 時間
phishing_attempt	SEV4	T1566.001	24 時間
security_alert	SEV4	N/A	24 時間

SEV のエスカレーショントリガー

以下のいずれかに該当すると、重大度が自動的に引き上げられます。

トリガー	新しい重大度
ランサムウェアの脅迫文が見つかった	SEV1
データの流出が進行中であると確認された	SEV1
CloudTrail または SIEM が無効化された	SEV1
ドメインコントローラーへのアクセスが確認された	SEV1
2 台目のシステムが侵害された	SEV1
流出したデータ量が 1 GB を超える	SEV2 以上
C スイートのアカウントにアクセスされた	SEV2 以上

---

重大度フレームワーク

SEV レベルマトリックス

レベル	名前	基準	呼び出されるスキル	エスカレーション経路
SEV1	重大	ランサムウェアを確認済み、PII/PHI の流出が進行中（>10K records）、ドメインコントローラー侵害、防御回避（CloudTrail 無効化）、サプライチェーン侵害	すべてのスキル（並列）	SOC Lead → CISO → CEO → Board Chair
SEV2	高	機密システムへの不正アクセスを確認済み、特権昇格を伴う認証情報の侵害、水平移動を確認済み、実行は確認されていないがランサムウェアの兆候がある	トリアージ + 封じ込め + フォレンジック	SOC Lead → CISO
SEV3	中	不正アクセスの疑い（未確認）、マルウェアを検出して封じ込め済み、単一アカウントの侵害（特権昇格なし）	トリアージ + 封じ込め	SOC Lead → Security Manager
SEV4	低	影響が確認されていないセキュリティアラート、情報提供のみの兆候、データリスクを伴わないポリシー違反	トリアージのみ	L3 Analyst queue

---

誤検知のフィルタリング

トリアージツールは、誤検知の増加を防ぐため、エスカレーションの前に5つのフィルターを適用します。

誤検知フィルターの種類

フィルター	説明	パターンの例
CI/CD エージェントのアクティビティ	既知のビルド／デプロイエージェントが異常としてフラグ付けされる	jenkins, github-actions, circleci, gitlab-runner
テスト環境のタグ付け	非本番環境としてタグ付けされたアセット	test-, staging-, dev-, sandbox-
スケジュール済みジョブのパターン	アラートを発生させる想定内のバッチプロセス	cron, scheduled_task, batch_job, backup_
ホワイトリスト登録済みの ID	明示的に承認されたサービスアカウント	svc_monitoring, svc_backup, datadog-agent
スキャナーのアクティビティ	既知のセキュリティスキャナーおよび脆弱性ツール	nessus, qualys, rapid7, aws_inspector

誤検知と確認された場合、エスカレーションを抑止し、監査用に抑止理由を記録します。同じソースから誤検知が繰り返し発生する場合は、トリアージ時に何度もフィルタリングするのではなく、検出レイヤーで調整して除外してください。

---

フォレンジック証拠の収集

証拠の収集には、DFRWS の6段階フレームワークと、揮発性の高いものから取得する原則を適用します。

DFRWS の6段階

フェーズ	作業	優先度
識別	どのような証拠がどこに存在するかを特定する	即時
保全	変更を防止する — 書き込みブロック、スナップショット、法的保全	即時
収集	揮発性の高い順に証拠を取得する	即時
検査	収集した証拠を技術的に分析する	2時間以内
分析	調査の状況を踏まえて調査結果を解釈する	4時間以内
提示	保管の連鎖を記載した調査結果報告書を作成する	インシデントの終結前

揮発性証拠 — 最初に収集

1. 稼働中のメモリ（RAM ダンプ）— 再起動時に失われます
2. 実行中のプロセスと開いているネットワーク接続（netstat、ps）
3. ログイン中のユーザーとアクティブなセッション
4. システム稼働時間と現在時刻（タイムラインの基準として）
5. 環境変数とロード済みのカーネルモジュール

保管の連鎖に関する要件

すべての証拠項目について、次の情報を記録する必要があります。

• 取得時の SHA-256 ハッシュ
• タイムゾーンオフセット付きの UTC 取得タイムスタンプ
• 使用ツールの出所（FTK Imager、Volatility、dd、AWS CloudTrail エクスポート）
• 調査担当者の ID
• 移管記録（誰がいつ保管していたか）

---

エスカレーション経路

重大度別

重大度	即時連絡先	ブリッジコール	外部通知
SEV1	SOC Lead + CISO（15分）	即時にウォールームを開設	法務 + 広報は待機；規制当局への通知は期限表に従う
SEV2	SOC Lead（30分以内に非同期で連絡）	1時間のブリッジコール	PII が関与する場合は法務に通知
SEV3	Security Manager（4時間以内）	非同期のみ	対象範囲が拡大しない限り不要
SEV4	L3 Analyst queue（24時間以内）	なし	なし

インシデントの種類別

インシデントの種類	主なエスカレーション先	二次対応
ランサムウェア／APT	CISO + CEO	データが危険にさらされている場合は取締役会
PII／PHI の侵害	法務 + CISO	規制当局（期限表に従う）
クラウドアカウントの侵害	クラウドセキュリティチーム	CISO
内部脅威	HR + 法務 + CISO	犯罪に該当する場合は法執行機関
サプライチェーン	CISO + ベンダー管理部門	取締役会

---

規制当局への通知義務

通知期限のカウントは、調査の完了時ではなく、インシデントの宣言時に開始します。

フレームワーク	インシデントの種類	期限	罰則
GDPR (EU 2016/679)	個人データの侵害	発見から72時間以内	全世界の売上高の最大4％
PCI-DSS v4.0	カード会員データの侵害	アクワイアラーへ24時間以内	カードブランドによる罰金
HIPAA (45 CFR 164)	PHI の侵害（500人超）	発見から60日以内	違反カテゴリごとに最大190万ドル
NY DFS 23 NYCRR 500	サイバーセキュリティイベント	DFS へ72時間以内	規制上の制裁
SEC Rule (17 CFR 229.106)	重要なサイバーセキュリティインシデント	重要性の判断から4営業日以内	SEC による執行
CCPA / CPRA	機微な PI の侵害	不合理な遅延なく	AG による執行、私的訴権
NIS2 (EU 2022/2555)	重大なインシデント（不可欠なサービス）	24時間以内に早期警告、72時間以内に通知	各国当局による制裁

運用ルール： 宣言時に対象範囲が不明確な場合は、適用される期限のうち最も厳しいものを想定し、最初の対応時間枠内に対象範囲を確認してください。

期限の完全な一覧：references/regulatory-deadlines.md

---

ワークフロー

ワークフロー 1：迅速なトリアージ（15分）

エスカレーションの判断前に分類が必要な単一のアラート向け：

# 1. Classify the event with false positive filtering
python3 scripts/incident_triage.py --input alert.json \
  --classify --false-positive-check --json

# 2. Review severity, escalation_path, and false_positive_flag in output
# 3. If severity = sev1 or sev2, page SOC Lead immediately
# 4. If false_positive_flag = true, document and close

判断： 終了コード 2 = 直ちに SEV1 の対策チームを招集。終了コード 1 = 30分以内に SEV2 のブリッジコールを実施。

ワークフロー 2：完全なインシデント対応（SEV1）

T+0   Detection arrives (SIEM alert, EDR, user report)
T+5   Classify with incident_triage.py --classify --false-positive-check
T+10  If SEV1: page CISO, open war room, start regulatory clock
T+15  Initiate forensic collection (volatile evidence first)
T+15  Containment assessment (parallel with forensics)
T+30  Human approval gate for any containment action
T+45  Execute approved containment
T+60  Assess containment effectiveness, brief Legal if PII/PHI scope
T+4h  Final forensic evidence package, dwell time estimate
T+8h  Eradication and recovery plan
T+72h Regulatory notification submission (if GDPR/NIS2 triggered)

# Full classification with forensic context
python3 scripts/incident_triage.py --input incident.json \
  --classify --false-positive-check --severity sev1 --json > incident_triage_output.json

# Forensic pre-analysis
python3 scripts/incident_triage.py --input incident.json --json | \
  jq '.forensic_findings, .chain_of_custody_steps'

ワークフロー 3：机上演習シミュレーション

実際のイベントを発生させずに、特定の重大度レベルのインシデントをシミュレーションします：

# Simulate SEV1 ransomware incident
echo '{"event_type": "ransomware", "host": "prod-db-01", "user": "svc_backup"}' | \
  python3 scripts/incident_triage.py --classify --severity sev1 --json

# Simulate SEV2 credential compromise
echo '{"event_type": "credential_compromise", "user": "admin_user", "source_ip": "203.0.113.5"}' | \
  python3 scripts/incident_triage.py --classify --false-positive-check --json

# Verify escalation paths for all 14 incident types
for type in ransomware data_exfiltration credential_compromise lateral_movement; do
  echo "{\"event_type\": \"$type\"}" | python3 scripts/incident_triage.py --classify --json
done

---

アンチパターン

1. 調査完了時に通知期限のカウントを開始する — 規制上の期限（GDPR は72時間、PCI は24時間）は調査完了時ではなく、発見時に開始します。宣言が遅れると、インシデント自体が軽微でも、組織は最大限の罰則を受ける可能性があります。
2. 揮発性証拠を収集する前に封じ込める — システムを再起動または隔離すると、RAM、実行中のプロセス、アクティブな接続が失われます。揮発性証拠のフォレンジック収集は封じ込めと並行して行う必要があり、封じ込め後に行ってはなりません。
3. エスカレーション前に誤検知を確認しない — すべてのアラートを SEV1 としてエスカレーションすると、SOC の信頼性が低下し、アラート疲れを引き起こします。CISO に通知する前に、必ず誤検知フィルターを実行してください。
4. インシデント指揮の判断を記録しない — 不確実な状況下での判断を含め、SEV1 中に行われたすべての判断は、タイムスタンプと理由を添えて証拠の記録に残す必要があります。記録されていない判断は、規制当局による調査で正当性を示せません。
5. インシデントのクローズを調査完了とみなす — インシデントは、調査が完了した時ではなく、根絶と復旧が完了した時点でクローズします。フォレンジックレポートや規制当局への提出は、運用上のクローズ後も続く場合があります。
6. 単一の情報源に基づく分類 — 裏付けとなる証拠なしに、単一のデータソース（1件の SIEM アラート）からインシデントを分類すると、誤分類につながることが少なくありません。SEV1 を宣言する前に、少なくとも2つの独立したシグナルを収集してください。
7. 封じ込めにおける人間の承認ゲートを迂回する — 人間の承認なしに実行する自動封じ込めアクション（ネットワークの隔離、認証情報の失効）は、本番環境の停止や証拠の破壊、法的責任の発生につながる可能性があります。変更を伴う封じ込めアクションには、必ず人間の承認が必要です。

---

相互参照

スキル	関連性
threat-detection	ハンティングで確認された調査結果は、トリアージと分類のためにインシデント対応へ引き継がれます
cloud-security	クラウドのセキュリティ態勢に関する調査結果（IAM の侵害、S3 の露出）により、インシデント分類が必要になる場合があります
red-team	レッドチームの調査結果は検知範囲を検証し、確認されたギャップはハンティングの仮説になります
security-pen-testing	実環境で悪用されたペネトレーションテストの脆弱性は、進行中のインシデントに対応するため、インシデント対応へ引き継がれます