AI加持事件解剖：重排安全建设优先级

原创

aerfa21
aerfa21

我的安全视界观

2026年10月6日 06:06
浙江

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

安全建设最难的不是技术，是排序。而排序最好的依据，不是别人的最佳实践，是自己每一次被打穿的完整记录。

一、瓶颈不在“做什么”，在“排序”

安全行业不缺方法论。攻防矩阵、合规条款、厂商方案，随便一个都够读几百页。一个中等规模的安全团队，一个季度能列出来的待办事项通常有几十条。

真正的瓶颈，是另一件事：这些事，先做谁？

排序一旦失去依据，就会退化成几种替代方案 - - 谁喊得响谁先做、哪个合规条款先到期哪个先做、哪个产品正在推哪个先做、上一季度的整改计划改个日期变成这一季度的。这几种方式都能运转，但它们有一个共同缺陷：依据不来自我们身上真实发生过的事。

于是就有了那个循环：每年演练，每年复盘，每年在报告里写下“弱口令问题依然突出”、“安全意识有待加强”、“历史漏洞未及时修复”。

我们换了个思路：把每一次失守的完整记录，当作安全建设优先级的输入。

这条链上有六到七个独立问题，分属不同团队、不同系统、不同预算。如果复盘停在“加强访客管理”，其余问题一个都不会被处理。

这就是“事件解剖”要解决的事。

二、方法：一把尺子，三步走

整套方法只有三件事，但有一个前提：得先有一把尺子：一张能把任何一次失守，拆成结构化数据的固定表格。没有它，后面两步都做不了。

输入是四类东西：

处理分三步：

第一步　结构化拆解每个事件，按固定矩阵拆到可执行项

第二步　跨周期聚合归一化、去重、频次统计、盲区统计

第三步　生成建设清单措施生成 → 归类 → 排序 → 落归属

三步里，第一步决定后面两步能不能做。大部分复盘停在“写总结”，没有产生结构化数据，于是后面两步根本无从谈起。接下来三节，一节讲一步。

三、第一步：拆到可执行

我们用的矩阵，四个大类、十一个子类。每个子类都带一个判定问题，答“是”就落进这个格子。

这张表看起来像记录表，实际是一把尺子。它规定了每一份复盘必须回答哪些问题、必须拆到哪一层。【提示：文末提供原始复盘分析Excel表格！即是文中所言的尺子】

分类本身不重要，重要的是它必须：一个现象只能落进一个格子，否则跨周期聚合时无法对齐，第二步就废了。

三条硬约束

约束一：现象必须落到可执行项。

“钓鱼成功 39 人”不是问题点，是现象。往下拆：是终端未覆盖这批人，是覆盖了未检出，还是检出了策略未拦截？再往下：如果是未检出，是引擎能力问题，是样本用了白加黑绕过，还是规则库没有覆盖这类行为？一直拆到能对应上一个具体动作，才算拆完。

约束二：每个攻击招式，至少对应一个检测手段。

用来堵“知道了但没做”的口子。红队用过的招式，如果防守侧连一个能看见它的手段都没有，就显式标记为无检测覆盖。这类条目在后续排序中权重最高 - - 它意味着一个永久敞开的通道。

约束三：每个事件必须同时产出两个视角。

攻击方视角：哪些招式不常用但有效（说明攻击模拟的覆盖面不够，需要补测试用例）。

防守方视角：哪些招式反复使用且反复得手（说明排序排错了，或者根本没归属）。

一个拆解示例

一行现象，拆出三个可执行项，分属三个负责人：

如果只写“终端防护被绕过”，得到的是一个结论；拆开之后，得到的是三张可以派下去的工单。

四、第二步：让重复浮出来

单看一个季度，每个事件都不一样：有的是钓鱼，有的是未授权访问，有的是漏洞利用，有的是凭据泄露。把所有季度的问题点摊在一起，按子类归拢，重复会自己浮出来。

聚合有两个维度，缺一不可。

4.1 时间维度：哪些坑反复踩

我们把八个复发模式在各次演练中的出现情况标了出来：

这张图值得多看两眼：八个模式里，有五个在三次以上演练中出现过；其中“凭据散落”和“内网默认互信”各出现了五次。

而每一行横着看，都是在讲同一件事：这个问题大概率上一轮见过，写了整改，然后它又来了。

4.2 空间维度：哪些地方没人看

复发频次回答“哪些坑反复踩”，覆盖盲区回答“哪些地方从来没人看”。数据来自防护有效性专项验证：

这组数字里，最值得注意的是 25% 和 84.5% 的对比：已接入统一防护的那部分资产，能拦住 84.5% 的 Web 攻击——说明这项防护本身是有效的，问题出在覆盖率上。

这是一个很典型的判断错误：当防护效果不好的时候，第一反应往往是“产品不行，换一个”。但数据说的是“装得太少”，不是“产品不行”。

而40.3% 双盲意味着四成资产既没有防护、也没有检测 - - 它们不出现在任何告警里，不是因为没有攻击，是因为没人看。

五、第三步：排出优先级

有了重复，优先级就变成一道算术题，而不是一场辩论。

5.1 措施生成：一对一

每条不足对应一条加强措施，不允许含糊。“终端被致盲”对应的措施是“Agent 自保护机制建设 + 卸载与致盲行为独立告警”，不是“加强终端防护”。

一对一的好处是可验证：措施做完之后，能明确回答“这条不足现在还剩多少”。

5.2 归类到治理域

几百条措施最终收敛到十几个治理域：

互联网暴露面收敛　/ 安全产品自身安全基线　/　凭据与口令治理　/　检测能力提升（流量、主机、终端）　/　日志审计纵深　/　资产安全运营　/　敏感信息泄露监测　/　攻击面管理

5.3 排序：两个维度，一个加权项

两个维度分别是复发频次（该问题在几次演练中出现过）和影响半径（单点 / 单系统 / 跨系统 / 全域）。高频且大半径的直接进 P0。

另外有一个加权项：标记为“无检测覆盖”的招式，无论频次高低，一律上调。因为它意味着一个永久敞开的通道 - - 不是“可能会被打”，是“现在就能被打，而且我们看不见”。

5.4 每一项落三个字段

必须落：优先级 / 归属团队 / 依托平台。

这一步最容易被省，也最不能省。没有归属的措施等于没写，没有平台的措施会烂在表格里。

六、六次演练跑下来，数据说了什么

方法讲完了。但方法本身不说明任何问题 - - 真正有意思的是它跑出来的数字。把六次演练的复盘表摊在一起，得到的是这样一组数：94 个问题点，153 处维度确认，67 条不足。同期防守方记录在案的优点，13 条。

13 比 67。而且这 13 条里，大部分是“某个检测恰好起了作用”（钓鱼被拦、准入阻断），真正属于“我们主动发现了什么”的，只有两三条。

再看问题点落在哪里。这里面有三件事，跟我们事前的直觉不一样。

所以第一优先级该是什么？数据已经把答案写出来了。

1、凭据与口令治理

范围：默认口令强制更换、密码复用检测、凭据散落扫描（镜像、文档、代码、终端）。

2、检测体系失效本身

终端 Agent 被致盲、日志通道被切断、监控平台凭证可被伪造 - - 这三件事的共同点是：以为在监控，实际没有。

注意，这两项里没有一项是“买新设备”。它们全是“把已有的东西管好”。

如果这份清单是拍脑袋拍出来的，我也会心虚，但它不是。清单上的每一条，都能倒推回具体的事件编号和攻击路径。

七、AI 让这套方法可以每季度跑一次

前面三节讲的是方法。但方法有一个现实问题：它太重了，重到没人愿意坚持做。

一个季度几十个事件，每个事件要拆到十几个子类，拆完还要跨季度去重、统计频次、生成措施、归类、排序。这件事枯燥、重复、量大，而且恰好落在“重要但不紧急”的象限里 - - 每次演练完大家都很亢奋，一周之后就没人愿意再碰那张表了。

AI 在这里的作用不是替我们做分析，是让这套方法从“一个季度勉强做一次”变成“每个月度都能做”。

7.1 前提：AI 分析不了它看不懂的东西

把演练报告直接丢给模型，它会给一份读起来很顺的总结：“安全意识有待加强”、“检测能力需要完善”、“建议加强供应链管理”。

这些话放哪一年都对，也放哪一年都没用 - - 因为它没有结构，只是在复述原文。让这件事跑起来的不是模型，是那把尺子。

7.2 从五天到两分钟，让复杂的事可以常态做

框架做完之后，我手工做了第一份分析：一个季度的事件，逐条拆到可执行项，大概花了 五天（期间有其他事情穿插着做）。做完之后我意识到：这五天里最值钱的不是那份分析，是那把尺子。

把框架交给模型，让它按同样的结构去读每一份演练报告、每一份验证结果，逐条抽取，再按框架生成结论与启发。现在一份 2 分钟。

五天到两分钟，这个差距不是“提效 30%”那种差距，是“这件事以前一个季度只能做一次，现在每个月度都能做、甚至每一起事件都能做”的差距。

7.3 把“尺子”写成机器可执行的规格

人脑里的分类和机器能执行的分类，不是一回事。“安全防护”这四个字，人一看就懂；机器拿到它，不知道边界在哪。

要让 AI 稳定输出，每个子类必须带一个排他性判定问题 - - 答“是”就落进这个格子，答“否”就往下走。

id: ENDPOINT_SELF_PROTECTcategory: 安全防护question: Agent 被卸载、停止或致盲时，是否存在独立于 Agent 自身的告警？exclusive: trueaction_hint: Agent 自保护机制、看门狗进程、独立上报通道

三个设计要点：

• 枚举，不是自由文本。子类必须是闭合集合。模型可以新增候选子类，但不能直接写进结果——新子类要人工评审后入枚举，否则跨季度无法对齐。
• 判定问题必须排他。一个现象只能命中一个格子。我们最早的一版有重叠（“未鉴权访问”同时可以归到“安全设计”和“运维管理”），聚合阶段就崩了。
• 带上 action\_hint。子类对应的大致处置方向。它不直接进清单，但能大幅提高模型生成措施时的命中率。

7.4 抽取分两遍，不要一次做完

最开始的提示词是“按矩阵分析这份报告，输出全部字段”。结果是：输出很好看，但细节丢得厉害 - - 模型会在“归纳”这一步把具体的技术动作合并掉，只剩下一句“攻击者利用弱口令横向移动”。

拆成两遍之后稳定很多。第一遍只抽问题点，不做任何归纳，要求保留原文的表述粒度，宁可拆碎；第二遍再逐条归类，并生成对应不足与加强措施。

为什么必须分两遍？：抽取和归纳是两种不同的任务。混在一起做，模型会优先满足“让输出好看”，而牺牲掉“把细节留住” - - 而细节恰恰是后面所有步骤的原料。

同时有一条硬要求：每条判断必须回填原文证据。

{\"finding\": \"使用企业IM机器人发送钓鱼消息卡片，点击后浏览器自动下载样本，最终 29 台终端上线\",\"subcategory\": \"检测能力\",\"gap\": \"终端对 IM 渠道投递的样本无检出能力\",\"evidence\": \"共上线39人\",\"action\": \"补充 IM 渠道投递类样本的检测规则\"}

证据字段有两个作用：一是人复核时不用回头翻原报告，二是它是校验幻觉的唯一切口。

7.5 输出必须过校验，不能直接采信

这一步不能省。不加校验的自动化，产出的是一份看起来很完整、实际上无法用于统计的数据——比不做更危险，因为它会让你以为已经做完了。

7.6 归一化：让不同季度的同一件事对上

这一步最容易被低估，也最难。同一个问题，在不同季度的报告里表述完全不同：

按原文做频次统计，这三组会被算成 8 个独立问题，各出现一次；归一之后，它们是 3 个问题，各出现 2-3 次。

8 个一次性问题，和 3 个反复出现的问题，在排序上完全是两个结论。

我的做法是给每个复发模式一个稳定 ID，把定性的观察变成“标签 + 计数”：

CRED_DEFAULT　默认口令未更换CRED_REUSE　口令复用（服务器 / 域 / 应用）CRED_SCATTER　凭据散落（镜像、文档、代码、终端）ENDPOINT_TAMPER　终端 Agent 被卸载 / 致盲PATCH_STALE　历史漏洞未修复IMPLICIT_TRUST　内网默认互信 / 未鉴权访问TOKEN_FORGE　身份令牌可伪造LOG_SINGLE　日志通道单一且可被切断

有了稳定 ID，频次统计就退化成一次 group by，跨季度对齐不再依赖谁的记忆更好。有两个工程约束必须守住：

• 标签由人命名。模型可以提“疑似新模式”，但 ID 必须人工确认后入库。放任模型自由命名，同一件事会在一百份报告里长出一百个名字。
• 映射表要随分析一起迭代。新标签入库后，历史数据要回标一遍，否则频次会被截断。

7.7 输入输出规格

完整的字段规格（输入、框架、输出、后处理、可复算性），我放进了文末获取的模板里，单独一个工作表，方便直接对着改。

这里只说一句最要紧的：框架是会改的。每次改矩阵，都要记版本号，并把历史分析按新版本重跑一遍 - - 否则手里会同时存在几套不可比的数据。

7.8 边界：AI 做什么，不做什么

省下来的是重复的体力，不是判断。AI 初稿的归类会错，归因有时停在现象层，偶尔会漏掉整个维度，这些都要人审。工作量没有消失，只是换了个位置 - - 人从搬砖的，变成质检的。

三件事不交给模型：

• 归因的准确性。“为什么没检出” - - 是引擎能力问题、策略配置问题，还是样本本身在白名单里，三种答案对应完全不同的动作。模型给出的归因看起来很合理，但它不在现场，不知道我们上周刚改过策略。
• 优先级背后的权衡。技术上的第一优先级，可能因为业务窗口期、人力、跨部门现实需要后移。取舍是人做的，也必须有人负责。
• 责任的归属。这条措施归谁，不是模型能决定的，需要人根据实际职责分工来做出判断。

顺序不能反：先有框架，再有 AI。框架是人想清楚的，复制是机器干的。人省下来的是重复劳动，换来的应该是更长的复核时间和更厚的判断。

八、沉淀下来的几条判断

方法之外，把拆事件拆出来的、最通用的判断放在这里。每一条后面都有一次真实的失守。

1. 安全产品自身往往是最危险的入口。它能直连内网、有高权限、常年不更新、漏洞没人敢报。

2. 防不住卸载的终端防护等于没装。一个能被普通权限干掉、且干掉之后没人知道的 Agent，提供的是虚假的安全感。

3. “内网 = 可信”是所有失守的共同前提。攻击者在内网拿到的每一样东西，都是我们自己放在那儿的。

4. 凭据是攻击链上的硬通货。复用、明文、浏览器保存、镜像残留、离职未回收——攻击者不需要多聪明，他只需要比你先找到。

5. 默认口令出现一次是疏忽，反复出现是治理失能。

6. 监控系统本身不能是被绕过的那一个。一个令牌可被伪造的平台，它发出的每一条告警都值得怀疑，包括“一切正常”。

7. 单一日志通道一定会被切断，第二条独立采集路径不是冗余，是视力。

8. 漏洞不修，就是把上一季度的失败存进下一季度。

九、结语

回到最开始那个“前台开门”的攻防演练。现在回头看，那是这几年里最有价值的一次演练 - - 不是因为它暴露了物理安全的漏洞，而是因为它逼着我们把一台没锁屏的电脑，一路拆到了 CI/CD 的凭据管理。

从“前台不该随便放人”，到“凭据不该散落在镜像和文档里”，中间隔了七八个归因层级。大多数复盘，停在了第一层。而第一层的结论，通常是最没用的那一层 - -因为第一层的结论，往往是“某个人的问题”，而不是“某个体系的问题”。

这也是那份数据想说的：“人的问题”只占 14.4%。剩下 85.6%，是我们自己可以动手改的东西。

所以别把复盘报告存进档案室。把它们摊开，一条一条拆。这一步没人能省 - - 得先自己动手拆出一份，哪怕花上五天。因为这五天里真正值钱的，是手里那把尺子。

尺子做出来之后，剩下的事可以交给 AI：归类、去重、数频次。让它告诉哪些坑，已经掉进去过很多次了。那份清单，就是接下来的建设计划。