mcpField
P
post-incident-analysis

post-incident-analysis

github.com/happy-technologies-llcセキュリティ4141 回インストール2 日前に更新
リポジトリ

post-incident-analysis について

ServiceNow Security Operationsで、クローズ済みのセキュリティインシデントを振り返るためのスキルです。インシデント記録、作業メモ、タスク、監査履歴、脅威オブザーバブル、脆弱性データをまとめ、タイムラインや対応指標、改善案を作成します。

主な機能

  1. 01インシデントのタイムライン再構成
  2. 02検知・対応指標の算出
  3. 03検知とプロセスの不備を特定
  4. 04オブザーバブルと脆弱性の関連付け
  5. 05レビュー報告と改善案の作成

活用シーン

  1. 01解決済みセキュリティインシデントのレビュー
  2. 02検知や対応の遅延分析
  3. 03インシデントの作業メモへの結果記録

MCP 対応

MCP ツールで ServiceNow のインシデント、タスク、監査、オブザーバブル、脆弱性データを取得し、分析結果をインシデント記録に記載します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/happy-technologies-llc/happy-platform-skills --skill post-incident-analysis

インストール後、Claude Code で/post-incident-analysisを入力して読み込まれたか確認します。

詳細

インシデント事後分析

概要

このスキルは、ServiceNow Security Operations でクローズ済みのセキュリティインシデントに対する事後レビュー（PIR）を実施するための、体系的な手法を提供します。インシデントのタイムラインを再構築し、検知および対応プロセスの不足点を特定して、包括的な教訓の文書を作成します。

主な機能：

  • インシデントの作成から解決までの完全な時系列を再構築します
  • 主要な対応指標（検知、封じ込め、根絶、復旧までの時間）を算出します
  • インジケーターの見落としや遅延があった検知の不足点を特定します
  • 対応の有効性とプロセスの遵守状況を分析します
  • 根本原因の調査結果と寄与要因を文書化します
  • 実行可能な改善策を提案します
  • 体系化された教訓の記録を作成します

使用するタイミング： セキュリティインシデントの解決およびクローズ後に使用します。通常、重大なインシデントではクローズから5～10営業日以内に、または重大度の低いイベントでは定期レビューの一環として実施します。

前提条件

  • ロール： sn_si.analyst、sn_si.manager、sn_si.admin
  • アクセス： sn_si_incident、sn_si_task、sn_ti_observable、sn_vul_vulnerable_item、sys_journal_field、sys_audit テーブルへの読み取りアクセス
  • プラグイン： Security Incident Response (sn_si)、Threat Intelligence (sn_ti)、Vulnerability Response (sn_vul)
  • データ： 作業メモ、タスク、オブザーバブルが登録されたクローズ済みのセキュリティインシデント

手順

ステップ 1：クローズ済みのインシデントレコードを取得する

解決の詳細と時間フィールドを含む、インシデントレコード全体を取得します。

MCP を使用する場合：

Tool: SN-Get-Record
Parameters:
  table_name: sn_si_incident
  sys_id: [INCIDENT_SYS_ID]
  fields: sys_id,number,short_description,description,category,subcategory,priority,state,assigned_to,assignment_group,cmdb_ci,opened_at,resolved_at,closed_at,close_notes,close_code,business_criticality,risk_score,attack_vector,kill_chain_phase,affected_user,caller_id,contact_type

REST を使用する場合：

GET /api/now/table/sn_si_incident?sysparm_query=number=[INCIDENT_NUMBER]&sysparm_fields=sys_id,number,short_description,description,category,subcategory,priority,state,assigned_to,assignment_group,cmdb_ci,opened_at,resolved_at,closed_at,close_notes,close_code,business_criticality,risk_score,attack_vector,kill_chain_phase,affected_user,contact_type&sysparm_limit=1&sysparm_display_value=true
ステップ 2：作業メモからインシデントのタイムラインを作成する

すべての作業メモとコメントを時系列順に取得し、イベントのタイムラインを再構築します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sys_journal_field
  query: name=sn_si_incident^element_id=[INCIDENT_SYS_ID]^elementINwork_notes,comments^ORDERBYsys_created_on
  fields: element,value,sys_created_on,sys_created_by
  limit: 500

REST を使用する場合：

GET /api/now/table/sys_journal_field?sysparm_query=name=sn_si_incident^element_id=[INCIDENT_SYS_ID]^elementINwork_notes,comments^ORDERBYsys_created_on&sysparm_fields=element,value,sys_created_on,sys_created_by&sysparm_limit=500
ステップ 3：関連するすべてのタスクとその結果を取得する

セキュリティインシデントのタスクを取得し、対応ワークフローとタスクの完了時刻を確認します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sn_si_task
  query: security_incident=[INCIDENT_SYS_ID]^ORDERBYopened_at
  fields: sys_id,number,short_description,state,priority,assigned_to,assignment_group,opened_at,closed_at,close_notes,work_duration
  limit: 50

REST を使用する場合：

GET /api/now/table/sn_si_task?sysparm_query=security_incident=[INCIDENT_SYS_ID]^ORDERBYopened_at&sysparm_fields=sys_id,number,short_description,state,priority,assigned_to,assignment_group,opened_at,closed_at,close_notes,work_duration&sysparm_limit=50&sysparm_display_value=true
ステップ 4：監査ログからフィールドの変更履歴を分析する

フィールドの変更（優先度、状態、割り当て）を確認し、インシデントの推移を追跡します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sys_audit
  query: tablename=sn_si_incident^documentkey=[INCIDENT_SYS_ID]^fieldnameINpriority,state,assigned_to,assignment_group,category^ORDERBYsys_created_on
  fields: fieldname,oldvalue,newvalue,sys_created_on,user
  limit: 200

REST を使用する場合：

GET /api/now/table/sys_audit?sysparm_query=tablename=sn_si_incident^documentkey=[INCIDENT_SYS_ID]^fieldnameINpriority,state,assigned_to,assignment_group,category^ORDERBYsys_created_on&sysparm_fields=fieldname,oldvalue,newvalue,sys_created_on,user&sysparm_limit=200
ステップ 5：脅威オブザーバブルと脅威インテリジェンスを確認する

特定された IOC とその特定時刻を調べ、検知の適時性を評価します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sn_ti_observable
  query: security_incident=[INCIDENT_SYS_ID]^ORDERBYfirst_seen
  fields: sys_id,type,value,source,confidence,first_seen,last_seen,threat_score,sys_created_on
  limit: 100

REST を使用する場合：

GET /api/now/table/sn_ti_observable?sysparm_query=security_incident=[INCIDENT_SYS_ID]^ORDERBYfirst_seen&sysparm_fields=sys_id,type,value,source,confidence,first_seen,last_seen,threat_score,sys_created_on&sysparm_limit=100
ステップ 6：脆弱性データと関連付ける

攻撃が既知の脆弱性を悪用したか、またパッチが利用可能だったかを確認します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sn_vul_vulnerable_item
  query: cmdb_ci=[AFFECTED_CI_SYS_ID]
  fields: sys_id,vulnerability,cmdb_ci,state,risk_score,cvss_score,first_found,last_found
  limit: 50

Tool: SN-Query-Table
Parameters:
  table_name: sn_vul_entry
  query: sys_idIN[VULNERABILITY_SYS_IDS]
  fields: sys_id,cve_id,description,cvss_score,severity,exploit_available,vendor_advisory,published_date
  limit: 20

REST を使用する場合：

GET /api/now/table/sn_vul_vulnerable_item?sysparm_query=cmdb_ci=[AFFECTED_CI_SYS_ID]&sysparm_fields=sys_id,vulnerability,cmdb_ci,state,risk_score,cvss_score,first_found,last_found&sysparm_limit=50&sysparm_display_value=true

GET /api/now/table/sn_vul_entry?sysparm_query=sys_idIN[VULNERABILITY_SYS_IDS]&sysparm_fields=sys_id,cve_id,description,cvss_score,severity,exploit_available,vendor_advisory,published_date&sysparm_limit=20
ステップ 7：対応指標を算出する

インシデントのタイムラインから主要なパフォーマンス指標を算出します。

算出する指標：

  • 検知までの時間（TTD）： 最初のオブザーバブルの first_seen とインシデントの opened_at の間の時間
  • トリアージまでの時間（TTT）： opened_at と「New」から最初に状態が変更されるまでの時間
  • 封じ込めまでの時間（TTC）： opened_at と封じ込めタスクの完了までの時間
  • 根絶までの時間（TTE）： 封じ込めから根絶タスクの完了までの時間
  • 解決までの時間（TTR）： opened_at と resolved_at の間の時間
  • 再割り当て回数： 監査ログに記録された assignment_group の変更回数
  • エスカレーション回数： 監査ログに記録された優先度の引き上げ回数
ステップ 8：インシデント事後分析を文書化する

MCP を使用する場合：

Tool: SN-Add-Work-Notes
Parameters:
  table_name: sn_si_incident
  sys_id: [INCIDENT_SYS_ID]
  work_notes: |
    === POST-INCIDENT ANALYSIS REPORT ===
    Incident: SIR0008901 | Analyst: J. Smith | Review Date: 2026-03-19

    EXECUTIVE SUMMARY:
    Ransomware incident affecting file server FILESVR-03. Initial access
    via phishing email delivered to user in Finance department. Malware
    propagated to shared drives before containment. No data exfiltration
    confirmed. Full recovery from backups completed.

    TIMELINE RECONSTRUCTION:
    2026-03-10 08:15 - Phishing email received by user (first observable)
    2026-03-10 08:22 - User clicked malicious link and downloaded payload
    2026-03-10 08:45 - Malware executed, began encrypting local files
    2026-03-10 09:30 - Encryption spread to mapped network drives
    2026-03-10 10:15 - Help desk ticket opened by affected user
    2026-03-10 10:30 - Security incident created (SIR0008901)
    2026-03-10 10:45 - Triage complete, escalated to P1
    2026-03-10 11:00 - Server isolated from network (containment)
    2026-03-10 14:00 - Malware sample identified, IOCs extracted
    2026-03-11 09:00 - Full forensic analysis complete
    2026-03-12 16:00 - Server rebuilt and restored from backup
    2026-03-13 10:00 - Incident resolved and closed

    RESPONSE METRICS:
    Time to Detect: 2h 15m (email received → incident created)
    Time to Triage: 15m
    Time to Contain: 30m (from triage)
    Time to Eradicate: 1d 3h
    Time to Resolve: 3d 1h 30m
    Reassignments: 1
    Escalations: 1 (P3 → P1)

    DETECTION GAP ANALYSIS:
    - Email gateway did not flag the phishing email (new domain, no reputation data)
    - EDR agent on workstation was running outdated signatures (3 days old)
    - Network-based detection triggered 45 minutes after execution
    - No UEBA alert for anomalous file access patterns

    ROOT CAUSE:
    Primary: Spear-phishing email bypassed email security controls
    Contributing: EDR signature update delay, user security awareness gap

    WHAT WENT WELL:
    - Rapid containment once incident was identified (30 minutes)
    - Clean backups available for full restoration
    - Clear communication to management throughout

    IMPROVEMENT RECOMMENDATIONS:
    1. Implement URL sandboxing on email gateway (Priority: High)
    2. Reduce EDR signature update interval to 4 hours (Priority: High)
    3. Deploy UEBA for anomalous file access detection (Priority: Medium)
    4. Conduct targeted phishing awareness training for Finance (Priority: Medium)
    5. Add network segmentation between user workstations and file servers (Priority: Low)

    LESSONS LEARNED:
    - Phishing remains the primary initial access vector; defense-in-depth required
    - Backup strategy proved critical for recovery; validate backup integrity quarterly
    - Containment playbook was effective; formalize for similar future incidents

ツールの使用方法

ツール目的
SN-Query-Tableインシデント履歴、タスク、オブザーバブル、監査エントリー、脆弱性を取得します
SN-Get-Recordレビュー対象のインシデントの詳細を取得します
SN-Add-Work-NotesPIR の調査結果をインシデントレコードに記録します
SN-Update-Recordclose_code などのインシデントフィールドを更新するか、PIR への参照を追加します
SN-Execute-Background-Script関連レコード全体にわたる複雑な指標を算出するスクリプトを実行します

ベストプラクティス

  • 詳細が新しいうちに速やかに PIR を実施します。重大インシデントの場合は、5 営業日以内に行います
  • 個人の失敗ではなく、プロセスやツールの不足に焦点を当てることで、非難しない文化を維持します
  • バランスの取れた評価のため、定性的な分析と併せて定量的な指標（TTD、TTC、TTR）を使用します
  • MITRE ATT&CK フレームワークに照らし、手法ごとの検知と防止における不足を体系的に特定します
  • 改善アクションを正式なタスクまたは変更リクエストとして追跡し、確実に実行します
  • 過去の指標を用いてベースラインと比較し、インシデント対応のパフォーマンスを適切な文脈で評価します
  • 包括的なレビューのため、IT 運用チーム、ネットワークチーム、管理者を含むすべての関係者を参加させます
  • PIR レポートをナレッジ記事として保管し、今後の参照やトレーニングに活用します

トラブルシューティング

作業メモの欠落によるタイムラインの不完全さ

原因： インシデントの対応に追われ、アナリストが作業メモにすべてのアクションを記録していない場合があります。 解決策： 監査ログデータ（sys_audit）、syslog エントリ、タスク完了時のタイムスタンプで補完し、タイムラインの空白を埋めます。必要に応じて、対応したアナリストに聞き取りを行います。

正確な検知時間を算出できない

原因： オブザーバブルの first_seen タイムスタンプは、攻撃が実際に始まった時刻ではなく、データが取り込まれた時刻を示している場合があります。 解決策： 外部 SIEM または EDR のタイムスタンプと照合します。syslog エントリを使用して、侵害の最も早い証拠を特定します。

脆弱性データがインシデントの CI にリンクされていない

原因： 命名の不一致により、インシデントの cmdb_ci フィールドが脆弱性レコードの CI と一致しない場合があります。 解決策： LIKE 演算子を使って CI 名で sn_vul_vulnerable_item を検索するか、IP アドレスまたはホスト名でクエリを実行します。

監査ログに欠落がある

原因： 監査ログの保持ポリシーにより、古いインシデントのエントリが削除されている場合があります。 解決策： アーカイブされたレコードがないか、sys_audit_delete テーブルを確認します。今後の PIR では、監査ログを少なくとも 90 日間保持するようにします。

例

例 1：フィッシングインシデントの PIR

  1. クローズ済みのインシデント SIR0008901 と、関連するすべてのフィールドを取得します
  2. 3 日間のインシデント対応期間にわたる、45 件の作業メモを取得します
  3. 封じ込め、フォレンジック、復旧、コミュニケーションを含む 12 件のタスクを特定します
  4. 8 件のオブザーバブル（IP アドレス 3 件、ドメイン 2 件、ファイルハッシュ 2 件、メールアドレス 1 件）を見つけます
  5. TTD を 2 時間 15 分と算出し、組織の目標である 1 時間と比較します
  6. 担当者を割り当てた 5 件の改善提案を記録します
  7. メールゲートウェイでの URL サンドボックス化を目的とした、フォローアップの変更リクエストを作成します

例 2：規制上の影響を伴うデータ侵害の PIR

  1. PII の漏えいが確認されたインシデント SIR0007500 を取得します
  2. 最初の侵害から発見までの 7 日間のタイムラインを再構成します
  3. 攻撃者が検知されないままアクセスできていた、72 時間の検知ギャップを特定します
  4. 影響を受けたサーバー上の、未適用の 3 件の重大な脆弱性と関連付けます
  5. 規制当局への通知のタイムラインとコンプライアンス状況を記録します
  6. 法務チームとコンプライアンスチーム向けのエグゼクティブサマリーを作成します
  7. 必須のパッチ適用 SLA の遵守徹底など、8 件の改善アクションを作成します

関連スキル

  • secops/correlation-insights - PIR 中に発見された関連インシデントを関連付けます
  • secops/incident-summarization - PIR の調査結果からエグゼクティブサマリーを作成します
  • secops/metrics-analysis - PIR 指標の経時的な傾向を追跡します
  • secops/shift-handover - シフトの引き継ぎ時に PIR の調査結果を参照します
  • security/incident-response - PIR 中にレビューするインシデント対応手順

コメント

Markdown 対応