4. MITRE ATT&CK与检测映射

在SIEM检测规则开发中，最怕的不是规则写得少，而是规则写得散：今天补一条“可疑PowerShell”，明天加一条“异常登录”，规则之间没有统一的攻击行为坐标系，导致覆盖盲区无法度量、告警优先级无法解释、规则迭代无法复盘。MITRE ATT&CK的价值，正是提供一套公开、结构化、可对齐的攻击行为知识库，把“攻击者做了什么”拆解为战术、技术、子技术，并进一步关联到数据源与检测策略，最终转化为可落地的规则需求。

一、ATT&CK的层级结构：从战术到子技术

ATT&CK Enterprise矩阵的核心层级是：战术（Tactic）→ 技术（Technique）→ 子技术（Sub-technique）。战术回答“攻击者想达到什么目的”，例如初始访问、执行、持久化、权限提升、防御规避、凭据访问、发现、横向移动、收集、命令与控制、数据外泄、影响。技术回答“用什么方法达成该目的”，例如T1059命令与脚本解释器、T1053计划任务、T1078有效账户。子技术进一步细化，例如T1059.001 PowerShell、T1059.003 Windows命令Shell、T1053.005计划任务。

需要特别注意的是，战术不是攻击链上的严格顺序，而是攻击者目标的分类标签；同一技术可能同时服务于多个战术。例如T1078有效账户既可用于初始访问，也可用于持久化和权限提升。因此，在做检测映射时，不能把战术当作流程节点，而应把它当作“检测意图”的分类维度。

二、数据源：检测规则能否落地的物理基础

ATT&CK为每个技术标注了可能的数据源（Data Source），例如进程创建、命令行参数、文件创建、注册表修改、网络连接、登录会话、云审计日志等。数据源决定了规则能否被写出。如果某技术对应的数据源在当前SIEM中根本没有采集，那么无论规则逻辑多完美，都无法落地。因此，检测映射的第一步不是写规则，而是做“数据源可用性核对”。

以T1059.001 PowerShell为例，常见数据源包括：Windows安全事件4688（进程创建，需开启命令行审计）、PowerShell操作日志4104（脚本块日志）、模块日志4103、Sysmon事件1（进程创建）与事件3（网络连接）。如果只采集了4688但没有命令行字段，那么基于命令行关键字的检测就无法实现，只能退化为“进程名= powershell.exe”的弱规则，误报率会显著上升。

三、检测策略：从技术描述到规则逻辑的桥梁

ATT&CK中的检测策略（Detection Strategy）给出了针对某技术“应该观察什么”的分析思路，通常包含可观测对象、可疑行为特征和可能的误报来源。它不等同于具体规则，而是规则需求的来源。把检测策略转化为规则需求，需要完成三次翻译：

  1. 行为翻译：把技术描述翻译为可观测事件。例如“攻击者使用PowerShell下载并执行远程脚本”可翻译为：进程创建事件中，映像为powershell.exe，命令行包含-enc、DownloadString、IEX等特征。
  2. 字段翻译：把可观测事件翻译为SIEM中的具体字段，例如process_name、command_line、parent_process_name、user_name、host_name。
  3. 阈值与上下文翻译：确定单事件匹配还是聚合匹配，是否需要白名单、时间窗口、资产重要性等上下文。

下面这张图展示了从ATT&CK技术到规则需求的完整映射链路，以及数据源可用性对映射结果的反向约束。

ATT&CK 技术 → 数据源 → 检测策略 → 规则需求 映射链 战术 Tactic 执行 Execution 技术 Technique T1059 命令与脚本解释器 子技术 Sub-technique T1059.001 PowerShell T1059.003 Windows Cmd T1059.005 Visual Basic 数据源 Data Source 4688 进程创建+命令行 4104 脚本块日志 Sysmon Event 1 / 3 检测策略 观察编码命令 观察远程下载 观察父进程异常 数据源可用性核对 字段缺失 → 规则降级或阻塞 规则需求 Rule Requirement 规则名称：PowerShell 编码命令执行 匹配字段：process_name = powershell.exe 条件：command_line 含 -enc / -EncodedCommand 上下文：排除已知运维脚本白名单 映射三问 1. 该技术对应哪些事件？ 2. 事件字段是否已采集？ 3. 单事件还是聚合匹配？ 4. 误报来源与白名单？ 覆盖度度量 已映射技术数 已落地规则数 数据源缺口数 高优先级盲区

四、把攻击行为映射为规则需求的实际做法

假设我们要针对“T1059.001 PowerShell”开发检测规则，可以按以下流程推进。第一步，查ATT&CK页面，确认该子技术的战术归属（执行）、技术描述、常见数据源和检测策略。第二步，核对本地数据源：确认Windows安全日志4688是否开启命令行审计，PowerShell 4104是否启用，Sysmon是否部署。第三步，把检测策略拆成若干条规则需求，例如：

  • 需求A：检测PowerShell使用-EncodedCommand或-enc参数执行编码命令。
  • 需求B：检测PowerShell命令行中出现DownloadString、Invoke-WebRequest、IEX等远程下载执行特征。
  • 需求C：检测Office进程（winword.exe、excel.exe）作为父进程启动powershell.exe的异常链。
  • 需求D：检测PowerShell启动后短时间内发起外网连接（结合Sysmon Event 3）。

第四步，为每条需求写出可执行的规则逻辑。以需求A为例，在SIEM中可表达为：

event_id = 4688
AND process_name = "powershell.exe"
AND (command_line CONTAINS "-enc" OR command_line CONTAINS "-EncodedCommand")
AND NOT user_name IN ("svc_backup", "svc_monitor")

第五步，标注该规则对应的ATT&CK编号（T1059.001）、战术（Execution）、数据源（4688+命令行）、置信度（中高）、误报来源（运维脚本、自动化工具）。这样，规则不再是孤立的查询语句，而是攻击行为坐标系中的一个可管理节点。

五、映射中的常见误区与处理原则

第一个误区是“一条规则只映射一个技术”。实际上，一条规则可能同时覆盖多个技术，例如检测“计划任务创建”可能同时关联T1053.005和T1059。映射时应允许多对多关系，但要在规则元数据中明确主技术，避免统计时重复计数。

第二个误区是“有技术就必须有规则”。ATT&CK中部分技术在当前环境中不可观测或风险极低，强行写规则只会制造噪声。正确做法是建立“技术—数据源—规则”三列覆盖表，对无法落地的技术标注原因（数据源缺失、环境不适用、已有补偿控制），而不是假装覆盖。

第三个误区是“映射一次就永久有效”。ATT&CK矩阵会更新，数据源会变化，业务环境也会变化。建议每季度复核一次映射表，重点检查新增子技术、数据源采集变更和规则误报率变化。

在实际项目中，可以把ATT&CK映射表作为检测工程的核心资产，字段至少包括：技术编号、技术名称、战术、数据源、规则ID、规则名称、置信度、误报来源、覆盖状态、复核日期。这样，检测规则开发就从“凭经验写查询”升级为“按攻击行为坐标系做工程化覆盖”。

总结来说，MITRE ATT&CK与检测映射的本质，是建立一条从“攻击行为知识”到“可执行规则需求”的可追溯链路。战术提供分类视角，技术提供行为粒度，子技术提供精确落点，数据源提供可行性约束，检测策略提供分析思路，最终汇聚为规则需求。只有把这条链路走通，SIEM检测规则才能从零散堆叠走向系统覆盖。

← 上一章 📖 返回目录 下一章 →