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-Notes	在事件记录中记录 PIR 调查结果
SN-Update-Record	更新事件字段，例如 close_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 个可观测对象（3 个 IP、2 个域名、2 个文件哈希值、1 个电子邮件地址）
5. 计算 TTD 为 2h 15m，并与组织 1h 的目标进行比较
6. 记录 5 项改进建议并指定负责人
7. 创建后续变更请求，为电子邮件网关启用 URL 沙箱检测

示例 2：涉及监管影响的数据泄露 PIR

1. 检索涉及已确认 PII 暴露的事件 SIR0007500
2. 重建从初始失陷到发现为止的 7 天时间线
3. 找出 72 小时的检测延迟，在此期间攻击者的访问未被发现
4. 将受影响服务器上的 3 个未修补严重漏洞与事件关联起来
5. 记录监管通知时间线和合规状态
6. 为法务和合规团队生成执行摘要
7. 创建 8 项改进措施，包括强制执行补丁 SLA

相关技能

• secops/correlation-insights - 关联 PIR 期间发现的相关事件
• secops/incident-summarization - 根据 PIR 发现生成执行摘要
• secops/metrics-analysis - 跟踪 PIR 指标随时间变化的趋势
• secops/shift-handover - 在交班简报中参考 PIR 发现
• security/incident-response - PIR 审查的事件响应流程