1、上来就整一个暴论 私认为一个完善形态的 SOC 必不可少的几大项：SIEM、UEBA、SOAR、TIP、EDR
2、啥是 SIEM 1、我，张三，信息安全主管，来到这家公司，才知道这里次次 HVV 行动都被 Red Team 打烂，才知道是被忽悠来，要对公司的安全建设进行升级。
2、公司安全建设现状：基本的安全设备（其他那些所谓高大上的安全设备先按下不表），能买的都买了，软的硬的都上了。
出口边界：已经有 NGFW、IPS、DDOS，邮件防护网关等
DMZ 区：已经有 WAF、系统防护软件等
办公区：终端防护软件等终端几件套
运维区：DLP、运维审计系统等
3、我还能做些什么呢？还要上啥设备吗？
首先，肯定得招些安全运维，还要懂点安全分析的老哥，将安全运维常态化。7*24 实时监控，及时处理告警，定期出具安全报告。
问题是总不能让这个老哥一遍又一遍的轮询这些安全设备吧。那他不出一个月肯定想着跑路了。
4、不得不面对的现实，最残忍的就是收到市里应急响应中心的红头文件通报，什么监测到你司的公网 IP 在挖矿，或是僵尸网络，限期几天内整改，还要出份报告。那就得溯源分析了，主要的安全设备都过一遍，单单网络排查，流量进站方向查一查，出站筛选查一查，内部横向查一查，真是够忙活。
5、此时，引出了 SIEM，以 Splunk enterprise 为例，把所有安全设备的安全日志管理都收集起来统一存放到存储桶，字段提取，为每台设备提供一个仪表板区域。比如被通报的是僵尸网络，通报附上是广州出口 IP 连接到哪个外部 IP，或是解析什么域名。假如是解析僵尸主机域名 www.attack.com 那么此时只需要简单地在搜索框输入以下命令，就会所有设备有关该域名的所有日志全都搜索出来，排查思路跟上篇大差不差。
index=guangzhou www.attack.com
6、SIEM 的好处：
安全运维的老哥不需要做轮询机器人了，只需要一站式检索，即可了解攻击事件的攻击链；展示 1 块大屏仪表板显示各种如外部攻击源 Top，外部攻击目的 Top，内部攻击源 Top 等等，老板看的很爽，觉得钱没白投，安全工作成果一下子可视化了、等保要求的六个月日志储存要求也 OK，等等。。。
7、SIEM 的不足：
所有的安全信息来源于这种基于签名的传统安全设备日志，本质上还是一种被动防御，不能检测未知攻击或已知攻击变种，尤其是 0-day 攻击。需要不断更新攻击签名数据库，耗时耗力，在每次 HVV 行动，RedTeam 的兄弟不是过狗就过 WAF 各显神通。
日志告警噪声太大。SIEM 是一个溯源的好帮手，但所有安全设备的告警都汇聚过来直出展示到大屏，海量告警直接把安全运维小哥干蒙了，在实时告警处理这块无从下手了，他排查速度都比不上日志滚动速度，特别检测到一些不合安全规范的代码，传统设备的静态规则会造成大量的误报，不到半个月运维小哥又想跑路了，麻蛋还不如我一台一台看设备算了，虽然轮询慢，但是不至于这么乱。
8、Splunk 的做法
所谓日常安全运营安全分析岗，无非就关注这么几件事，看告警日志，对一些攻击次数高的外部 IP 进行封堵，对一些外部攻击事件结果为成功的事件进行确认，如是则进一步排查乃至溯源。定期变身文档工程师统计下攻击数据及封堵数据。
Splunk 的搜索与报表功能、告警功能解决这些问题。比如我们可以通过上面的思路 Splunk 的 SPL 语句（类似 SQL）为部署在边界的某厂牌防火墙实时筛选出暴力破解事件： image.png
这里 SPL 语句的意思是，筛选这台防火墙 UTM 模块的安全日志，等级为高的，源地址为外部地址的，攻击签名带有暴力破解的事件，因为可能 1 个外部 IP 会有很多条日志，为了好看，使用 Stats 统计命令，将其他字段的值根据源 IP 来合并，然后当搜索暴力破解事件出现次数大于 3 时（HVV 时调的低一点），就出告警，此搜索语句，每 30 分钟执行一次，搜索前 30 分钟内的事件 image.png
然后告警触发时，发送邮件给运维小哥和我张三 image.png
其他安全设备同理，此时的安全运营工作变成了导入安全设备的安全日志，保存，字段提取，搜索重要字段，转成计划任务，出告警邮件，处理。
这样他就不需要轮询安全设备了，也不需要被那个撑门面的大屏海量告警淹没了。他只需要收邮件来处理了，没邮件时，就可以摸鱼写博客了，比如现在（： 。。。
3、啥是 UEBA image.png
0、先前是对其他那些所谓高大上的安全设备先按下不表，现在正式开炮。二营长，拉意大利炮来。第二个暴论，只要是还在基于签名规则库，没有内部用户角色识别，用户线性行为建模功能的一众态势感知也罢，行为感知也罢，都配不上这些名字。
1、无法被忽视的问题，基于静态签名的传统安全设备真是该报的不报（各种 Bypass），不该报的报一堆（好吧有时是开发不规范的锅），大量误报干扰。（回忆起那段轮询设备运营的时光，某眼是最让我恶心的，100 条告警一大半都是误报，就这也好意思叫态势感知）
2、我们知道，IPS 也好，WAF 也好，直连也好，旁路也好，本质上是对进出流量进行检测，对每个包进行规则库匹配。
3、UEBA 同样是对流量进行检测，又是如何有别于传统安全设备，真正做到了真正的态势感知，行为感知的呢。正是实现了两个重要的功能，内部用户角色识别，用户线性行为建模，至于外部 IP 识别，先按下不表 4、UEBA 的工作模式
分别在接入层、汇聚层、核心层的交换机部署探针收集镜像流量，而 Splunk 的 UEBA 是利用 Enterprise 这个核心平台去收集这些网络流日志，然后使用 UEBA 模块进行分析 image.png
根据采集到的实时流量特征不断数据挖掘自学习，进行网段登记、主机标签自动化登记，不断动态描绘整个内部网络环境，举个例子，有一台内部主机不停的收到 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 的规则非常的少。
5、优缺点总结：
优点：传统安全设备是对过往数据包进行规则匹配，误报多，Bypass 率高。UEBA 是基于角色行为模型自学习来匹配规则的，误报率低，真正实现了全流量行为感知。凡是还在基于签名库匹配的算不上真正的 UEBA
缺点：他终究是个行为规则匹配的机器，只是基于用户角色观察网络行为，当行为与角色标签出现偏差时，并发出警报，同样会存在误报。（当然没有基于签名的安全设备高）。
4、TIP 1、现在我们的网络架构已经有了 SIEM 平台统一收集传统安全设备的安全日志，还会计划出告警邮件。同时我们也部署了 UEBA，通过其数据挖掘功能，用户行为学习自画像功能，行为关联分析功能，产生的告警也推送邮件告警，大大降低了我们被 Bypass 的情况。
2、然而终究有误报，里面确也混杂了真实的安全攻击，只是加密了，一时间看不出了，毕竟 SOC 成员的分析研判能力也有上限。
3、假如有这么一种情况（实际上真有，每年 HVV 看到一大堆实习生，Payload 都看不懂就在那摸鱼），SOC 新招的成员李二狗，确实收到了大量可疑的事件，还是同一个外部 IP 访问过来的。李二狗看了看传统设备的日志，确实中了不少告警，UEBA 也出了告警，检测到这是一个从来没访问过我们的这台服务器的罕见外部 IP，李二狗就把这个 IP 添加到外部防火墙黑名单了。结果主管张三跑过来，问李二狗是不是封了这个 IP，原来这是个正常的 IP，是总部大领导在访问广州分部网站的，这把是真寄了。影响了大领导的使用体验。
4、经验老道的如花喊了声，你特么干嘛不扔到微步查一查。一查这个 IP，是北京移动的出口 IP。这就引出来新的问题，事件检测我们有 SIEM 和 UEBA，已经非常的 NICE 了，事件研判处理时准确性严重不足。
5、网络交互中，源地址对目的地址做了什么事，特别是外部源地址的识别极其重要，UEBA 做到了内部用户识别，对于外部 IP 识别是无法实现的，就需要威胁情报库做参考了。
6、当我们研判外部攻击事件时，威胁情报对此 IP 的判断对我们是否封堵 IP 起到了极其重要的作用。
7、Splunk 的 UEBA 模块是没有情报库匹配的。别急，继续往下一节看。
5、啥是 SOAR image.png
攻击事件的研判，有了情报库，大大提升了我们研判的准确性。问题又来了，这两个步骤还是要靠人去做。收到告警，特别是疑似攻击成功的告警，还是外部 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 核心平台，展示到大屏。
6、总结 自此，最理想的 SOC 中的主要模块都纳入了。他们不再是孤立的被动防御，是联动起来的主动防御。
传统设备支持已知攻击签名的安全检测
SIEM 统一管理了他们的告警
UEBA 支持安全告警挖掘，补充了未知行为、异常行为的检测
SOAR 借助威胁情报降低了研判的难度，提高了研判准确性和应急响应处置速度
EDR 没有讲，终端检测响应。Splunk 是可以采集主机进程和网络日志来分析终端行为的。但我认为非常不现实，因为需要采集所有主机的进程日志，每台机子都部署一遍日志采集器。而且这是一个非常重要的安全检测部门，由专门的 EDR 设备来检测和响应就好，特别是现在的 EDR 往往兼具终端管理系统那部分工作，Splunk 就更没有了。