摘要：
1. 创建了一个基于流的查询系统，该系统将来自企业中多个主机的实时事件提要作为输入，并提供了一个异常查询引擎，该引擎查询事件提要以基于以下内容识别异常行为指定的异常。
2. 为了简化根据专家知识来表达异常的任务，我们的系统提供了特定于域的查询语言SAQL，SAQL允许分析人员表达针对（1）基于规则的异常，（2）时间-系列异常，（3）基于不变式的异常和（4）基于离群值的异常。
3. 我们在包含150台主机的NEC Labs America中部署了我们的系统，并使用1.1TB的实际系统监视数据（包含33亿个事件）对其进行了评估。
现有缺点：现有的方法在使用系统监视数据检测多种类型的异常时面临挑战。
1.与apt等攻击做斗争。我们需要一个实时的异常检测工具来搜索apt,以防止进一步的损坏。
2.从数据得出的模型已越来越多的用于检测各种类型的风险事件，但是如何提供实时工具来检测异常，同时整合专家知识？
3.系统监控每天产生大量日志，这需要对大规模出处的数据进行高效的实时数据分析。
但是现有的系统都专注于特定的异常，通过结合专家知识为用户指定异常模型提供了支持。这些模型缺乏现有的针对通用数据流的流查询系统。
1. introduce
1. 贡献：我们设计并构建了一个新颖的基于流的实时查询系统。我们的系统采用了从企业中多个主机聚合的实时事件提要，并提供了异常查询引擎。查询引擎为用户提供了一种新颖的界面，使用户可以使用我们的特定于域的语言【基于流的异常查询语言SAQL】提交异常查询，并针对查询检查事件以实时检测异常。
2. 语言：【我没看懂】 SAQL提供（1）事件模式的语法，以简化指定相关系统活动及其关系的任务，从而有助于规范基于规则的异常； （2）滑动窗口和有状态计算的构造，允许在数据流的每个滑动窗口中计算有状态异常模型，这有助于规范时间序列异常，基于不变式的异常和基于异常值的异常。
3. 执行引擎：我们在Siddhi [20]的基础上构建查询引擎，以利用其成熟的流管理引擎。基于输入的SAQL查询，我们的系统综合了Siddhi查询以匹配流中的数据，并执行状态计算和异常模型构建以检测流中的异常。
该设计面临的主要挑战是在大规模系统监视数据上处理多个并发异常查询的可伸缩性。为了满足这些需求，现有系统采用的方法是制作流数据的副本，并将副本提供给每个查询，从而允许每个查询单独操作。但是这种方案在处理从系统监视中收集的大数据时效率不高。
为了解决这一挑战，我们设计了一种依赖于主服务器的查询方案，该方案可识别兼容的查询并将其分组，以使用流数据的单个副本来最大程度的减少数据副本。
我们的系统首先根据提交窗口中的滑动窗口对时间维度进行分析，并根据主机和事件属性对空间维度进行分析。根据分析结果，我们的系统将兼容查询分为几组，其中在每个组中，主查询将直接访问流数据，而其他相关查询将利用主查询的中间执行结果。请注意，这种优化利用了系统监视数据的时空特性和SAQL查询的语义，这对于基于一般流的查询系统[20、12、51、4]中的查询是不可能的。
4. 部署和评估：我们基于现有的系统级监视工具（即Audited [15]和ETW [13]）和现有的流管理系统（即Java）构建了整个SAQL系统（约50,000行Java代码）我们在由150个主机组成的NEC Labs America中部署了该系统。我们在部署的环境中执行了一系列广泛的攻击行为，并使用1.1TB的实际系统监视数据（包含33亿个事件）对系统进行了评估：
（1）我们对四种主要攻击行为类型进行了案例研究（ 17个SAQL查询）表明我们的SAQL系统具有较低的警报检测延迟（<2s）；
2）我们的压力测试表明，对于单个代表性的基于规则的查询（它监视文件访问），我们的SAQL系统具有很高的系统吞吐量（110000个事件/秒），并且可以在已部署的服务器上扩展到约4000台主机；
（3）我们使用64个微基准查询的性能评估表明，与Siddhi相比，我们的SAQL系统能够有效处理并发查询的执行并实现更有效的内存利用率，平均节省30％。所有评估查询都可以在我们的项目网站上找到[19]。
2. background and examples
1. present the background on system monitoring
2. show SAQL queries to demonstrate the major types of anomaly models supported by system.
1. system monitoring
系统监控数据以时间和时间的形式表示各种系统活动，每个事件可以描述为对另一个系统实体（对象）执行某些操作的系统实体（对象）。例如，进程读取文件或进程访问网络连接。
系统监视数据记录了有关系统调用的系统审核事件，这些事件对于安全性分析很重要。被监视的系统调用映射到三种主要的系统事件类型：1.过程创建和破坏，2.文件访问 3.网络访问。
在大多数情况下，系统的实体entity是文件，网络连接和进程。本文中将系统实体看作数据模型中的文件，进程和网络连接。我们将实体之间的交互定义为一个事件，该事件event使用三元组《主题，操作，对象》表示。根据事件实体的类型，我们将事件分为三类：文件事件，进程事件，网络连接事件。
实体【文件，进程，网络连接】的属性包括实体的属性，以及区分实体的唯一标识符。
事件的属性包括事件的起源，操作以及其他安全性相关的属性。
2. SAQL Queries for Anomalies ：SAQL异常查询
使用saql作为统一接口来指定各种类型的异常系统行为。
（1）基于规则的异常：高级网络攻击通常包含一系列利用多个系统中的漏洞窃取敏感信息的步骤。
（2）时间序列的异常：saql提供了滑动窗口的结构，以便能够指定时间序列异常模型。例如，SAQL查询可能会监视某些进程发送的数据量，并检测到在短时间内传输的意外大量数据。
（3）基于不变（invariant）的异常：基于不变的异常将训练期间的不变量捕获为模型，并在以后使用这些模型检测异常。SAQL提供了不变模型的构造和学习细节，以定义和学习系统行为的不变性，从而使用户可以将状态计算和在正常操作下学到的不变式结合起来进行检测更多类型的异常系统行为。
（4）基于异常值的检测： outlier-based anomaly。
基于异常值的异常允许用户通过对等比较来识别异常系统行为。例如，通过将异常过程与其他对等进程进行比较来找到异常过程。为了检测基于异常值的异常，SAQL提供了异常值模型的构造，以定义时间窗口中的哪些信息形成多维点，并计算群集以识别异常值。
3. 系统概述和威胁模型
我们在企业中的服务器，台式机和笔记本电脑上部署监视代理，以通过收集有关内核的系统调用信息来监视系统级活动。
Windows，Linux和Mac OS的系统监视数据是通过ETW事件跟踪[13]，Linux Audit Framework [15]和DTrace [8]收集的。收集的数据发送到中央服务器，形成事件流（system event stream ）。
该系统由两个组件组成：（1）使用ANTLR 4 [3]实现的语言解析器，对输入查询进行语法和语义分析，并为每个查询生成异常模型上下文【基于规则的查询，基于时间的，基于不变量的，基于异常值的】。异常模型上下文是输入查询的对象抽象，其中包含查询执行和异常检测所需的所有信息。 （2）建立在Siddhi [20]上的执行引擎监视数据流并根据异常模型上下文的执行情况报告检测到的警报。
执行引擎具有四个子模块：（1）多事件匹配器将流中的事件与查询中指定的事件模式进行匹配； （2）状态维护者维护根据匹配事件计算出的每个滑动窗口的状态； （3）并发查询调度程序根据与主相关的查询方案（第5.2节）将并发查询分为几组，以最大程度地减少对数据副本的需求； （4）错误报告程序在执行过程中报告错误。
威胁模型：SAQL是一个基于流的查询系统，用于对系统监视数据进行查询，因此，我们遵循有关系统监视数据的先前工作的威胁模型[63、64、69、68、32、50]。我们假设从内核空间[15，13]收集的系统监视数据未被篡改，并且内核是可信的。任何有意损害安全审核系统的内核级攻击均不在本工作范围之内。
我们确实认为内部人员或外部攻击者对已部署的SAQL查询和异常模型有全面的了解。他们可以通过看似“正常”的活动来发动攻击，以逃避SAQL的异常检测，并且可以通过模仿对等主机的行为来隐藏攻击，以避免SAQL的异常发现。
4 SAQL Language Design
SAQL提供了明确的结构来指定系统实体/事件以及事件的关系。这有助于规范基于规则的异常，以检测已知的攻击行为或实施企业范围的安全策略。SAQL还提供了用于滑动窗口和状态计算的构造，这些结构允许在数据流的每个滑动窗口中计算状态异常模型。这有助于规范时间序列的异常，基于不变式的异常和基于离群值的异常，它们缺乏现有的流查询系统和基于流的异常检测系统的支持。
4.1多事件模式匹配SAQL提供事件模式语法（格式为{subject-operation-object}）来描述系统活动，其中系统实体表示为主体和对象，而交互表示为由主体发起并针对的操作对象。另外，该语法直接支持事件时间关系和属性关系的规范，这有助于规范复杂的系统行为规则。
4.2有状态计算
基于滑动窗口的构造，SAQL提供了用于状态计算的构造，它包括两个主要部分：基于滑动窗口定义状态以及访问当前窗口和过去窗口的状态以指定时间序列异常，基于不变的异常和基于异常值的异常。
4.3警报条件检查
“ alert”规则指定触发警报的条件（布尔表达式）。 这使SAQL可以为时间序列异常（例如，查询2中的第5行），基于不变式的异常（例如，查询3中的第9行）和基于异常值的异常（例如，第7行）指定广泛的检测逻辑集 在查询4中）。 请注意，除了查询2中指定的移动平均检测逻辑外，SAQL的灵活性还可以指定其他众所周知的逻辑，例如3-sigma规则。
4.4返回和过滤器
“报告”规则指定要作为结果返回的合格事件的所需属性。 诸如group by，sort by和top之类的构造可用于进一步的结果操纵和过滤。 这些结构可用于查询最活跃的进程和IP地址，以及指定基于阈值的异常模型而无需显式定义状态。 例如，查询5在1分钟的滑动窗口中计算每个进程的IP频率，并返回频率大于100的活动进程。
5 SAQL Execution Engine
图2中的SAQL执行引擎将事件流作为输入，执行解析器生成的异常模型上下文，并报告检测到的警报。为了使系统在支持多个并发查询方面更具可伸缩性，该引擎采用了一个与主服务器相关的查询方案，该方案将语义上兼容的查询分组，以共享流数据的单个副本以执行查询。这样，SAQL系统可大大减少流的数据副本。
5.1 查询执行管道
给定一个SAQL查询，解析器将执行语法分析和语义分析，以生成异常模型上下文。查询优化器中的并发查询调度程序会根据当前正在运行的查询的现有异常模型上下文来分析新到达的异常模型上下文，并通过利用依赖于主服务器的查询方案来计算优化的执行调度。
多事件求解器分析SAQL查询中的事件模式及其相关性，并通过发出Siddhi查询来访问流中的数据来检索匹配的事件。如果查询涉及状态计算，则状态维护者会利用中间执行结果来计算和维护查询状态。如果查询满足警报条件，将生成警报。
5.2并发查询调度器
图2中的并发查询调度程序调度并发查询的执行。一种简单的调度策略是制作流数据的副本，并将副本提供给每个查询，从而允许每个查询分别操作。但是，系统监视会产生大量的每日日志[69，88]，并且这种复制方案会导致大量的内存使用，这极大地限制了系统的可伸缩性。
主从查询方案：为了有效地支持并发查询执行，并发查询调度器采用了主从查询方案。在该方案中，只有主查询可以直接访问数据流，而从属查询的执行取决于其主查询的执行。假设查询的执行管道通常涉及四个阶段（即，事件模式匹配，状态计算，警报条件检查和属性返回），则关键思想是维护从主查询到其依赖查询的映射M ，并让相关查询的执行在某些阶段共享其主查询的中间执行结果，从而可以显着减少流中不必要的数据副本。算法1显示了调度算法。
ATTACK CASES STUDY
APT ATTACK :
APT攻击：我们要求白帽黑客在部署的环境中进行APT攻击，如图3所示。攻击步骤如下：
c1最初的威胁：攻击者向受害者发送了一封精心设计的电子邮件。该电子邮件包含一个嵌入了恶意宏的Excel文件。
c2恶意软件感染：受害者通过Outlook客户端打开Excel文件并运行宏，该宏下载并执行恶意脚本（CVE-2008-0081 [6]），为攻击者打开后门。
c3特权升级：攻击者通过后门进入受害者的计算机，扫描网络端口以发现数据库的IP地址，然后运行数据库破解工具（gsecdump.exe）来窃取数据库的凭据。
c4渗透到数据库服务器：攻击者使用凭证渗透到数据库服务器，并提供一个VBScript来删除另一个恶意脚本，从而创建另一个后门。
c5数据泄漏：攻击者可以访问数据库服务器，使用osql.exe转储数据库内容，并将数据转储发送回其主机。
对于每个攻击步骤，我们都会构建一个基于规则的异常查询（即查询7至11）。此外，我们构造了3个高级异常查询：
我们构造一个基于不变式的异常查询（查询12）以检测Excel执行从未执行过的恶意脚本的情况：不变式包含前100个滑动窗口中Excel启动的所有唯一进程。在检测阶段，偏离不变的新过程将被报告为警报。此查询可用于检测由Excel启动的看不见的可疑Java进程（即步骤c2）。
•我们基于SMA构建时间序列异常查询（查询13），以检测通过数据库服务器上的网络交换大量数据的情况（即步骤c5）：对于数据库服务器上的每个进程，此查询可检测将异常大量数据传输到网络的进程。此查询可用于检测从数据库服务器传输的大量数据。
•我们还构造了一个基于异常值的异常查询（查询14），以检测将大量数据传输到网络的进程（即步骤c5）：该查询通过基于DBSCAN的对等比较来检测此类进程。这里的检测逻辑不同于查询13，后者通过与基于SMA的历史状态进行比较来检测异常。
请注意，这3个查询的构造假定不了解详细的攻击步骤。
8 Related Work
审计记录和取证：利用系统级取证进行取证分析已经取得了重大进展，重点是为攻击因果分析生成了取证图[74，75，63，64，32，69，88]。最近的工作还研究了如何过滤出处图中的无关活动[71]，以及如何减少在分布式系统（如数据中心）中产生的出处图的存储开销[57]。这些系统考虑了历史日志，并且其贡献与SAQL的贡献正交，这为调查人员从系统日志流中查询异常行为提供了一个有用且新颖的界面。尽管如此，SAQL可以与这些系统互操作，以通过简洁的出处图对检测到的异常进行因果分析。
高等。 [50]提出了AIQL，它可以通过查询存储在数据库中的历史系统审核日志来进行有效的攻击调查。 AIQL可用于调查由我们的SAQL系统在系统监视数据流中检测到的实时异常。这两个系统一起可以更好地防御高级网络攻击。
与安全性相关的语言：在各种安全领域中存在特定于域的语言，这些语言具有完善的低级算法语料库，例如密码系统[33，34，70]，安全覆盖网络[61，72] ]，网络入侵[36、44、82、86]和混淆[47]。这些语言被明确设计用于解决特定于领域的问题，为其特定的问题领域提供特定的构造，并避免不相关的功能。与这些语言相反，SAQL的新颖之处在于如何将异常模型指定为查询，以及如何在系统监视数据上执行查询。
安全异常检测：异常检测技术已广泛用于检测恶意软件[58、83、65、67]，防止网络入侵[89、90、80]，内部威胁检测[81]和攻击预测[87]。 。基于规则的检测技术通过分析来表征程序的正常行为，并检测在表征过程中未观察到的未知行为[49，58]。基于异常值的检测技术[89、90、80]基于聚类或其他机器学习模型来检测异常系统行为。与这些专注于发现有效特征并在不同情况下构建特定模型的技术不同，SAQL提供了一个统一的接口来基于专家的领域知识来表达异常。
复杂事件处理平台和数据流管理系统：复杂事件处理（CEP）平台，例如Esper [12]，Siddhi [20]，Apache Flink [4]和Aurora [29]将连续传入的事件与模式进行匹配。与传统的数据库管理系统不同，传统的数据库管理系统对存储的数据执行查询，而CEP查询则应用于可能无限的数据流，并且所有与查询无关的数据都会被立即丢弃。这些平台提供了自己的特定于域的语言，这些语言可以在滑动窗口的支持下组成复杂事件的模式。 Wukong + S [91]构建了一个可以查询流数据和存储数据的流查询平台。诸如CQL [51]的数据流管理系统[79]管理多个数据流并提供查询语言以处理流上的数据。这些CEP平台可用于管理大量数据流。因此，它们可以用作我们方法的管理基础结构。但是，仅这些CEP系统无法提供语言结构来支持滑动窗口中的状态计算，因此像我们的系统一样无法表达状态异常模型。
流计算系统：流计算系统允许用户基于流数据计算各种度量。这些系统包括Microsoft StreamInsight [31]，MillWheel [30]，Naiad [76]和Puma [41]。这些系统通常为无状态计算（例如，数据聚合）提供良好的支持。但是，它们不像我们的SAQL系统那样支持状态异常模型，该模型比数据聚合要复杂得多。其他系统分析语言：Splunk [21]和Elasticsearch [10]是自动解析常规应用程序日志并提供基于关键字的搜索语言以过滤日志条目的平台。 OSQuery [17，18]允许分析人员使用SQL查询来探查实时系统状态。但是，这些系统和语言本身不支持异常检测，也不支持滑动窗口中的状态计算。其他语言，例如Weir [37]和StreamIt [84]，则专注于监视系统性能，并且缺乏对表达异常模型的支持。
9结论
我们提出了一种新颖的基于流的查询系统，该系统采用实时事件提要，该事件提要是在监视下从不同主机聚合的，并提供了异常查询引擎，可根据安全分析人员提交的查询检查事件流以检测异常实时。我们的系统提供了一种特定于领域的语言SAQL，该语言专门设计用于简化基于领域知识来表达异常的任务。 SAQL提供事件模式的构造以轻松指定相关的系统活动及其关系，并提供结构化状态的计算，方法是在滑动窗口中定义状态并访问历史状态以计算异常模型。通过这些构造，SAQL允许安全分析人员针对（1）基于规则的异常，（2）时间序列异常，（3）基于不变式和（4）基于离群值的异常表示模型。我们对17个攻击查询和64个微基准查询的评估结果表明，SAQL系统具有较低的警报检测延迟和较高的系统吞吐量，并且比现有的流处理系统更有效地利用了内存。