文章目录

  • 1 摘要
  • 2 介绍
    • 2.1 方法概览
    • 2.2 贡献
      • 2.2.1 基于内存的依赖图表示
      • 2.2.2 基于标签
      • 2.2.3 利用标签进行溯源和影响性分析
      • 2.2.4 可定制的策略框架
      • 2.2.5 实验评估为DARPA TC项目
  • 3 主存依赖图
  • 4 标签和攻击检测
    • 4.1 标签设计
    • 4.2 基于标签的攻击检测
  • 5 策略框架
    • 5.1 标签初始化策略
    • 5.2 标签传播策略
  • 6 基于标签的双向分析
    • 6.1 回溯分析
    • 6.2 前向分析
  • 7 实验评估
    • 7.1 数据集
    • 7.2 重建结果
    • 7.3 总体效果
    • 7.4 误报
    • 7.5 运行时间和内存使用
    • 7.6 为数据和代码分别分配标签的好处

原文标题:SLEUTH: Real-time Attack Scenario Reconstruction from COTS Audit Data

原文作者:Md Nahid Hossain, Stony Brook University; Sadegh M. Milajerdi, University of Illinois at Chicago; Junao Wang, Stony Brook University; Birhanu Eshete and Rigel Gjomemo, University of Illinois at Chicago; R. Sekar and Scott Stoller, Stony Brook University; V.N. Venkatakrishnan, University of Illinois at Chicago

原文来源:USENIX 2017

原文链接:https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/hossain

1 摘要

本文提出了一种可以在企业主机上实时重构攻击场景的方法和系统——SLEUTH,开发了一种平台无关基于主存的审计日志数据依赖图抽象

本文提出了一种基于标签的技术来分析攻击行为,包括源识别和影响分析。同时本文通过构建简洁、可视的攻击步骤来揭示攻击的总体情况。系统所用的评估数据仍然来自DARPA组织的红队攻击。

2 介绍

像IDS和SIEM这样的工具会产生大量的信息,安全分析人员从中辨别出真正的攻击变得十分困难;而且,对于跨越多个应用、主机以及时间跨度很长的攻击行为,分析人员缺乏工具将这些片段拼凑起来。因此,分析人员所需要的工具不仅能够检测攻击,而且能够产生基于因果的攻击链的简单总结。据此,分析人员可以快速判断系统是否遭受了入侵、了解攻击者是如何发动攻击的以及确定攻击带来的影响。

实时检测相对于取证分析(Forensic Analysis)而言,存在下面几个挑战:

  • 事件(Event)存储和分析:如何高效地存储上百万条记录,并在几秒钟的时间内筛选这些数据
  • 将实体(Entities)按优先级排序:如何协助分析人员,在大量的数据中优先选出并放大最有可能是攻击行为的场景。
  • 场景重构:如何从攻击者的入口点开始,简洁地总结攻击场景,并识别整个攻击行为的影响
  • 处理常见的使用场景:如何处理类似于攻击期间活动的正常行为,如软件下载
  • 快速地交互式推理:如何让分析人员通过数据有效地进行推理,比如在“可选择性假设”的情况下。

2.1 方法概览

来自不同操作系统的审计数据被处理成平台独立的图,其中顶点表示subjects(进程)和objects(文件、sockets);边表示审计事件(读、写、执行等操作;连接)。这个图作为攻击检测、关联分析和场景重构的基础。

2.2 贡献

2.2.1 基于内存的依赖图表示

为了应对第一个挑战,本文开发了简洁的基于内存的依赖图表示,解决了如何高效地存储和分析事件的问题。基于主存的图算法可以比基于硬盘快几个数量级,这是本文能做到实时分析的一个重要因素。在实验中能够在14秒内处理79小时的FreeBSD审计数据,内存消耗84MB,该速度比数据生成速度快20K倍。

2.2.2 基于标签

为了应对第二个挑战,本文开发了基于标签(tag-based)的方法来识别最有可能涉及攻击的subjects、objects和events。标签代表对数据(objects)和进程(subjects)的**可信度(trustworthiness)敏感度(sensitivity)**的评估。

2.2.3 利用标签进行溯源和影响性分析

为了应对第三个挑战,本文开发的算法可以使用标签来对攻击进行溯源和影响性分析。从告警产生的位置来时,回溯分析算法可以根据图中的依赖性识别攻击的源头;从攻击源头开始,前向搜索算法可以进行全面的影响分析。同时,本文提出了一些准测用来修剪这些搜索过程,从而生成简洁的图。实验结果表明,SLEUTH可以将38.5M的事件转换为包含130个事件的攻击场景图,其大小降低了5个数量级。

2.2.4 可定制的策略框架

为了应对最后两个挑战,本文提出了可定制的策略框架,用于标签的初始化和传播。本文的框架给出了合理的默认值,但也可以根据特定的操作系统或应用来进行调整,从而避免误报。

分析人员还可以测试攻击的“可选择性假设”,如果分析人员怀疑某个行为是攻击的结果,可以使用策略捕获这些行为,然后重新运行分析以发现其原因和影响(重放)。由于其处理和分析比数据的生成快上万倍,所以可以对假设进行高效、并行、实时的测试。

2.2.5 实验评估为DARPA TC项目

在此次评估中,攻击活动模拟现代的APT组织在Windows、FreeBSD和Linux上展开了为期两周的攻击。在评估中,SLEUTH可以做到:

  • 在几秒钟的时间内,处理包含数千万事件的审计日志
  • 成功地检测和重构攻击细节,包括攻击入口点、在系统中的活动和逃逸点
  • 过滤与攻击不相关的事件(削减率可以到达100K倍),从而可以提供一个关于攻击的几乎没有噪声的语义表示
  • 较低的误报率和漏报率

该系统设计的目的不在于检测出最高级的APT攻击,而是在给定许多未知可能性的情况下,不需要人工干预,该系统就能够实时的给出一个按照威胁程度排列的结果。

3 主存依赖图

为了支持快速检测和实时分析,本文以图作为数据结构存储依赖关系。一种可行的方法是使用图数据库,例如Neo4J、Titan,但是除非内存足够大,否则这些数据库在运行许多图算法时会受到限制;另外,对于我们的问题来说,一般的图数据库内存消耗太高,即便是进行过内存优化的两个图数据库STINGER和NetworkX,存储一条边也要消耗250 bytes和3 KB。因此,本文提出了一种更加节省内存的依赖图设计,每条边仅占10 bytes,在实验中存储38M的事件仅需要329MB的内存。

依赖图包含两种类型的实体

  • Subjects:

    • 表示进程;
    • 属性值包括:process id(pid)、命令行、所有者(owner)以及代码和数据的标签
  • Objects:
    • 表示实体,例如文件、pipes、网络连接
    • 属性值包括:名称、类型(文件、pipe、socket等)、所有者和标签

事件:subjects和objects之间或者两个subjects之间带标签的边,用read、connect、execveread、connect、execveread、connect、execve来表示

为了减少依赖图的存储需求,在所有可能的地方,使用32-bit的标识符而不是64-bit的指针,这使得单台主机的依赖图可以存储40亿的subjects和objects,我们所使用的数据集远小于该数字。

本文的设计强调实体的简洁数据结构,然而事件的简洁性更为重要。因为事件的数量要比实体大两个数量级,而且事件和实体的比例随着时间而增加。因此我们需要为事件设计一个更加简洁的表示,使许多事件仅用6 bytes就能表示。

事件存储在subjects中,从而消除了subject-event的指针、事件标识符(event id)的需求。他们的表示采用可变长编码,在通常情况下可以采用4 bytes,当需要时可以扩展到8、12或者16 bytes。

(不懂)大多数事件是对objects进行操作,并且有时间戳。由于每个subject的事件顺序保持不变,因此我们无需为时间戳设置微秒级的粒度,而是选择了毫秒级的粒度。另外,我们仅存储同一subject中自上一个事件以来的相对时间,这使得我们在通常情况下可以使用16-bits来表示时间戳。

object使用索引指向object标识符per-subject表。这些索引可以看作文件描述,他们通常都是一些较小的值,因为大多数的subjects使用了相对较少的objects,这使得object引用(索引??)可以用8 bits或更少来表示。

我们用3 bits或更少对经常出现的事件名称进行编码,如open、close、read和write。这给我们留下了几位用于存储事件变量信息的摘要,同时仍在32位之内。

(重要)对于取证分析来说,需要我们从object追溯subject。鉴于此,我们需要使用object-event记录来维护objects中的事件信息。该记录仅维护事件的一部分子集,具体而言,比如像read和write这样会导致数据流的事件。object-event记录可以通过存储一个指向对应subject-event记录的引用来进一步收缩,而不是复制完全一样的信息。

类似于subject-event记录,我们对object-event记录也采用可变长编码,使得他们在通常情况下只需要16 bits来存储。我们注意到,object一次仅被一个subject操作,这个subject可能会在该object上进行一系列的动作,比如打开、读、写、关闭。每个动作都对应一个subject-event记录和object-event记录,由于这些记录的subject和object是相同的,所以我们可以在object-event记录中重用subject,从而在大多数记录中可以不存储subject标识符。

接下来,我们允许object-event记录为subject中的事件记录存储一个相对索引,subject中两个连续的事件记录可能比较接近,一般会是几十或者几百个。这意味着存储在object-event记录中的相对索引大多数情况下12 bits就够了,所以我们分配16 bits足矣。

(总结)这种设计使我们使用6 bytes就可以存储双向的带时间戳的边,subject-event记录占4 bytes,object-event记录占2字节。在实验中使用更大的数据集时,平均每个事件占用内存也在10 bytes以内。可变长编码还使得我们可以表示重要但出镜率比较少的事件,比如rename、chmod、execve等rename、chmod、execve等rename、chmod、execve等。

4 标签和攻击检测

问题:标签是什么??

我们使用标签来描述objects和subjects的可信度和敏感度。对可信度和敏感度的评估基于以下三个因素:

  • 起源(Provenance):依赖图中,subject或object直接祖先的标记
  • 系统先验知识:我们对一些重要应用行为的了解,比如远程接入服务器、软件安装程序和重要的文件(/etc/passwd 和 /dev/audio)
  • 行为:观察subject的行为,并将其与预期行为进行比较

一个默认的策略被用从从input到output传播标签:为output分配input的可信度标签中的最低值,以及机密性标签的最大值(也就是说,入口点的行为是危险的,出口点的行为也被标注为危险;入口点的数据是机密的,出口点的数据也被标注为是机密的)。这是一种保守的策略,该策略可能会导致一些良性事件被错误地识别为恶意事件(over-tainting),但绝不会漏掉攻击。

标签在SLEUTH中扮演了核心角色。它为攻击检测提供了重要的上下文信息,每个事件都在这些标记组成的上下文中进行解释,以确定其导致攻击的可能性。此外,标签对我们的前向和回溯分析的速度也很有用。最后,标签为消除大量与攻击无关的审计数据也起到了关键作用。

4.1 标签设计

如下定义可信度标签(trustworthiness tags,t-tags),可信度依次降低:

  • 良性可信标签(Benign authentic tag):为数据和代码分配该标签,其来源(source)为良性且可靠性可被验证
  • 良性标签(Benign tag):为数据和代码分配该标签,其来源为良性,但是来源可靠性未被充分验证
  • 未知标签(Unknown tag):为数据和代码分配该标签,但是其来源未知

策略(policy)定义了那些来源是良性的,哪些来源验证时充分的;策略的最简单情况是白名单。如果对于某个源,没有策略应用在它上面,那么这个源则被打上未知标签。

如下定义机密性标签(confidentiality tags,c-tags),机密性依次降低:

  • Secret:高度敏感的信息,例如登陆凭证、私钥
  • Sensitive:数据的披露可能会对安全产生重大影响,例如,披露了系统中的漏洞,但没有为攻击者提供访问系统的直接途径。
  • Private:资料的披露涉及私隐,但未必构成安全威胁。
  • Public:可以被公开的数据

我们设计的一个重要方面是分离代码和数据的t-tag。具体而言,即一个subject给定两个t-tag,一个表示其代码可信度(code trustworthiness,code t-tag),另一个表示其数据可信度(data trustworthiness,data t-tag)。这样的设计可以削减重建场景的规模,加快取证分析的速度。而机密性标签仅仅与数据相关联。

(重要)已经存在的objects和subjects使用标签初始化策略分配初始标签。在系统执行过程中还会产生新的objects和subjects,它们由标签传播策略分配标签。最后,基于行为的检测策略来检测攻击。

4.2 基于标签的攻击检测

检测方法不应该要求知晓特定应用的一些细节,因为这需要有关应用程序的专家知识,而在动态环境中,应用程序可能会频繁更新。

我们不把着眼点放在变化的应用行为上,而是着眼于攻击者的高级别目标,比如后门插入和信息窃取。具体而言,我们结合了攻击者的动机和手段的推理,注意到我们提出的标签就是用来捕获攻击者的手段:如果一段数据或代码有未知标签未知标签未知标签,那么它就是由不受信任的源产生的。

根据攻击者的攻击步骤,我们定义了下面包含攻击者目标和手段的策略(Detection Policy):

  • 不受信任的代码执行:当一个拥有高code t-tag的subject执行或加载拥有低t-tag的object时,便会引发警报
  • 被拥有低code t-tag的subject修改:当拥有低code t-tag的subject修改一个拥有高t-tag的object时,便会引发警报。修改的可能是文件内容或者文件名、文件权限等。
  • 机密文件泄露:当不可信的subjects泄漏敏感数据时,将触发警报。具体地说,也就是具有sensitive c-tag 和 unkonwn code t-tag的subject在网络中执行写操作时会触发警报。
  • 为执行准备不可信的数据:该策略由一个拥有unknown t-tag的subject的操作触发,该操作使一个object可执行。这样的操作会包含chmod和mprotect

一点优势:值得注意的是,攻击者的手段并不会因为数据或代码经过了多个中间媒介之后而被“稀释”。啥意思呢?举个栗子:对于不受信任的代码执行策略来说,如果直接从未知网站加载数据的话,当然会触发警报。但是,当这些数据是被下载、提取、解压缩,甚至有可能是编译之后再加载的,在经过了重重转化之后,只要数据被加载,该策略仍然能够被触发。随后再进行回溯分析,就可以找到漏洞利用的第一步。

与其它探测器合作的能力)另外,其它检测器的输入可以很容易地被集成到SLEUTH中。比如说,某个外部的检测器将一个subject标为可疑,这个时候再SLEUTH中可以将该subject的code t-tag标为unknown,从而后面的分析都会受益。此外该操作也会保留图节点之间的依赖关系。

被不受信的代码执行所触发的策略,不应该被认为工作在静态环境中(需要动态匹配策略),静态环境意味着不允许新代码产生。实际上,我们期望可以连续地更新和升级,但在企业环境中,我们不希望用户下载未知代码。因此,下面会叙述如何支持标准化的软件更新机制

5 策略框架

本文开发了一个灵活的策略框架(policy framework),用于标签的分配、传播和攻击检测。我们使用基于规则的记法来描述策略,例如:

exec⁡(s,o):o.ttag<benign→alert("UntrustedExec")\operatorname{exec}(s, o): o.ttag < benign \rightarrow alert ("UntrustedExec")exec(s,o):o.ttag<benign→alert("UntrustedExec")

这条规则被触发的条件是:当一个subject sss执行了一个object ooo(比如文件),而ooo的t-tag要小于良性。

在该策略框架中,规则通常与事件关联,并且包含objects或subjects的属性的一些条件,这些属性包括:

  • name:使用Perl正则表达式来匹配object namesubject命令行
  • tags: 条件中可以放置objects或subjects的t-tags或者c-tags。对于subjects来说,代码和数据的t-tag可以分别使用
  • 所有权和权限:条件中可以放置objects和subjects的所有权,或者objects和事件权限

不同类型的策略有不同的作用:

  • 检测策略:引发警报
  • 标签初始化和传播策略:修改标签

(干嘛的?)触发点(trigger points):为了更好地控制不同类型策略的匹配,我们将策略与触发点联系起来。此外,触发点允许有相似目的的不同事件共享策略。

上图展示了策略框架中定义的触发点,definedefinedefine表示一个新的object,比如一个新网络连接的建立、首次提及一个已经存在的文件、新文件的创建等。

(检测策略匹配过程)当事件出现时,检测策略就会被执行。后面,除非手动配置,否则仅当目标subject或object(某个信息流的终点,Target)发生变化时,检测策略才会被再次执行。

(标签策略)然后,标签策略按照指定的顺序进行尝试,一旦规则匹配,被规则指定的标签将会被分配给目标事件(Target,也就是subject/object)

5.1 标签初始化策略

该策略被init trigger​唤醒,然后将初始化标签应用于新的objects(subject呢?),或者早已存在但是在审计数据中第一次提及的objects。回顾一下,当一个subject创建了一个object的时候,默认object会继承该subject的标签,但是用标签初始化策略会将其覆盖。

仍使用正则表达式来为object定义初始化标签:

5.2 标签传播策略

该策略可以覆盖默认标签。

该策略还可以防止“过度污染”,例如某应用每次被唤醒的时候,都会读写.bash_history.bash\_history.bash_history文件,但是该操作是正常的,下面的策略对该文件不进行任何操作:

下面的策略将bash读取文件的行为视为加载(load):

下面的策略对sshd的行为进行任何操作。虽然受信任的服务,比如sshd会与不受信的站点进行交互,但是这些服务被认为可以自我保护,并且仅允许授权用户访问系统,因此这样的服务不应该给他们的数据可信度降级。同样从不受信站点下载的软件安装包或更新包,但是在安装之前会验证受信的软件提供商前面。

另外,当登录阶段完成之后,通常通过执行setuid操作来标识,所以应该为进程分配适当的标签:

6 基于标签的双向分析

6.1 回溯分析

回溯分析的目标是识别攻击的入口点,入口点是图中入度为0的节点,并且被标记为untrusted。通常是网络连接,但有时也会是其他形式,比如U盘中的文件。

回溯分析的起点是检测策略产生警报的地方。每个警报都与一个或多个实体相关,这些实体在图中被标记为可疑节点。反向搜索涉及对图的反向遍历,从而识别由可疑节点连接到入口点的路径。我们注意到,在这样的遍历和接下来的讨论中,依赖关系边的方向是相反的。反向搜索带来了几个重大挑战:

  • 性能:依赖图可能包含数亿条边。警报数可以达到数千。在这么大的图上执行反向搜索,会消耗大量的计算资源。
  • 多路径:通常,从可疑节点向后可访问多个入口点。然而,在APT攻击中,通常只有一个真正的入口点。因此,简单的反向搜索可能会导致大量的误报

标签可以用来解决这两个挑战。一方面,标签的计算和传播本来就是一种简洁的路径计算。另一方面,如果节点的标签值是unknown,那么该节点很有可能会构成攻击路径。如果节点A的标签是unknown,这意味着至少存在一条路径,从不受信任的入口点指向节点A,这样节点A就比其他拥有良性标签的邻居节点更有可能是攻击的一部分。使用标签来进行反向搜索,消除许多无关节点,极大地减少了搜索空间。

基于此,我们将反向分析当作最短路径问题的一个实例,标签被用来定义边的代价(cost)。一方面,标签能够“引导”搜索沿着攻击相关的路径,并远离不相关的路径。这使得搜索可以在不必遍历整个图的情况下完成,从而解决了性能方面的挑战。另一方面,最短路径算法通过选择最接近可疑节点的入口点(以路径成本衡量)来解决多个路径的挑战。

计算最短路径使用Dijkstra算法,当入口点被加入到路径中时,算法就停止。

代价函数设计:对于那些表示节点依赖关系的,如果其标签是**“未知”,则为其分配较低的开销**;其它节点分配较高的开胶,具体地说:

  • 从一个“未知”数据/代码 t-tag 的节点,到一个“良性”代码/数据 t-tag 节点的边,为其分配代价为0
  • 从一个“良性”代码/数据 t-tag 的节点引出的边,为其分配一个较高的代价
  • 从已有“未知” tag 的节点之间引入边,为其分配代价为1

与未知 subject/object 直接相关的良性 subject/object 表示图中恶意和良性部分之间的边界。因此,它们必须包含在搜索中,因此这些边的代价是0。

良性实体之间的信息流动不是攻击的一部分,因此我们将它们的代价设置得非常高,以便将它们排除在搜索之外。

不可信节点之间的信息流可能是攻击的一部分,因此我们将它们的代价设置为一个较低的值。它们将被包括在搜索结果中,除非由较少边组成的可选路径可用。

6.2 前向分析

前向分析的目的是为了评估攻击的影响。通过从一个入口点开始,发现所有依赖于入口点的可能影响。与反向分析类似,主要的挑战是图的大小。一种简单的方法是,标记所有从入口点可到达的 subject/object,这些 subject/object 是通过反向分析得到的。不幸的是,这种方法将导致影响图太大。

在实验中,利用这种方法得到的影响图包含数百万条边,利用我们的简化算法可以降低100到500倍。

一个降低其大小的方法是使用距离阈值dthd_{t h}dth​,来排除那些距离可疑节点太远的点,分析人员可以调节该阈值。我们使用在回溯分析时使用到的 cost 。

(为什么回溯分析不考虑??)不同于回溯分析的是,我们考虑机密性。特别的,一条边两端的节点,一个由高机密性标签,另外一个具有低代码 integrity(可信度??) 标签(如未知进程)或者低数据 integrity 标签(如未知socket),那么为这条边分配代价为0;而当另一个节点由良性标签时,为其分配较高代价值。

7 实验评估

(请求公开源码)

7.1 数据集

数据集同样来自DARPA TC项目,时间跨度为358小时,包含7300万事件。最后一行是历经3-5天从4台Linux服务器上收集到的良性数据,是本文作者在其实验室中自己生成的。

7.2 重建结果

(1)下图是W-2的攻击场景图:

(2)下图是F-3的攻击场景图,攻击者使用窃取的ssh凭证

  • scp:secure copy,用于远程文件拷贝

7.3 总体效果

(1)经典APT攻击阶段汇总

除了上述阶段,其它比较重要的APT阶段包括后门植入C&C服务器痕迹清除(包括攻击过程中投放的可执行文件和创建的文件)和数据窃取

下图通过计数关键文件、网络连接、攻击涉及的程序数量,将攻击场景重建结果分割:

其中,入口实体包括入口点以及与入口点进行通信的进程。Exit Points用于逃逸,比如网络套接字。

7.4 误报

评估SLEUTH在良性环境下的表现,用到了作者在自己的实验室中生成的良性数据。四台服务器上的数据主要来源于软件的更新和升级:

正如前面所提到的,策略应该配置为:允许使用企业中批准的标准方法进行软件更新和升级。对于Linux来说,我们有一个策略规则允许这样的操作:当使用apt命令或者unattended-upgrades执行dpkg时。因此,所有10K+的文件下载被标注为良性,而SLEUTH也没有产生警报

7.5 运行时间和内存使用

测试环境是搭载2.8GHz AMD Opteron 62xx 处理器和48GB主存的Ubuntu 16.04


例如L-2,SLEUTH使用了大约329MB内存来存储跨越3.5天所产生的38.5M的事件。在大数据集中,SLEUTH只需要8 bytes内存来存储每个事件;而小数据集中需要20 bytes.(why ?)

第四行展示了总运行时间,包括消耗数据集、构建依赖图、检测攻击、重建攻击场景。由于我们使用了标记,因此分析所需的大部分信息都可以在本地获得。这是我们性能提升的主要原因。

“Speed-up”一栏说明了SLEUTH的性能优势。它是SLEUTH可以同时处理的数据流的数量,如果CPU的使用是唯一的限制的话。

7.6 为数据和代码分别分配标签的好处

通过在代码可信度上进行检测和前向分析,可以削减掉大量的警报,极大减小前向分析输出的规模。

下图展示了使用单个的可信度标签和分离可信度标签(code/data)时,所产生报警数目的不同,注意到在一些情况下,报警数量减少了100-1000倍:

下图展示了因为标签的分割,前向分析所达到的提升。前向分析的输出被输入到简化引擎中,结果如第六行所示;Total列是Split t-tag和SLEUTH Simplification共同作用的结果。

Paper Note - SLEUTH:基于COTS审计数据的实时攻击场景重构相关推荐

  1. 【Paper Note】基于情感分析和关系网络的影视产品评论数据文本挖掘研究

    中国知网链接 摘要 [目的]为了挖掘观众对影视产品的主观感受,建立合适的模型评估影视产品的质量. [方法]本文通过对web影视作品评论数据建立评估模型,通过LDA和关系网络进行分析研究,并将结果与影视 ...

  2. 【Paper Note】基于决策树算法的电信运营商客户流失预测

    1.引言 随着互联网业务的速发展,移动业务市场的客户流失预警成为每一个电信运营商重点关注的内容,在商务智能与机器学习快速发展的当下,运用数据挖掘的方法,实现对电信客户的挽留.转化.精准营销越来越彰显其 ...

  3. CPS攻击案例(一)——基于脉冲宽度调制PWM的无人机攻击

    本文系原创,转载请说明出处 Please Subscribe Wechat Official Account:信安科研人,获取更多的原创安全资讯 原论文链接:sec22-dayanikli.pdf ( ...

  4. PostgreSQL 业务数据质量 实时监控 实践

    2019独角兽企业重金招聘Python工程师标准>>> 标签 PostgreSQL , pg_stat , 实时质量监控 背景 当业务系统越来越庞大后,各个业务线的数据对接会越来越频 ...

  5. Paper Note - HOLMES:基于可疑信息流的实时APT检测

    文章目录 1 简介 1.1 杀伤链模型 1.2 研究现状 1.3 本文创新点 1.4 解决的主要问题 2 方法提出 3 系统设计 3.1 数据收集和表示 3.2 TTP规范 3.3 HSG构建 3.4 ...

  6. Paper Note - 基于高效数据流标记和跟踪的可精炼跨主机攻击调查

    原文标题:Enabling Refinable Cross-Host Attack Investigation with Efficient Data Flow Tagging and Trackin ...

  7. 基于 PacBio 测序数据的纠错算法评测与剪切位点识别研究

    基于 PacBio 测序数据的纠错算法评测与剪切位点识别研究 摘 要 高通量测序技术的产生和发展催生了许多大规模基因测序项目, 如国际千人基 因组计划. 英国 UK10K 计划以及中国的百万人群基因组 ...

  8. 大数据主题分享第三期 | 基于ELK的亿级实时日志分析平台实践

    猫友会希望建立更多高质量垂直细分社群,本次是"大数据学习交流付费群"的第三期分享. "大数据学习交流付费群"由猫友会联合,斗鱼数据平台总监吴瑞诚,卷皮BI技术总 ...

  9. 如何基于DataWorks构建数据中台?

    简介:为了应对众多业务部门千变万化的数据需求和高时效性的要求,阿里巴巴首次提出了数据中台的概念,经过众多项目的实践已经沉淀出了标准化的流程和方法论.如何构建一个数据中台?一个好的数据中台需要具备哪些功 ...

最新文章

  1. C笔记(2014-12备份)
  2. GXGetImage方式连续采集和发送软触发采集
  3. 聊一聊:拿到年终奖后马上辞职,厚道吗?
  4. Windows删除指定时间之前指定后缀名的文件
  5. Struts2中ActionContext和ServletActionContext
  6. C语言-动态内存管理
  7. php dbutils 使用,dbutilsapi
  8. 风控贷中环节应该监控哪些风险指标
  9. RSTP比STP快在哪?
  10. 七月算法机器学习4 凸优化初步
  11. 聚类和分类算法的区别
  12. python读取csv数据出错_使用Pandas在python中读取csv文件时出错
  13. BI项目篇——项目启动
  14. MySQL数据库的恢复-mysql数据库的恢复
  15. html单元格下拉菜单怎么做,Excel 2013如何制作下拉菜单?(excel下拉菜单怎么做?)...
  16. Blender 合成节点 中英文对照
  17. Qlik Sense 集合表达式
  18. word去除各种下划线
  19. Gitlab权限说明
  20. SDUT OJ C语言实验——Hello World!(printf练习)

热门文章

  1. MyBatis(2.1) 增删改查 mysql java
  2. 华北电力大学2021年高等代数试卷
  3. 英文自我介绍(考研/校内面试/复试)
  4. altera CPLD通过nios在线升级
  5. 解读采用DSP工业电机控制系统电路_电动机控制电路图讲解
  6. 市场营销学【最精典】案例分析
  7. 计算机大赛可以跨学校组队吗,大学生创新创业大赛可以跨校组队吗
  8. 苹果销量第一,棉鞋成养生必备?视频号热销商品还有哪些?
  9. libgdx 处理加速传感器
  10. 【整理】常用电子设备功耗(不定期更新)