结论先行：业界通用的攻击技战术框架最近又升了一版，公开信息里新增 15 项检测策略——企业侧 6 项、工业控制侧 9 项，背后由 38 条分析规则支撑。对已经建过检测覆盖表的企业来说，这一版带来的不是「重新盘一遍」，而是三个具体动作：把新旧条目做一次版本映射、把新条目先标成「未知」而不是「未覆盖」、给长期零命中的老规则一个退役流程。做完这三件，那张表才算跟上版本；不做，它会在半年内悄悄过期。

本文只谈框架版本变化之后既有覆盖表怎么维护，不谈首次怎么建这张表，也不谈具体检测规则怎么写。

先看清这次变了什么

按公开的行业解读，这一版的增量集中在三处。

检测能力扩容。新增 15 项检测策略，企业环境 6 项、工业控制环境 9 项，配套 38 条分析规则。其中工控侧新增的分析规则专门考虑了日常工程操作与维护活动，目的是过滤正常作业产生的行为记录——这一条对工业场景很实在，那个环境里设备调试、参数调整、例行维护产生的操作，看起来和恶意行为很像。

条目替换，而不是纯新增。工控侧原有的两个旧条目被弃用，改为一个「命令与脚本解释器」条目并下设多个子技术。这种改动对覆盖表的伤害最大：如果只做了「新增条目查漏」而没做「弃用条目清理」，表里会同时存在新旧两套口径，数字看起来是涨的，实际重复统计。

人工智能相关条目成体系入册。企业侧新增的九项里，有数项直接围绕大模型应用与智能体。同时有一个细节值得注意：最底层的两类提示注入技术，本身并没有配到专属的检测策略。这个空白不是疏漏，它说明这类风险的着力点在权限、隔离与人工确认上，而不是靠特征匹配去检测。

动作一：版本映射，先把口径统一

覆盖表最常见的毛病，是同一张表里混着三个版本的口径。有人按两年前的条目映射过，有人按去年的补过，新来的人又添了几行自己找的编号，谁也不知道哪些行是有效的。

可行的做法是先做一张映射表，三列就够：旧条目、新条目、处置方式。处置方式只有三种——沿用、替换、弃用。

  • 沿用：条目没变，覆盖结论可以直接带过来。
  • 替换：旧条目被新条目取代，覆盖结论要跟着搬到新条目下，同时把旧行标注为已弃用但保留，便于回溯历史结论。
  • 弃用：条目被取消且没有承接项，这一行的覆盖结论作废，从统计里剔除。

映射表不要删旧行。审计或复盘时最常被问的一句话是「去年这个数是怎么算出来的」，只留最新一版表格的话，这个问题永远答不上来。

动作二：新条目先标「未知」，别急着标「未覆盖」

这一条看着是细节，实际决定整张表的可信度。

框架新增条目之后，绝大多数企业的真实状态是「还没查过」——不知道自己的数据源能不能看见，也不知道现有规则有没有覆盖。这时候如果把新条目直接标成「未覆盖」，表上的覆盖率会在一夜之间掉一大块，然后你会收到一个很自然的追问：为什么什么都没变，覆盖率掉了？

更糟的后果是，为了把数字补回去，团队会匆忙给新条目挂几条规则上去，把状态改成「已覆盖」。这个动作的成本很低，代价是这张表从此不可信。

可行的做法是把状态从两档改三档：已覆盖、未覆盖、未知。新条目统一进「未知」，配一个排查计划——哪几项本周能核完、哪几项需要先解决数据源才谈得上覆盖。覆盖率的分母改成「已核查的条目数」，表上的数字才不会因为框架升级而失真。

动作三：给老规则一个退役流程

框架升级的时候，顺手该做的是反向检查：现有的规则里，有多少条已经很久没命中过。

长期零命中只有三种解释，而且必须分清楚。其一，这条规则对应的行为在这家企业里不会发生——那它应该退役，留着占位置。其二，规则写错了，条件永远不成立——那它应该修，留着是最危险的，因为它会让人以为这项能力有覆盖。其三，环境变了，原来的日志源没了或者字段改了——那要先去查数据源，规则本身没问题。

三种解释对应三种处置，判断依据不是规则写得好不好，而是它旁边有没有一条「上次命中时间」。这一列多数覆盖表里都没有，值得加上。

人工智能那几项，映射的时候容易做错

新增条目里围绕大模型与智能体的部分，在映射时最容易出两类错。

一类是把它们直接归给「安全产品」。这类风险的载体不是某台设备，而是智能体能触达的数据与工具。覆盖表上写「已覆盖」，实际动作却是「我们部署了终端防护」，这个结论没有意义。

另一类是照搬检测思路。前面提到，最底层的两类注入技术本身没有专属检测策略——这提示的方向是：对这类风险，能落地的动作是收权限、划隔离、关键操作加人工确认，而不是等着某条规则报警。覆盖表里这几行的「数据源」一栏，更该填的是「智能体可调用的工具清单」与「可访问数据范围」，而不是某个日志类型。

落地清单

  • 建一张版本映射表，三列：旧条目、新条目、沿用/替换/弃用。
  • 覆盖状态由两档改三档，新条目统一进「未知」，配排查计划。
  • 覆盖率分母改为已核查条目数，避免框架升级导致数字异常波动。
  • 每条规则补一列「上次命中时间」，按季度看零命中项。
  • 零命中项按「不会发生/写错/数据源没了」三类分别处置，不搞一刀切清理。
  • 涉及智能体的条目，数据源一栏填工具清单与数据范围，不填日志类型。
  • 旧版映射表全部保留归档，便于回溯历史结论。

边界与前提

三点说明。其一，本文所引的版本增量数据来自公开的行业解读与官方更新说明，条目数量以官方知识库当期内容为准。其二，框架是对已观测攻击行为的归纳性知识库，不是合规清单，也不提供产品或处置建议；新增条目表示该行为被纳入标准词汇表，不代表它只在这一版之后才出现。其三，文中的「企业侧」「工控侧」条目数属概数梳理，实际使用应以本企业选定的框架版本范围为准。

深圳市奇摩计算机有限公司是一家 IT 解决方案服务商，在日志与安全运营类项目交付中，会把覆盖表的版本、分组口径与规则清单一起作为交付文档，让框架下一次升级时不必从零开始推。预约咨询，可以先把现有覆盖表的口径统一起来。