2. 安全事件生命周期与工单模型

在SOC日常运营中，一条告警从产生到最终闭环，往往要经过多个系统、多个角色和多次状态跃迁。如果没有统一的生命周期模型和工单状态机，就会出现“告警已处理但工单还挂着”“工单已关闭但事件又复发”这类脱节问题。本节把事件生命周期、工单状态机、优先级与SLA三件事放在一起讲，因为它们本质上是同一套编排逻辑的三个侧面：生命周期定义“事件走到哪一步”，状态机定义“工单允许怎么走”，优先级与SLA定义“每一步该多快走完”。

一、事件生命周期：从告警到闭环的六个阶段

安全事件的生命周期可以抽象为六个阶段，每个阶段都有明确的输入、输出和判定条件。需要强调的是，这里的“阶段”是逻辑划分，不是每个事件都必须严格串行经过；低危事件可能跳过部分阶段，高危事件则可能在阶段间反复回退。

• 告警产生（Alert）：由SIEM、EDR、NDR、WAF等检测源产生原始告警，携带时间戳、检测规则ID、源/目的IP、主机名、用户、原始日志等字段。此阶段的关键是“可追溯”，每条告警必须有唯一ID。
• 事件确认（Triage）：由一线分析师判断告警是否为真实安全事件。判定依据包括：告警是否命中已知白名单、是否与资产重要性匹配、是否与近期变更相关。确认后事件从“告警”升级为“事件”，生成工单。
• 事件分级（Classification）：根据影响范围、数据敏感度、攻击阶段（如是否已进入横向移动）确定优先级。分级结果直接决定SLA计时起点和响应时限。
• 调查与遏制（Investigation & Containment）：分析师收集证据、还原攻击链、隔离受影响主机或封禁IP。此阶段可能产生子工单，例如“主机隔离”“账号禁用”“防火墙封禁”。
• 根除与恢复（Eradication & Recovery）：清除恶意文件、修复漏洞、恢复业务。恢复前需确认不再有残留IOC，并记录恢复验证结果。
• 闭环与复盘（Closure & Review）：工单关闭，事件归档，输出复盘报告。闭环不是“点一下关闭”，而是确认所有子任务完成、SLA达标、证据留存完整。

这六个阶段中，最容易出问题的是“确认”与“分级”之间的衔接。很多SOC把确认和分级合并成一步，导致低危告警被误升级为高危，或者高危事件被误判为低危而延迟响应。建议在工单模型中保留独立的“分级”字段，并记录分级依据，便于后续审计和模型调优。

二、工单状态机：让状态跃迁可审计、可约束

工单状态机是事件生命周期的“执行骨架”。一个可落地的状态机至少包含以下状态：新建（New）、已确认（Acknowledged）、调查中（Investigating）、已遏制（Contained）、已恢复（Recovered）、待关闭（Pending Closure）、已关闭（Closed），以及两个特殊状态：误报（False Positive）和挂起（On Hold）。

状态之间的跃迁必须满足前置条件。例如：从“新建”到“已确认”必须填写确认人和确认时间；从“调查中”到“已遏制”必须至少有一条遏制动作记录；从“待关闭”到“已关闭”必须所有子工单完成且SLA计时已停止。不允许从“新建”直接跳到“已关闭”，也不允许在“已关闭”后直接修改状态，只能通过“重开（Reopen）”回到“调查中”。

状态机的价值在于：它把“谁在什么时候把工单改成了什么状态”变成可查询的记录。当出现“事件复发”时，可以回溯上一次关闭时的状态和证据，判断是关闭过早还是根除不彻底。下面这张图展示了事件生命周期与工单状态机的对应关系，以及优先级和SLA在其中的作用位置。

三、优先级设计：从“拍脑袋”到可计算

优先级不能只靠分析师主观判断，否则同一类事件在不同班次可能得到不同级别。建议采用“影响度 × 紧急度”的二维矩阵，并给出可计算的评分规则。影响度由资产重要性、数据敏感度、受影响用户数决定；紧急度由攻击阶段、是否仍在活跃、是否有横向移动迹象决定。

一个可落地的评分示例：影响度取值1~5，紧急度取值1~5，优先级分数 = 影响度 × 紧急度。分数≥20为P1，12~19为P2，6~11为P3，≤5为P4。例如：核心数据库服务器（影响度5）出现勒索软件加密行为（紧急度5），分数25，判定为P1；普通办公终端（影响度2）出现一次失败的暴力破解（紧急度2），分数4，判定为P4。这个规则不是绝对标准，但能让分级有据可依，也便于在工单系统中自动计算。

四、SLA设计：分阶段计时，而不是只算总时长

SLA最容易犯的错误是只定义一个“总响应时间”，导致工单在“调查中”停留过久却无人察觉。更合理的做法是分阶段设置时限：确认时限（T0→T1）、遏制时限（T1→T2）、恢复时限（T2→T3）、关闭时限（T3→T4）。每个阶段独立计时，超时触发升级通知。

以P1事件为例：确认≤5分钟，遏制≤30分钟，恢复≤4小时，关闭≤24小时。如果遏制阶段超时，系统应自动通知SOC主管并触发升级流程。需要注意的是，挂起状态应暂停SLA计时，但必须记录挂起原因和预计恢复时间，否则挂起会变成“逃避SLA”的手段。

五、闭环判定：什么才算真正关闭

闭环不是状态变成“已关闭”就结束了。一个合格的闭环至少满足四个条件：所有子工单已完成；遏制和恢复动作有记录且可验证；IOC已同步到检测规则或封禁列表；复盘报告已归档。如果事件涉及数据泄露或合规要求，还需确认通知流程已完成。

对于误报关闭，同样需要记录判定依据，例如“命中白名单规则WL-2024-017”或“资产负责人确认该行为为计划内维护”。误报数据是优化检测规则的重要输入，不能随意丢弃。

最后，工单模型要支持“重开”。当同一事件在关闭后再次出现，或者发现上次关闭时证据不足，应允许从“已关闭”重开到“调查中”，并关联原工单ID。这样既能保留历史上下文，又能避免重复劳动。状态机、优先级和SLA三者配合，才能让安全事件从告警到闭环的每一步都清晰、可度量、可追溯。