老是忘了关冰箱 - 利用Splunk构建SOC、SOC建设漫谈及Splunk的角色">老是忘了关冰箱 - 利用Splunk构建SOC、SOC建设漫谈及Splunk的角色

老是忘了关冰箱 - 利用Splunk构建SOC、SOC建设漫谈及Splunk的角色

免喷符

SOC部门小菜鸟一枚，此乃自闭学安全的笔记记录，行文潦草，随性笔记。
通过上一篇的勒索病毒案例，已经了解到Splunk的强大之处。Splunk那么死贵，他的角色是怎样的，又是怎么和安全及SOC联系起来的，该如何利用它。
这个故事得从SOC开始说起。 SOC，就是那个SOC啊。。。。本人从2020年在某乙方安全中厂开始接触SOC运营至今，从一开始被如SIEM、态势感知、MSS、UEBA、SOAR等一堆名词弄一脸懵逼，到现在算是小有头绪，希望用大白话的方式（主要我也是野路子）能对正在进行SOC安全建设的小伙伴提供一些思路上的帮助。

上来就整一个暴论

私认为一个完善形态的SOC必不可少的几大项：SIEM、UEBA、SOAR、TIP、EDR

啥是SIEM

我，张三，信息安全主管，来到这家公司，才知道这里次次HVV行动都被Red Team打烂，才知道是被忽悠来，要对公司的安全建设进行升级。
公司安全建设现状：基本的安全设备（其他那些所谓高大上的安全设备先按下不表），能买的都买了，软的硬的都上了。

出口边界：已经有NGFW、IPS、DDOS，邮件防护网关等
DMZ区：已经有WAF、系统防护软件等
办公区：终端防护软件等终端几件套
运维区：DLP、运维审计系统等

我还能做些什么呢？还要上啥设备吗？
首先，肯定得招些安全运维，还要懂点安全分析的老哥，将安全运维常态化。724 实时监控，及时处理告警，定期出具安全报告。
问题是总不能让这个老哥一遍又一遍的轮询这些安全设备吧。那他不出一个月肯定想着跑路了。
不得不面对的现实，最残忍的就是收到市里应急响应中心的红头文件通报，什么监测到你司的公网IP在挖，或是僵尸网络，限期几天内整改，还要出份报告。那就得溯源分析了，主要的安全设备都过一遍，单单网络排查，流量进站方向查一查，出站筛选查一查，内部横向查一查，真是够忙活。
此时，引出了SIEM，以Splunk enterprise为例，把所有安全设备的安全日志管理都收集起来统一存放到存储桶，字段提取，为每台设备提供一个仪表板区域。比如被通报的是僵尸网络，通报附上是广州出口IP连接到哪个外部IP，或是解析什么域名。假如是解析僵尸主机域名www.attack.com那么此时只需要简单地在搜索框输入以下命令，就会所有设备有关该域名的所有日志全都搜索出来，排查思路跟上篇大差不差：

index=guangzhou www.attack.com

SIEM的好处
安全运维的老哥不需要做轮询机器人了，只需要一站式检索，即可了解攻击事件的攻击链；展示1块大屏仪表板显示各种如外部攻击源Top，外部攻击目的Top，内部攻击源Top等等，老板看的很爽，觉得钱没白投，安全工作成果一下子可视化了、等保要求的六个月日志储存要求也OK，等等。。。

SIEM的不足
所有的安全信息来源于这种基于签名的传统安全设备日志，本质上还是一种被动防御，不能检测未知攻击或已知攻击变种，尤其是0-day攻击。需要不断更新攻击签名数据库，耗时耗力，在每次HVV行动，RedTeam的兄弟不是过狗就过WAF各显神通。
日志告警噪声太大。SIEM是一个溯源的好帮手，但所有安全设备的告警都汇聚过来直出展示到大屏，海量告警直接把安全运维小哥干蒙了，在实时告警处理这块无从下手了，他排查速度都比不上日志滚动速度，特别检测到一些不合安全规范的代码，传统设备的静态规则会造成大量的误报，不到半个月运维小哥又想跑路了，麻蛋还不如我一台一台看设备算了，虽然轮询慢，但是不至于这么乱。

Splunk的做法
所谓日常安全运营安全分析岗，无非就关注这么几件事，看告警日志，对一些攻击次数高的外部IP进行封堵，对一些外部攻击事件结果为成功的事件进行确认，如是则进一步排查乃至溯源。定期变身文档工程师统计下攻击数据及封堵数据。
Splunk的搜索与报表功能、告警功能解决这些问题。比如我们可以通过上面的思路Splunk的SPL语句（类似SQL）为部署在边界的某厂牌防火墙实时筛选出暴力破解事件：

这里SPL语句的意思是，筛选这台防火墙UTM模块的安全日志，等级为高的，源地址为外部地址的，攻击签名带有暴力破解的事件，因为可能1个外部IP会有很多条日志，为了好看，使用Stats统计命令，将其他字段的值根据源IP来合并，然后当搜索暴力破解事件出现次数大于3时（HVV时调的低一点），就出告警，此搜索语句，每30分钟执行一次，搜索前30分钟内的事件：

然后告警触发时，发送邮件给运维小哥和我张三：

其他安全设备同理，此时的安全运营工作变成了导入安全设备的安全日志，保存，字段提取，搜索重要字段，转成计划任务，出告警邮件，处理。
这样他就不需要轮询安全设备了，也不需要被那个撑门面的大屏海量告警淹没了。他只需要收邮件来处理了，没邮件时，就可以摸鱼写博客了，比如现在（：。。。

啥是UEBA

先前是对其他那些所谓高大上的安全设备先按下不表，现在正式开炮。二营长，拉意大利炮来。第二个暴论，只要是还在基于签名规则库，没有内部用户角色识别，用户线性行为建模功能的一众态势感知也罢，行为感知也罢，都配不上这些名字。
无法被忽视的问题，基于静态签名的传统安全设备真是该报的不报（各种Bypass），不该报的报一堆（好吧有时是开发不规范的锅），大量误报干扰。（回忆起那段轮询设备运营的时光，某眼是最让我恶心的，100条告警一大半都是误报，就这也好意思叫态势感知）
我们知道，IPS也好，WAF也好，直连也好，旁路也好，本质上是对进出流量进行检测，对每个包进行规则库匹配。
UEBA同样是对流量进行检测，又是如何有别于传统安全设备，真正做到了真正的态势感知，行为感知的呢。正是实现了两个重要的功能，内部用户角色识别，用户线性行为建模，至于外部IP识别，先按下不表

UEBA的工作模式
分别在接入层、汇聚层、核心层的交换机部署探针收集镜像流量，而Splunk的UEBA是利用Enterprise这个核心平台去收集这些网络流日志，然后使用UEBA模块进行分析：

根据采集到的实时流量特征不断数据挖掘自学习，进行网段登记、主机标签自动化登记，不断动态描绘整个内部网络环境，举个例子，有一台内部主机不停的收到DHCP的请求流量，那么UEBA就会赋予它一个DHCP服务器的标签。比如一台服务器经常收到一些Kerberos请求，那么会赋予它Domain control标签，这就是内部用户角色识别的大概意思。
我们知道传统安全设备对流量包进行实时的规则匹配出告警，比如WAF检测Web攻击如SQL注入，比如XSS攻击，但是会被Bypass。而ueba是怎么做的呢。他压根就没有这种规则。他是对每个角色的全流量行为进行检测，不只对某一瞬间的包进行规则匹配，还会对一段时间的行为进行记录。例如Splunk的UEBA模块，会对1小时内的数据进行关联分析，也会对24小时内的数据进行关联分析。对于关联分析结果严重程度，赋予事件不同的告警分数。这也是有别于传统安全设备分类为高中低的事件规则，他的规则是极度灵活的。

关于角色行为关联分析
举个栗子，IP 192.168.1.10通过用户标签识别为web服务器，我们知道服务器主要是作为应答者，但是检测到一个报文是192.168.1.10主动向外部IP发起的连接，那么此时这个报文就会被列为可疑，然后会被ueba观察，经过一段时间内的观察，或者说某个规则检测的是这种情况在几分钟出现多少次，则出告警，那么这台服务器就会触发一个告警。
而如果是传统安全设备呢，他只知道是一个流量，使用规则匹配一下，没事就放走了，他压根就不知道这是台服务器。
什么叫用户行为分析，得先知道用户角色，这个角色哪些该做，哪些不该做的，那便是可疑了。而关联，必然具备时间线性的关联。

关于时间关联分析
再举个栗子，IP 192.168.100.10，被UEBA识别为服务器，从外部IP下载了个文件，然后马上就连接到外部其他IP，并且是加密流量，那么传统设备，以及那些依然基于攻击签名的所谓行为感知设备根本就无法把前后关联起来。并且，还能够对于相同规则产生告警的不同角色，以及其他的偏移量，赋予这个同名事件的不同事件分数。

关于误报处理
再举个例子，IP 192.168.200.2，内部的漏扫服务器，一般他基本不会产生流量交互，最多就是向外请求更新下漏洞库。所以UEBA的用户识别行为一般直接给他一个Desktop标签。但是内部主机漏扫任务启动，产生了大量内部扫描活动，UEBA出了相关行为告警，端口扫描事件，比如暴力破解事件。我们此时可以在UEBA上为这个IP赋予一个Security Device标签，那么，UEBA就会根据这个标签，下次的漏扫任务将不再触发安全告警。
当然只是屏蔽了他主动发起的攻击行为，如果是有外部IP对他发起的攻击，一样会有规则适用于他，这就是UEBA基于角色行为的灵活和精准（再次不得不提一嘴某眼，只要一下发内部扫描，整个事件面板都会被这个IP占满，就离谱。）而UEBA的攻击告警展示也不再是一条一条这么罗列出来，主要是以IP资产的形式罗列出来，这样完美解决了海量告警滚动到麻木，当然以事件规则的形式同一归类列出来，但是UEBA的规则非常的少。

优缺点总结

优点
传统安全设备是对过往数据包进行规则匹配，误报多，Bypass率高。
UEBA是基于角色行为模型自学习来匹配规则的，误报率低，真正实现了全流量行为感知。凡是还在基于签名库匹配的算不上真正的UEBA

缺点
他终究是个行为规则匹配的机器，只是基于用户角色观察网络行为，当行为与角色标签出现偏差时，并发出警报，同样会存在误报。（当然没有基于签名的安全设备高）。

TIP
现在我们的网络架构已经有了SIEM平台统一收集传统安全设备的安全日志，还会计划出告警邮件。同时我们也部署了UEBA，通过其数据挖掘功能，用户行为学习自画像功能，行为关联分析功能，产生的告警也推送邮件告警，大大降低了我们被Bypass的情况。
然而终究有误报，里面确也混杂了真实的安全攻击，只是加密了，一时间看不出了，毕竟SOC成员的分析研判能力也有上限。
假如有这么一种情况（实际上真有，每年HVV看到一大堆实习生，Payload都看不懂就在那摸鱼），SOC新招的成员李二狗，确实收到了大量可疑的事件，还是同一个外部IP访问过来的。李二狗看了看传统设备的日志，确实中了不少告警，UEBA也出了告警，检测到这是一个从来没访问过我们的这台服务器的罕见外部IP，李二狗就把这个IP添加到外部防火墙黑名单了。结果主管张三跑过来，问李二狗是不是封了这个IP，原来这是个正常的IP，是总部大领导在访问广州分部网站的，这把是真寄了。影响了大领导的使用体验。
经验老道的如花喊了声，你特么干嘛不扔到微步查一查。一查这个IP，是北京移动的出口IP。这就引出来新的问题，事件检测我们有SIEM和UEBA，已经非常的NICE了，事件研判处理时准确性严重不足。
网络交互中，源地址对目的地址做了什么事，特别是外部源地址的识别极其重要，UEBA做到了内部用户识别，对于外部IP识别是无法实现的，就需要威胁情报库做参考了。
当我们研判外部攻击事件时，威胁情报对此IP的判断对我们是否封堵IP起到了极其重要的作用。
Splunk的UEBA模块是没有情报库匹配的。别急，继续往下一节看。

啥是SOAR

攻击事件的研判，有了情报库，大大提升了我们研判的准确性。问题又来了，这两个步骤还是要靠人去做。收到告警，特别是疑似攻击成功的告警，还是外部IP的，就把IP扔到微步查一查，好的红色IP，OK封掉。这个步骤能不能省略掉，这就是SOAR的意义。
Splunk的SOAR是以Rest API的形式实现的。首先，从SIEM和UEBA中获取告警。就可以开始写剧本，这个剧本代表着分析过程以及匹配时做什么动作。
简单举例，假如是一个钓鱼邮件事件，邮件是成功投递给了目标用户，通过SIEM我们知道邮件安全网关上的日志关于此事件的Action是Allowed的。
那么我们可以这样写一个剧本，首先，通过api查询微步或者virustotal，查询邮件附件的Hash或者源IP情况，假如Hash有1个厂商报毒，那么就封堵这个源IP。假如Hash不报毒，但是源IP有5个厂商都报毒了，那么同样封堵这个源IP。
封堵IP的操作就是splunk再发起一个Http请求给边界防火墙，如果终端安全管理系统支持API，还可以下发扫描任务给邮件目标主机。
SOAR主机执行的剧本情况产生的Syslog日志还可以发邮件给客户作为提醒，或是审批，或是直接回传给SIEM核心平台，展示到大屏。

总结
自此，最理想的SOC中的主要模块都纳入了。他们不再是孤立的被动防御，是联动起来的主动防御。
传统设备支持已知攻击签名的安全检测
SIEM统一管理了他们的告警
UEBA支持安全告警挖掘，补充了未知行为、异常行为的检测
SOAR借助威胁情报降低了研判的难度，提高了研判准确性和应急响应处置速度
EDR没有讲，终端检测响应。Splunk是可以采集主机进程和网络日志来分析终端行为的。但我认为非常不现实，因为需要采集所有主机的进程日志，每台机子都部署一遍日志采集器。而且这是一个非常重要的安全检测部门，由专门的EDR设备来检测和响应就好，特别是现在的EDR往往兼具终端管理系统那部分工作，Splunk就更没有了。