安全管理平台，SOC/SIEM的实践分享【背景篇】

SOC/SIEM可以解决企业内网以及边界的各类安全防御技术手段的分析结果，同时通过集中采集日志，进行二次分析，进而给予安全管理人员以告警信息，让安全管理人员借此得到提示，展开取证调查。

SIEM建设背景

1.1 目前企业安全运营面临的主要问题

• 安全设备多，日常维护压力大。 企业经过一段时间的安全建设，会建立起较为完善的安全防御体系，这其中可能会包含多种类型的安全产品，如防火墙、WAF、IPS、NIDS、防病毒、邮件网关、HIDS 等，各类安全产品之间是相互孤立的。如何维系不同类别产品之间的运行呢？
• 日志量大，告警事件多，且无事件处理优先级之分。 种类众多的安全设备，每天都会产生大量的日志，其中不乏大量的误报信息。如何识别正确的告警信息？
• 安全事件闭环处理进展缓慢，或者并无闭环处置。 安全事件对应的资产，往往需要单独再去资产库里面进行查询，同时资产上对应的漏洞也无从得知，在整个安全事件闭环管理上，容易出现安全管理人员未知的大量空白区，导致安全管理人员无法做出有效且快速的判断，实现对安全事件的处置。

除了以上几点，安全运营涉及的方面还有很多，往往需要跨部门沟通，过程缓慢、推进困难，另外在企业的边界上、各安全域中，会出现了多少个安全事件？涉及多少种告警类型？安全事件发展趋势如何？最终结果是成功还是失败？要回答上面的几个重要问题，还需要先对企业自身的内外网环境以及边界加以了解。

部分企业内网环境相对比较复杂。边界也不仅限于互联网边界，也可能是各个安全域之间的边界情况。所以我们需要一个平台或工具类的产品，就是 SOC/SIEM。

SOC/SIEM可以解决企业内网以及边界的各类安全防御技术手段的分析结果，同时通过集中采集日志，进行二次分析，进而给予安全管理人员以告警信息，让安全管理人员借此得到提示，展开取证调查。

1.2 传统 SOC/SIEM 的建设过程

先来用一张图说明 SOC/SIEM 的建设流程，现实的情况要复杂的多。

在SOC/SIEM建设过程中，数据源包括安全设备、网络设备、应用系统、数据库，以及其他的日志类型。采集端一般会接收到数据源转发过来的日志，日志进来之后往往会有一个范式化清洗的流程，这个过程，会将不同类型的事件进行解析、映射，处理之后去做统计分析。再然后是消息队列，可能是 Kafka 之类的组件，之后范式化后的数据一方面入库，我们也可以基于范式化后的结果进行查询、统计、分析。而分析可能采用的是计算引擎或如日志易的 SPL，最后会把分析结果或查询统计结果给到前端进行调用、展示。

这其中更为主要的节点是在解析阶段，因为解析的质量直接影响分析及展示的效果。

1.3 目前 SOC/SIEM 存在的通用落地问题

• 安全事件处置优先级并无明确指引。 很多企业往往只是固化地按照威胁定义的高中低告警级别来实施处理，但实践证明，在大量威胁告警并发情况下，按高中低的评估方式存在较大的不足。原因在于，风险值没有对应的指引方式，无法落实到相应的漏洞。如有些告警虽然是高危，但被阻断了；有些威胁，虽然是低危，但是恰好资产上存在对应的漏洞，可被其利用（则需要重点关注攻击的结果以及后续漏洞的修复）。


• SOC/SIEM 平台只有安全管理人员使用，安全事件的闭环处置无法执行完整流程。 安全事件的处置是多角色参与，如网络管理人员、基础架构人员等。因为一个安全事件从监测、分析到处置，需要多个不同角色的人员进行配合，而在沟通的过程中，就需要强调 SOC/SIEM 平台的权限管理能力。对不同角色划分不同的数据访问权限或临时授权，有利于提高沟通的效率。

• 依赖已知威胁场景的构建，忽略了应强调对可疑事件以及未知威胁的分析。

威胁分为三类，已知威胁、可疑威胁（不能马上确认，需要进行调查分析的事件）、未知威胁（不在认知中，需对海量日志进行挖掘统计，才能发现异常的威胁）。上述的威胁，在企业环境中客观存在。很多厂商规则库中内置了几百种规则 ，然而企业真正能开箱即用的规则很少，很多规则都需要进行优化调试才具备落地投产的价值。然而，大多数企业往往看重已知威胁，实际上，企业应该将更多时间花在对可疑事件以及未知威胁的分析上，发挥 SOC/SIEM 平台的价值。

• 落地威胁场景的过程，忽略持续对其优化。 我们需要基于对实际环境的了解，不断对规则进行优化过滤，如白名单、严格过滤收敛，最后缩小范围，提高规则的准确度。不同企业安全体系建设的侧重点不同，不能持续优化、收敛的规则，对企业的环境而言不具备普适性，可能就是不适用于我们的环境的。

影响SOC/SIEM项目成功的三要素

通过对 SOC/SIEM 建设背景的分析，我们可以得出：SIEM 的成功实施离不开这三个要素——人、流程、技术。而企业 SIEM 建设需要注意以下几点：

1. SIEM 流程建设应融入整体工作流程。 只有这样，安全才不是一个孤立的系统。我们的 SIEM 要与工单系统对接，与 OA 对接。
2. 做好用户分权设计。 SIEM 体系建设需要多方协同，有多角色参与的需要，就要有不同角色的权限分配或针对某个事件，对某个角色（可能是外部的第三方人员）临时授权之类的权限管理。这里面一部分是安全事件处置的流程化影响的。
3. SIEM 建设需要提高威胁模型准确度。 不是一味的强调开箱即用，需要不断投入，不断优化使用的过程。
4. SIEM 建设还应着重于可疑威胁的分析。 什么事件是可疑的呢？比如某些安全事件，可能已经被 WAF 过滤掉了，但可能又是另外一个安全事件的分析入口。又比如新创建的账户、账户出现了权限变更，在特定的时间、情境下，都需要引起分析人员的注意。
5. 做好事件优先级的判断。 需要安全管理人员结合资产、漏洞的情况进行识别分析，不仅仅依靠高中低的告警级别进行判断，因为机器是远不如人类智能的，规则是死的，而实际情况是多变的。