3.1　当前ATT&CK数据源利用急需解决的问题

通过ATT&CK框架提供的数据源信息，我们可以将网络环境中的攻击活动与监测数据关联起来。根据ATT&CK框架查看需要收集哪些数据来检测攻击技术时，数据源是不可或缺的一部分。不同的数据源能够检测的技术和子技术的数量是不同的，从图3-2可以看出，通过进程监控、命令行参数和文件监控相关的数据源能够检测非常多的攻击技术和子技术。

MITRE总结了一些方法来改善数据源的利用情况，通过以下三种方法，可以极大提升数据源的利用效果。

3.1.1　制定数据源定义

明确定义好每个数据源可以提高数据收集效率，同时也有助于数据收集策略的制定，使ATT&CK用户能够更快速地将数据源对应到环境中的特定日志和终端设备中。图3-3明确定义了进程监控、Windows注册表和数据包捕获所需的事件日志。

3.1.2　标准化命名语法

将数据源命名语法标准化，是提高数据源利用效率的另一个重要因素。如图3-4所示，如果不对命名语法制定标准化规则，就可能对数据源做出不同的解释。例如，某些数据源涵盖的要素是特定的（例如Windows注册表），而其他数据源（例如恶意软件逆向工程）涵盖的要素是非特定的。可以按照统一的命名语法结构处理正在收集的数据（例如文件、进程、DLL等）中的相关要素。

数据源没有标准化命名语法的另一个后果是冗余，这也可能导致重叠情况的发生，以下提供了三个详细示例。

1. 加载DLL和DLL监控

从MITRE ATT&CK网站信息可知，与DLL相关的推荐数据源有两种不同的检测机制，如图3-5和图3-6所示。但是，这两种子技术都利用加载DLL来执行恶意代码。这就会产生一系列问题，我们是收集“加载DLL”呢？还是收集“DLL监控”呢？还是同时都收集呢？它们来自于同一个数据源吗？

2. 收集进程监测数据

如图3-7所示，进程命令行参数、进程的网络使用和进程监控提供的信息都包含同一个要素——进程。我们是否可以认为“进程命令行参数”可能包含在“进程监控”中呢？“进程的网络使用”是否也会涵盖“进程监控”呢？还是说二者来自不同的数据源呢？

3. Windows事件日志分类与汇总

最后，诸如“Windows事件日志”之类的数据源范围非常广泛，并涵盖了其他数据源。图3-8展示了一些数据源，也可以归类为从Windows终端收集的事件日志。

对此，MITRE建议从PowerShell日志、Windows事件报告、WMI对象和Windows注册表等数据源收集事件（见图3-9）。但是，正如上文讲到的，“Windows事件日志”可能已经涵盖了这些内容。我们是应该将每个Windows数据源都归入“Windows事件日志”下，还是将它们列为单独的数据源呢？

3.1.3　确保平台一致性

从技术的角度来看，有一些数据源直接关联到了某些平台，但在这些平台上无法进行数据收集。例如，图3-10突出显示了与Windows平台相关的数据源，例如PowerShell日志和Windows注册表，这些数据源也可以在其他平台（例如macOS和Linux）上使用。

ATT&CK子技术的发布在一定程度上解决了这个问题。例如，图3-11为MITRE ATT&CK网站上OS凭证转储技术的相关页面，介绍了技术的概况、可执行此技术的平台以及相关的数据源。

尽管根据MITRE ATT&CK网站上OS凭证转储存储器（OS Credential Dumping: LSASS Memory）数据源属性显示（如图3-12所示），可以将PowerShell日志数据源与非Windows平台关联起来，但深入研究子技术的详细信息就会发现，PowerShell日志与非Windows平台之间没有关系。

因此，在数据源层面确定好数据收集平台，会提高数据收集效率。这可以通过将数据源从简单属性或字段值升级为ATT&CK框架中的一个对象（类似于技术/子技术）来实现。