面向XDR的数据质量度量方法（一）">面向XDR的数据质量度量方法（一）

面向XDR的数据质量度量方法（一）

告警疲劳现象严重影响了安全运营团队的运营成效：运营专家绝大部分的时间精力消耗在低质量低风险告警及事件的研判过程中，高隐匿性攻击行为的少量关键线索难以被快速召回。
造成这一现象的一个关键影响因素在于，大规模收集的日志、告警、事件等数据的质量层次不齐，难以为运营过程提供足够且有效的信息量支撑。为此，观测、记录、分析、优化威胁检测数据的质量，是提升安全运营能效的关键环节。
本文将介绍MITRE公司组织的ATT&CK Evaluation项目的评估方法，分析MITRE在威胁检测能力归类方面的方法论。

一、MITRE ATT&CK Evaluation检测能力归类方法的演化

ATT&CK知识框架的影响力已在业界形成共识。MITRE从2018年以来持续运营基于ATT&CK的检测分析能力开放评估项目[1]，特别是针对企业威胁分析，组织并模拟了四轮攻击模拟评估，包括APT3（2018年）、APT29（2019年）、Carbanak+FIN7（2020年）、Wizard Spider + Sandworm（2021年）。
22.04.12-绿盟 - 面向XDR的数据质量度量方法（一） - 图1
图1 ATT&CK Evaluation项目
MITRE在指定靶场上进行攻击模拟，参与厂商机基于部署的传感器与分析平台给出分析报告，以评估针对以上评估场景下技战术识别的覆盖情况。尽管参与厂商大概率提供了检测日志、事件、告警与ATT&CK矩阵的技战术映射关系，但是如何在各个厂商之间，对齐各家检测能力的粒度，是影响最终评估效果对比的一个关键因素。MITRE公司对此项工作的定位是：

“供应商使用他们自己的术语和方法来检测潜在的对手行为。他们以独特的方式向我们提供这些信息，然后我们有责任使用检测类别抽象数据，以类似的方式谈论产品。”

因此，需要一种分类规范，以对厂商的检测能力进行公平的归类。MITRE在每一轮评估项目中提供了“Detection Categories”检测能力归类规范说明。随着评估项目的完善，该检测能力归类方法也在持续演进。以下对几轮的检测能力归类方法进行简介与分析。

1. APT3 Enterprise Evaluation 2018

APT3项目中，MITRE采用的基本检测能力归类策略描述如下：

“这些类别分为两种类型：“主要”和“修饰符”。每个检测都会收到一个主要类别名称，该类别名称与提供给用户的上下文数量有关。检测可以选择接收一个或多个修饰符类别名称，以帮助更详细地描述检测。”

即，采用了必选的主分类（Main）和可选的次分类（Modifier）。同时，主分类主要依据检测结果提供的上下文、信息量来划分的。检测能力归类主要包括以下类别，总结如下：

主类别	次类别	含义	举例
Main Detection Types	None	由于能力限制或其他原因，供应商无法检测到红色活动。如果数据与测试程序不直接相关，则将其归类为“无”。在这些情况下，供应商可能会收到“无”的分类，并附有有关该数据的附加说明和屏幕截图。可概括为：无检测能力，无对应实际攻击行为的可观测数据。	不会收集与正在执行的特定操作相关的数据。在红队执行该程序的同时会发出警报，但它与所测试的技术无关。该工具允许用户对文件进行取证分析。此取证分析显示文件的功能，但不直接显示已执行程序。
	Telemetry	该功能会生成一些最终用户可以访问的经过最少处理的数据，并直接表明红队活动是在用户执行人工分析之后发生的。不存在导致数据输出的复杂逻辑或高级规则的证据，并且除了简单的字段标记外，不会发生任何标记。检测需要与实际执行的程序在逻辑上明确相关。检测证明可以包括用于访问数据和/或检测输出（例如，表视图或流程树）的视图、查询或 API 搜索。可概括为：基本对应原始采集日志，且日志中明确包含攻击行为线索。	正面例子：生成的命令行输出显示某个命令是由给定用户名在工作站上运行的。反面例子：该功能显示恶意文件可能执行的所有潜在行为，但不指示实际发生的行为。这不是遥测检测，因为检测与正在执行的程序没有明显关系。
	Indicator of Compromise	供应商根据已知的哈希、IP 地址、C2 域、工具名称、工具字符串或模块名称来识别红队活动。检测证明可以包括规则名称、用于访问数据的 API/查询和/或检测输出。可概括为：基于已知IOC匹配的检测结果。	红队C2 IP地址被认定为恶意。
	Enrichment	该功能捕获数据（通常是上面“可用遥测”类别中描述的数据），然后使用规则名称、标签、标签或有助于用户分析数据的 ATT&CK 策略或技术等附加信息来丰富它超出了最初呈现的内容。富集必须与所测试的 ATT&CK 技术在逻辑上明确相关。没有证据表明复杂的逻辑或高级规则导致数据输出超出了简单的“如果 X，标记为 Y”条件。检测证明可以包括用于访问数据和/或检测输出（例如，表视图或流程树）的视图、查询或 API 搜索。可概括为：基于原始日志，实现对行为的ATT&CK技战术基本映射和标签富化。	正面例子： - 查找任何 foo.exe 执行的简单规则会生成一个名为“Foo Discovery Occurred”的警报，其中包含支持数据“cmd.exe foo”。 - 显示带有“侦察观察”信息的“cmd.exe foo”的数据。 - 显示带有“ATT&CK 技术 T9999 Foo Discovery”信息的“cmd.exe foo”的数据。

反面例子：
- 显示“Process: cmd.exe foo”且标有“Process created”的数据算作遥测而不是 Enrichment，因为“Process created”对分析师来说已经很明显，并且与被测技术无关。
| | | General Behavior | 该功能基于某种类型的复杂逻辑或规则（除了简单的“如果 X，显示 Y 规则名称”，将被归类为丰富）产生可疑或潜在恶意行为的警报检测。

警报必须与被测技术在逻辑上明确相关，并且能力必须具有指示这是警报的视觉指定（例如，指示警报的图标、通知、影响分数或类似的视觉表示）。这种检测可以提供 ATT&CK “策略”级别的描述（例如，发现、执行等）和/或指示行为异常的一般描述，但不提供检测到的过程的具体细节（即“黑匣子”） .

（对于以这种方式对检测进行分类的 ATT&CK 引用不是必需的，但如果包括在内，将予以注明。）检测证明可以包括执行检测的规则名称或模块以及检测输出。

可概括为：通过分析手段实现了对攻击行为的显示告警，该告警是ATT&CK Tactic战术层级的通用行为告警。 | 一系列发现技术会触发名为“恶意发现”的警报。该警报有一个分数，表明该警报可能是恶意的。警报显示未识别执行的特定类型的发现。

首次执行可执行文件时触发“可疑文件”警报。 | | | Specific Behavior | 该功能基于一些复杂的规则或逻辑检测可疑行为，并提供活动的 ATT&CK“技术”级别描述（除了简单的“如果 X，显示 Y 规则名称”，将被归类为丰富）。

（以这种方式对检测进行分类不需要 ATT&CK 参考，但如果包括在内，将予以注明。）检测包括额外的语言和/或解释，以提供更多细节，而不是一般指定该行为是恶意的。

警报必须与被测技术明显和逻辑相关，并且能力必须具有指示这是警报的视觉指定（例如，指示警报的图标、通知、影响分数或类似的视觉表示）。

检测证明可以包括执行检测的规则名称或模块以及检测输出。

可概括为：通过分析手段实现了对攻击行为的显示告警，该告警是ATT&CK Technique技术层级的特定行为告警。 | 该功能会生成一个名为“UAC Bypass”的警报。该警报包含详细信息，显示该功能检测到一系列相关事件的过程完整性级别的变化。

该功能会为 Mimikatz 登录密码凭据转储生成一个名为“凭据转储”的警报。 | | Modifier Detection Types | Delayed | 当红队执行操作时，该功能不会实时或近乎实时地检测到活动，但随后的警报、数据、扩充或其他处理会产生对活动的检测。

延迟类别不适用于仅基于常规检测出现在功能中所需的时间的数据，也不适用于与功能本身无关的范围或连接问题。

检测证明必须包括对延迟检测和证明的解释，其中可能包括其他警报、叙述、用于获取检测的查询和/或检测输出。

可概括为：相关检测数据未能及时触发，例如云端检测和MSSP分析等，可见示例。 | 当红队执行操作时，该功能不会实时或近乎实时地检测到活动，但随后的警报、数据、扩充或其他处理会产生对活动的检测。

延迟类别不适用于仅基于常规检测出现在功能中所需的时间的数据，也不适用于与功能本身无关的范围或连接问题。

检测证明必须包括对延迟检测和证明的解释，其中可能包括其他警报、叙述、用于获取检测的查询和/或检测输出。 | | | Tainted | 该功能基于先前识别的与检测相关或“受其污染”的可疑/恶意行为来检测活动。

一个示例可以包括先前将一个进程识别为恶意，并通过直接操作/结果或其他关系将与该进程相关的后续事件标记为恶意。

检测证明必须包括明确的视觉证据，表明检测使用了受污染的传播，包括哪些其他活动导致了这种检测。

可概括为：基于前序检测结果，通过某种机制传播（如关联）形成的新的检测结果，可见示例。 | 该功能会为“检测到恶意进程”生成一般行为警报，然后在树视图中显示 cmd.exe 运行了 ipconfig。

由于从父常规行为检测到子遥测检测之间存在一条线，ipconfig 遥测检测显示为受污染，因此遥测检测将被归类为遥测和受污染。 | | | Configuration Change | 通过特殊的配置更改或额外的 API 访问可以进行检测，从而使最终用户通常无法访问的数据变得可用。

此类别适用于由于对初始配置进行更改而产生的检测（如供应商在评估开始时所述）。

检测证明应包括由更改产生的检测输出以及有关更改原因、更改方式以及最终用户如何请求更改的注释。

可概括为：厂商经过检测机制、配置文件中的配置参数修改后，才产生或展现出来的检测结果。 | 显示帐户创建的数据在后端收集，但默认情况下不显示给最终用户。供应商更改后端设置以允许在用户界面中显示帐户创建的遥测，因此将为创建帐户技术提供对遥测和配置更改的检测。

当执行 foo、foo1 和 foo2 发现命令时，供应商会切换一个显示附加标签“发现”的设置。将给出对丰富和配置更改的检测（与在更改之前给出的遥测检测相反）。

创建并追溯应用规则或检测逻辑，或者稍后重新测试以显示功能中存在的功能。 |

表1 APT3 Enterprise Evaluation 2018检测能力分类

2. APT29 Enterprise Evaluation 2019

整体上，APT29攻击模拟检测评估中，采用的检测能力归类策略与APT3一致，即划分为主、次两种大的类别，其中主分类主要依据检测结果提供的上下文、信息量来划分的。
与APT3不同，相关主类别和次类别进行较大调整，主要是剔除了APT3中的Indicator of Compromise和Enrichment主类别，增加了MSSP主类别，对通用和技战术先关的主类别进行了重构。次类别融合了APT3的一些主类别，调整幅度更大。APT29评估项目的检测能力归类机制主要结构如下：
22.04.12-绿盟 - 面向XDR的数据质量度量方法（一） - 图2
图2 APT29评估项目的检测能力归类机制
本轮次的划分机制总结如下：

主类别	次类别	含义	举例
Main Detection Types	None	没有自动收集、处理并在与被测行为相关的能力范围内可用的数据。如果数据与测试程序不直接相关，则将其归类为“无”。在这些情况下，供应商可能会收到“无”的分类，并附有有关该数据的附加说明和屏幕截图。可概括为：无检测能力，无对应实际攻击行为的可观测数据。与APT3基本一致。	不会收集与正在执行的特定操作相关的数据。在红队执行该程序的同时会发出警报，但它与所测试的技术无关。
	Telemetry	功能收集的最少处理数据，表明事件发生特定于被测行为（即显示已执行的过程/命令）。证据必须明确表明发生了行为并且与执行机制相关（确实发生了与可能已经发生）。证据必须与导致该行为的原因有关。没有证据表明复杂的逻辑或导致数据输出的高级规则，并且除了简单的字段标记之外没有发生任何标记可概括为：基本对应原始采集日志，且日志中明确包含攻击行为线索。与APT3基本一致。	生成的命令行输出显示某个命令是由给定用户名在工作站上运行的。
	MSSP	数据来自托管安全服务提供商 (MSSP) 或基于人工分析和事件发生指示的监控服务。由于必要的手动分析，MSSP 本质上是延迟的，并且将被标记为延迟以与其他延迟检测保持一致。可概括为：基于远程MSSP的检测结果。相对APT3为新增。	收到一封来自分析师的电子邮件，描述了与数据泄露相关的操作的上下文。
	General	处理过的数据，指定发生了与被测行为相关的恶意/异常事件。（即 cmd.exe /c copy cmd.exe sethc.exe，是异常/恶意活动或说明“发生可疑活动”的标识符。没有或有限的详细信息说明为何执行该操作（策略），或详细信息动作的执行方式（技术）。可概括为：一般类型检测数据，如异常行为等，不包含对技战术的详细映射和识别。无APT3的对应类别。	将“cmd.exe /c copy cmd.exe sethc.exe”描述为异常/恶意活动的警报，但未说明它与辅助功能相关或更具体的描述。首次执行可执行文件时触发“可疑文件”警报。一条警告说“发生了可疑活动”与某项操作相关，但未提供详细信息。
	Tactic	处理后的数据，指定 ATT&CK 战术或能力收集的数据的同等丰富水平。向分析师提供有关活动潜在意图的信息，或帮助回答“为什么会这样做”的问题（即设置了持久性或存在一系列发现命令）。可概括为：该数据映射到ATT&CK Tactic并包含了ATT&CK Tactic战术层级的信息，能够给出并解释告警对应行为的“Why”问题。基本对应APT3的General Behavior类别。	一系列发现技术会触发名为“恶意发现”的警报。该警报有一个分数，表明该警报可能是恶意的。该警报不识别执行的特定类型的发现。描述持久性发生但未指定如何实现持久性的警报。
	Technique	处理后的数据，指定 ATT&CK 技术或能力收集的数据的同等丰富水平。向分析师提供有关如何执行操作的信息，或帮助回答“做了什么”的问题（即可访问性功能或凭证转储）。可概括为：该数据映射到ATT&CK Technique并包含了ATT&CK Technique技术层级的信息，能够给出并解释告警对应行为的“How”问题。基本对应APT3的Specific Behavior类别。	触发一个名为“凭据转储”的警报，其中包含足够的详细信息，以显示哪个进程引发了针对 lsass.exe 的行为和/或提供了有关发生哪种类型的凭据转储的详细信息。触发“带有服务执行的横向移动”的警报，描述启动的服务和目标系统。
Modifier Detection Types	Alert	数据作为优先通知呈现给分析人员，作为发生可疑或恶意事件的指示，以供进一步调查（例如：图标、队列、突出显示、弹出窗口等）。不是遥测的修饰符。可概括为：指示检测结果为告警类型。相对APT3把数据粒度更精细化了，主分类只提数据和标签，不区分是否是告警。这更符合ATT&CK行为识别而非攻击识别的中性数据假设。	仪表板和/或警报队列中出现“横向移动”发生的视觉通知。填充到仪表板的可识别标识符，以便分析师识别可能已发生的高严重性事件。
	Correlated	根据提请分析师注意的警报或高度怀疑活动，将数据显示为先前被识别为可疑/恶意事件的后代。相关证据的示例包括带注释的过程树或应用于事件链的标签，显示可疑/恶意事件与来自被测技术的数据之间的关系。可概括为：基于前序检测结果，通过某种机制传播（如关联）形成的新的检测结果，可见示例。基本对应APT3的Tainted类型，语义表达更明确了。	对进程树或事件链进行注释，显示 net.exe 进程与“凭据转储”上的先前警报之间的关系。仪表板中的遥测显示 ipconfig.exe 的进程启动与 IOC 上的先前警报之间的关系，以显示活动的沿袭。
	Delayed	检测（警报、遥测、策略、技术等）是不可用的，因为某些因素会减慢或延迟其呈现给用户的速度，例如后续或额外的处理会产生对活动的检测。延迟类别不适用于正常的自动数据摄取和常规处理，需要最少的时间让数据出现在用户面前，也不适用于与功能本身无关的范围或连接问题。延迟修饰符将始终与描述延迟性质的更多详细信息的修饰符一起应用。延迟细分为：手动 - 处理是由人为触发的，而不是自动启动的。在 MSSP 提供检测的情况下，人工分析师审查并生成输出，然后提交给分析师。处理 – 基于额外的数据处理，将复杂的逻辑应用于事件，然后分析人员可以获得结果，检测会产生延迟。可概括为：相关检测数据未能及时触发和展示，例如云端检测和MSSP分析等。基本对应APT3的Delayed子类型，增加了分类。	该功能的云服务组件使用机器学习算法，在红队执行后几小时触发凭证转储检测。此检测将接收技术的主要检测类别和延迟处理的修改器检测类别。该功能将数据发送回分析团队，分析团队手动分析原始数据并创建一个名为“检测到恶意行为”的警报，该警报会在红队执行该程序三小时后出现在界面中。此检测将接收 MSSP 的主要检测类别和延迟手动的修改器检测类别。
	Host Interrogation	通过分析功能从端点手动提取数据。此类别表示通过手动分析从数据中识别出的可能行为，这些数据不是自动摄取和分析的，能够向分析师显示特定于被测行为的事件发生。虽然对某些安全团队来说是一种有用的能力，但通过这些方式捕获数据可能很困难和/或取决于分析师的技能水平以获取可操作的信息。 Host Interrogation 是一个修饰符，仅适用于 None 类别。它将被标记为延迟以与其他延迟检测保持一致。可概括为：通过非自动化手段直接拉去目标主机数据进行分析，只针对None这一主类型。相对APT3为新增子类型。	该功能有一个远程 shell 组件，可用于从怀疑受到威胁的系统中提取本机操作系统日志以进行进一步分析。
	Residual Artifact	需要额外分析以确定可能使用了哪些功能或行为的数据，例如二进制或进程内存。此类别表示通过手动分析从数据中识别出的可能行为，这些数据不是自动摄取和分析的，能够向分析师显示特定于被测行为的事件发生。收集到的数据更多是对手行为的副产品，而不是对手行为的指示。虽然对某些安全团队来说是一种有用的能力，但通过这些方式捕获数据可能很困难和/或取决于分析师的技能水平以获取可操作的信息。 Residual Artifact 是一种仅适用于“无”类别的修饰符。它将被标记为延迟以与其他延迟检测保持一致。可概括为：通过非自动化的手段（通过专家）对特定数据进行再分析，以得出进一步的检测结果和信息。只针对None这一主类型。相对APT3为新增子类型。	收集 svchost.exe 的进程内存以供以后分析，因为它被识别为可疑进程。后来的字符串分析表明，系统上可能存在键盘记录器。 PowerShell 脚本在执行时自动收集。稍后对脚本的分析表明它包含捕获用户桌面屏幕截图的功能。
	Configuration Change	自评估开始以来，功能的配置已更改。可以这样做以显示可以收集和/或处理额外的数据。配置更改修饰符可以与描述更改性质的附加修饰符一起应用。配置变更细分为： UX：改变的是用户体验，而不是检测行为的能力。更改可能包括显示已收集但对用户不可见的某种类型的数据。检测：改变能力捕获或处理影响其检测对手行为能力的信息的能力。更改可能包括通过传感器收集新类型的信息或部署的新处理逻辑。可概括为：厂商经过检测机制、配置文件中的配置参数修改后，才产生或展现出来的检测结果。基本对应APT3的Configuration Change子类型，增加了分类。	显示帐户创建的数据在后端收集，但默认情况下不显示给最终用户。供应商更改后端设置以允许在用户界面中显示帐户创建的遥测，因此将为创建帐户技术提供对遥测和配置更改-UX 的检测。当执行 foo、foo1 和 foo2 发现命令时，供应商会切换一个显示附加标签“发现”的设置。将给出对战术和配置更改检测的检测（与在更改之前给出的遥测检测相反）。创建并追溯应用规则或检测逻辑，或者稍后重新测试以显示功能中存在的功能。这将使用修饰符 Configuration Change-Detection 进行标记。
	Innovative	指定用于检测被测技术的创新和有用的方法。并非所有技术都会或可以将此指定应用于供应商解决方案。它旨在强调为消费者带来价值和更深入洞察力的准确和强大的方法。此修改器将由评估团队自行决定应用，并将考虑收集的数据、检测方法、检测准确性、提供给最终用户的上下文以及信息显示。可概括为：经评估团队认定的鲁棒、准确的分析方法产生的检测结果。相对APT3为新增子类型。	/

表2 APT29 Enterprise Evaluation 2019检测能力分类

3. Carbanak+FIN7 Enterprise Evaluation 2020

本次评估中，基本的检测能力分类策略与前两次是一致的。基于APT29轮次的策略，Carbanak+FIN7项目中对归类方法进行了简化，剔除了MSSP主类型（猜测测试中只测试自动化部分，不涉及MSSP业务接口能力测试），剔除了多种子类型，只保留了Configuration Change和Delayed两个子类型。此外，Carbanak+FIN7增加了防护（Protection）方面的能力归类策略。
评估项目的检测（Detection）能力归类机制主要结构如下：
22.04.12-绿盟 - 面向XDR的数据质量度量方法（一） - 图3
图3 Carbanak+FIN7评估项目的检测能力归类机制
评估项目的防护能力归类机制主要结构如下：

图4 Carbanak+FIN7评估项目的防护能力归类机制
本轮次的检测能力归类机制总结如下：

主类别	次类别	含义	举例
Main Detection Types	Not Applicable	供应商无法查看被测系统。供应商必须在评估之前说明他们没有在哪些系统上部署传感器，以使 Not Applicable 在相关步骤的范围内。可概括为：无检测数据采集能力，无法收集相关数据。相对APT29为新增。	环境中的 Linux 系统中没有部署传感器来捕获命令行活动，而这些活动是满足被测技术的检测标准所必需的。
	None	在与满足指定检测标准的被测行为相关的能力范围内，没有数据可用。 None 不包含修饰符、注释或屏幕截图。可概括为：无检测能力，无对应实际攻击行为的可观测数据。与APT29基本一致。	/
	Telemetry	由能力收集的最少处理数据，表明事件发生特定于被测行为，满足指定的检测标准。证据必须明确表明发生了行为并且与执行机制相关（确实发生了与可能已经发生）。此数据必须在工具中本地可见，并且可以包括从端点检索的数据。可概括为：基本对应原始采集日志，且日志中明确包含攻击行为线索。与APT29基本一致。	生成的命令行输出显示某个命令是由给定用户名在工作站上运行的。该功能中有一个远程 shell 组件，可用于从怀疑受到威胁的系统中提取本机操作系统日志以进行进一步分析。
	General	处理过的数据，指定发生了与被测行为相关的恶意/异常事件。没有提供或提供有限的细节来说明为什么执行该动作（策略），或有关如何执行该动作的细节（技术）。可概括为：一般类型检测数据，如异常行为等，不包含对技战术的详细映射和识别。与APT29基本一致。	将“cmd.exe /c copy cmd.exe sethc.exe”描述为异常/恶意活动的检测，但没有说明它与辅助功能相关或更具体的描述。首次执行可执行文件时触发“可疑文件”检测。一项检测表明“发生了可疑活动”与某项操作相关，但未提供有关被测技术的详细信息。
	Tactic	处理后的数据，指定 ATT&CK 战术或能力收集的数据的同等丰富水平。向分析师提供有关活动潜在意图的信息或帮助回答“为什么要这样做”的问题。要获得检测的资格，事件上必须有一个以上标识 ATT&CK 战术的标签，并且它必须清楚地将战术级别的描述与被测技术联系起来。可概括为：该数据映射到ATT&CK Tactic并包含了ATT&CK Tactic战术层级的信息，能够给出并解释告警对应行为的“Why”问题。与APT29基本一致。	一系列发现技术触发了一种称为“恶意发现”的检测。检测不识别执行的特定类型的发现。描述发生持久性但未指定如何实现持久性的检测。
	Technique	处理后的数据，指定 ATT&CK 技术、子技术或能力收集的数据的同等丰富水平。向分析师提供有关如何执行操作的信息或帮助回答“做了什么”的问题（即可访问性功能或凭证转储）。要获得检测的资格，事件上必须有一个标识 ATT&CK 技术 ID (TID) 的标签，并且它必须清楚地将技术级别描述与被测技术联系起来。可概括为：该数据映射到ATT&CK Technique并包含了ATT&CK Technique技术层级的信息，能够给出并解释告警对应行为的“How”问题。与APT29基本一致。	触发称为“凭据转储”的检测并具有足够的详细信息，以显示针对 lsass.exe 的行为源自哪个进程和/或提供有关发生哪种类型的凭据转储的详细信息。触发“带有服务执行的横向移动”的检测，描述启动了什么服务以及针对什么系统。
Modifier Detection Types	Configuration Change	自评估开始以来，功能的配置已更改。可以这样做以显示可以收集和/或处理额外的数据。配置更改修饰符可以与描述更改性质的其他修饰符一起应用，包括：数据源：传感器为收集新信息所做的更改。检测逻辑：对数据处理逻辑所做的更改。 UX：与显示已收集但用户不可见的数据相关的更改。可概括为：厂商经过数据源、检测机制、配置文件中的配置参数修改后，才产生或展现出来的检测结果。与APT29基本一致，增加了分类。	重新配置传感器以创建能够监控与数据收集相关的文件活动的能力。这将被标记为配置更改数据源的修饰符。创建新规则、启用预先存在的规则或更改敏感度（例如，黑名单）以在重新测试期间成功触发。这些将使用修饰符 Configuration Change-Detection Logic 进行标记。显示帐户创建的数据在后端收集，但默认情况下不显示给最终用户。供应商更改后端设置以允许在用户界面中显示帐户创建的遥测，因此将为创建帐户技术提供对遥测和配置更改-UX 的检测。
	Delayed	由于某些因素会减慢或推迟其向用户的呈现，例如后续或额外的处理会产生对活动的检测，因此分析人员无法立即获得该检测。延迟类别不适用于正常的自动数据摄取和常规处理，需要最少的时间让数据出现在用户面前，也不适用于与功能本身无关的范围或连接问题。延迟修饰符将始终与描述延迟性质的更多详细信息的修饰符一起应用。可概括为：相关检测数据未能及时触发和展示，例如云端检测等。与APT29基本一致，删除了MSSP相关的示例和描述。	该功能使用机器学习算法，在正常数据摄取期后触发对凭证转储的检测。此检测将收到一个修饰符检测类别延迟，其中包含额外处理时间的描述。

表3 Carbanak+FIN7 Enterprise Evaluation 2020检测能力分类
本轮次的新增的防护能力归类机制较为简要，总结如下：

主类别	次类别	含义	举例
Protection Categories	Not Applicable	供应商没有在被测系统上部署保护功能。供应商必须在评估之前说明他们没有在哪些系统上部署传感器，以使 Not Applicable 在相关步骤的范围内。可概括为：无防护能力。	环境中的 Linux 系统中没有部署传感器来阻止红队活动。
	None	被测技术未被阻止和/或技术不成功，并且没有向用户提供证据表明该功能阻止了活动。可概括为：未成功防护。	所测试的技术是成功的。测试中的技术不成功，但在能力中没有显示任何证据表明该行为被工具明确阻止。
	Blocked	被测技术被阻止，并且用户被明确告知该功能阻止了该活动。可概括为：成功阻断攻击行为。	为“潜在的恶意凭证转储”生成了检测，指定该功能检测到潜在的凭证访问活动并成功阻止了该行为。
Protection Modifier Categories	User Consent	在用户手动提供确认/同意后，被测技术被阻止。可概括为：通过人工介入实现攻击行为阻断。	为“潜在的恶意凭证转储”生成检测，指定该功能检测到潜在的凭证访问活动，并仅在用户接受提示以确认应阻止该行为后成功阻止该行为。此保护将收到用户同意的修改保护类别。

表4 Carbanak+FIN7 Enterprise Evaluation 2020防护能力分类

4. Wizard Spider + Sandworm Enterprise Evaluation 2021

本次评估中，直接沿用了Carbanak+FIN7评估项目的检测能力归类方法，详见上一节。说明经过前三轮的能力覆盖度评估，MITRE Engenuity评估团队的检测能力归类策略趋于稳定。

二、MITRE ATT&CK Evaluation检测能力归类方法总结

从以上几轮评估中采用的检测能力归类方法来看，可以归纳两个重要的变化方向：
（1）整体上，各个评估轮次中的主分类归类原则保持相对稳定，同时归类方法趋于简约。可以看到APT29评估轮次中，相对于APT3，增加了多项分类子类别。可以猜想MITRE公司与参与评测的各个厂商进行了充分的沟通，以通过足够丰富的标签化方法全方位展现并归类厂商的检测能力。但是很显然，相对后续的两轮的简约归类方法，前两轮的丰富标签大大增加了评测分类的难度，尽管多种子类型标签给最终给参与厂商留了一些评估效果缓冲的余地。Carbanak+FIN7和Wizard Spider + Sandworm两轮评测保持了稳定的归类方法，说明MITRE的评估策略对重点能力更聚焦了，也反映出参与厂商对评估方案更加熟悉，能够在检测方面提供更聚焦的能力。
（2）检测能力归类原则，更加聚焦在ATT&CK矩阵所要求的行为粒度，主分类更关注相对中性的技战术行为观测与识别能力。主分类标签是以检测结果数据提供的上下文信息量来划分的。特别是APT29相对APT3，主分类只说明数据和标签，不再强调并区分是否是告警。是否是告警只在子分类标签中体现。在后两轮评估中，这个告警字标签也被剔除了。此外，最初的IOC主分类也只在第一轮次出现，后面几轮都删除了这一分类。这一点更符合ATT&CK行为粒度，并且是相对中性行为识别而非攻击识别的建模假设。即，ATT&CK是一个行为级别的抽象能力评估框架，尽管框架致力于描述APT等攻击的意图与技术实现，但在框架设计中，原子化的战术、技术类别只提供行为观测的描述，而不提供可供量化的行为威胁等级信息。

三、小节

通过MITRE的ATT&CK能力覆盖评测，我们看到了MITRE在检测能力归类方面的方法论，及其在评测实践中的演化过程。基于数据湖，特别是多源异构的数据湖进行XDR能力建设，需要有一套自成体系的检测能力分类策略，或称为数据分类分级方案。只有对数据进行细粒度、精细化的管理和分诊，才能缓解当前SOC大数据实践中遇到的信息爆炸问题。
当然，MITRE提供的检测能力归类，是面向数据分类与知识库映射的，主要是围绕覆盖率这一指标构建的归类策略。实际上，面向安全运营效率提升的目标，数据湖数据的分类分级分诊体系化方法需要更完备、更精细的方案，所考虑的指标也更加复杂。
更多相关内容，欢迎大家关注本系列后续文章。

参考文献

https://attackevals.mitre-engenuity.org/enterprise