写在前面

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

背景

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

a

“散装”（基于开源）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中对数据处理的部分：

2. 数据处理

2.1 标准化

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

b. 标准化 - alert 事件（Suricata）

• Logstash Conifg

c. 标准化 - fileinfo 事件（Suricata）

• Logstash Conifg

d. 标准化 - flow 事件（Suricata）

• Logstash Conifg

e. 标准化 - http 事件（Suricata）

• Logstash Conifg

f. 标准化 - http 请求头（Suricata）

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

• Logstash Conifg

• Ruby Code

• 示例

a). 标准化之前的数据

b). 标准化之后的数据

g. 标准化 - tls事件（Suricata）

• Logstash Config

2.1.2 SIEM告警标准化逻辑

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

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