论文笔记----DEPCOMM: Graph Summarization on System Audit Logs for Attack Investigation

本篇文章是最近IEEE的一篇论文-----DEPCOMM: Graph Summarization on System Audit Logs for Attack Investigation的阅读笔记，其中包含对DEPCOMM的基本介绍以及相关的一些扩展资料，水平有限，仅做学习记载。

文章原文

背景介绍

高级持续威胁

高级持续性威胁（APT（Advanced Persistent Threat）），本质是针对性攻击。 利用先进的攻击手段对特定目标进行长期持续性网络攻击的攻击形式。
主要针对企业和政府重要信息资产的，对信息系统可用性、可靠性构成极大挑战的信息安全威胁
其一般受国家或大型组织操控，受国家利益或经济利益驱使，由具有丰富经验的黑客团伙实施，具有技术性强、持续时间长、危害性较大等特点，是近年来出现的新型综合性网络攻击手段。

APT攻击的主要特点

（1）高级：
是指执行APT攻击需要比传统攻击更高的定制程度和复杂程度，需要花费大量时间和资源来研究确定系统内部的漏洞
（2）持续
持续也可理解为长期，是为了达到特定目的，过程中“放长线”，持续监控目标，对目标保有长期的访问权；
（3）威胁
威胁强调的是人为参与策划的攻击，攻击目标是高价值的组织，攻击一旦得手，往往会给攻击目标造成巨大的经济损失或政治影响，乃至于毁灭性打击。
（4）隐秘
APT攻击一般会以各种方式巧妙绕过已有的入侵检测系统，悄然进入目标网路
（5）潜伏
这些新型的攻击和威胁可能在用户环境中存在一年以上或更久，他们不断收集各种信息，直到收集到重要情报
（6）多态
攻击者的攻击方式不是一成不变的，既包括病毒、木马植入等传统入侵手段，也包括SQL注入、零日漏洞、软件后门、操作系统缺陷等，甚至结合社会工程学、心理学等各种线下手段实施攻击

APT的攻击阶段

（1）探测期
探测期是APT攻击者收集目标信息的阶段
（2）入侵期
初始攻击，命令和控制：在避免用户觉察的条件下取得服务器、网络设备的控制权
（3）潜伏期
后续攻击，横向渗透，资料回传
（4）退出期：
清理痕迹，为了避免受害者推断出攻击的来源，APT代码需要对其在目标网络中存留的痕迹进行销毁

根据APT的攻击阶段可知，要想对APT进行攻击检测，必须要在前三个时期进行，那么APT攻击具有危害性大，攻击隐蔽性前，如何对APT攻击进行检测呢？？？
----------- 传统被动、静态特征规则驱动的攻击检测方法，与关键线索驱动的逐步搜索溯源方法，难以应对相关攻击事件带来的潜在重大风险。而当今流行的主动的威胁狩猎技术与自动化安全运营技术，为我们应对APT提供了新的方案；
对于主动威胁狩猎技术可以理解为主动的去寻找系统中存在的潜在风险。

基本概念介绍

系统审计日志

监视系统，观察系统之间的响应，并将生成的内核级审计事件作为系统审计日志。系统审计日志，通常记录进程、网络、文件等内容

溯源图

记录终端上实体的行为逻辑依赖关系，通过溯源图的后向追溯和前向追溯，可实现攻击事件的溯源与取证。在溯源图中结点代表实体，边代表实体之间的依赖关系

攻击检测

通过对行为、安全日志或审计数据或其它网络上可以获得的信息进行操作，检测到对系统的闯入或闯入的企图”

攻击溯源

通过综合利用各种手段主动地追踪网络攻击发起者、定位攻击源，结合网络取证和威胁情报，有针对性地减缓或反制网络攻击，争取在造成破坏之前消除隐患，在网络安全领域具有非常重要的现实意义。

那么面对复杂网络攻击（APT攻击），可用通过基于系统审计日志生成的溯源图进行攻击溯源，安全分析人员可以通过重构导致POI 事件的事件链，来获取与攻击相关的上下文信息。从而获取到攻击的源头，便于进一步解决问题。但是这种方式会出现一个问题----依赖爆炸。

依赖爆炸

依赖爆炸问题为什么会出现呢？

（1）从终端溯源数据中挖掘并生成精简的攻击溯源子图，并不是简单和直接的任务，其中一个关键阻碍就是溯源数据中大量的信息流依赖。限于采集平台的性能开销与技术瓶颈，目前绝大部分溯源数据采集系统所采集的数据是粗粒度的（Coarse-Grained）。粗粒度的行为数据采集采取“贪心”的方式，记录实体间所有可能的依赖关系，难以精确跟踪实体间的信息流向。特别是类似系统级别的服务进程、用户级别的浏览器等长期存活的实体，作为信息流传播的中心环节，大规模关联实体的信息流会在该中心实体交汇，导致上下游信息流无法有效溯源。

（2）在现有的粗粒度溯源数据采集技术基础上，终端关键实体之间，特别是进程、文件、连接等实体，存在自然的信息流传染效应。在没有先验知识或基线数据的情况下，任何恶意信息流经过中间实体的中转，将以一定的概率向上下游实体扩散。随着信息流在关联实体各自邻域的传播，特别是通过常驻实体的传播，进一步导致了终端溯源数据中的信息流依赖爆炸问题。
简单来说就是由于系统之间的实体很多，实体之间的相关联系也很多，溯源图采用粗粒度的方式记录了所有实体之间的依赖关系，那么就会出现大规模的信息流，那么与POI事件相关联的事件也随之增大，则会导致依赖爆炸问题的出现，从而造成安全分析人员无法有效的进行分析数据。（POI事件，英文全称point of interest，在本篇论文中指的是与攻击有关的事件）

如何解决依赖爆炸问题？

有人提出了一种自动过滤无关事件并揭示攻击相关事件的技术的方法，但这种技术存在了一些问题；具体表现为
（1）系统中总是存在残留风险，这些自动化技术无法准确地揭示这些风险，特别是对于严重依赖系统概要的技术
（2）威胁在不断演变，以规避防御技术，例如新兴的攻击战术和攻击者最近开发的技术。
（3）现有技术主要依赖于启发式规则，导致信息丢失和入侵式系统变化。（这里启发式规则可以理解为用简单的规则去解决复杂的问题）

基于上述问题的出现，本文中提出了DEPCOMM—一种图摘要的方式

DEPCOMM

DEPCOMM的设计动机，期望和目标

动机： 为了有效地协助攻击调查，和解决依赖爆炸的挑战
目标： 开发一种图摘要方法，通过将依赖关系图划分为许多社区（即子图）并为每个社区提供简洁的摘要来生成一个摘要图。
期望： DEPCOMM能过对大规模依赖图进行图摘要总结，并能与各种自动调查技术协作，突出表示与攻击相关的社区，并将其可视化

DEPCOMM概述

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

实现DEPCOMM存在的挑战

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

而针对这三点挑战，在本文中提到了这些应对方法：
1、如何保证依赖图（异构图）中的全面信息，并有效检测社区？----------DEPCOMM将依赖关系图划分为以进程为中心的社区，每个社区包括一组紧密的流程和这些进程访问的系统资源。
2、如何去除图中不重要的依赖关系，从而压缩图？---------DEPCOMM识别 基于进程（process-based） 和 基于资源（resource-based） 的模式，并根据这些模式为每个社区进行压缩。我们的社区检测不像现有工作那样保留依赖关系，而是允许在社区内的多个进程之间进行有力压缩
3、如何对边序列进行摘要总结或者说如何生成infopath？--------通过仔细检查各种攻击的依赖图，主要的系统活动和攻击行为通常被表示为攻击相关过程之间的信息流，这样的信息流通常表示为社区中从输入节点到输出节点的路径，称为InfoPaths。并将更可能代表攻击步骤和主要系统活动的信息路径排在最前面。

DEPCOMM的框架

根据这个框架图来进行理解----（1）首先根据系统审计日志生成与POI时间相关的因果关系图，这是最初的依赖图（2）将依赖图的多余边进行合并并过滤掉只读文件生成了预处理的依赖图（3）将预处理的依赖图进行社区压缩：及将一组亲密进程和与进程相关的资源划分为同一个社区（3）将生成的以进行为中心的依赖如进行社区压缩：基于两种模式进行压缩–以进程为中心的模式和以资源为中心的模式（4）将压缩后的依赖图生成InfoPath，并对其进行排序，将排名最高的InfoPath作为社区摘要
以上是整个大致的运行流程

DEPCOMM的核心组成部分

社区检测

DEPCOMM将依赖关系图划分为以进程为中心的社区，每个社区包括一组紧密的流程和这些进程访问的系统资源。

社区：在本文中的含义是包含了一个主进程节点以及与主进程节点相关的一组子进程节点，以及与主进程节点和子进程节点相关联的资源

那么在社区检测中可以大致分为三个过程----（1）分层随机游走算法：Hierarchical Random Walk（2）进程节点表示学习方法：Process Node Representation（3）进程节点聚类：Process Node Clustering

Hierarchical Random Walk

分层随机游走算法：两种因素 + 8种游走方案 = 游走序列
其中两种因素分别是
（1）进程的邻居因素：从节点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 节点的紧密进程节点提供更高的概率。（进程邻居的因素）
（2）global process lineage trees：对于每个进程节点p，DEPCOMM检查p的单跳邻居节点（one-hop），并将p关联到：① 父进程节点 ② 子进程节点 ③ 访问的资源节点。特别地，我们观察到，对于一个进程 pr 和它的子进程 pc ，如果pc开始生成它自己的子进程（通常是多个子进程），pc很可能启动一个新的系统任务，而生成的子进程不与pr合作。因此，pc的子进程应该与pr的在不同的社区。为了识别这种子进程的创建，DEPCOMM搜索 global process lineage trees，并将每个进程节点与 ④ 有多个子进程的最近的祖先关联起来。

八种游走方案如下：

a) 考虑 vi-1表示vi的父进程节点，若vi还有其他邻居，那么vi会跳到这些邻居；如果只有vi-1这一个邻居，那么vi将会返回至vi-1
b)、考虑vi-1表示vi的子进程节点，若vi的其他子进程节点与vi-1有数据依赖关系，比如访问同一资源节点，那么vi会选择走到其他子进程节点；否则，vi将会回到vi-1
c)、vi-1表示vi的唯一子进程节点（其他都是资源节点），表明vi和派生出vi-1来处理同样的数据，因此它们属于同一社区。因此，如果vi还存在其他资源节点邻居，那么vi将会去探索他们（因为要尽可能地将有联系的节点归到一个社区中）；但如果没有其他邻居，那么行走者将会返回至vi-1
d)、vi-1是一个进程节点，vi是一个资源节点（vi-1访问vi）。如果其他访问vi的进程节点与vi-1进程节点有一个共同的父节点，那么其他访问vi的进程节点可能属于vi-1的社区
e)、vi-1是一个资源节点，vi是一个有多个子进程节点的进程节点，且vi-2是vi的一个子进程节点。可以看出，vi-2进程节点访问vi-1这个资源节点。如此，vi的其他子进程节点不属于vi-2的社区。但是，如果vi的其他子进程节点与vi-2存在数据依赖关系，比如vi的其他子进程节点与vi-2存在访问同一资源节点，那么在跳转时，vi会倾向于（w=1）跳转至这些子进程节点以及vi-2，而不会跳转至那些没有数据依赖关系的子进程节点
f)、vi-1是一个资源节点（且被vi-2所访问），vi是一个有多个子进程节点的进程节点，且vi-2并不是vi的子进程节点。如此，将vi视为一个社区中的主节点，那么vi的子进程节点与vi-2将不会是同一个社区。因此，行走者将会返回至vi-1
g)、vi-1是一个资源节点，vi是一个有多个子进程节点的进程节点，并且vi=vi-2。这说明，vi-1是一个信息流的结束。为了增加对紧密进程节点的采样效率，行走者将会继续行走至vi的其他子进程节点，而不会去vi-1
h)、vi-1是一个资源节点，vi是最多只有一个子进程节点的进程节点。如此，如果vi有除了vi-1之外的其他邻居节点（进程/资源），那么行走者将会行走至这些邻居节点，并不会返回至vi-1。如果没有，为了防止终止行走，将会行走至vi-1
这八种游走序列是否遵循一个共同的规则？？

Process Node Representation

进程节点表示学习方法：
作者采用的是Word2Vec的Skim-Gram模型来进行进程节点表示的

Word2ec是从大量文本语料中以无监督的方式学习语义知识的一种模型，它被大量地用在自然语言处理（NLP）中。一个嵌入空间使得语义上相似的单词在该空间内距离很近。而Skip-Gram是给定input word来预测上下文，其主要可与分为两个过程（1）建立模型（2）通过模型获取嵌入词向量。
那么在这里我理解的是：通过游走序列作为输入建立模型，在通过模型获取每个节点的行为表示。在将具有相同行为表示的节点聚集到一起，形成社区
关于word2Vec的介绍

Process Node Clustering

进程节点聚类：

为了根据进程节点的行为表示计算其聚类（可能存在交叉），DEPCOMM采用了一种软聚类方法FCM （Fuzzy C-Means）。与硬聚类方法（如K-means）不同，FCM通过最小化目标函数来输出每个聚类中每个进程节点的隶属度：

其中，uij 表示进程节点vi属于社区cj的程度。如果uij高于给定的阈值，那么vi将分类至社区cj。根据最近的工作，我们设置阈值λ = 0.8·maxj{uij}。如果一个进程节点有多个社区（重叠），我们创建节点的多个副本，并将一个副本分配给每个社区。此外，DEPCOMM根据模糊划分系数（FPC）确定社区数量|C|：

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

社区压缩

DEPCOMM采用的是基于两种方式进行压缩
（1）Process-based Patterns：基于进程的模式反映的是，一个进程节点派生出重复的子进程节点，他们访问的是同一资源节点

进程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只选择具有相同父节点的重复子树，并将所选子树合并为一个子树。合并子树中每个节点和边的属性是原节点和边的属性并集.复的节点和边。具体步骤如下：
（2）Resource-based Patterns：基于资源的模式—将某一进程节点访问的所有资源节点合并成一个节点

社区摘要生成

InfoPath：社区中从输入到输出节点的信息流，那么一个社区可能不止一对输入输出节点，因此会有多个信息流。社区摘要的生成主要分为两个过程：
（1）InfoPath Ectraction:
对于每一对输入和输出节点(从输入到输出会有多个节点,采用DFS来搜索)，DEPCOMM使用深度优先搜索(DFS)算法寻找没有重复节点的最长路径作为InfoPath
（2）InfoPaths Prioritization:
(a) POI Event (fpoi). 包含POI事件的InfoPath与攻击直接相关
(b) 赋予输入或输出节点为进程的InfoPath更高的优先级:
© 出现在较少社区中的文件事件更有可能表示社区中的主要活动
(d) 时间跨度与社区时间跨度相似的InfoPath更有可能代表社区中的主要活动

实例分析：

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

其生成的依赖图如下：这里的图，是进过了社区检测和社区压缩之后的图；

这是其生成的对应的摘要图

根据这个实例进行分析，我们发现POI事件发生在C3社区，那么将与C3社区相关联的所有社区进行对比，我们很容易就发现C2社区与攻击事件相关联（根据InfoPath，C2与C3进程相关leak），那么再进一步将与C2社区相关联的所有社区进行对比，我们发现C1是更可能与攻击事件相关的社区，因此定位到C1社区。再对C1社区进行检测，没有与C1社区相联系的社区，因此认为C1是攻击事件的起点。

实验评估

DEPCOMM在实验设置中执行的6次真实攻击和来自DARPA TC数据集的8次攻击。总共有大约1.5亿个系统审计事件，生成的依赖图平均由1,302.1个节点和7,553.4条边组成。

RQ1: DEPCOMM在总结依赖关系图方面的总体效果如何?
在我们的评估中，DEPCOMM为一个依赖图平均生成18.4个社区，比原始图小了约70倍。这些社区平均包含43.1个节点和248.5条边。

RQ2: DEPCOMM如何与自动调查技术HOLMES合作?
与HOLMES合作的评估表明，除两个攻击相关的社区外，其他所有攻击相关的社区都映射到Kill Chain的步骤上（召回率为96.2%），通过考虑相邻的攻击社区，这两个未揭示的社区很容易被识别
RQ3: 与其他最先进的方法相比，DEPCOMM在社区检测(发现)方面的效果如何?
与9种最先进的社区检测算法相比，DEPCOMM的f1得分（94.1%）平均比其他算法的f1得分高2.29倍
RQ4: DEPCOMM在社区压缩方面的效果如何?
DEPCOMM根据检测到的基于进程和基于资源的模式压缩社区，平均压缩率为44.7%。压缩后的社区平均有15.7个节点和32.1个边，分别减少了63.6%和87.1%。
RQ5: DEPCOMM使用排名靠前的InfoPaths生成社区摘要的效果如何?
使用排名前2的InfoPaths可以有效地调查所有攻击，即平均15.7条InfoPaths中有2条作为摘要
RQ6: 在总结依赖关系图时，DEPCOMM的 turnaround performance 如何?
DEPCOMM的 turnaround time performance 可以通过并行分层行走和向量化进一步提高

这些结果表明，这些摘要图在攻击调查中需要的人工工作要少得多

Limitations of DEPCOMM

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

总结

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