浅谈等保2.0背景下SOC安全运营中心的建设思路

随着等保2.0的出台，“一个中心，三重防御” 的思想被反复提及。其中一个中心的 “安全管理中心” 与我们常规 “安全运营中心（SOC）” 的建设，在概念和思路上有很多重叠的地方。

今天，我们来简单谈谈过去SOC的建设中的一些经验以及踩过的坑，并就未来SOC可能的建设方向进行初步探讨。

1 什么是SOC?

SOC是一个面向企业全网信息处理设施的集中化的安全管理平台。SOC集预警、保护、监控、 响应和分析等重要功能于一身， 并集成标准化的管理流程，可以实现持续的安全运营。

而安全信息和事件管理平台（SIEM）也会常被同业们一起提及，称其为SOC的 “大脑”。SIEM作为安全事件和告警、威胁情报的数据汇总平台，承担着记录、分析及响应的重要角色，然而，巧妇难为无米之炊，如果采集的信息不足、广度不够或维度缺失，那么SIEM也会由于缺乏必要的安全设备数据支持，而难以发挥应有的价值。

可以用下面这张图来简要表示SOC的运作模式：

图：SOC建设三要素

其中，制度（组织架构、规章、策略、规划、预案、操作规范等等），流程（安全事件处置流程、应急响应流程、工单处理流程等等）和技术平台产品（各类安全设备、数据采集工具、监测、分析、告警等等），三者协同作业，流程设计依赖于制度的合理性和技术平台的可实现性，技术平台则会对制度和流程起到监督补充的作用，而流程则是制度和技术平台的衔接。它们之间两两相互影响，任何一者的不足都会引起SOC整体运行效果大打折扣。

2 SOC如何设计？

早期SOC建设大都是从制度的设计开始起步的，先制定长远规划和高阶设计，以获得公司管理层的认可，然后自上而下的推广实施。这个过程中，最被人诟病的，恐怕是前期很难充分考虑底层数据的支撑和一线运营人员的使用需求，也就是大家常说的“没办法落地”，导致后期推广困难，乃至不了了之。

与此不同，也有的SOC建设是由技术平台起步，进而完善制度及流程的建设，这属于比较典型的自下而上的设计思路，通常由IT技术或者安全部门直接发起。这类思路的实施难点通常在于，大家会对于SOC平台有很高的期待，希望最大限度地在其他系统不做任何改动的前提下，借由SOC平台解决所有需求和问题。

因此，在建设过程中，特别是涉及到与其他安全厂商/供应商的对接、跨部门的数据读取调用、运营人员使用习惯改变时，其阻力可想而知。这种场景下的SOC平台建设，需要花费大量时间做定制开发、系统对接的工作，而高层领导和业务部门一旦失去耐心、缺少了预算支持，项目将更加难以展开。

诸多实践下来，比较靠谱的建设设计思路，便是以上两者相结合，有重点、分阶段的实施模式。同时，引入 “安全管理域” 概念，让非技术背景的高级管理层更容易理解和接受；在不同的管理域中设计不同的“指标”（这里的 “指标” 并不是一个具体的数值，可以是场景、IoC、use case等），这将有利于后期的落地实现和前端运营人员的理解执行。

这些指标每个都可能涉及一种或多种类型的安全产品，通过阈值定义触发告警，或严重的可以自动或手动升级为安全事件，进而启动事件处置流程，从而把整个SOC运行起来。

3 影响SOC成败的关键因素有哪些？

我们发现，实际上影响SOC成功与否的因素是多方面的，每家企业会遇到不同的难点，印象最深的一句话是 “我们公司比较特殊，可能与其他企业不太一样”，这里也仅是列举个人理解下值得关注的几点：

A. 来自高级管理层的持续支持对项目非常重要。SOC的完整建设周期一般都相对较长，在此过程中管理层的人员或意志变动带来的风险可能对项目造成难以估量的影响。曾听说行业里的一个项目，由于对方CIO人员变动，新的CIO执意更换SIEM产品，导致项目团队做了大量额外工作，并最终延期交付。

B. 采集数据的质量将直接影响对最终的分析结果。目前，本人所了解到的项目中，30%-60%的项目时间会花费在与其它安全产品的对接，以及协助其他安全产品调整参数和配置上，否则采集到的数据可能会有误差和欺骗性，直接导致指标的失准，产生大量的误报，进而影响最终的决策和判断。站在使用者的角度上，用户通常会直接认为是SOC方案或设计存在问题。

C. 选择合适的SIEM平台会对项目产生积极影响。平台不仅需要采集常见的安全产品日志，对于企业内部的自开发系统也要能够支持，尽量减少对接调试的时间，把更多的精力放在指标、制度、流程的设计上。

D. 对整体项目有合理的规划和预期，莫好高骛远。还是建议能以 “有效改善现有问题，提升工作效率” 为目标，未来人工智能、态势感知的实现也离不开基础数据的准确性，低质量的数据只能带来更多的误报。

4 在等保2.0的背景下，SOC如何优化和调整？

我们都看到了等保1.0到2.0的重大转变，由被动防御变为主动防御。