猎鹰札记：如何改善基于ATT&CK框架的数据源利用情况

随着传统安全边界日益模糊，攻击面不断增大，传统的被动等待警报出现再做出响应的网络防御措施已不能满足组织机构的安全需求。相反，组织机构要转换心态，变被动为主动，主动开展威胁狩猎。在威胁狩猎过程中，威胁狩猎的执行者是人（有关威胁猎人的更多信息，请参见《猎鹰札记：威胁猎人的“千人千面”及场景实践》，而威胁狩猎的对象是数据。数据从哪里来，如何提高数据收集质量与效率是威胁狩猎能否成功的一个关键推动力。本文将介绍在威胁狩猎中，如何改善基于ATT&CK框架的数据源利用情况。

图1：ATT&CK技术的数据源属性

改善ATT＆CK数据源的当前利用情况

通过ATT＆CK框架的数据源，我们可以将网络环境中的攻击活动与遥测数据关联起来。在根据ATT＆CK框架来查看需要收集哪些数据来检测攻击技术时，数据源就成为了不可或缺的一部分。

图2：ATT＆CK数据源及其可以检测的技术数量

我们总结了一些方法来改善数据源的利用情况。

1. 制定数据源定义

明确定义好每个数据源可以提高数据收集效率，同时也有助于数据收集策略的制定。ATT＆CK用户也就能够更快速地将数据源对应到其环境中的特定日志和终端设备。

图3：事件日志与数据源的映射

2. 标准化命名语法

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

图4：命名语法结构示例

3.解决冗余和重叠问题

数据源没有标准化命名结构的另一个后果是冗余，这也可能导致重叠。

示例A：加载DLL和DLL监控

与DLL相关的推荐数据源有两种不同的检测机制。但是，这两种技术都利用加载DLL来代理执行恶意代码。我们是收集“加载DLL”呢，还是“DLL监控”呢？还是同时进行收集？它们是来自于同一个数据源吗？

图5：AppInit DLLs子技术

图6：Netsh Helper DLL子技术

示例B：收集进程遥测数据

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

图7：数据源之间的冗余和重叠

示例C：Windows事件日志分类与汇总

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

图8：Windows事件日志查看器

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

图9：Windows事件日志重叠范围

4. 确保平台一致性

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

图10：Windows数据源

ATT＆CK子技术的发布也在一定程度上解决了这个问题。例如，在下图中，我们可以看到OS凭据转储（T1003）技术的介绍、可执行此技术的平台以及相关的数据源。

图11：OS凭据转储技术

尽管根据字段展示，我们会将PowerShell日志数据源与非Windows平台关联起来，但是我们深入研究子技术的详细信息就会发现，PowerShell日志与非Windows平台之间没有关系。

图12：LSASS内存子技术

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

升级ATT＆CK数据源的使用

鉴于上文提到的问题，对每个ATT＆CK数据源进行定义是合理之举。但是，我们也意识到，如果没有一种描述数据源的结构和方法，很难对数据源进行定义。虽然描述诸如“进程监控”、“文件监控”、“Windows注册表”甚至是“DLL监控”之类的数据源非常简单，但是描述“磁盘取证”、“爆震室”或“第三方应用程序日志”的数据源则要非常复杂。

因此，我们需要利用数据概念来帮我们以一种标准化方式为每个数据源提供更多的上下文。这样，我们就能够发现数据源之间的更多潜在关系，并改善攻击行动与收集的数据之间的映射关系。

以下六点介绍了如何改善ATT＆CK数据源的使用情况：

1. 利用数据建模

数据模型是将数据元素组织在一起并将它们之间的关系标准化的一组概念集合。如果我们将这些基本概念应用于安全数据源，那么我们就可以找出核心数据元素，通过这些元素用更结构化的方式来描述数据源。此外，这还有助于我们发现数据源之间的关系，并改善攻击行动中TTP的捕获过程。

以下是ATT＆CK数据源的拟定数据模型：

表1：数据建模概念

根据这一概念模型，我们可以找出数据源之间的关系及其与日志和终端设备之间的映射关系。例如，下图代表了在使用Sysmon事件日志时涉及到的几个数据元素及元素之间的关系：

图13：进程数据对象的关系示例

2. 通过数据元素定义数据源

通过数据建模，我们能够验证数据源名称，并以标准化方式对每个数据源进行定义。我们可以利用收集的数据中的主要数据元素来定义。

我们可以使用数据元素来命名与攻击行动有关的数据源。例如，如果攻击者修改了Windows注册表中的某个值，我们会从Windows注册表中收到遥测数据。我们还可以利用其它上下文来辅助定义数据源，例如攻击者是如何修改的以及是谁修改了信息等等。

图14：将注册表键值作为主要数据元素

我们还可以对相关的数据元素进行分组，从而对所需收集的信息有大致的了解。例如，我们可以对提供有关网络流量元数据的数据元素进行分组，并将其命名为Netflow。

图15：Netflow数据源的主要数据元素

3. 整合数据建模和攻击者建模

还可以利用数据建模概念来增强ATT＆CK数据源与技术或子技术之间的映射关系。通过分解数据源并将数据元素彼此之间的关联方式标准化，我们就能够从数据角度围绕攻击者行为提供更多的上下文信息。ATT＆CK用户可以采用这些概念，并确定他们需要收集哪些特定事件，确保覆盖特定的攻击行动。

例如，在下图中，我们可以通过提供一些相互关联的数据元素来为Windows注册表数据源添加更多信息，从而提供更多有关攻击者行动的上下文。我们可以从Windows注册表转到“进程——已创建——注册表键”。

这只是我们可以映射到Windows注册表数据源的一种关系。但是，这些附加信息将有助于更好地理解我们需要收集哪些特定数据。

图16：数据建模示例

4. 将数据源作为对象集成到ATT＆CK框架中

ATT＆CK框架中的关键组成部分（战术、技术和攻击组织）都被定义为对象。下图展示了技术对象在ATT&CK框架中的位置。

图17：ATT＆CK对象模型（含数据源对象）

5. 扩展ATT＆CK数据源对象

在我们将数据源作为对象集成到ATT＆CK框架中，并且建立了定义数据源的结构化方法后，我们就可以通过属性的形式确定其他信息或元数据了。

下表概述了数据源对象的一些基本属性：

表2：数据建模概念

通过这些基本属性，可以提高ATT＆CK数据源的级别，也方便获取更多信息，从而逐渐形成更有效的数据收集策略。

6. 使用数据组件扩展数据源

最后，需要对数据组件进行定义。上文中，我们讨论过了与数据源相关的数据元素之间的关系（例如，进程、IP、文件、注册表），这可以归为一类，并为数据源提供另一个级别的上下文信息。这一概念也是开源安全事件元数据（OSSEM）项目的一部分。

在下图中，我们扩展了进程的概念，并定义了一些数据组件，包括进程创建和进程网络连接，以提供其他上下文信息。这就提供了一种可视化方法，介绍了如何从进程中收集数据。这些数据组件是根据数据源遥测数据中已确认的数据元素之间的关系来创建的。

图18：数据组件及数据源之间的关系

下图介绍了ATT＆CK框架可以提供相关信息来确定各个数据元素之间的关系。在实际应用中，我们可以自行决定如何将这些数据组件和关系映射到已收集的特定数据。

图19：扩展ATT＆CK数据源

写在最后

Mitre ATT&CK框架是进行威胁狩猎的一个重要参考模型。在利用这一框架的过程中，我们通常会关注战术、技术、步骤、检测方法和缓解措施，但却忽略了一个重要因素——数据源。每种技术的数据源都提供了重要的上下文信息，有助于通过分析各种数据信息提高威胁狩猎的效率。本文介绍了如何改善和升级数据源的使用情况，希望能够为从事攻击技术检测和威胁狩猎的安全人员提供一些数据收集的思路。