NEC美国实验室是智能运维领域我长期在关注的一个组织。日志异常检测方面的LogMine和LogLens都出自该实验室。

今天又去看了一下,发现他们最近连着出了好几篇有关安全日志分析的论文,仔细一瞧,还真是有趣,记录下来,给大家分享一下。https://arxiv.org/pdf/1806.02290.pdf

论文中选定了APT攻击的三种常见场景,采集auditd和ETW日志,规划好数据模型,按照实体分组和时序分区的原则存入PostgreSQL,并设计了一个专门用于进行这种分析的DSL(攻击调查查询语言,AIQL),以及针对该模型和查询语言特定的存储和执行引擎。执行过程示意如下:

场景示例

比如上面第1个场景,最后的AIQL查询语句如下:

我们可以看到,这里面有着和普通SQL、SPL、CQL都完全不同的关键字:proc、start、read、write、before、after。(论文中有整个语法树,关键字不止这些)

这前4个,是典型的实体/关系模型,我们通常用图数据库的语法来描述:

MATCH evt4 = (p4:Proc{name:"sbblv.exe"})-[conn:CONNECT]->(i1:IP)
WHERE i1.dstip =~ /*.129/
RETURN evt4

而后2个,是典型的事件序列,我们通常用复杂事件处理的模式来描述:

every-distinct(evt4.name)
  evt1:StartEvent
  -> evt2:WriteFileEvent
  -> evt3:ReadFileEvent(name==evt4.procname)
  -> evt4:ConnEvent

但要把二者合二为一,还真是不怎么见过。

论文中除了对比测试不同实现下的分析耗时性能以外,还额外对比了一下不同实现下的查询语句的复杂度,见下表:

不过,上面说不怎么见过,不代表真的没有。其实还真有一家公司有,这就是SIEM魔力象限里位居中流的LogPoint公司:https://www.logpoint.com/en/

LogPoint公司的SPL是同时兼容普通的搜索统计和流式事件处理的。按照上面的例子,auditbeat日志用LogPoint的SPL语法写,大概会是这样(只看过文档没试用过):

[tag=audit event.action=write_file process.name="sbblv.exe"] as evt3
followed by
[tag=audit event.action=network_flow destination=/*.129/] as evt4
on evt3.process.name = evt4.process.name
| table evt4.process.name, evt4.destination, evt3.file.path

看起来好像也不是多很多字?——那是因为auditbeat已经是一个event输出一条日志了,如果是采集的原始auditd日志,一个event有三四条分开的日志记录。那么还要用having same event.id within 5 seconds来先做一次合并。一下子就膨胀很多了~~

总之,能够针对场景实现自定义的DSL语法,真的是很舒服和省力的做法。