小议SOC（安全运营中心）

之前的一点感悟，趁周末写下来留一个备忘，很零碎不成体系。

这两年SOC似乎成为一个很有黑暗系色彩的词语，很多时候安全运营人员不愿意提到这个词。因为他们亲身的项目体验，或者是同行间的经验交流，似乎都告诉他一个结论，SOC——至少是曾经的SOC产品在安全运营中起到的作用似乎并不大，甚至有人直白的说“SOC无用”。SOC真的没有用处吗？

企业到了一定的规模，安全运营中心的问题就会摆在企业安全决策者面前，无论最终是否实施SOC项目，企业都会进行相应的建设，这是复杂IT资产管理的需要，是提升安全运营效率的需要，也是从被动安全向自适应安全转换的需要；特别是当前安全问题被视为一种数据分析问题的时候，SOC 更为重要。如果真要认为SOC 无用，也只是某些产品在如何帮助企业做好安全运营及安全分析上做得还不够好。所以可以将前面那句“SOC无用”转化一个说法—市场上好用的SOC还是太少了。

日常安全运营

企业建立安全运营中心，本来就不是一个单纯产品或工具的问题，还涉及到人员能力和业务流程的建设，这两部分对于SOC项目的成功同样至关重要。因此对于项目实施来说，业务咨询和调研是其中非常重要的部分、不容回避，越是想交付一个标准的产品而回避这方面的问题，往往到后来会自食其果。而另一方面就涉及到SOC产品自身，是否能够利用SOC产品良好的设计来减少对人员水平的要求，以及将通用的流程通过产品使用逻辑体现出来、以降低实施的难度和成本。

因此一个好的SOC必然是嵌入了大量的安全运营用例知识的系统，从日常安全运营的角度看，这些知识包括2个层面：

1. 日常安全运维应该关注哪些方面？漏洞是最基本的内容，但从最佳实践中看还有一些需要考虑：未授权设备和资产监控、授权软件清单、系统配置核查、最小化服务访问端口、安全产品的引擎和签名升级、管理员特权控制、系统的服务和性能监控等等；
2. 关注面的具体核查点：譬如漏洞管理大家都知道需要做，但具体需要哪些运营动作、通过哪些数据点的统计监控，来确认漏洞管理方面的运营状态是合理合格的，好的产品往往会通过预定义的仪表盘来提供这方面的展示。另一个典型的例子就是不同法规的合规性要求检查项，通过自动生成相应的统一报告让人来方便的进行核查。

从这个角度上，SOC是一个知识系统，但这个知识系统不是简单的将一些攻防知识录入系统形成的，而是通过系统的每一个仪表盘、每一个预定义关联规则、每一个页面的操作逻辑组成的。

威胁管理

SOC曾经被认为最重要的功能是威胁管理，这应该是一个美丽的误解。很多时候人们提到关联分析引擎就直接认为发现威胁或归并报警是其唯一的价值，而实际上在上一代SOC中起到的最大作用是提取运营活动中需要关注的异常（往往和攻击事件无关）。而威胁管理相关的内容，考虑到之前的SOC往往只是接收报警而缺乏具体的流量和主机行为日志，这个领域对于它来说是不可能很好完成的任务。这更多的是大数据安全分析的范畴，或者说现今正在发展中的新一代SOC的任务。如果说优秀的上一代SOC帮助企业完成架构安全和被动防御方面的安全任务，那么新一代SOC 就需要完成主动防御（或者说自适应安全）方面的安全运营。从这个角度看两代SOC在企业中可以同时存在，而不是替换的关系。

对于新一代SOC来说，既然定位在威胁管理为中心，那么威胁情报和安全狩猎就成为其重中之重。威胁情报作为发现确定性、关键性事件的有效工具很多业内人士已有诸多体验，无需多说。而安全狩猎考虑到对安全人员尚有较高的技术要求，因此还没有被广泛使用，因此往往会提到有这个方面的出路有两条，一是让能做的人来做，即服务外包，但从国外的经验看，似乎随着时间的推移，一些组织不得不回到内部来进行安全监控，因为狩猎的分析过程需要比过去更多的本地应用程序及业务实践方面的知识，对于外部服务人员不适合、也不大可能掌握。其二就是让日常的狩猎更简单，就是UEBA的道理，通过整合专家能力和人工智能的方式，更自动化的发现通过签名或简单的异常规则不能有效监控的威胁风险。似乎第二条道路更符合大多数客户的需要。