定义ATT&CK数据源：赋能当下2021-01-14    启明星辰专家视野-专家团蒋蓉生

译者按

随着头部组织对积极防御诉求的不断加深，仅仅满足于借助IOCs指导被动防御显然是不够的。今天，常常强调“可见性”，强调流量、资产、应用依赖、数据血缘抑或是上块大屏等等的不同可见性体现。同样，如果看不到网络中到底发生了了什么，再强大的防御措施也没法施展拳脚。所以，应重新看待“检测”这件事，基于样本散列、IP、DNS的检测对手很容易绕过；而对TTPs的检测则提高了对手绕过的难度。（引申阅读：《SIGMA与失陷指标》）

要获得“检测”的智慧，大量的原始数据是必不可少的，所以本文将围绕着数据源展开。所论述之“ATT&CK‘数据源’”是指ATT&CK技术（子技术）中的“Data Sources”字段/属性。（文章原标题：《Defining ATT&CK Data Sources, Part I: Enhancing the Current State》；作者：Jose Luis Rodriguez）

图1：数据源到事件日志的映射示例

围绕着ATT&CK的讨论经常涉及战术、技术、过程、检测和缓解，但是一个重要因素经常被忽视：数据源。每种技术的数据源都提供了有价值的上下文和洞察，来提升组织的安全状况并影响组织的检测策略。

本文将引入一种新的方法来扩展ATT&CK当前的数据源。通过探索数据源现状，产生了运用数据建模进行增强的初步想法。进一步定义ATT&CK数据源对象的表征，以及如何扩展它以引入数据组件的概念。在本系列的下一篇文章中，将引入方法论来协助定义新的ATT&CK数据源对象。

下表列出了被提出的数据源对象结构：

表1：ATT&CK数据源对象

哪里可找到数据源

数据源是技术（子技术）对象属性的一部分：

表2：LSASS Memory子技术

虽然上面只是介绍了数据源的名称，但要理解和有效地应用这些数据源，就必须将它们与检测技术、日志和采集器对齐。

改善ATT&CK现有数据源

《MITRE ATT&CK:设计和哲学》白皮书将数据源定义为“由采集器或日志系统收集的信息，有助于识别对手正在采取的行为、行为步骤或这些行为的结果”。

ATT&CK的数据源提供了一种方法，可以在网络环境中发现对手行为与遥测数据之间的关系。这使得数据源至关重要，得以开发出映射到框架的对手行为检测规则。

JoseLuis Rodriguez和Roberto Rodriguez两兄弟在ATT&CKcon上介绍了如何探索更多关于“数据源元数据”，以及“如何使用数据源成功狩猎”的内容。

译者按：从下图可以发现，“进程监控、进程命令行参数和文件监控”数据源对应了最多的对手技术。Red Canary在《2020威胁检测报告》中也将“进程注入”技术列为十大对手技术之首。这不是巧合，围绕着端侧一直是阵地据守的重点。

图3：ATT&CK数据源

通过社区的反馈，对于强化当前数据源，采取了如下措施。

1、 促进数据源定义

社区反馈强调，定义清楚每个数据源将提高效率，同时也有助于数据收集策略的改进。这将使ATT&CK用户能够在他们的环境中快速地将数据源映射到特定的采集器和日志上。

图4：数据源到事件日志

2、 标准化命名语法

对数据源的标准化命名约定是在彼此交流中要考虑的另一个因素。正如下图中那样，数据源可以有不同的解释。有些数据源非常具体，如Windows注册表，而其他数据源，如恶意软件逆向工程，则有更广泛的范围。我们提出了一种一致的命名语法结构，用于从收集的数据(如文件、进程、DLLs等)中明确定义感兴趣的元素。

图5：命名语法结构

3、 地址冗余和重叠

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

例A：加载DLLs和DLL监控

推荐给DLLs相关的数据源隐含两种不同的检测机制；倒是这两种技术都要将DLLs加载到恶意代码的代理中执行。那么应收集“加载的DLLs”还是关注“DLL监控”？还是两者都要覆盖？可以只是一个数据源吗？

图6：AppInit DLLs子技术（T1546.010）

图7：Netsh Helper DLL子技术（T1546.007）

例B：采集进程遥测

进程命令行参数、进程使用网络和进程监控提供的所有信息都引用了一个共同的兴趣元素——进程。是否认为“进程命令行参数”可以包含在“进程监控”中？“进程使用网络”是否也包括了“进程监控”，或者可以是一个独立的数据源？

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

例C：分解或聚合Windows事件日志

最后，像“Windows事件日志”这样的数据源具有非常广泛的范围，还涵盖了其他的数据源。下图展示了该数据源，Windows终端事件日志的不同分组：

图9：Windows事件查看器

ATT&CK建议从诸如PowerShell日志、Windows事件报告、WMI对象和Windows注册表等数据源收集事件。然而如前面提到的，这些可能已经被“Windows事件日志”覆盖了。是将每个Windows数据源分组在“Windows事件日志”下，还是将它们都作为独立的数据源看待？

图10：Windows事件日志覆盖与重叠

4、 确保平台一致性

还有一些数据源，从技术的角度来看，如果与平台相关，则无法收集他们。如下图，重点展示了与Windows平台相关的数据源，如PowerShell日志和Windows注册表，但却依然出现了macOS和Linux平台。

图11：Windows数据源

这个问题已经通过ATT&CK的子技术在一定程度上得到了解决。如下图，是对操作系统凭证转储（T1003）技术的描述，以及可以实施凭证转储的平台以及推荐的数据源

图12：操作系统凭证转储（T1003）

虽然字段上的描述可以引导我们将PowerShell日志数据源与非Windows平台联系起来，但一旦开始深挖子技术细节，PowerShell日志与非Windows平台间的联系就消失了。

图13：LSASS Memory子技术（T1003.001）

在数据源级定义平台的概念将提高收集的有效性。如可以通过将数据源中的一个简单属性或字段值升级到ATT&CK对象的地位来实现，那么就能成为某种子技术。

ATT&CK数据源方法论

根据来自ATT&CK社区的反馈，为每个ATT&CK数据源进行定义是有价值的。不过，如果没有描述数据源的结构和方法论，要进行定义将是富有挑战的。尽管描述数据源很简单，比如“进程监控”、“文件监控”、“Windows注册表”甚至“DLL监控”，但类似“磁盘取证”、“Detonation Chamber(也称为动态执行环境，在隔离环境或虚拟沙箱中打开电子邮件附件、执行不受信任或可疑的应用程序和执行URL请求)”或“第三方应用日志”这种数据源描述就复杂了。

我们最终认识到，需要运用数据科学中的概念，这些概念可以帮助我们以一种有组织和标准化的方式为每个数据源提供更多的上下文。这样还可以识别数据源之间的潜在关系，更好地映射对手行为和采集到的数据。

1、 利用数据建模

数据模型是集合概念，用于组织数据元素并对它们之间的关系进行标准化。如果我们将这个基本概念应用于信息安全领域的数据源，就可以识别核心数据元素，用更结构化的方式描述数据源。

以下是对ATT&CK数据源提出的初步数据模型：

表2:数据建模概念

基于上述概念模型，就可以开始确定数据源之间的关系，以及它们如何应用于日志和采集器了。下图表示了处理Sysmon事件日志时的几个数据元素和关系：

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

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

数据建模使我们能够验证数据源名，并以标准化的方式为每个数据源提供定义。这是通过所收集到数据所呈现的主要数据元素来实现。

可以使用数据元素来命名对手行为相关的数据源，这样就能更有针对性的收集数据。如果对手修改了Windows注册表值，那就围绕Windows注册表收集遥测数据。如执行操作的进程或用户，以了解对手是怎样修改注册表的。

图15：注册表项作为主要数据元素

还可以对相关的数据元素进行分组，以构建需要收集哪些内容的宏观概念。如对网络流量元数据的数据元素进行分组，并将其命名为Netflow。

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

3、 合并数据建模和对手建模

利用数据建模概念还可以增强ATT&CK当前将数据源映射到技术或子技术的能力。分解数据源并标准化数据元素相互关联的方式将使我们从数据的角度开始了解更多关于对手行为的上下文。ATT&CK使用者可以运用这些概念，判定他们需要收集哪些事件，以确保对对手行为的覆盖。

如下图，围绕对手行为的上下文数据元素可以为Windows注册表数据源提供更多信息。从Windows注册表一直延伸到进程-创建行为-注册表键。这只是映射到Windows注册表数据源的一种关系。这些额外的信息将有助于更好地理解需要收集的具体数据。

图17：ATT&CKcon 2019演讲——准备好ATT&CK了吗？带上自己的数据(BYOD)，验证你的数据分析

4、 将数据源作为对象集成到ATT&CK中

ATT&CK的关键部分——战术、技术和团队——都可以被定义为对象。下图演示了如何在框架中表示技术对象。

图18：带有数据源对象的ATT&CK对象模型

虽然数据源一直是具体技术的属性/字段，但现在是将它们转换为独立对象的时候了。

5、 扩展ATT&CK数据源对象&CK中

一旦将数据源作为对象集成进ATT&CK框架中，并建立了一种结构化的方法来定义数据源，就可以开始以属性的形式识别附加信息或元数据。

下表是数据源对象属性的初步设计：

表3：数据建模概念

这些属性初设将把ATT&CK数据源提升到新维度，并为更多信息敞开大门，这些信息反过来又会为更有效的数据收集策略提出要求。

6、 数据组件扩展数据源

我们前面讨论的与数据源相关的数据元素（如进程、IP、文件、注册表）之间的关系可以组合在一起，并为数据源提供额外的上下文子层。这个概念成为了开源安全事件元数据（OSSEM）项目的一部分，并在2018年和2019年的ATT&CKcon上进行了介绍。我们将这个概念称为数据组件。

7、 数据组间实战

如下图所示，我们扩展了进程的概念，并定义了一些数据组件，包括进程创建和进程网络连接，以提供额外的上下文，以了解如何从进程的角度进行数据收集。

图19：数据组件和数据源间关系

继续对上图进行丰富，以展示ATT&CK与信息安全社区间关系。如下图所示。

图20：扩展ATT&CK数据源

下一步计划

在本系列的第二篇文章中，我们将继续探索新的方法论来帮助定义ATT&CK数据源对象，以及如何使用现有的数据源来实现。还将发布应用数据建模概念输出的新数据源对象原型后的初步分析。

·

end

·

数据运营·情报赋能