【APT检测——论文精读】SLEUTH: Real-time Attack Scenario Reconstruction from COTS Audit Data

2017 USENIX Security 顶会

Abstract

提出了一种实时重建企业主机攻击场景的方法和系统。为了满足问题的可扩展性和实时性需求，我们开发了一个平台中立的、基于主存的、并使用依赖图来抽象审计数据。然后，我们提出了有效的、基于标签的攻击检测和重建技术，包括源识别和影响分析。我们还开发了一些方法，通过构造紧凑的攻击步骤可视化图来揭示攻击的全貌。我们的系统参加了DARPA组织的红队评估，能够成功检测并重建红队对运行Windows、FreeBSD和Linux的主机的攻击细节。

Introduction

我们目睹了有针对性的网络攻击(“企业高级和持续威胁(apt)”)[1]的快速升级，这些攻击是由熟练的对手发起的。通过将社会工程技术(如鱼叉式网络钓鱼)与先进的漏洞利用技术相结合，这些攻击者通常会绕过广泛部署的软件保护，如ASLR、DEP和沙箱。因此，企业越来越依赖于二线防御，例如入侵检测系统(IDS)、安全信息和事件管理(SIEM)工具、身份和访问管理工具以及应用程序防火墙。虽然这些工具通常是有用的，但它们通常会产生大量的信息，使安全分析师难以区分真正的重大攻击犹如“大海捞针”。此外，分析人员缺乏“connect the dots（链接各个点）”的工具，即将跨越多个应用程序或主机并在很长一段时间内扩展的攻击活动的片段拼凑在一起。相反，需要大量的手工工作和专业知识来拼凑多个安全工具发出的大量警报。因此，许多攻击活动被忽略了数周甚至数月[7,40]。

为了有效地遏制高级攻击活动，分析人员需要新一代的工具，这些工具不仅可以帮助检测，还可以生成一个简洁的因果链总结，总结攻击。这样的摘要将使分析人员能够快速确定是否存在重大入侵，了解攻击者最初是如何破坏安全性的，并确定攻击的影响。

将导致攻击的事件因果链拼凑在一起的问题在Backtracker中首次进行了探讨[25,26]。随后的研究[31,37]提高了Backtracker构建的依赖链的精度。然而，这些工作是在纯粹的取证环境（forensic setting）中进行的，因此不能处理实时执行分析的挑战。相比之下，本文介绍了SLEUTH一个可以实时提醒分析人员正在进行的活动的系统，并在攻击发生后的几秒钟或几分钟内为他们提供一个紧凑的、可视化的活动摘要。这将使受害企业在遭受巨大损害之前能够及时作出反应。

与纯粹的取证分析相比，实时攻击检测和场景重建带来了以下额外的挑战:

1. 事件存储和分析:我们如何有效地存储来自事件流的数百万条记录，并让算法在几秒钟内筛选这些数据?
2. 分析确定实体的优先级:我们如何帮助被大量数据淹没的分析人员确定优先级并快速“放大”最有可能的攻击场景?
3. 场景重建:我们如何简洁地总结攻击场景，从攻击者的入口点开始，并确定整个活动对系统的影响?
4. 处理常见的使用场景:如何处理正常的、良性的活动，这些活动可能类似于攻击期间通常观察到的活动，例如软件下载?
5. 快速、互动的推理:我们如何为分析师提供通过数据进行有效推理的能力，比如，用另一个假设?

SLEUTH假设攻击最初来自企业外部。例如，攻击者可以通过外部提供的恶意输入劫持web浏览器，插入受感染的USB记忆棒，或者向企业内部运行的网络服务器提供零日漏洞来启动攻击。我们假设在SLEUTH开始监控系统之前，攻击者还没有在主机上植入持久的恶意软件。我们还假设操作系统内核和审计系统是值得信赖的。

1.1 Approach Overview and Contributions

Figure 1 概述了我们的方法。SLEUTH是操作系统中立的，目前支持微软Windows, Linux和FreeBSD。来自这些操作系统的审计数据被处理成与平台无关的图形表示，其中顶点表示subjects(进程)和objects(文件、套接字)，边表示审计事件(例如，读、写、执行和连接等操作)。该图可以作为攻击检测的基础，也可以作为因果关系分析和场景重建的基础。

• 解决了高效事件存储和分析的挑战，是开发了紧凑的主存依赖图表示(第2节)。在主存表示上的图形算法可以比磁盘表示快几个数量级，这是实现实时分析能力的一个重要因素。在我们的实验中，我们能够在14秒内处理来自FreeBSD系统的79小时的审计数据，主内存使用量为84MB。该性能表示的分析速率比生成数据的速率快20K倍。
• 本文的第二个主要贡献是开发了一种基于标签的方法，用于识别最有可能参与攻击的subject、对象和事件。标签使我们能够确定优先级并集中分析，从而解决上面提到的第二个挑战。标签编码了对数据(即对象)和过程(subject)的可信度和敏感性的评估。此评估基于来自审计日志的数据来源。从这个意义上说，从审计数据派生的标签类似于粗粒度信息流标签。我们的分析自然也可以支持更细粒度的标签，例如，细粒度的污点标签[42,58]，如果它们可用的话。第3节将更详细地描述标签，以及它们在攻击检测中的应用。
• 本文的第三个贡献是开发了利用标签进行入口点识别和影响分析的新算法(第5节)。从图1所示的攻击检测组件产生的警报开始，我们的反向分析算法遵循图中的依赖关系来识别攻击源。从源开始，我们使用前向搜索对对手的行动进行全面的影响分析。我们提出了几个标准来修剪这些搜索，以产生一个紧凑的图。我们还提出了一些转换，进一步简化了这个图，并产生了一个以简洁和语义有意义的方式直观地捕捉攻击的图，例如图4中的图。实验表明，我们基于标签的方法非常有效:例如，SLEUTH可以分析3850万个事件，并生成一个仅包含130个事件的攻击场景图，表示事件量减少了五个数量级。
• 本文的第四个贡献，旨在解决上面提到的最后两个挑战，是一个用于标签初始化和传播的可定制策略框架(第4节)。我们的框架带有合理的默认值，但可以覆盖它们以适应特定于操作系统或应用程序的行为。这使我们能够调整检测和分析技术，以避免在良性应用程序表现出类似攻击行为的情况下误报。(详情见6.6节。)策略还使分析人员能够通过重新分类被认为值得信赖或敏感的内容并重新运行分析来测试攻击的“替代假设”。如果分析人员怀疑某些行为是攻击的结果，他们还可以使用策略来捕获这些行为，并重新运行分析以发现其原因和影响。由于我们处理和分析审计数据的速度比生成审计数据的速度快数万倍，因此可以对不同的假设进行高效、并行、实时的测试。
• 本文的最后贡献是一个实验评估(第6节)，主要基于DARPA组织的红队评估，作为其透明计算计划的一部分。在这次评估中，类似现代apt的攻击活动在Windows、FreeBSD和Linux主机上进行了为期两周的攻击。在这次评估中，SLEUTH能够:
  • 在几秒钟内处理审计日志，其中包含审计业务期间产生的数千万个事件;
  • 成功检测并重建这些攻击的细节，包括它们的入口点、系统中的活动和渗出点;
  • 过滤掉无关事件，在数据中实现非常高的减少率(高达100K次)，从而提供这些攻击的清晰语义表示，几乎没有来自系统中其他活动的噪音;
  • 实现低假阳性和假阴性率。

我们的评估并不是要表明我们发现了最老练的对手;相反，我们的观点是，考虑到一些未知的可能性，我们的系统可以在没有任何人工帮助的情况下，实时地给出正确的优先结果。因此，它确实填补了目前存在的一个空白，即取证分析似乎主要是手动启动的

2 主内存依赖图

为了支持快速检测和实时分析，我们将依赖关系存储在图数据结构中。存储此图的一个可能选择是图形数据库。然而，Neo4J[4]或Titan[6]等流行数据库的性能[39]对于许多图算法来说是有限的，除非主存足够大以容纳大部分数据。此外，对于我们的问题来说，一般图数据库的内存使用过高。即使是STINGER[16]和NetworkX[5]这两个针对主存性能进行优化的图数据库，每个图边也分别使用约250字节和3KB[39]。每天在企业网络上报告的审计事件数量很容易在数十亿到数百亿之间，这将需要几tb的主内存。相比之下，我们提出了一个更节省空间的依赖图设计，每条边只使用大约10个字节。在一次实验中，我们能够在329MB的主内存中存储38M个事件。
依赖关系图是每个主机的数据结构。它可以引用其他主机上的实体，但针对主机内部引用的常见情况进行了优化。图表示两种类型的实体:subjects表示进程，objects表示文件、管道和网络连接等实体的对象。subjects属性包括进程id (pid)、命令行、所有者以及代码和数据的标记。objects属性包括名称、类型(文件、管道、套接字等)、所有者和标记。

使用objects和subjects之间或两个subjects之间的标记边缘捕获审计日志中报告的事件。为简洁起见，我们对事件使用read、connect和execute等UNIX名称。

我们已经开发了许多技术来减少依赖性图的存储需求。只要有可能，我们就使用32位标识符而不是64位指针。这允许单个主机的依赖图包含40亿个objects和subjects。在我们最大的数据集中，objects/subjects的数量比这个数字小几个数量级。

虽然我们的设计强调objects和subjects的紧凑数据结构，但事件的紧凑性更为重要:在我们最大的数据集中，事件的数量比objects和subjects多两个数量级。此外，事件与objects+subjects的比例随着时间的推移而增加。出于这个原因，我们开发了一种超紧凑的事件表示，对于许多事件只需6字节的存储空间。

事件存储在subjects中，因此不需要subjects到事件的指针，也不需要事件标识符。它们的表示使用可变长度编码，因此在典型情况下，它们只能使用4字节的存储空间，但在需要时，它们可以使用8、12或16字节。大多数事件都在对象上操作，并具有时间戳。由于维护了每个subject的事件顺序，所以我们不用微秒粒度的时间戳，而是选择毫秒级的分辨率。此外，我们只存储自同一subject上的最后一个事件以来的相对时间，这允许我们在典型情况下使用16位时间戳。在事件中使用索引来表示object，索引在含有object标识符的每个subject表可以查询。这些索引可以看作是文件描述符——它们往往具有较小的值，因为大多数subjects使用相对较少的objects。这使得objects引用可以用8位或更少的比特来表示。我们对频繁发生的事件(例如，打开，关闭，读取和写入)使用3位或更少的事件名称进行编码。这就为我们留下了几个位来存储事件参数信息的摘要，但仍然在32位之内。

我们可以使用存储在subjects中的事件数据实现从subjects导航到objects。我们需要使用object-事件记录来维护object中的事件信息。object-事件记录仅为事件子集维护:具体来说，是导致数据流的读和写等事件。其他事件(例如，open)不存储在object中。通过存储对相应subject-事件记录的引用，而不是复制信息，可以进一步缩小object-事件记录。

与subject事件记录一样，我们对object事件记录使用可变长度编码，使它们能够在最常见的情况下仅以16位存储。要了解这是如何可能的，请注意对象往往是由单个subject一次操作的。通常，该subject对对象执行一系列操作，例如，打开，然后进行一些读取或写入，然后关闭。通过允许对象-事件记录重用其前身的subject，我们可以避免在大多数记录中存储subject标识符的需要。接下来，我们允许对象-事件记录在subject中存储事件记录的相对索引。同一subject中操作同一对象的两个连续事件记录可能彼此相对较近，例如，中间有数十或数百个事件。这意味着存储在对象事件记录中的相对索引在大多数情况下可以是12位或更少，因此在典型情况下允许这些记录是16位或更少。

因此，这种设计允许我们在6字节内存储双向时间戳边(subject事件记录为4字节，对象事件记录为2字节)。在使用较大数据集的实验中，我们系统的总内存使用量平均在每个事件10字节以内。

可变长度编码允许我们表示重要(但罕见)事件的完整信息，例如rename、chmod、execute等。因此，在不丢失任何重要信息的情况下实现了紧凑性。尽管这种编码减慢了访问速度，但访问时间通常仍小于100ns，这比磁盘延迟快了许多个数量级，磁盘延迟在磁盘驻留数据结构上的随机访问中占主导地位。

3 标签和攻击检测

我们使用标签来总结我们对对象和subject的可信度和敏感性的评估。这种评估可以基于三个主要因素:

• 出处:依赖图中对象或subject的父节点上的标签;
• 先验系统知识:我们对重要应用程序(如远程访问服务器和软件安装程序)和重要文件(如/etc/passwd和/dev/audio)行为的了解
• 行为:观察对象的行为，以及他们与预期行为的比较。
  我们已经开发了一个策略框架，如第4节所述，用于根据这些因素初始化和传播标签。在没有特定策略的情况下，使用默认策略将标记从输入传播到输出。默认策略将输入的可信度标签中最低的标签和机密性标签中最高的标签分配给输出。此策略是保守的:它可能会出现过度污染的错误，但不会导致攻击未被检测到，或者导致前向(或后向)分析错过objects, subjects 和事件。

标签在SLEUTH中起着核心作用。它们为攻击检测提供了重要的上下文。在这些标记的上下文中解释每个审计事件，以确定其导致攻击的可能性。此外，标签对于我们向前和向后分析的速度是有用的。最后，标签在场景重建中发挥着核心作用，它消除了大量审计数据，这些审计数据满足依赖性的技术定义，但对我们理解攻击没有任何意义。

3.1 标签设计

我们定义了以下可信性标签(t-tags):

• 良性的可信标签被分配给从可信的源接收的数据/代码，其真实性可以验证。
• 良性标签反映的信任程度比良性可信低:虽然数据/代码仍然被认为是良性的，但没有执行足够的身份验证来验证源。
• 未知标签是指来自我们没有可信度信息的来源的数据/代码。这些数据有时可能是恶意的。

策略定义了哪些源是良性的，哪些形式的身份验证是足够的。在最简单的情况下，这些策略采用白名单的形式，但我们也支持更复杂的策略。如果没有策略适用于某个源，则将其t标记设置为unknown。
我们定义了以下保密标签(c-tags)，来解释信息窃取攻击:

• 机密:高度敏感的信息，如登录凭据和私钥。

• 敏感:披露会对安全产生重大影响的数据，例如，披露系统中的漏洞，但不会为攻击者提供访问系统的直接途径。

• 私有:其披露涉及隐私问题，但不一定构成安全威胁的数据。

• 公共:可以广泛获得的数据，例如，在公共网站上。

我们设计的一个重要方面是代码和数据之间的t-tags的分离。具体来说，一个subject(即一个进程)被赋予两个t-tags:一个用于捕获其代码可信度(代码t-tags)，另一个用于捕获其数据可信度(数据t-tags)。这种分离极大地改进了攻击检测。更重要的是，它可以通过专注于更少的可疑事件来显著加快取证分析，同时大大减少重建场景的规模。注意，c-tag只与数据(而不是代码)相关联。

使用标记初始化策略为预先存在的subject和object分配初始标记。== 表示外部实体(如远程网络连接)的对象也需要分配初始标记。其余的subject和object是在系统执行期间创建的，它们的标记是使用标记传播策略确定的==。最后，使用基于行为的策略(称为检测策略)来检测攻击。如前所述，如果没有提供特定的策略，则将源标记为未知的可信度。同样，如果没有特定的传播策略，则使用默认的保守传播策略。

3.2 基于标签的攻击检测

SLEUTH中的一个重要约束是，我们只能使用审计数据中可用的信息。这表明可以使用审计数据作为反映作为检测的可能依据的来源。由于标签是来源的方法，我们将它们用于攻击检测。请注意，在我们的威胁模型中，审计数据是可信的，因此标记为检测提供了可靠的基础。
SLEUTH的第二个限制是检测方法不需要详细的应用程序特定知识。相比之下，大多数现有的入侵检测和沙箱技术在特定应用程序的上下文中解释每个安全敏感操作，以确定它是否可能是恶意的。这需要有关应用程序的专业知识，或者在动态环境中进行现场培训，其中应用程序可能经常更新。
我们的检测技术不是关注那些易变的应用程序行为，而是关注大多数攻击者的高级目标，比如后门插入和数据泄露。具体来说，我们结合了对攻击者动机和手段的推理。如果审计数据中的事件可以帮助攻击者实现他/她的关键高级目标，这将为在攻击中使用该事件提供动机和理由。但这还不够:攻击者还需要手段来引起这一事件。请注意，我们的标签被设计为捕获手段:如果一段数据或代码带有未知的t标签，那么它来自(因此受到)不可信的来源。
至于攻击者的高级目标，一些报告和白皮书已经确定了以下步骤是大多数高级攻击活动的典型步骤：

1. 在受害系统上部署和运行攻击者的代码。
2. 替换或修改重要文件，例如/etc/passwd或ssh key。
3. 泄露敏感数据。

具有短暂影响的攻击可能能够避免前两个步骤，但大多数复杂的攻击，例如APT活动中使用的攻击，需要在受害者系统上建立更永久的足迹。在这些情况下，似乎没有办法避免前两个步骤中的一个或两个。即使在不建立永久基地的情况下，攻击者的目标也可以实现，第三步通常代表了攻击者的基本目标。

基于上述推理，我们定义了以下攻击检测策略，这些策略包含了攻击者的目标和手段:

t-tag为可信标签，c-tag保密标签

• 不受信任的代码执行:当具有较高代码t-tag的subject执行(或加载)具有较低t-tag的object时，此策略将触发警报。
• 低t-tag的subject修改:当低t-tag的进程修改高t-tag的对象时，该策略会发出告警。
• 修改可能涉及文件内容或其他属性，如名称、权限等。
• 机密数据泄露:当不受信任的进程泄露敏感数据时，会发出告警。具体来说，该策略是在具有敏感c标签和未知代码t标签的subject进行网络写入时触发的。
• 为执行准备不受信任的数据:此策略由带有未知代码标签的subject的操作触发，前提是该操作使对象可执行。这些操作包括chmod和mprotect。

重要的是要注意，“means”不会因为数据或代码通过多个中间节点而被淡化。例如，不可信代码策略不需要从未知网站直接加载数据;相反，数据可以下载、提取、解压缩，并可能进行编译，然后加载。无论中间步骤有多少，在加载或执行结果文件时都会触发此策略。这是我们的攻击检测有效的最重要的原因之一。

当前的漏洞利用通常在第一步中不涉及不受信任的代码，因此不会被不受信任的代码执行策略检测到。然而，攻击者的最终目标是执行他/她的代码，或者通过下载和执行文件，或者通过向包含不受信任数据的内存页添加执行权限。在任何一种情况下，上述策略都可以检测到攻击。随后的反向分析可以帮助识别漏洞利用的第一步。

其他的检测器输入可以很容易地集成到SLEUTH。例如，如果外部检测器将进程标记为可疑对象，则可以通过将subject的t标记设置为unknown来实现。因此，上面提到的其余检测策略都可以从外部检测器提供的信息中获益。此外，在可疑节点设置未知t标签保留了引起警报的图顶点之间的依赖结构，这是我们在取证分析中利用的事实。

我们的许多策略是由不受信任的代码执行触发的，这一事实不应该被解释为意味着它们在静态环境中工作，在静态环境中，系统中不允许有新代码。的确，我们希望软件更新和升级不断发生，但在企业环境中，我们不希望最终用户从随机站点下载未知代码。因此，我们随后描述了如何支持标准化的软件更新机制，例如在当代操作系统上使用的那些机制。

4 Policy Framework

我们为标签分配、传播和攻击检测开发了一个灵活的策略框架。我们使用一种简单的基于规则的符号来表示策略

当进程执行t标记小于良性的(文件)对象时触发此规则。它的作用是引发一个名为UntrustedExec的警报。如本例所示，规则通常与事件相关联，并包括事件中涉及的对象和/或subject的属性条件。感兴趣的属性包括:

带有策略触发点的边。direction栏中，S表示subject，O表示客体。接下来的两列表示检测策略和标记设置策略的触发点。

• name：正则表达式可用于匹配object名称和subject命令行。正则表达式使用Perl语法。

• 标签:条件可以放在对象和/或主题的t标签和c标签上。对于主题，代码和数据t-标签可以独立访问。

• 所有权和许可:条件可以放在对象和主体的所有权上，或者与对象或事件相关的权限。

策略的效果取决于它的类型。检测策略的作用是发出告警。对于标记初始化和传播策略，其效果是修改与事件中涉及的对象或主题关联的标记。虽然我们在本文中使用基于规则的符号来指定策略，但在我们的实现中，每个规则都被编码为(c++)函数。

为了更好地控制检查不同类型策略的顺序，我们将策略与触发点(而不是事件)关联起来。此外，触发点提供了一定程度的间接性，支持在具有相似目的的不同事件共享策略。表2显示了当前在策略框架中定义的触发点。第一列标识事件，第二列指定信息流的方向，最后两列定义与这些事件关联的触发点。

请注意，我们使用一个名为define的特殊事件来表示定义新对象的审计记录。这个伪事件假定在第一次遇到一个新对象时发生，例如，建立一个新的网络连接，第一次提到一个预先存在的文件，创建一个新文件等。表中的其余事件是不言自明的。

事件发生后，将执行与该告警触发器关联的所有检测策略。除非特别配置，否则仅在目标主体或对象的标签即将更改时才检查检测策略。
(这里的“目标”是指操作中数据流的目的地。)在此之后，将按照指定的顺序尝试与事件标记触发器关联的策略。一旦找到匹配的规则，此规则指定的tag被分配给事件指向的节点，并且不评估其余的标记策略。

我们当前的检测策略在前一节中有非正式的描述。因此，在本节中，我们将重点讨论当前的标记初始化和传播策略。

4.1 标记的初始化策略

这些策略在init触发器处调用，并用于初始化新对象的标记，或者在审计数据中首次提到之前存在的对象时初始化它们。回想一下，当一个主题创建一个新对象时，该对象默认继承主题的标签;但是，可以使用标记初始化策略覆盖这一点。

我们当前的标签初始化策略如下。注意使用正则表达式方便地为对象组定义初始标记。

第一条规则为内网连接指定标签，由远程主机的地址前缀10.0和127标识。它在没有在远程主机上部署SLEUTH的上下文中很有用。第二条规则指出，所有其他主机都是不可信的。第三条规则为所有预先存在的文件分配了相同的标记。我们的实现使用了另外两个指定c-标签的策略。

4.2 标签传播策略

这些策略可用于覆盖默认标记传播语义。可以为相关事件类型的不同组定义不同的标记传播策略，如表2中的“tag trigger”列所示。

标记传播策略可用于防止由于每次调用应用程序时重复读写.bash历史记录等文件而导致的“过度污染”。以下策略跳过此特定文件的污染传播:

这里有一个策略，它将bash(解释器)读取的文件视为加载，并因此更新代码t标记。

尽管可信的服务器(如sshd)与不可信的站点交互，但它们可以保护自己，并且只允许授权用户访问系统。这样的服务器不应该降低它们的数据可信度。类似的评论也适用于软件更新程序和安装程序，这些程序从不受信任的网站下载代码，但在安装之前会验证受信任的软件提供商的签名。

此外，当登录阶段完成时(通常通过执行setuid操作来标识)，应该为进程分配适当的标记。

5 基于标签的双向分析

5.1 反向分析

反向分析的目标是确定攻击活动的入口点。入口点是图中in度为零并标记为不可信的节点。通常它们代表网络连接，但它们也可以是其他类型的，例如，插入受害者主机的USB棒上的文件。

反向分析的起点是检测策略产生的告警。特别是，每个告警都与一个或多个实体相关，这些实体在图中被标记为可疑节点。向后搜索涉及到图的向后遍历，以确定连接可疑节点到入口节点的路径。

我们注意到，在这样的遍历和下面的讨论中，依赖边的方向是颠倒的。向后搜索带来了几个重大挑战:

• 性能:依赖图很容易包含数亿条边。警报很容易达到数千个。在如此大的图上运行反向搜索在计算上是非常昂贵的。

• 多路径:通常从一个可疑节点可以向后到达多个入口点。然而，在apt类型的攻击中，通常只有一个真正的入口点。因此，简单的向后搜索可能导致大量误报。

我们的方法背后的关键见解是，标签可以用来解决这两个挑战。实际上，标签的计算和传播已经是一种隐式的路径计算，可以重用。此外，节点上的标记值为unknown提供了该节点成为攻击潜在部分的可能性的重要线索。特别是，如果某个节点A存在未知标签，这意味着至少存在从不受信任的入口节点到节点A的路径，因此节点A比其他具有良性标签的邻居更有可能成为攻击的一部分。利用标签进行逆向搜索，消除了大量不相干的节点，大大减少了搜索空间

基于这一见解，我们将反向分析作为最短路径问题的一个实例，其中标签用于定义边缘成本。实际上，标签能够“引导”搜索沿着相关的路径，远离不太可能的路径。这个因素使得无需遍历整个图即可完成搜索，从而解决了性能挑战。此外，我们的最短路径公式通过优先选择最接近可疑节点的入口点(通过路径成本测量)来解决多路径挑战。

对于最短路径，我们使用Dijkstra算法，因为它按照成本的递增顺序发现路径。特别是，该算法的每一步都向最短路径树添加一个节点，该树由迄今为止计算的最短路径组成。这样一来，一旦将一个入口点节点添加到此树中，就可以立即停止搜索。

成本函数设计。我们的设计将低成本分配给具有未知标签的节点依赖的边，而将高成本分配给其他边。具体费用如下:

• 引入从未知代码或数据t标签的节点到具有良性代码或数据t标签的节点的依赖的边的代价为0。

• 引入依赖于具有良性代码和数据t标签的节点的边缘被分配了高成本。

• 在已经有未知标签的节点之间引入依赖关系的边被分配成本为1。

这种设计背后的直觉如下。与未知主题/对象直接相关的良性主题或对象表示图中恶意部分和良性部分之间的边界。因此，它们必须包含在搜索中，因此这些边的代价为0。良性实体之间的信息流不是攻击的一部分，因此我们将它们的代价设置得非常高，以便它们被排除在搜索之外。不可信节点之间的信息流很可能是攻击的一部分，因此我们将其代价设置为较低的值。除非存在包含较少边的替代路径，否则它们将被包含在搜索结果中。

5.2 正向分析

正向分析的目的是通过从一个切入点开始，并发现依赖于切入点的所有可能的影响，来评估活动的影响。与反向分析类似，主要的挑战是图的大小。一种朴素的方法将识别并标记从通过向后分析确定的入口点可到达的所有主题和对象。不幸的是，这样的方法将导致影响图太大而对分析人员无用。例如，在我们的实验中，一个简单的分析产生了具有数百万条边的影响图，而我们的改进算法将这个数字减少了100倍到500倍。

减小大小的一种自然方法是使用距离阈值dth来排除距离可疑节点“太远”的节点。阈值d可以由分析人员交互式地进行调整。我们使用了与反向分析相同的成本度量，但进行了修改以考虑机密性。特别是，具有高机密性标签(例如secret)的节点与具有低代码完整性标签(例如未知进程)或低数据完整性标签(例如未知套接字)的节点之间的边被分配的代价为0，而具有良性标签的节点的边被分配的代价为高。

5.3 重建与呈现

为了提供更简洁的攻击视图，我们将以下简化应用于前向分析的输出:

• 修剪无兴趣的节点。前向分析的结果可能包括许多与攻击无关的依赖关系，例如，主题写入缓存和日志文件，或者写入临时文件然后删除它。这些节点可能出现在正向分析的结果中，但没有可疑节点依赖于它们，因此可以对其进行修剪。

• 合并名称相同的实体。这种简化合并了具有相同名称的主题，而忽略了它们的进程id和命令行参数。

• 重复事件过滤。这种简化将同一实体之间多次发生的事件(例如，多次写，多次读)合并为一个。如果存在交错事件，那么我们将显示两个事件，分别表示两个实体之间事件的第一次和最后一次发生。

实验结果