depcomm论文精读笔记

DEPCOMM论文精读笔记

论文基本信息：

会议名：IEEE Symposium on Security and Privacy （S&P）

会议级别：CCF-A

会议track：research track

年份：2022

标题：DEPCOMM: Graph Summarization on System Audit Logs for Attack Investigation

作者及工作单位：

Abstract

（背景介绍，因果关系分析的应用）因果关系分析从系统审计日志中生成依赖关系图，这已成为攻击调查的重要解决方案。在依赖关系图中，节点表示系统实体（如process和file），边表示实体之间的依赖关系（如写入文件的进程）。（提出挑战，即这种方法存在的问题/挑战）尽管早期的结果取得了好的效果，但因果关系分析经常产生一个大规模图（大于10万条边），对安全分析人员来说，检查这样一个大规模图进行攻击调查是一项艰巨的任务。（解决挑战，提出本文方法）为了解决攻击调查中的上述挑战，本文提出了DEPCOMM，这是一种图总结方法，通过将一个大规模图划分为以进程（process）为中心的社区，并为每个社区呈现总结概览，从依赖图生成总结（摘要）图。（具体阐述本文方法）具体地说，每个社区都由一组相互协作的紧密进程组成，这些进程完成特定的系统活动（例如，文件压缩），以及这些进程访问的资源（例如，文件）。在社区中，DEPCOMM进一步识别由不那么重要和重复的系统活动引起的冗余边，并对这些边进行压缩。最后，DEPCOMM使用表示跨社区的信息流的InfoPaths为每个社区生成摘要。这些InfoPaths更有可能捕获一组与攻击相关的进程，这些进程协同工作以实现某些恶意目标。（实验评估，先叙述在减少规模上的效果）本文对真实攻击（约1.5亿个事件）的评估表明，DEPCOMM为一个依赖图平均生成18.4个社区，这比原始图小了约70倍。DEEPCOMM的压缩进一步将每个社区的边平均减少到32.1条。（与baselines相比，社区发现方面效果）与9种最先进的社区发现算法相比，DEPCOMM在社区发现方面的F1-score比这些算法高2.29倍。（与HOLMES结合）通过与自动技术HOLMES的结合，DEPCOMM可以识别出与攻击相关的社区，召回率达到96.2%。（上升到实际应用）本文对真实攻击的案例研究也证明了DEPCOMM在促进攻击调查方面的有效性。

keywords：attack investigation；system auditing；graph summarization；community detection

1. INTRODUCTION

（背景，引入系统审计日志和因果分析）最近的网络攻击已经渗透到许多保护良好的企业，造成重大经济损失。为了对抗这些攻击，基于ubiquitous system monitoring的因果分析成为攻击调查的重要方法。（系统审计日志来源，将什么作为研究/检测对象）监视系统观察系统之间的下响应，并将生成的核级审计事件作为系统审计日志。（这些日志作用）这些日志使因果关系分析能够识别入侵实体（后向索引），也能够识别攻击的后果（前向索引），这在协助攻击调查和及时系统恢复方面是有效的。

（介绍因果分析方法，依赖图）虽然早期的结果表明因果关系分析是有效的方法，但现有的方法需要大量的人工检查，这阻碍了它们的广泛应用。因果关系分析方法认为，在同一个系统调用事件（例如，读取文件的进程）中涉及的系统实体（例如，文件、进程和网络连接）具有因果依赖性。（指出依赖图的优势）基于这些依赖关系，这些方法使用系统依赖关系图来表示系统调用事件，其中节点表示系统实体，边表示从系统事件派生的依赖关系。使用依赖图，安全分析人员可以通过重构导致POI （Point-Of-Interest，可理解为攻击行为事件，破坏性大事件）事件的事件链（例如，入侵检测系统报告的警报事件）来调查攻击的上下文信息。（指出优势，但存在挑战，依赖爆炸问题）这样的上下文信息可以有效地揭示与攻击相关的事件，例如区分ZIP的良性使用与勒索软件。然而，由于依赖爆炸问题，安全分析人员很难有效地从一个巨大的图（通常包含大于100K条边）中提取所需的上下文信息。

（为解决这个挑战的相关工作存在的问题，或者效果不好的原因）意识到在攻击调查中使用依赖图的挑战，最近有学者提出了自动过滤无关事件并揭示攻击相关事件的技术。虽然这些技术取得了很好的效果，但由于三个主要原因，手工攻击调查仍然是必不可少的。首先，尽管很少，但系统中总是存在残留风险，这些自动化技术无法准确地揭示这些风险，特别是对于严重依赖系统概要的技术。其次，威胁在不断演变，以规避防御技术，例如新兴的攻击战术和攻击者最近开发的技术。第三，现有技术主要依赖于启发式规则，导致信息丢失和入侵式系统变化，如二进制工具，阻碍了其实际应用。

（本文方法DEEPCOMM动机）Motivation.为了有效地协助攻击调查，在本文中，我们旨在开发一种图摘要方法，该方法可以在依赖图中保留系统活动的语义关系，同时通过隐藏不太重要的细节来缩小依赖图的大小。更具体地说，我们的目标是通过将依赖关系图划分为许多社区（即子图）并为每个社区提供简洁的摘要来生成一个摘要图。每个社区只包含密切相关的进程，它们一起协作以完成某些系统任务（例如，文件压缩）。然后，我们计算使用这些流程及其访问的资源的摘要，这些资源可以表示高级系统活动，共同勾勒出原始依赖关系图的框架。此外，我们的图总结可以与现有的自动调查技术相结合，以突出体现与攻击相关的社区。

（指出DEEPCOMM存在的挑战）**Challenges. **图摘要技术通过生成图的紧凑表示，即摘要图，可以有效地管理大规模图。然而，关于摘要图对攻击调查的安全影响的研究很少。特别是，依赖图的独特特征为DEPCOMM生成依赖图的摘要图带来了三个主要挑战。

• 依赖图是一种异构图，其中节点表示不同类型的系统实体（即进程、文件和网络连接），并在攻击步骤中扮演不同的角色。一种通用的总结技术，如果平均对待每个节点，就不能有效地检测代表主要系统活动的社区。此外，非安全域的特定于域的技术，即使是为异构图设计的，也很可能导致攻击信息的丢失。（如何保证依赖图（异构图）中的全面信息，并有效检测社区？）
• 因果关系分析依赖于事件时间来识别因果依赖关系（例如，一个进程在另一个进程写入文件之后读取一个文件），而依赖关系图包含了许多不太重要的依赖关系，这些依赖关系代表了不相关的系统活动，如记录系统维护任务和不相关的网页浏览。这些依赖关系却成为依赖关系图的主要部分，压缩这些活动是一项具有挑战性的任务。（如何去除图中不重要的依赖关系，从而压缩图）
• 图摘要技术主要处理存储在数据库中的数据，其模式和约束在生成的摘要图中起着重要作用。但是在依赖图中，表示系统活动的边序列应该是生成的攻击调查摘要图的核心。如何总结这些边序列成为DEPCOMM的另一个挑战。（如何对边序列进行摘要总结？）

（指出DEEPCOMM的贡献）**Contributions. **为了解决上述依赖图在图摘要方面的挑战，我们提出了DEPCOMM，这是一种图摘要方法，它检测以进程为中心的社区，压缩每个社区内部不太重要的边，并使用表示社区之间信息流的top-ranked路径（最能够代表）来总结每个社区。DEPCOMM是一种对大规模依赖图进行图摘要的通用方法，它可以与各种自动调查技术协作（如何协作？），突出表示与攻击相关的社区，并将其可视化。DEPCOMM的设计由以下的灵感启发：

• 首先，在系统审计日志中，系统活动(（例如，下载恶意脚本并执行该脚本）通常表示为一组进程节点，这些节点之间要么具有很强的相关性，要么通过一些资源节点具有数据依赖性。例如，进程tar生成子进程bzip2，它们一起协作来压缩文件。通过仔细检查进程之间的协作，我们观察到这些进程（1）要么具有父子关系（即，一个进程产生一组子节点），要么（2）共享同一个父进程（即，兄弟进程），并通过某些资源（例如，文件）具有数据依赖性。因此，为了解决**第一个挑战，DEPCOMM将依赖关系图划分为以进程为中心的社区，每个社区包括一组紧密的流程和这些进程访问的系统资源。（贡献一也就解决挑战一，首先说明进程、文件之间的数据依赖性，且共同完成一项活动，利于划分为社区来维持攻击信息**）

• 其次，正如最近的研究所表明的，由于不那么重要和重复的系统活动，如历史记录任务和备份文件更新，会产生许多冗余边。因此，为了解决第二个挑战，DEPCOMM识别 基于进程（process-based） 和 基于资源（resource-based） 的模式，并根据这些模式为每个社区进行压缩。我们的社区检测（发现）不像现有工作那样保留依赖关系，而是允许在社区内的多个进程之间进行有力压缩（那是如何保留依赖关系的？）。（贡献二也就是解决挑战二，如何对社区进行压缩）

• 第三，通过仔细检查各种攻击的依赖图，主要的系统活动（如压缩文件）和攻击行为（如泄漏数据）通常被表示为攻击相关过程之间的信息流，如压缩敏感数据和泄漏压缩文件。这样的信息流通常表示为社区中从输入节点到输出节点的路径，称为InfoPaths。例如，恶意脚本通过打包、加密、上传等方式泄露敏感文件，对应的InfoPath为：…/secret.doc→tar→…/upload.tar→bzip2→

  …/upload.tar.bz2→gpg→…/upload.gpg→curl→xxx->xxx。此外，在一个社区中，从输入到输出可能存在许多infopath，并且不是所有的infopaath都与主要的系统活动相关。因此，为了解决这一挑战，DEPCOMM将每个社区中的信息路径排序（如何排序？），并将更可能代表攻击步骤和主要系统活动的信息路径排在最前面。（贡献三也就是解决挑战三，生成InfoPaths，并对这些InfoPaths排序）

（介绍社区发现、压缩、生成摘要的方法）**Approach. **基于这些想法，DEPCOMM提供了新的技术（是什么？）来检测以进程为中心的社区（社区发现），在被检测的社区内部执行压缩，并为每个社区生成有代表性的摘要。

社区发现：为了检测以进程为中心的社区（第IV-C节），DEPCOMM学习依赖图的进程节点的行为表示形式（图表示学习），并将具有类似表示形式的进程节点聚集到一个社区中。具体来说，DEPCOMM在每个进程节点上执行随机游走，以获得游走序列，并通过向量化这些游走序列来计算每个进程节点的表示。特别是，由于现有的随机游走算法[34-38]（DeepWalk、Node2vec）对每个节点都是平等的，它们在为有紧密联系的进程生成相似的行为表示时效果较差。因此，作者设计了一系列新的分层随机游走方案，利用过程的局部邻居信息和全局过程索引树来选择更容易找到紧密进程的游走序列。通过学习到的每个进程节点的表示，DEPCOMM将这些进程节点聚集到社区中（先将具有紧密关联的进程节点分到同一个社区），并进一步将这些进程访问的资源节点分类到检测到的社区中（然后再去找社区中的进程节点访问的资源节点，从而形成以进程为中心的社区），从而生成以进程为中心的社区。

**社区压缩：**要执行社区压缩（第IV-D节），DEPCOMM首先为每个社区计算一个进程谱系树（如何生成？），并将每个进程节点与访问资源节点的事件关联起来（先生成树）。通过搜索这棵树，DEPCOMM可以识别基于进程的模式（例如，一个bash进程生成多个vim进程）和基于资源的模式（例如，多个vim进程编辑一个源文件）。基于已识别的基于进程和基于资源的模式，DEPCOMM合并所有重复的边和节点，以压缩一个社区。

**生成摘要：**在压缩社区之后，DEPCOMM为每个社区生成InfoPaths，对InfoPaths进行优先级排序，并将排名最高的InfoPaths作为社区的摘要（第IV-E节）。为此，DEPCOMM首先根据社区之间的信息流识别每个社区的输入节点和输出节点，然后通过为每对输入和输出节点查找路径来生成InfoPaths。接下来，DEPCOMM根据每个InfoPath代表社区中的主要系统活动（例如，包含POI事件）的可能性为其分配优先级分数（如何计算分数，为什么可以计算？）。最后，DEPCOMM根据优先级对这些InfoPaths进行排名，并将排名靠前的InfoPaths作为社区的摘要。虽然前2个InfoPaths可以揭示大多数社区的攻击行为（第V-E节），但安全分析人员可以根据他们的需求确定社区摘要中显示的InfoPaths的数量。

（实验评估部分）Evaluation 我们评估了DEPCOMM在我们的实验室设置中执行的6次真实攻击和来自DARPA TC数据集的8次攻击。总共有大约1.5亿个系统审计事件，生成的依赖图平均由1,302.1个节点和7,553.4条边组成。在我们的评估中，DEPCOMM为一个依赖图平均生成18.4个社区，比原始图小了约70倍。这些社区平均包含43.1个节点和248.5条边。与9种最先进的社区检测算法相比，DEPCOMM的f1得分（94.1%）平均比其他算法的f1得分高2.29倍（社区发现方面的效果）。接下来，DEPCOMM根据检测到的基于进程和基于资源的模式压缩社区，平均压缩率为44.7%。压缩后的社区平均有15.7个节点和32.1个边，分别减少了63.6%和87.1%。（社区压缩方面的效果）此外，使用排名前2的InfoPaths可以有效地调查所有攻击，即平均15.7条InfoPaths中有2条作为摘要。这些结果表明，这些摘要图在攻击调查中需要的人工工作要少得多。（图摘要方面的效果）与HOLMES合作的评估表明，除两个攻击相关的社区外，其他所有攻击相关的社区都映射到Kill Chain的步骤上（如何映射的？）（召回率为96.2%），通过考虑相邻的攻击社区，这两个未揭示的社区很容易被识别（与HOLMES结合的效果）。DEPCOMM的实现和评估数据集可以在作者的项目网站上找到。（https://github.com/ieeesp2021sub/depcomm）

2. BACKGROUND AND MOTIVATION

A. System Event and Causality Analysis

System Audit Event

监视和分析内核级审计事件（还需要去理解审计事件，要比较熟）对于攻击调查和检测至关重要。系统审计事件描述了两个系统实体之间的交互，它们被表示为3元组——（主题、操作、对象）。根据前面的工作，主题表示进程实体，对象表示进程、文件或网络实体。系统审计事件根据审计对象的类型进行分类：进程事件、文件事件和网络事件。进程事件记录进程的操作，如fork和clone。文件事件记录了对文件的操作，如文件的读、写、重命名等。网络事件记录了网络访问的操作，如从套接字发送和接收消息。

Causality Analysis

因果分析已广泛应用于攻击调查与检测中。它推断出系统审计事件之间的因果依赖关系，并将它们组织成一个依赖关系图。依赖图是有向图，其中节点表示系统实体（即进程、文件和网络连接），边表示系统审计事件。在依赖图G(E, V)中，将一个系统审计事件表示为有向边E (u, V)，其中u∈V, V∈V, E∈E，边的方向代表数据流的方向（即从u流向V），边记录了事件的开始时间(e.st)和结束时间(e.et)。给定两个节点n1和n2，如果存在两条边e1(n1, v1)和e2(v2, n2)，使v1 = v2，1.st≤e2.et，则n2对n1有因果依赖性。（如下图所示）

B. Motivating Example

我们以数据泄露攻击为例来解释DEPCOMM。在该攻击中，攻击者通过Apache Sever在目标系统中下载并执行一个后门程序bdoor，并利用打开的9999端口后门打开终端（即bash）。然后，攻击者下载一个可执行脚本leak.sh，并利用root访问权限运行该脚本来收集敏感文件，这些文件被发送到可疑的远程主机。进程和操作系统资源之间的所有这些活动都被捕获在系统审计日志中（捕获/采集数据）。我们通过从将文件发送到远程IP的可疑事件（即POI事件）应用因果关系分析来构建依赖关系图（构建依赖关系图，即原始图）。

上图（图1）是数据泄露攻击场景中部分的 dependency graph。完整的 dependency graph 共有 1038 个节点和4039条边（含攻击相关和正常事件）。DEPCOMM将 dependency graph 划分为10个以 process 为中心的社区（C1-C10），其中红色虚线框是具有与攻击事件相关的社区（加粗的红色边），蓝色虚线框是只有正常事件的社区。对于表示社区输入和输出的节点（是什么，为什么这种节点作为输入输出？），DEPCOMM创建此类节点（蓝色节点）的副本，并将每个副本分配给一个社区。这些副本与有向边（蓝色虚线箭头）连接，其中方向表示跨社区信息流的方向。

在本文中，作者设计DEPCOMM将一个大型依赖图总结为一个紧凑的图，以便于攻击调查。DEPCOMM包括三个关键组件：(1)社区检测，(2)社区压缩，(3)社区汇总

用图1解释 community detection 和 community conpression

community dection

DEPCOMM首先将依赖关系图划分为10个以进程为中心的社区（C1-C10），如图1所示。

• 节点：每个社区包含紧密联系的 process 节点以及它们所访问的 resoure 节点。比如在 C3 社区中，leak 这个 process 节点 派生出 tar、bzip2、gpg、curl这些子process节点。并且，/upload.tar.bz2、…/upload.tar、…/upload这些资源节点被以上的进程节点所访问，因此归入C3社区。（区分进程节点和资源节点） 不是说利用图表示学习嘛？
• 边（依赖关系）：① 基于边的依赖关系：表示两个社区相通（联系）的边（如C1和C2中的 bdoor 和 bash）② 基于节点的依赖关系：表示 输入/输出 的关系（如 C2 和 C3 中的 leak）

community compression

在尽可能保持语义关系的前提下减少每个社区中节点和边的数量，如

C9中，bash 派生出 python（12次） 和 vim 节点（13次）（进程节点）去对 …/adjust.py 和 /dev/null（资源节点） 分别进行读取和写入操作 ，这可以总结为 ① process-based pattern（如 bash 派生出 python 和 vim 节点）② resource-based pattern （如 …/adjust.py 被许多 python 和 vim 节点访问）。压缩后，C9的边数从108减少到33（压缩率69.4%）。同样，C5从58条边压缩为2条边(压缩率96.5%)。（图1所示是根据两种模式压缩后展示的图）

community Summarization

上图（图2）是对图1中的 dependency graph 进行 community summarization。包含三部分：① Master process node（社区内各种操作的来源）② time span（社区中最早一个事件的开始时间到最近一个事件的结束时间之间的时间跨度） ③ top-ranked InfoPath（排名最高的InfoPaths，显示社区的主要信息流）如C3中该InfoPath排序最高（leak to xxx->xxx： leak→tar→…/ upload.tar→bzip2→…/upload.tar.bz2→gpg→…/upload→curl→xxx->xxx），因为其包含POI（Point-Of-Interest）事件 curl-xxx-xxx）。（如何标注POI事件？）

用图2解释 Attack Investigation

Attack Investigation

采用图2演示如何从C3中的POI 事件 curl-xxx-xxx去检测攻击。首先，调查所有从 C2、C4、C6、C7、C8到C3的边，发现从C2来的边与C3中的 master 节点 leak 以及 C3中的top1 InfoPath 比 其他社区更相关。因此，C2被认为存在导致 POI 事件（比如 a file download）的攻击行为。然后，对于C2和其他社区之间的边，我们识别出C1的 bdoor→bash 这条边比C5的边更相关（为什么呢？因为C2的InfoPath也有bash嘛？）。此外，从其他社区到C1不存在依赖关系。因此，C1很可能代表攻击的初始步。总之，我们仅通过检查53个节点和8个InfoPaths就识别了35个与攻击相关的事件

3. OVERVIEW AND THREA T MODEL

上图（图3）表示DEPCOMM的框架： (1) Dependency Graph Generation, (2) Dependency Graph Pre-processing, (3) Community Detection, (4) Community Compression, and (5) Community Summarization

输入：系统级的审计事件

Dependency Graph Generation：采用因果分析从系统审计事件中生成依赖图，并且会标注并引入POI事件（得到依赖图）（第IV-A节）

Dependency Graph Pre-processing：通过合并两个节点之间的相同类型的边并过滤掉只读文件节点来预处理图（得到预处理后的依赖图）（第IV-D节）

Community Detection：将图划分为多个以进程为中心的社区，并将资源节点与社区关联起来（得到以进程为中心的社区子图）（第IV-C节）

Community Compression：利用基于进程的模式和基于资源的模式来对社区规模进行压缩（得到压缩后的以进程为中心的社区子图）

Community Summarization：为每个社区提取InfoPaths，并对这些InfoPaths进行优先级排序（得到 Summary Graph）

输出：一个包含排名最高的InfoPaths的Summary Graph

**Threat Model：**本文采用与之前安全调查工作相同的威胁模型。系统级别的事件从系统内核收集。作者假设系统内核是可信的，不会被对手篡改（所做的假设）。任何有意破坏安全审计系统的内核级攻击都超出了这项工作的范围，现有的软件和内核加固技术可以用来更好地保护日志存储。本文也不考虑使用无法被底层来源跟踪器捕获的侧通道或过程间通信（IPC）执行的攻击。可以使用捕获内存跟踪的细粒度审计工具或侧通道分析技术来解决这些攻击，但它们不是本工作的重点。

DEPCOMM将系统行为聚集到社区中，并对表示跨社区信息流的InfoPaths进行优先级排序。因此，完全了解DEPCOMM生成摘要方法的攻击者可能会故意将攻击限制在几个进程和文件内，从而最小化他们在社区内和跨社区的痕迹。这类攻击通常通过操纵进程的内存来破坏进程（例如，代码复用攻击），可以应用诸如内存随机化等专门技术来加强内存保护。攻击者还可能通过执行生成大量日志的活动（例如创建大量临时文件）来泛滥系统审计日志。为了防范这种攻击，可以使用现有的日志压缩技术来压缩系统审计日志的规模，DEPCOMM可以方便地处理压缩日志，因为这些压缩日志在DEPCOMM保留了依赖性。此外，可以部署异常检测技术，对日志收集中的这种意外峰值发出警报。（这一段叙述DEPCOMM可能面临的威胁，以及相应地解决办法）

4. DESIGN OF DEPCOMM

A. Dependency Graph Generation

DEPCOMM使用运行在主流操作系统（Windows、Linux、Mac OS和Android）上的系统监控工具收集系统审计事件，包括进程事件、文件事件和网络事件。对于每个收集到的实体和事件，DEPCOMM记录对安全分析至关重要的属性（例如，实体的PID、文件名和IP；事件的开始时间、结束时间和操作），如表1和表2所示。

给定一个POI事件（例如，关于文件下载的警报），DEPCOMM通过执行反向因果分析（从POI事件回去）来跟踪依赖关系，从而构建一个依赖关系图。从POI事件开始，因果分析迭代地查找与POI事件有依赖关系且发生在POI事件之前的事件。这些发现的事件（即边）形成导致POI事件的依赖图，如图1所示的图。（因果分析是什么？如何进行？）

B. Dependency Graph Preprocessing

**Edge Merge：**依赖图通常在进程节点和文件/网络节点之间有许多并行边，表示短时间内重复的读/写操作。这是因为OS通常通过将数据按比例分配给多个系统调用来执行读/写任务。如最近的研究[26]所示，这些平行边并没有为攻击调查提供额外有用的信息，因此DEPCOMM直接将相同操作类型的平行边合并为一条边。

Filtering Read-only file nodes：正如最近的研究[33,51]所示，依赖图具有许多只读文件，这些文件通常是用于进程初始化的库、配置文件和资源（例如/lib64/libdl.so.2），不包含有用的与攻击相关的信息[33]。因此，DEPCOMM过滤掉只读文件并保留进程，以保留主要系统活动的语义。（相关文献证明）

C. Community Detection

DEPCOMM将一组紧密的进程聚集为以进程为中心的社区。以**进程为中心**的社区是一个图，它包含(1)一个主进程节点，(2)一组子进程节点，这些子进程节点代表主进程派生子进程的子集，因此这些子进程彼此之间具有数据依赖性，(3)一组由主进程和这些子进程访问的资源节点。

比如：在图1中，leak 是 C3 的 master process node，派生出 tar, bzip, gpg，curl 这些 子 process node。这些子进程至少与另一个子进程有数据依赖关系，这可以从依赖关系图中的以下路径中反映出来：tar→…/upload.tar→bzip2 →…/upload.tar
.bz2→gpg→…/upload→curl→xxx->xxx。此外，有些流程或资源节点可以属于多个社区，称为重叠节点。例如，在图1中，leak首先与curl联系，在C2中完成脚本leak.sh的执行，然后生成子进程tar、bzip2、gpg和curl，在C3中压缩并上传文件。在这种情况下，leak是在C2和C3重叠的节点。我们将重叠节点分为三种类型，如图4所示：

• 为不同的系统活动与不同的 child process node 联系的 process node
• 一个process node，它与它的兄弟节点协作完成一个系统活动，同时生成 child process node完成一个不同的系统活动
• 由来自不同社区的 process node 访问的 resource node

接下来，本文描述DEPCOMM社区检测模块的两个阶段：以进程为中心的社区检测和资源节点关联

Process-Centric Community Detection：

DEPCOMM根据作者提出的分层游走方案在每个进程节点上进行随机游走，生成行走路线，然后应用word2vec模型[62]学习基于每个进程节点的游走路线的行为表示。基于行为表示，DEPCOMM将具有类似表示的流程节点聚集到相同的社区中。接下来将详细描述每个步骤。

（1）Hierarchical Random Walk

从节点v1出发的随机游走生成特定长度W = {v1，···，vl}的行走路径，其中vi∈W以一个跳转概率被随机选择。vi到邻居节点n的转移概率为Pr(vi, n) = w(vi, n)/WN(vi)，其中w(vi, n)表示从vi到n的行走权值（权值怎么定义？），WN(vi)表示vi所有邻居的行走权值之和。与现有的随机游走算法以相等的概率（比如a, 1-a）处理相邻节点不同，DEPCOMM中的随机游走为可能是 vi 节点的紧密进程节点提供更高的概率。

具体来说，行走者同时考虑 进程的邻居 和 global process lineage trees（这个树是什么？） 来保证联系紧密的进程更可能被采样到同一条游走路径中，因此，在嵌入表示之后，这么紧密联系的进程也会很相似。对于每个进程节点p，DEPCOMM检查p的单跳邻居节点（one-hop），并将p关联到：① 父进程节点 ② 子进程节点 ③ 访问的资源节点。特别地，我们观察到，对于一个进程 pr 和它的子进程 pc ，如果pc开始生成它自己的子进程（通常是多个子进程），pc很可能启动一个新的系统任务，而生成的子进程不与pr合作。因此，pc的子进程应该与pr的在不同的社区。为了识别这种子进程的创建，DEPCOMM搜索 global process lineage trees，并将每个进程节点与 ④ 有多个子进程的最近的祖先关联起来。

使用从进程的邻居和global process lineage trees收集的信息（①②③④），DEPCOMM采用8种分层游走方案生成游走序列。具体来说，当walker从进程节点v1开始时，它给每个邻居分配相同的权重（初始化），并随机移动到其中一个。经过这个初始步骤后，行走者根据8种分层行走方案选择下一个节点，如图5所示。在具有通用性的前提下，我们假设步行者目前在节点vi上，目前产生的游走序列为Wv1 = {v1，···，vi}， vi的邻居是节点N = {n1，···，nk}的集合，R(v)表示返回进程节点v访问的资源节点，L(v)找到进程节点v的最近祖先，它有多个子进程。下面详细叙述这8种 Hierarchical Random Walk ：

采用8种 Hierarchical Random Walk 来生成游走序列，如图5所示

以下8种策略要结合图来理解

Scheme S1：考虑 vi-1表示vi的父进程节点，若vi还有其他邻居，那么vi会跳到这些邻居；如果只有vi-1这一个邻居，那么vi将会返回至vi-1

Scheme S2：考虑vi-1表示vi的子进程节点，若vi的其他子进程节点与vi-1有数据依赖关系，比如访问同一资源节点，那么vi会选择走到其他子进程节点；否则，vi将会回到vi-1

Scheme S3：vi-1表示vi的唯一子进程节点（其他都是资源节点），表明vi和派生出vi-1来处理同样的数据，因此它们属于同一社区。因此，如果vi还存在其他资源节点邻居，那么vi将会去探索他们（因为要尽可能地将有联系的节点归到一个社区中）；但如果没有其他邻居，那么行走者将会返回至vi-1。

Scheme S4：vi-1是一个进程节点，vi是一个资源节点（vi-1访问vi）。如果其他访问vi的进程节点与vi-1进程节点有一个共同的父节点，那么其他访问vi的进程节点可能属于vi-1的社区

Scheme S5：vi-1是一个资源节点，vi是一个有多个子进程节点的进程节点，且vi-2是vi的一个子进程节点。可以看出，vi-2进程节点访问vi-1这个资源节点。如此，vi的其他子进程节点不属于vi-2的社区。但是，如果vi的其他子进程节点与vi-2存在数据依赖关系，比如vi的其他子进程节点与vi-2存在访问同一资源节点，那么在跳转时，vi会倾向于（w=1）跳转至这些子进程节点以及vi-2，而不会跳转至那些没有数据依赖关系的子进程节点。

Scheme S6：vi-1是一个资源节点（且被vi-2所访问），vi是一个有多个子进程节点的进程节点，且vi-2并不是vi的子进程节点。如此，将vi视为一个社区中的主节点，那么vi的子进程节点与vi-2将不会是同一个社区。因此，行走者将会返回至vi-1（因为其他节点不是同一个社区啊，就没必要走）

Scheme S7：vi-1是一个资源节点，vi是一个有多个子进程节点的进程节点，并且vi=vi-2。这说明，vi-1是一个信息流的结束。为了增加对紧密进程节点的采样效率，行走者将会继续行走至vi的其他子进程节点，而不会去vi-1（因为是一个信息流的结束啊）

Scheme S8：vi-1是一个资源节点，vi是最多只有一个子进程节点的进程节点。如此，如果vi有除了vi-1之外的其他邻居节点（进程/资源），那么行走者将会行走至这些邻居节点，并不会返回至vi-1。如果没有，为了防止终止行走，将会行走至vi-1。

（2）Process Node Representation

与DeepWalk、Node2vec等图表示学习方法一样，还是采用word2vec中的skip-gram模型来节点的表示学习。

（3）Process Node Clustering

为了根据进程节点的行为表示计算其聚类（可能存在交叉），DEPCOMM采用了一种软聚类方法FCM （Fuzzy C-Means）。与硬聚类方法（如K-means）不同，FCM通过最小化目标函数来输出每个聚类中每个进程节点的隶属度：$$\begin{array}{c}J=\sum _{i=1}^{|V_p|}\sum _{j=1}^{|C|}{u}_{ij}^2||v_i-c_j{\Vert }^2\end{array}$$

其中，uij 表示进程节点vi属于社区cj的程度。如果uij高于给定的阈值，那么vi将分类至社区cj。根据最近的工作，我们设置阈值λ = 0.8·maxj{uij}。如果一个进程节点有多个社区（重叠），我们创建节点的多个副本，并将一个副本分配给每个社区。此外，DEPCOMM根据模糊划分系数（FPC）确定社区数量|C|：$$\begin{array}{c}F(|C|)=1/\left|V_p\right|\sum _{j=1}^{|C|}\sum _{i=1}^{|V_p|}{u}_{ij}^2\end{array}$$

这可以用来衡量不同数量的簇的有效性。由于FPC值越高表示对数据分布的描述越好，DEPCOMM选择FPC最大的簇数量|C|。

D. Community Compression

Process-based Patterns

基于进程的模式反映的是，一个进程节点派生出重复的子进程节点，他们访问的是同一资源节点

图6(a)示例：

进程P0重复生成名为P1和P2的子进程来写入文件F1。但是，重复的活动并不能为安全分析人员提供额外的价值。因此，DEPCOMM旨在识别这种模式并合并重复的节点和边。具体步骤如下：

• Step1：Building process lineage tree. （构造进程树）

给定一个以进程为中心的社区，DEPCOMM通过遍历社区内的进程节点，从社区的主进程节点构建一棵进程索引树。该树可以表明进程节点的派生子进程节点的行为。

• Step 2: Association with Accessed Resources.（与访问的资源节点联系）

为了获得进程树中每个进程的资源使用情况，DEPCOMM检查社区内的事件，以确定这些进程访问的资源（节点）。具体来说，每个进程都与所访问资源的代表性属性（即文件的文件名和网络连接的ip）和这些资源上的操作类型相关联。

• Step 3: Mining Process-based Patterns.（挖掘基于进程的模式）

特别是，DEPCOMM使用进程树为每个进程节点生成子树。然后，DEPCOMM通过附加子树中进程节点的关联资源节点属性，将子树编码为字符串，并标识相同的字符串（即重复子树）

• Step 4: Compression based on the Patterns. (基于上述得到的模式来压缩)

识别的重复子树可能有不同的父节点。为了确保子树及其父节点之间的依赖关系不被破坏，DEPCOMM只选择具有相同父节点的重复子树，并将所选子树合并为一个子树。合并子树中每个节点和边的属性是原节点和边的属性并集.

Resource-based Patterns

将某一进程节点访问的所有资源节点合并成一个节点(为什么可以合并呢?访问的资源不同啊?) 如图6(a)所示

E. Community Summarization

对于每个社区，DEPCOMM生成一个由三部分组成的摘要: 主进程、时间跨度和排名最高的InfoPaths，如图2所示。主进程表示社区中系统活动的根进程。时间跨度是使用社区中所有事件中最早的开始时间和最晚的结束时间计算的,这为索引特定的事件活动提供了时间信息.InfoPaths表示社区中从输入到输出的信息流，代表社区中的主要活动。

InfoPaths Ectraction

给定一个以进程为中心(什么叫以进程为中心呢?process-based?还是都是进程呢?)的社区，DEPCOMM首先标识其输入和输出节点。输入节点表示社区的传入信息流，这些输入节点是连接两个社区的边(蓝色虚线)的终止节点(例如,图1中C3社区的leak 和 …/analysis.txt 节点) 和 社区内有出边的节点(图1中C1社区中xxx->xxx,表示社区从其接收文件的外部IP). 此外，对于没有入边的社区(如图1中的C5)，我们选择主进程作为输入节点。一个输出节点代表一个社区的传出信息流，它是一个连接两个社区边的源节点(如图1中C2的 leak)，有入边的节点(如图1中C3的xxx-> xxx，表示社区向其发送文件的外部IP)，以及POI节点(因为一条路径的终点也是为了抵达POI节点)。然后，对于每一对输入和输出节点(从输入到输出会有多个节点,采用DFS来搜索)，DEPCOMM使用深度优先搜索(DFS)算法寻找没有重复节点的最长路径作为InfoPath。这样的路径通常比较短的路径包含更多的活动信息。

InfoPaths Prioritization

社区通常包含多对输入和输出节点，因此有多个infopath。DEPCOMM根据InfoPaths代表主要活动(例如，攻击行为)的可能性对其进行优先级排序。InfoPath Pk: v0→v1→···→v|Pk|−1的优先级评分根据以下四个关键特征计算:

(a) POI Event (fpoi). 包含POI事件的InfoPath与攻击直接相关。因此，如果InfoPath包含POI事件，fpoi为1，否则为0.

(b) Input/Output Type (fiot). 由于进程驱动攻击执行，安全分析人员更有可能通过进程节点找到另一个攻击阶段。例如，在图1中，可以通过输入进程节点 leak 来跟踪从C3到C2的攻击，但不能通过输入文件节点…/analysis.txt。因此，fiot 赋予输入或输出节点为进程的InfoPath更高的优先级: $$\begin{array}{c}{f}_{iot}=\frac{1}{2}\left(\delta \left(v_0\right)+\delta \left(v_{|P_k|-1}\right)\right)\end{array}$$

如果vi是一个过程，那么δ(vi)为1，否则为0

© Event Uniqueness (funi). 出现在较少社区中的文件事件更有可能表示社区中的主要活动，例如仅出现在C4中的事件vim write ./analysis.txt，而在不同社区中经常观察到的文件事件通常表示在后台运行的不相关的历史记录任务。基于这一观察，我们设计了funi特征来度量文件事件的唯一性:

$$\begin{array}{c}{f}_{uni}=\frac{1}{\left|Evt\left(P_k\right)\right|}\sum _{e_i\in P_k,e_i\in Ev{t}_f}\frac{1}{\left|\mathrm{Comm}\left(e_i\right)\right|}\end{array}$$

其中|Evt(Pk)|表示Pk中文件事件的数量，ei∈Evtf表示文件事件，|Comm(ei)|表示ei发生的社区数量。当|Comm(ei)|较小时，funi值较大。

(d) Time Span (fspan). 直观地看，时间跨度与社区时间跨度相似的InfoPath更有可能代表社区中的主要活动。我们设计fspan特性来模拟这种直觉:

$$\begin{array}{c}{f}_{span}=\frac{e\left(v_{|P_k|-2},v_{|P_k|-1}\right).et-e\left(v_0,v_1\right).st}{c.et-c.st}\end{array}$$

其中，分子表示InfoPath的时间跨度，分母表示社区的时间跨度。

基于这4个特征，通过赋予每个特征相等的权重(0.25)来计算Pk的优先级得分。根据分配的优先级分数，对InfoPaths进行排序，并选择前n个路径作为摘要，当然,安全分析人员可以灵活地选择n的值.

5. EVALUATION

评估数据集包括在部署了系统监控工具的测试环境中执行的6次攻击，以及在DARPA TC(透明计算)数据集中执行的8次攻击。在评估中，作者旨在回答以下研究问题:

• RQ1: DEPCOMM在总结依赖关系图方面的总体效果如何?
• RQ2: DEPCOMM如何与自动调查技术HOLMES合作?
• RQ3: 与其他最先进的方法相比，DEPCOMM在社区检测(发现)方面的效果如何?
• RQ4: DEPCOMM在社区压缩方面的效果如何?
• RQ5: DEPCOMM使用排名靠前的InfoPaths生成社区摘要的效果如何?
• RQ6: 在总结依赖关系图时，DEPCOMM的 turnaround performance 如何?

A. Evaluation Setup

Attack Dataset

我们采用Sysdig从拥有10个活动用户的6台Linux主机上收集攻击数据集。这些主机上的常规系统任务包括网页浏览、文本编辑、代码开发和一些其他服务(例如，数据库)。在这些主机上，我们基于已知的漏洞[12,13,26,70]和Kill Chain[71]执行了6个多步攻击。收集的数据集包含三天内的1亿个事件。以下是这些攻击的细节:

A1: Penetration into Email Server(渗透到电子邮件服务器)

公司内部的攻击者在正常软件中插入恶意代码，并将修改后的软件上传到公司的资源服务器。一名员工下载这个修改过的软件并执行它，恶意代码就会创建一个到攻击者主机的连接，使攻击者能够轻松地劫持电子邮件。

A2: Crashing Compiler (编译器破损)

内部攻击者向内部资源服务器上传恶意C代码。当员工下载并编译源代码时，恶意代码会导致编译器崩溃，最终编译器生成一个错误的可执行文件.

A3: Tampering Sensitive Files (篡改敏感文件)

在三天的时间里，内部攻击者使用窃取的密码多次登录员工的主机，然后收集和篡改一些敏感文件。最后，攻击者通过电子邮件将这些敏感文件发回。

A4: Data Exfiltration. (数据泄露)

攻击者通过利用Shellshock漏洞进入受害主机，设置后门，并通过在主机中安装恶意软件窃取敏感数据。

A5: Cracking Password. (破解密码)

在弹震穿透后，攻击者从C&C服务器下载一个密码破解有效载荷，然后通过运行破解程序获得根用户的密码。然后，攻击者使用通过破解的密码获得的root特权渗透到同一网络中的其他主机。

A6: VPN Filter. (VPN过滤器)

为了发动更持久和隐形的攻击，攻击者使用更复杂的多阶段VPN Filter恶意软件在shellshock穿透后，攻击者从C&C服务器下载第1阶段可执行文件。当触发时，阶段1可执行文件将下载阶段2可执行文件，该阶段2可执行文件将收集敏感文件，并建立与C&C服务器的秘密连接，以进行数据泄露.

DARPA TC Dataset

需要研究这个数据集

DARPA TC数据集致力于发展高级持久性威胁(APT)的取证分析和检测。该数据集记录了不同操作系统(例如，Linux和Windows)上各种漏洞利用的攻击痕迹。在我们的评估中使用8次攻击(约5000万事件)。

Labeling Ground Truth

作者通过从POI事件进行跨主机的后向跟踪分析方法系统级依赖图.作者使用攻击脚本和攻击描述分别识别在测试环境和DARPA TC数据集中执行的攻击的POI事件和攻击相关事件。表3 展示了溯源图的具体统计信息. ”Dep.Graph”列表示原始依赖图的节点数和边数。“Pre-processed Dep. Graph”列显示预处理（即合并边和过滤只读文件）后图的节点数和边数。“Attack”列显示了与攻击相关的节点和边的数量。最后，我们手动==(???)将每个依赖图划分为社区。特别地，我们首先通过检查它们是否通过资源具有数据依赖性来识别由相同的父进程创建的进程，且它们之间相互关联。每一组相关的过程都被放到一个社区中。然后，我们将父进程标记为社区的主进程，并根据资源节点与进程节点的依赖关系将资源节点与找到的社区关联起来。为了进一步获得更客观的基本事实，我们请了三位独立的专家来验证我们的基本事实。这些专家具有计算机科学博士学位，从事计算机系统领域的研究已超过十年。如果至少有两位专家认为某些节点应该属于不同的社区，我们就会修改我们的基本事实(???这?==)。所有这些结果都可以在我们的项目网站上找到。“|C|”列显示手动分区的社区数量。

B. RQ1: Overall Effectiveness of DEPCOMM

我们应用DEPCOMM为表三所示的依赖图生成摘要图，并测量了检测到的社区的数量及其大小，以证明该依赖图的有效性。图7展示了DEPCOMM检测社区的结果，溯源图平均分为 18.4 个社区。与原始的平均有1302.1个节点的依赖图相比，它比原来小70.7倍。由于社区的数量要少得多，因此可以将所有的社区可视化，以便安全分析人员能够轻松地看到所有相关系统活动的概述。

图7展示了14种攻击种与攻击相关的社区数量，还有与攻击无关的社区图8展示了14种攻击的社区大小（每个社区的节点数量）分布。可以看到，每个社区是相当小的，平均15.7个节点，这也减少了安全分析人员对每个社区进行检查的工作量。此外，这也大大减少了存储空间。

表3：将所有社区的前1、前2和前3 InfoPaths中的事件数量与NoDoze识别的事件进行比较。结果表明，DEPCOMM所得到的InfoPaths中包含的事件数量比Nodoze少了近21倍，说明DEPCOMM能够更加精准地从社区中找到代表攻击事件地InfoPaths

case study

通过一个例子说明摘要图为什么有利于攻击检测。图9展示了DEPCOMM针对攻击D5生成的 summary graph。DEPCOMM将 dependency graph 分成13个以进程为中心的社区。图9(a)展示C1-C4这四个社区，图9(b)展示了相应的 summary graph。C2包含POI事件，因此是一个与攻击相关的社区。从C2中的8个事件中，可以很容易地识别出8个攻击事件（红边）。这些攻击事件表示攻击者使用 mail 打开控制台后门的攻击行为。根据C1和C2的InfoPaths，可以看出C1是另一个与攻击相关的社区。同样，从C1中的17个事件中很容易识别出另外7个与攻击相关的事件，代表下载恶意文件/home /admin/profile的攻击行为。（如何看出？如何很容易？）通过检查InfoPaths，可以通过C3和C4对C1的依赖关系来进一步识别它们。然而，它们的InfoPaths的输出与C1的InfoPaths的输入不一样。因此，C3和C4不是与攻击相关的社区（会不会有点草率？）。总之，DEPCOMM通过检查原始图中的37,109个事件中的25个事件，揭示了攻击D5的攻击相关事件。（看一下开源项目 再理解下）

C. RQ2: Cooperation with HOLMES

表5展示了攻击相关社区的映射结果。

D. RQ3: Comparison of Community Detection

我们将DEPCOMM与其他最先进的社区检测算法进行了比较，以显示DEPCOMM在社区检测方面（前面不是说手动？）的有效性。考虑到依赖图的重叠性质，我们选择了9种典型的重叠社区检测算法作为baseline：NISE (2016) [36], EgoSpliter (2017) [41], NMNF (2017) [42], DANMF (2018) [43], PMCV (2019) [44], CGAN(2019) [45], VGRAPH (2019) [46], CNRL (2019) [47] and DeepWalk (2014) [38]。

表6展示了DEPCOMM与baselines社区发现的F1-Score和所检测出的社区数量。结果表明，DEPCOMM的F1-Score平均比baselines高2.29倍。这表明DEPCOMM的社区检测算法对以 process 为中心的社区检测是有效的。其他baseline方法效果不好的原因有：（1）baseline方法主要关注的是同质图，因此他们不能够有效地区分进程节点和资源节点，并且不能将这些节点放在一个社区，造成一个社区中包含了多种不相关的系统事件。（2）baseline方法依赖于同一假设，即社区内的边不仅仅是与其他社区里节点相连的边。因此，它们不能将与信息流相连的两个主进程节点分割为两个社区，即使这两个进程代表不同的系统活动。

此外，可以看到，DEPCOMM和DeepWalk都利用 SkipGram模型来从游走序列中学习节点表示，但DEPCOMM的效果要比DeepWalk好1.65倍。这表明，DEPCOMM的分层游走模式比DeepWalk中普通的随机游走模式（将每个节点同等对待）更有效。

E. RQ4: Effectiveness of Community Compression

为了评估社区压缩的有效性，我们计算了 $\gamma =1-Siz{e}_{post}/Siz{e}_{pre}$ 其中 $Siz{e}_{pre}$ 表示社区在压缩之前节点或边的数量，$Siz{e}_{post}$ 表示压缩之后社区节点或边的数量。

图10和图11分别显示了对节点和边的 compression rate。这两幅图分别显示了节点和边缘的压缩率的分布。我们可以看到，对于一个社区，节点数和边数的平均数量分别减少了38.4%和44.7%，节点数最大减少97.3%，边数减少98.9%。此外，考虑到压缩可能会改变InfoPaths。因此，作者还验证了InfoPaths在压缩后没有改变。原因是重复活动具有相同的信息流，通常通过单个节点进入重复活动形成的子图，通过另一个节点离开子图，因此压缩重复活动不会改变InfoPaths内部的事件。总之，压缩这些重复的活动仍然保留了一个社区所代表的活动。

F. RQ5: Effectiveness of InfoPath Ranking

对于每个社区，DEPCOMM根据其输入和输出节点提取信息路径。一个社区平均有4.3个输入节点和3.9个输出节点，形成15.7条InfoPaths。我们手动检查了每个社区的前3个信息路径，并确认前2个信息路径足以代表系统活动和攻击行为。也就是说，我们只需要检查提取的12.7%的信息路径。

接下来，我们使用两个社区来说明排名最高的InfoPath的有效性。表7显示了包含攻击行为的攻击相关社区C3和无攻击相关事件的社区C8的前3个InfoPath。

C3中的事件显示，攻击者运行一个恶意脚本来压缩、加密，并将敏感文件上传到远程服务器。我们可以看到，这些攻击行为可以通过使用优先级得分为0.8234的前1个InfoPath来有效地表示。虽然前2和前3也可以涵盖这些行为，但前1InfoPath的输入节点是一个恶意脚本过程（即 leak ），并且更容易帮助安全分析进一步跟踪创建恶意脚本的社区。C8中的事件显示，用户使用sshd登录到主机，将压缩文件从服务器传输到主机，并解压缩该文件。我们可以看到，优先级最高（0.4914）的前1信息路径可以代表所有这些活动，而前2的信息路径缺少sshd登录事件，前3的信息路径缺少sshd登录事件，包含许多社区中出现的文件事件（/dev/null→bash）。

G. RQ6: Turnaround Time Performance of DEPCOMM

为了理解DEPCOMM的 turnaround time performance（表示的是每个阶段需要的时间代价） ，我们测量了14种攻击情况下DEPCOMM中每个阶段的 turnaround time 。

在一个主机中采用多个进程来并行化 hierarchical walk（游走） 和 vectorization （向量化），对于每种攻击的每个图阶段的 turnaround time 如表8所示。由于社区检测阶段的分层游走和向量化是相互独立的，因此将所有分层游走和向量化并行化是可行的。我们在一台主机上使用多进程（20个进程）来实现并行化。结果见表8。平均而言，DEPCOMM生成摘要图的时间为1,148.90秒，比在单个进程中运行快了约6倍。具体来说，构建依赖图使用32.12s，预处理依赖图使用256.72s，社区检测使用858.48s。对于社区检测，分层遍历使用581.28秒，向量化使用269.26秒，比单个进程运行快4倍到7倍。最后，社区压缩使用1.41秒，社区摘要使用0.17秒。可以观察到：（1）由于分层游走采样序列和节点表示学习，社区检测阶段占用了大部分时间，这可以通过并行化来加速；（2）DEPCOMM采用高效的频繁模式挖掘算法（嗯？是什么？），压缩以进程为中心的社区所需的时间更短
；（3）压缩后的社区较小，社区总结阶段所需时间最短。总之，DEPCOMM的 turnaround time performance 可以通过并行分层行走和向量化进一步提高。

6. DISCUSSION

Cooperation with Other Investigation Techniques

除了突出显示与攻击相关的社区外，可视化技术还可以应用于DEPCOMM生成的摘要图，以显示系统活动的概述，并提供按需放大（缩小）功能，以显示（隐藏）社区中的详细事件。此外，通过与其他因果分析技术的集成[12,14,28]，DEPCOMM可以生成一个热力图（这一个点如何具体做？），突出显示可能包含可疑行为的社区。

Forensics of Real-World Attacks

最近真实世界存在的攻击，如高级持续威胁（Advanced Persistent Threat, APT），是复杂的（利用各种漏洞的多步攻击）和隐蔽性的（长时间保持休眠状态）。随着日志压缩技术的进步和存储成本的不断降低，可以将系统审计日志存储数月甚至数年。此外，最近的分布式数据库解决方案在提高日志的搜索性能方面有很好的效果，可用于为大量日志生成依赖图。通过与这些解决方案协同工作，DEPCOMM可以应用在生成的依赖图上检测社区，并与其他检测技术集成来突出显示与攻击相关的社区。

Analysis Turnaround Time

目前DEPCOMM实现平均消耗1,148.90秒（见表8）来生成一个总结图。由于分层游走和向量化是相互独立的，因此将所有分层游走和向量化并行化是可行的。通过与能够提供实时警报和防御的入侵检测系统合作，DEPCOMM可以用于识别攻击入口点和影响，使系统恢复更快，并防止未来遭到破坏。

Limitations of DEPCOMM

分层图嵌入是一种新的系统依赖图嵌入技术（作者的创新点）。然而，仍然有一些超参数（如游走序列长度、子序列提取的窗口大小和向量的维数）需要手动设置。根据现有的敏感度分析方法进行调整，其中游走序列长度设置为200，窗口大小为20，尺寸为20。但仍然有一些不太重要的事件不能被DEPCOMM压缩，例如与系统文件的一些交互（例如，bash→/dev/null）。通过检查社区，可以在不同的社区中发现这些事件，因此挖掘鉴别模式可能有助于识别这些模式。

7. RELATED WORK

相关工作：都是差不多用一句话（思想）来介绍下该类文献下的代表性文献

Causality Analysis via System Audit Logs

因果分析最初由King等人提出，其目的是自动重构代表攻击步骤的一系列事件。由于因果关系分析存在（suffers from）依赖爆炸问题[26,27,33,51]，最近的研究提出了执行细粒度因果关系分析[13,15,25,83,84]的技术，并对依赖关系进行优先级排序[12,14]。另外，Gui等人提出了一种方法，该方法定期呈现因果关系分析的更新，并让人参与到循环中，以提供减少生成的依赖图的启发式方法。与这些旨在揭示攻击相关事件的技术不同，DEPCOMM从依赖关系图生成一个摘要图，并可以使用这些技术突出显示与攻击相关的社区。

Behavior Analysis via System Audit Logs

Gao等人[18,19]提出了特定于具体领域的语言，用于查询系统审计日志，以高效地调查攻击。Milajerdi等人[32]提出依靠可疑信息流的相关性来检测正在进行的攻击活动，并利用来自网络威胁情报（CTI）报告的知识来检测系统审计日志中记录的攻击行为。Pasquier等人[87]通过将运行时内核层参考监视器与查询模块相结合，提出了一运行时的溯源分析。Hossain等人[28]提出了一种基于标记的技术，用于从系统审计日志执行实时攻击检测和重构。DEPCOMM生成的汇总图可以与这些技术集成，以促进对攻击行为的理解，并提供更好的防御。（如何与其他技术集成呢？）此外，最近的方法[14,88]利用威胁检测系统或软件应用程序的运行时日志活动的警报生成紧凑的图。与这些方法不同的是，DEPCOMM是一种通用方法，它只利用依赖图中的信息来检测社区，并且可以轻松地与各种自动调查技术[32]合作来检测与攻击相关的社区。

Community Detection

NISE[36]是一种局部扩展算法，它将初始化的种子集扩展为具有重叠的集群。EgoSplitter[41]首先通过将节点拆分为多个副本来构建节点解耦图，然后将一些经典的不相交社区检测方法应用到构建图中。NMNF[42]使用非负矩阵分解学习具有细致社区结构的节点表示。DANMF[43]提出了一种新的用于重叠社区检测的深度NMF模型，该模型采用自编码器网络对非负矩阵分解过程进行建模。PMCV[44]通过搜索和加入共享k-1节点的相邻k-cliques来检测重叠社区。CGAN[45]使用生成对抗网来学习节点到社区的成员强度。VGRAPH[46]使用神经网络对节点邻居的生成进行建模，将社区检测和节点表示学习结合起来。CNRL[47]对随机漫步序列应用潜狄利克雷分配模型(Latent Dirichlet Allocation model, LDA)来学习社区成员。DeepWalk[38]结合随机游走方案和word2vec学习具有社区结构的节点表示。这些现有算法主要关注同质图，并以相同权重对待每个节点，而DEPCOMM为更可能为表示亲密进程的邻居节点提供更高的权重。

Graph Summarization

图摘要生成大规模图的紧凑表示，便于识别数据的结构和含义。它有广泛的应用，如聚类、分类、社区发现和离群点检测。与这些目标数据主要存储在数据库中的技术不同，DEPCOMM处理依赖图，这是一种异构图，其中进程节点和其他资源节点表示系统活动的不同步骤。

8. CONCLUSION

本文作者提出 DEPCOMM 这种方法，它能够将彼此协作完成具体系统任务的紧密进程聚类到同一个社区，并能够对每一个社区中存在的重复事件进行压缩。对于每一个社区，DEPCOMM进一步识别能够代表跨社区信息流的 InfoPaths，并根据揭露攻击行为的概率来对这些 InfoPaths 排序。排序最高的 InfoPaths 会作为每个社区的摘要总结。作者在真实攻击中的评估表明了 DEPCOMM 在检测以进程为中心的社区、压缩重复事件、确定 InfoPaths的优先级以协助攻击调查的有效性。

在数据库中的技术不同，DEPCOMM处理依赖图，这是一种异构图，其中进程节点和其他资源节点表示系统活动的不同步骤。

8. CONCLUSION

本文作者提出 DEPCOMM 这种方法，它能够将彼此协作完成具体系统任务的紧密进程聚类到同一个社区，并能够对每一个社区中存在的重复事件进行压缩。对于每一个社区，DEPCOMM进一步识别能够代表跨社区信息流的 InfoPaths，并根据揭露攻击行为的概率来对这些 InfoPaths 排序。排序最高的 InfoPaths 会作为每个社区的摘要总结。作者在真实攻击中的评估表明了 DEPCOMM 在检测以进程为中心的社区、压缩重复事件、确定 InfoPaths的优先级以协助攻击调查的有效性。