检测规则之后是什么？ATT&CK中更智能的检测策略

防御者经常使用ATT&CK检测中的信息来帮助构建有用的分析功能。但随着检测工程的成熟，当前格式的扩展性并不理想。ATT&CK检测中的文本经常将过多行为打包到单个文本块中，使其难以解释或应用。重要的平台差异有时会被忽略，从对手行为到日志遥测的映射（尤其在复杂环境中）更像是一门艺术而非科学。

准备扩展您的映射

我们将在v18版本中对ATT&CK STIX格式和ATT&CK Workbench进行重大调整，引入两个全新的STIX域对象（SDO）和结构化关系模型。此更新将把ATT&CK检测指导转变为专注于检测策略的系统，提供模块化、行为优先的蓝图，更好地应对对手行为、平台多样性和可扩展检测。

检测策略一直是ATT&CK的核心部分，但我们捕获该指导的方式并不总能反映防御者（包括我们自己）的实际工作方式。早期版本使用技术内的x_mitre_detection STIX字段来描述检测建议。这将平台、行为和遥测源合并到单个段落中，难以自动化或适应不同环境。

我们后来转向当前ATT&CK中的方式，将检测逻辑结构化为数据组件和技术之间的检测关系。这有助于突出遥测与检测特定技术之间的联系，但这些关系通常存在于非结构化描述字段中，缺乏可见性且无法单独版本控制。随着ATT&CK的成熟，这导致了一个关键挑战：我们一些最有价值的检测见解被埋没了。

这一挑战让我们退后一步，思考如何以实际反映入侵发生方式和防御者思维方式来捕获检测策略。大多数检测还依赖于孤立事件：一个进程创建、一个文件写入、一个网络连接。

但对手不会单线操作。

现代检测策略不是关于单线检测，而是一系列检测。真实世界的入侵在多个事件中展开：进程将文件写入临时目录 -> 该文件通过已知库加密 -> 文件通过可疑通道外泄。

我们知道需要更好的方式来捕获和表达这种逻辑。因此，我们围绕一个简单原则重建检测模型：检测策略不是句子，而是系统。通过这个新系统，我们将检测逻辑分解为模块化STIX对象，每个对象都有自己的生命周期和版本控制，针对特定平台定制，并与行为、遥测和分析逻辑连接。

检测策略模型引入三个主要变化：

每个x_mitre_detection_strategy对象对应一个ATT&CK技术或子技术，并定义其旨在检测的对手行为。它本身不包含所有检测逻辑，而是引用一个或多个分析，描述如何在不同环境中检测该行为。

以前，检测说明试图在单个字段中解释Linux和Windows行为。现在，每个分析都是平台特定的，直接引用所需的日志源、数据组件和可调检测阈值。

ATT&CK现在将数据组件与日志源名称和描述绑定，包含数据组件特定排列：

这些日志源然后通过正式STIX关系与数据组件连接，创建从行为到遥测的清晰链。

以下是新检测策略模型在实践中如何工作，从高级策略到低级检测组件：

假设您的团队想要检测T1053.002：计划任务/作业：在Windows、Linux和macOS上执行：

检索DET-0084，它链接到：
- Windows的AN-3121（事件ID 4698 + 写入%SystemRoot%\Tasks的文件）
- Linux的AN-3122（cron日志 + /var/spool/cron/文件写入）
- macOS的AN-3123（launchd与文件放置在~/Library/LaunchAgents）
确认相关数据组件（DC-0033、DC-0037、DC-0039）已收集。
根据需要调整阈值：
- 将时间窗口延长至30分钟
- 标记工作时间外的执行（UserContext: !System）
使用对手仿真工具或ATT&CK Workbench场景运行器测试检测。

这会破坏我现有的ATT&CK集成吗？ 如果您依赖x_mitre_detection、带有relationship_type:“detects"的描述或x_mitre_data_sources，会的。

数据源会消失吗？ 不完全。它们将在旧版ATT&CK中保留，但在2025年10月后我们将转向日志源。

如果我没有列出的日志源怎么办？ 没问题。每个检测策略包括可调字段和平台特定选项，因此您可以将逻辑适应您已有的内容。

这如何影响ATT&CK Workbench？ Workbench将支持开箱即用地编写和可视化x_mitre_detection_strategy对象。

通过从单句指导转向结构化、行为驱动的策略，我们旨在使ATT&CK更可用、更适应，并与对手的实际操作方式更一致。