## 安全事件复盘行动项跟踪 {.case data-case-id="055"} | 字段 | 值 | | --- | --- | | 案例编号 | `055` | | 行业 / 部门 | 互联网 / 安全 | | 角色 | 安全负责人 | | 难度 | `进阶` | | 调用来源 | `manual`（复盘会结束后由安全负责人发起一次手动调用，带入行动项清单的令牌化条目——事件编号、行动项编号、级别与截止日） | 复盘会开完热热闹闹，行动项记了一板，三个月后同类事件再来一遍，才发现大半没人认领、逾期没人追。目标：复盘会后由安全负责人发起一次手动调用，让获授权 Agent 对带入的行动项清单（修复/制度/培训）逐项跟踪完成情况：完成与进行中的发进度回执；逾期的通知 Owner 与经理。完成不自动判定——Owner 申报完成必须经人工确认留痕后才计入"完成"。事件细节脱敏：回执与通知只显事件编号与级别，不外带漏洞细节、攻击路径与受影响系统。指标：逾期项 100% 当日通知到 Owner 与经理；计入"完成"的 100% 经人工确认并附判定依据与时间戳；全部关闭后 100% 发完成回执。 - **覆盖**：手动调用逐项跟踪行动项（修复/制度/培训）、三路分流（完成/进行中、逾期、清单不完整）、完成需人工确认留痕、全部关闭发完成回执、零结果与取数失败回执。 - **不覆盖**：自动判定行动项完成、自动改行动项或截止日、代替执行修复或培训、对事件根因重新下结论。 - **假设**：有一个经授权能读取行动项进度并在读取侧脱敏与令牌化的 Agent（通过 App/Extension）；清单在调用时作为输入提供，含事件编号、行动项编号、级别、类型、Owner 角色代号、截止日；Owner 仅用清单字段，缺失标"待确认"。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：安全事件复盘会结束后由安全负责人发起一次手动调用，让获授权的跟踪 Agent 经 App/Extension 读取行动项进度，App/Extension 在读取侧即完成脱敏与令牌化，Agent 只接收事件编号、行动项编号、事件级别、行动项类型、Owner 角色代号、截止日、状态与更新时间等白名单字段，不接收 Owner 姓名与工号——展示名由安全 App 在发送侧按角色代号回填；漏洞细节、攻击路径与受影响系统不进入 Agent 消息与运行记录，对带入的行动项清单（修复/制度/培训三类）逐项跟踪完成情况。事件细节脱敏：回执与通知只显事件编号与级别，不外带漏洞细节、攻击路径与受影响系统。 触发：手动发起调用，调用时带入行动项清单的令牌化条目（事件编号、行动项编号、级别、行动项类型、截止日）、安全频道、审批人与跟踪 Agent。 结果分三类处理： 完成或进行中：发进度回执，每项附当前状态与最近更新时间戳，证据留痕并留审计时间戳；其中申报完成的项必须经安全负责人人工确认（附判定依据与时间戳）后才计入"完成"，不自动判定完成。 逾期：通知 Owner 与其经理（仅用清单字段，缺失标"待确认"，不从事件记录猜），附事件编号、级别、行动项类型、截止日与当前状态，留审计时间戳。 输入清单不完整（行动项缺事件编号、类型、Owner 或截止日）：告警并留审计时间戳，通知安全负责人补全后新开一次调用，本次不重试、不猜测缺失字段。 另设两类边界结果： 本期无待跟踪行动项（查询成功但令牌化条目为空）：发一条"本期无待跟踪行动项"汇总回执并留时间戳，不静默结束。 取数失败（行动项进度数据源不可达、数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"本期无待跟踪行动项"，也不当作进行中。 清单全部行动项均确认关闭后，发一条复盘完成回执（含关闭项数与最后关闭时间戳）并留审计时间戳。 审批：申报完成的行动项由安全负责人确认留痕后才计入"完成"，不自动判定完成；审批为二值确认或驳回，不设自动超时，无默认通过/否决。 异常：跟踪 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：进度回执、逾期通知、清单不完整告警、零结果回执、取数失败升级、全部关闭回执，各自留审计时间戳后结束。 ``` ![案例 055 安全事件复盘行动项跟踪：复盘会后手动调用获授权 Agent 逐项跟踪行动项（修复/制度/培训）；进行中的项直接发进度回执（每项附状态与最近更新时间戳、证据留痕，不经人工确认），只有申报完成的项才进安全负责人人工确认（附依据与时间戳），确认后计入完成；逾期通知 Owner 与经理（缺失标待确认），清单不完整告警留审计新开调用不重试，本期无待跟踪发零结果回执，进度数据源不可达按取数失败告警留审计重试升级，全部关闭发完成回执；事件细节脱敏只显编号与级别；回传不合结构停在原等待点](../../../media/cases/fig-case-055-01-flow.svg){#fig-case-055-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **手动触发**：复盘会结束后由安全负责人发起一次调用，带入行动项清单的令牌化条目（事件编号、行动项编号、级别、行动项类型、截止日）、安全频道、审批人与跟踪 Agent。 2. **跟踪行动项**：获授权 Agent 经 App/Extension 读取行动项进度，App 在读取侧完成脱敏与令牌化，Agent 只接收白名单字段（事件编号、行动项编号、级别、类型、Owner 角色代号、截止日、状态、更新时间），Owner 展示名由安全 App 发送侧按角色代号回填，对清单（修复/制度/培训）逐项回传状态与最近更新时间；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **三路分流**： - **进行中**：直接发进度回执，每项附当前状态与最近更新时间戳，证据留痕；进行中项不经人工确认，也不与申报完成混在同一条路。 - **申报完成**：只有申报完成的项进入安全负责人人工确认（附判定依据与时间戳），确认后才计入"完成"；驳回则该项回跟踪中留审计。 - **逾期**：通知 Owner 与经理（仅用清单字段，缺失标"待确认"），附事件编号、级别、类型、截止日与状态，留审计时间戳。 - **输入清单不完整**：告警、留审计时间戳，通知安全负责人补全后新开一次调用，本次不重试。 4. **两类边界与收尾**：本期无待跟踪发零结果回执留时间戳；进度数据源不可达按取数失败告警留审计，按重试上限重试，仍失败升级值班频道；全部确认关闭后发复盘完成回执留审计时间戳。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动调用 + 完成人工确认 + 三路分流 + 全关回执"流程——它知道"跟踪行动项"需要一个发消息并等待回调的 Agent 环节、"按进度分流"需要一个条件路由、"确认完成"需要一个审批环节、"回执与通知"各需要一个发消息环节。AI 还会校验流程完整性，你不必关心这些技术细节。 - **行动项被"顺手关掉"**：这是复盘跟踪最常见的漏洞。完成判定只认人工确认，附判定依据与时间戳；Owner 申报完成只是触发确认的输入，不是结论。 - **进度数据源不可达、陈旧**：不当作"本期无待跟踪行动项"或进行中，而是告警留审计，按重试上限重试；仍失败升级值班频道。 - **Owner 缺失**：Agent 不从事件记录或值班表猜人，该字段标"待确认"，由安全负责人补全或指定。 - **输入清单不完整**：不猜缺失的事件编号、类型或截止日，告警留审计并通知安全负责人补全后新开一次调用，本次不重试。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无待跟踪（结果为 0）**：仍发零结果汇总回执并留时间戳，让"没消息"变成可核验的记录。 - **跟踪 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人确认完成**：审批不设自动超时，流程停在等待状态。若需响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知安全负责人。 申报完成的行动项必须经安全负责人确认留痕后才计入"完成"，不自动判定完成。确认时能看到事件编号、级别、类型、状态与最近更新时间（事件细节已脱敏），是"有依据的快速确认"。审批只有确认或驳回两种结果，驳回则该项回到跟踪中，不设自动超时，也没有"超时默认完成"。若要更严（如修复类行动项需技术负责人会签），在提示词里写明，AI 会在流程里多加一个审批环节。 行动项进度的读取由获授权 Agent 通过 App/Extension 完成，工作流不直接调用外部系统。安全频道与审批人作为输入提供；数据源访问凭据用 `` 占位，由 Agent 运行时从密钥引用。数据源不可达或陈旧属于取数失败，走失败回执与升级。最小披露：回执与通知只显事件编号、行动项编号与级别，不外带漏洞细节、攻击路径与受影响系统；Owner 展示名由安全 App 发送侧按角色代号回填。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），事件细节与 Owner 姓名工号在源头即被脱敏/令牌化，并按 10% 抽查四层实际记录。 - **回放集与基准**：取最近 5 次复盘的 60 条行动项（含完成、进行中、逾期、申报完成、字段缺失样本）回放，基准为既定状态分类与应通知清单。 - **分类准确**：完成/进行中与逾期判定和基准一致率 ≥ 95%；逾期项 100% 在当日通知到 Owner 与经理。 - **完成防线**：计入"完成"的项 100% 经人工确认并附判定依据与时间戳，自动判定完成 0 例。 - **字段纪律**：提供 Owner 时 100% 原样带出；缺失时 100% 标"待确认"，不出现猜测的 Owner；清单不完整时 100% 告警留审计、新开调用，0 次自动补猜。 - **脱敏**：按 10% 抽样，漏洞细节、攻击路径与受影响系统出现 0 次，事件呈现 100% 为编号与级别。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），漏洞细节、攻击路径、受影响系统与 Owner 姓名/工号出现 0 次，按 10% 抽查四层实际记录。 - **收尾可见**：全部关闭后 100% 发完成回执（含关闭项数与最后关闭时间戳）；五类结果 100% 各有可见回执留审计，不出现静默成功。 ### 复用与变体 - **同构迁移**：故障复盘行动项跟踪、合规问题整改跟踪、红蓝演练发现修复跟踪。 - **分级提醒**：修复类行动项逾期即通知经理，制度与培训类逾期 3 天再通知，在提示词里写明即可。 - **写回系统**：确认完成后加一个 Agent 环节，由它通过 App/Extension 把"已完成"状态写回事件管理台账；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=行动项编号+确认批次），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。