致我心中的 “散装”(开源)SIEM(一) – 作者:Shell.

写在前面

本篇《致我心中的 “散装”(开源)SIEM(一)》着重介绍的是对于数据流的处理,喜欢的朋友可以关注一下。

背景

由于工作比较忙,有段时间没有更了。这段时间主要精力都是在围绕着安全运营这一块的工作,随着工作的开展发现自己“组装”的SIEM用起来不是很“舒服”。这是我之前写的一篇《Wazuh:如何对异构数据进行关联告警》的文章,这是当时规划的Workflow:

a

1607572242_5fd19b1289bddc86004ba.png!small
“散装”(基于开源)SIEM主要是建立在ELK的框架之上,告警模块分别采用了Wazuh与Elastalert。早期为了使Wazuh能够消费异构数据(WAF、NTA、EDR)并进行关联告警,我在数据入库之前利用Logstash对异构数据进行了标准化,同时Wazuh对标准化后的数据进行关联。例如:Suricata通过Filebeat将告警事件发出,由Logstash统一进行标准化处理并同时输出到Elastic以及Wazuh。其中Elastic为告警的元数据,推送到Wazuh上的为标准化后的安全事件。

“散装”SIEM v0.1的不足与改进措施

1. 数据标准化

由于前期的标准化未采用ECS(Elastic Common Schema),导致后期沿用Elastic生态的时候出现了使用上的不便。大家都知道ES在7.X的版本推出了SIEM这个功能,如果想使用Elastic SIEM进行分析的话,那么ECS是首选。这里为了后期与开源生态更好的进行融合,需要将原先的标准化转为ECS的格式。

2. 告警丰富化

为了更有效的提升告警质量,提高安全分析的效率。需要对入库的安全事件以及产生的告警进行必要的丰富化。

  • 利用CMDB平台的数据对内部资产进行丰富化。例如增加:部门、业务、应用类型、负责人等字段。

  • 对接威胁情报数据,SIEM会对告警事件的攻击IP进行情报侧数据的丰富化;

    • 开源

    • 商业

    • 本地威胁情报(曾经攻击过我们的IP地址)

    • 第三方威胁情报

  • 敏感接口监控(如:登录接口、支付接口、钱包接口)。利用第三方数据对IP地址进行Proxy标记,为后期风控的研判提供一些数据支撑;

  • 为安全事件增加方向与区域的字段。便于分析人员第一时间识别内对内以及内对外的告警。也可针对方向进行告警级别的权重调整;

3. 提升检测能力

底层安全设备的检测能力与安全事件的可信度,是直接影响SIEM告警的关键因素。

  • 接入Imperva WAF的告警数据,与Suricata进行自动化关联,定期将绕过的规则“移植”到前端的Imperva WAF上,加强边界的安全防护能力;

  • “消费”AWS VPC FLOW数据,增加内对外的异常连接检测能力。由于是四层数据能够被“消费”的维度实在不多。主要实现了以下几种告警:

    • 短时间内,内网主机请求相同目的IP的多个端口

    • 短时间内,内网主机请求多个IP的相同目的端口

    • 周期性连接告警

    • 威胁情报类告警

    • 端口扫描类告警

    • 敏感端口请求告警

4. 溯源分析

目前SIEM产生的告警,并不会携带原始的安全事件,这对于分析小伙伴来说并不友好,特别是告警量比较多的时候。

现已为每一个告警增加了“Hunting”的字段,通过该字段可直接溯源到底层的安全事件;

增加了更适用于安全分析人员使用的仪表盘;

编写了一个自认为比较贴合分析人员使用的工具:HappyHunting

5. 其他改进

解决了SIEM联动CDN WAF API响应时间过长(15-20分钟)的问题。目前与Imperva WAF API联动已做到了准实时。

优化NTA login_audit代码,提升NTA性能。之前写过一篇文章《Suricata + Lua实现本地情报对接》,主要利用了Lua脚本对“敏感”接口进行登录审计并利用情报进行高危账号检测。现已将这部分功能移植到Logstash + Ruby上;

之前的自动化联动规则都是通过手动修改脚本调整rule.id来实现,这种方式在初期还能勉强运行。但在后期运行中暴露出了不足,既不便于管理也增加了维护的成本。所以为了维护SIEM的规则,这里采用了Redis来进行规则的统一管理。后期只需要将需要阻断的rule.id推送至Redis即可。同时也在输出的告警中通过event.action字段标准该告警的响应方式;

进化:“散装”SIEM v0.2

1. Workflow

这是重新调整之后的“散装”SIEM v0.2的Workflow。如下图所示,数据源采集端这里就不展开来说了,都是现成的工具发就完事儿了。下面主要说一下Logstash中对数据处理的部分:

1607594082_5fd1f062c029fb4985fdd.jpg!small

2. 数据处理

2.1 标准化

1607594121_5fd1f08950067a4657e61.png!small

2.1.1 安全事件标准化逻辑

针对设备的安全事件进行标准化,也就是安全设备发出的数据。参考上图中蓝色线所示部分;

官方已支持Suricata数据的ECS,我们可直接启用filebeat的Suricata模块。但是,这里需要注意一点,默认Suricata的模块中有一些标准化是交由Elastic来做的。由于我们需要利用Logstash做后续的ETL部分,所以现在的整个数据流是:Filebeat -> Logstash -> Elastic。那么,这一部分的标准化,需要我们在Logstash层面来实现。具体涉及到的配置如下:

a. 通用标准化配置 (Suricata)

1)删除一些filebeat自带的字段。

2)增加Provider、Product、Sensor等字段,为了后期区分不同的数据源类型,(例:NTA、WAF、EDR),以及不同的NTA产品(例:Suricata、Zeek

  • Logstash Conifg

1607914083_5fd6d26382d52171c9d05.png!small?1607914083637

b. 标准化 – alert 事件(Suricata)
  • Logstash Conifg

1607653834_5fd2d9caa33f5b679d125.png!small?1607653836180

c. 标准化 – fileinfo 事件(Suricata)
  • Logstash Conifg

1607653977_5fd2da59a0612007e2f31.png!small?1607653977885

d. 标准化 – flow 事件(Suricata)

  • Logstash Conifg

1607654092_5fd2dacc9596bc3644307.png!small?1607654094224

e. 标准化 – http 事件(Suricata)

  • Logstash Conifg

1607914222_5fd6d2ee0c7341a6a8761.png!small?1607914223329

f. 标准化 – http 请求头(Suricata)

Suricata设置dump-all-headers:both时,会将HTTP头全部输出。对于http_audit这个需求而言是个很好的功能,只不过输出的格式有点坑。为了更方便的在Kibana上进行筛选,我对这部分数据进行了标准化。

  • Logstash Conifg

1607654474_5fd2dc4a1d91e940f8aec.png!small?1607654474405

  • Ruby Code

1607654506_5fd2dc6ace6494a8cf0b0.png!small?1607654507347

  • 示例

a). 标准化之前的数据

1607654575_5fd2dcafb472976685b54.png!small?1607654576213

b). 标准化之后的数据

1607654601_5fd2dcc92916c093ba68e.png!small?1607654601435

g. 标准化 – tls事件(Suricata)

  • Logstash Config

1607654653_5fd2dcfdea057edb1a002.png!small?1607654654198

2.1.2 SIEM告警标准化逻辑

针对alarm事件进行标准化,也就是SIEM发出的数据。参考上图中红色线所示部分;

a. SIEM告警通用标准化配置

来源:freebuf.com 2020-12-10 17:49:22 by: Shell.

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论