企业官网建设流程全解析

简介：面向企业安全运营、红蓝对抗与威胁狩猎团队的ATT&CK落地参考PDF，内容整理自青藤云安全COO程度在安全大会上的分享，聚焦“如何建立”与“如何运营”两大主题。文档从框架背景与设计哲学讲起，说明ATT&CK如何以攻击者视角描述TTPs，并逐步覆盖企业、移动、云、ICS、容器等场景。建立部分给出理解攻击技术、填充TTPs、积累实战经验、跟踪版本更新四个步骤；运营部分展开威胁情报、模拟攻击、合规映射、分析师训练、威胁狩猎等十种方式，还结合哥斯拉、冰蝎、ReGeorg等真实攻击案例讲解防御策略，并提及V9版本数据源变化与2021年路线图。资源为单份PDF，大小5.44MB，已有400人学习，适合希望将ATT&CK从理论框架落地为日常安全能力的安全运营、红队和防御体系建设人员。

1. 为什么企业要自己建一份ATT&CK，而不是直接引框架

ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge）这几年几乎成了安全团队必谈的黑匣子：外部报告张口就是“T1059 命令行接口”，红队复盘动辄贴出一张五颜六色的攻击路径热力图。但对大多数企业来说，MITRE 原版框架只是一张公共攻击地图，它不会告诉你哪些技术在自家网络里真的可能发生，也不会替你写出匹配现有日志查询的检测规则。我见过太多团队照抄官网矩阵，导出一份 Navigator 热力图就宣布“建成了”，结果三个月后连谁负责更新都说不清。

企业建 ATT&CK 的目标不是复刻框架，而是把攻击知识变成可审计、可验证、可迭代的落地能力。它应该包含裁剪后的技术清单、日志和检测规则映射、责任人、状态和版本记录，最终交付物可以是一份 PDF 手册，也可以是一个内部 Wiki 或 JSON 库。适合谁？安全运营中心的检测工程师、负责红蓝对抗的渗透测试组，以及想推进威胁可量化管理的安全负责人。

2. 从引入到选型：以企业环境确定ATT&CK使用边界

很多团队拿到 ATT&CK 的第一反应是打开官网把矩阵抄一遍，或者下载一个 Navigator 层文件导入就算完成。我建议先停一下，因为内部建设不是复制粘贴。你需要先回答三个问题：建给谁看？覆盖哪些技术栈？以哪个版本为基线？这三个问题决定了后面积累的文档、规则和报告能不能持续复用。

2.1 先分清三种ATT&CK：企业版、ICS、移动版，避免建错对象

MITRE 官方把 ATT&CK 按对象拆成了几个矩阵，最常见的是企业版，另外还有 ICS 和移动版。我见过一家制造企业把工控环境的攻击技术往企业版矩阵里塞，结果 PLC 固件替换、工控协议异常指令在企业版里根本找不到对应技术，硬塞进去的映射在评审时被审计人员直接打回。正确做法是先判断管理边界：如果企业只有传统 IT、云和办公终端，用企业版就够；如果生产网里存在 SCADA、DCS、PLC，要单独为 ICS 矩阵建一套内部库，而不是和企业版混在一起；如果办公环境有大量 BYOD 手机，移动版可以作为补充，但一般不做主矩阵。

这个选择还会影响后续的数据源清单。企业版技术大多依赖进程、注册表、网络连接、认证日志；ICS 矩阵更依赖工控协议审计和控制器行为；移动版则要看设备管理平台。我一般建议在项目启动时用一张简单的表列出每个业务域应该引用哪个矩阵、矩阵版本、覆盖的资产域和日志域，避免不同小组各建一套。内部统一标准越早定，后面才不会出现两份对不上的攻击知识库。

2.2 按资产与数据源裁剪技术矩阵：哪些技术跟你无关

ATT&CK 矩阵里并不是每个技术都跟你有关。一个纯 Windows 终端环境不需要为 Linux 的可见性检测系统投入资源，一个没有 Kubernetes 的企业也没必要现在去研究容器逃逸技术。裁剪矩阵本质上是在做减法，让有限的检测资源集中到真实攻击面上。

我通常按两个维度来剪。第一维是资产维度：先枚举操作系统、中间件、数据库、云服务、身份源、网络设备，然后把每个 ATT&CK 技术标注为“适用”或“不适用”。比如内部没有 macOS 终端，macOS 特有的技术直接标记不适用；如果云上只有虚拟机没有 Serverless，服务控制相关的技术可以先挂起。第二维是数据源维度：对适用技术再往下看，当前有没有日志或遥测手段能观察到它。只有数据源覆盖不具备的技术，才有资格进入下一轮检测建设。

裁剪结果最好维护成一张表：技术 ID、技术名称、相关资产、当前数据源、覆盖状态。这张表会随着架构变化不断调整，所以一定要记日期和负责人，否则三个月后没人敢动它。裁剪不是一次性的，每一个新业务系统上线，都应该回到这张表里更新一次适用性判断。

2.3 建立内部编号与命名规范：让检测规则、报告、工单都引用同一套ID

ATT&CK 官方 ID 是 T 开头加数字，比如 T1059，子技术是 T1059.001。直接拿官方 ID 当内部唯一主键会踩一个坑：版本升级时 MITRE 可能合并、拆分或重新编号某个技术，官方 ID 一变，内部所有规则、报告、工单里的引用全部断链。所以我在企业内始终用一套语义化内部 ID，官方 ID 只作为关联映射保留。

具体做法：先约定内部 ID 格式，例如“AM-<战术缩写>-<三位序号>”，战术缩写取攻击战术的前三个字母，如 Initial Access 缩写为 INA，Exfiltration 缩写为 EXF。假设某个技术对应的是“通过 DNS 隧道外传数据”，内部 ID 就是 AM-EXF-001。这个 ID 一旦分配，永不更换，不管 MITRE 后续把官方 ID 改成什么，内部文档和检测规则都不受影响。

每个内部条目还需要记录版本、状态和负责人。最小字段表是这样的：内部 ID、MITRE ID、MITRE 版本、战术、技术名称、适用场景、数据源、检测规则、状态、负责人、更新日期。其中状态字段建议使用五态：不适用、未覆盖、覆盖待检测、有效检测、待验证。不要用“已映射”这种模糊词，因为映射不等于检测，这个概念后面会展开说。规范建立后，所有安全运营中心工单、红队报告、威胁情报订阅都强制引用内部 ID，这样统计和追踪才能做到端到端。

3. 把ATT&CK落成内部文档：从战术层到检测层的映射步骤

选好边界和编号以后，进入正式映射阶段。映射不是把整个矩阵平铺一遍，而是按战术逐层推进。我一般从 Initial Access、Execution、Persistence、Privilege Escalation、Defense Evasion、Exfiltration 这六类开始，因为它们和实际攻防的告警、应急响应关联最紧。每个技术要有三样产出：数据源映射、检测规则、响应动作。

3.1 第一步：整理企业数据源清单并映射到MITRE数据源

很多企业并不清楚自己手里到底有哪些安全日志，所以第一步是把数据源盘清。常见的内部数据源包括：EDR 的进程创建和命令行事件、Windows 事件日志中的登录和账号操作、DNS 服务器日志、边界防火墙和代理的网络连接日志、云平台审计日志、身份管理系统的认证日志。每种日志对应 MITRE 技术数据源中的一类，例如进程事件对应 Process Creation，登录事件对应 User Account Authentication。

下面是一个从实际项目中抽出来的映射片段，字段包括数据源、日志位置、能观察到的技术方向、当前留存周期：

这里注意：留存周期是内部策略，不是 ATT&CK 官方要求。没有日志的技术不要硬编，直接标记为“未覆盖”，等下一个日志源接入或采购新平台时再补。我见过有的团队为了覆盖率好看，把“理论上 EDR 能记录”当成“我们已经在记录”，后面检测演练一下就露馅。所以这一步宁可保守。

3.2 第二步：用ATT&CK Navigator输出当前覆盖率与差距

数据源清单整理好了，就可以用 MITRE 官方提供的 ATT&CK Navigator 工具来输出一张可视化的热力图。Navigator 可以加载官方矩阵，并允许给每个技术打上不同颜色和标签，例如绿色代表“有效检测”，黄色代表“覆盖待检测”，红色代表“未覆盖”，灰色代表“不适用”。

实际操作中，我一般会在 Navigator 里手动完成第一版标注，然后导出一个 JSON 层文件丢进 Git 仓库管理。这个 JSON 文件记录了每个技术的状态和备注，是后续评审的核心资产。操作步骤不复杂：在浏览器打开官方 Navigator 页面，选择企业矩阵，导入上一节生成的数据源覆盖清单，逐类技术标注状态，最后导出层文件并在文件名里标注日期，例如“enterprise-layer-20250512.json”。

但不要迷信 Navigator。它只是一个可视化前端，真正的权威数据是前面定义的结构化表格，或者后面落成的内部 JSON。每次用 Navigator 生成的层文件只是对外展示和评审用的视图。如果多个人同时编辑同一个层文件，很容易互相覆盖，我见过两次，最后不得不按日期分文件并手动合并。更稳的方式是让一个人统一维护层文件，或者在 Git 里做冲突管理。

3.3 第三步：为每个技术写内部条目：检测规则、响应动作、责任归属

可视化热力图只能告诉你哪里没覆盖，真正让 ATT&CK 可用的是每个技术背后的条目。一个内部条目至少要覆盖“是什么、怎么发现、发现怎么办、找谁改”。这里用一个字段模板来说明：

这里的检测规则不要写“关注异常流量”这种没法执行的话，要写清楚查询上下文和判定阈值。理论上这页还可以内嵌一条 SIEM 查询语句或 Sigma 规则，但文档里的内容是给人看的，真正的规则应单独放到规则仓库中，并用内部 ID 做外键关联。我建议初期只对能写清规则和响应动作的技术建立完整条目，先做 30 到 50 个最重要的，后面再扩充。宁可每个条目的质量高，也不要凑数量。

响应动作这一行特别容易被忽略，很多人只写“告警并调查”。但如果没有明确的负责人和动作，检测告警仍然是孤岛。所以我在每个条目里必须指定一名活人作为负责人，他需要在下次评审前负责验证规则是否仍然有效。这一步做扎实后，内部 ATT&CK 才从“知识库”变成了“运营工具”。

4. 避坑排查：企业ATT&CK落地路上最常见的五个大坑

光看上面这些步骤，很多人会觉得 ATT&CK 落地不难，但真正跑起来，翻车的往往是治理细节。我把过去几年在企业内部建设 ATT&CK 时碰到的问题收敛成五条，每条按现象、原因、解决来写。看完以后你再回去看自己的覆盖率数字，会冷静很多。

4.1 现象一：把“已映射”写成“已检测”，覆盖率看起来很漂亮

这是最普遍的问题。很多团队为了让管理看到进度，把“MITRE 技术对应的数据源我们有日志”写成“已检测”，于是热力图上一片绿色，覆盖率高达百分之七八十。但实际上，有日志和有能触发告警的检测规则是两回事。

原因在于“映射”和“检测”之间隔着一整条工程链路：日志采集要完整、字段要正确、查询逻辑要能匹配、告警要能联动、误报要可控。任何一环没通，技术状态都不应该叫“有效检测”。

我的解决方法是强制引入状态五态模型。只有经过一次模拟攻击或历史事件验证，确认规则能产生有效告警，才允许把状态改为“有效检测”。在评审时我会要求把验证证据贴到条目备注里，没有证据的只能算“覆盖待检测”。这样虽然数字不好看，但至少不会被一个突然的真实攻击打脸。

4.2 现象二：ATT&CK版本一升级，内部编号全线失效

MITRE 会定期更新 ATT&CK，有些技术会被合并，有些会被拆成子技术，还有新增技术补进来。如果内部文档直接引用官方 ID 而没做版本管理，一次升级后，文档里写着的旧编号可能已经找不到对应条目，工单里的引用也会断链。

原因很简单：把官方 ID 当成了内部主键，而官方 ID 本身不是稳定的业务语义。解决方法是前面提前设计的内部 ID 体系，保留官方 ID 但只是作为映射字段。每次 MITRE 发布新版本，我一般会跑一次官方变更记录，对照“合并到哪、拆分到哪、删除了什么”，把映射表里的 MITRE ID 更新一下，但内部 ID 不变。升级窗口期要固定，比如半年或一年一次，不要一看到新版就立刻全员切换。

4.3 现象三：红队报告用旧版，蓝队检测用新版，两边对不上

红队在做攻击复盘时通常会参考当前网上最流行的 ATT&CK 版本，蓝队可能因为内部体系刚升级而用了新版或旧版。两边在会议上讨论同一个事件时，A 说这是旧编号，B 说官方已经把它挪到别的地方了，于是讨论从攻击行为变成了一场版本考据。

原因是没有在企业内部统一“黄金版本”。解决方法是在制度层面规定：所有红队报告、蓝队规则、威胁情报、漏洞定级必须引用企业内部的“黄金版本”编号，并且在文档头部标注 MITRE 版本号。如果外部报告用其他版本，需要在录入内部条目时先做一次转换，转换规则由安全架构师确认，并保留原始版本字段。定期把这种转换评审纳入例会，防止积累太多历史映射无人清理。

4.4 现象四：只映射端点，不映射身份和数据平面

很多安全运营中心的 ATT&CK 建设是从 EDR 开始的，所以 Initial Access、Execution、Persistence 等端点相关技术覆盖得很好，但身份认证、云审计、网络流量方面的技术几乎一片空白。实际攻击中横向移动和权限维持大量依赖合法凭证，比如 T1078（使用有效账户）、T1110（口令爆破）、T1558（Kerberos 票据窃取）。端点做得好不代表检测做得好。

原因是我常说的“手电筒效应”：哪里亮就照哪里，而不是从攻击者视角看需要什么数据。解决方法是把数据源清单按平面分组：端点、身份、网络、云、办公应用，每个平面单独算覆盖率。Navigator 层文件也可以按平面拆成多个层，合并展示时不要只给一个总百分比，至少要让管理层看到每个平面的差异。这样才能把建设资源拉到真正薄弱的身份和云日志上。

4.5 现象五：文档写完没人维护，半年后就变成装饰品

这是最后也是最常见的“烂尾”。ATT&CK 落地伊始大家热情很高，把文档、PDF、热力图都做出来了，但之后没有人和流程驱动更新。半年后再打开，内容停留在初始版本，检测规则早就随着系统升级失效，新买的日志源也没有补充进去。

原因很简单：没有把维护任务安排给具体角色，也没有触发更新的机制。解决方法是把 ATT&CK 评审嵌入现有的安全运营节奏，比如每月一次“检测有效性评审”，每条技术条目带上负责人和下次更新日期。另外，每当有新系统上线、新日志源接入、红队完成一次行动、威胁情报发布重要报告，都要触发相关技术条目的更新。可以建一个简单的看板，把“待更新条目”挂在上面，与工单系统打通，维护动作可追踪。写文档只是入场，持续更新才是常态。

5. 验证企业ATT&CK建设质量的三种方式：红蓝复盘、检测演练、度量指标

ATT&CK 建得好不好，不在 PDF 页数，而在真实攻防中能不能派上用场。我常用的验证方式是三个：红蓝复盘、检测演练、度量指标。每次红队行动结束后，把红队实际用到的每一条技术逐个对照内部 ATT&CK 条目，问三个问题：条目里有没有这个技术的检测规则？规则是否有告警？告警关联到了哪个资产和哪次操作？任何一条答不上来，都需要在下次迭代里补上。这个复盘比看十份报告都有用，因为红队的技术路线会直接暴露你知识库里的盲区。

第二种方式是定期做检测演练。不需要每次都模拟完整攻击链，我先随机挑三到五个高风险技术，例如通过 PowerShell 下载执行、DNS 隧道、异常认证行为，然后在测试环境构造一次符合内部判定标准的攻击请求，观察 SIEM 和 EDR 是否按预设触发告警，响应手册里的人是否知道下一步该做什么。我一般每个季度做一轮，每次把演练结果写进对应条目的“验证记录”字段。

第三种是建立面向结果的质量指标，不要只盯覆盖率。可以看几个真正反映能力的数字：有效检测占比、检测规则误报率、告警平均响应时间、事件闭环率。例如我给自己定的目标是：核心战术的有效检测占比不低于 60%，关键检测规则误报率低于 10%，高危告警从触发到确认不超过 30 分钟。指标不用多，三五个就够，关键是要可统计、可回溯。

坦白说，维护内部 ATT&CK 没有什么一劳永逸的法子。我自己养成的习惯是每隔两个月打开那批内部条目，把状态为“有效检测”的技术重新过一遍：规则是否还在告警？负责人还在不在？企业新增了容器，我就得把容器逃逸相关技术从不适用改成适用。这件事没有做完的时候，但每多更新一次，下一次红蓝对抗就能早一点看到攻击的影子。希望帮到你。

本文还有配套的精品资源，点击获取