SOC理解分析和总结.docx

在soc的用途方面大家理解上的偏差

对于用户，关心的是自己网络或者业务所面临的安全风险，以及利用soc整合人员、流程应对安全事件，更好、更全面的了解现状和快速做出反应。

对于soc提供商，关心的是自己的技术如何，拥有多少的模块，支持多少的设备，漏洞库的数目等等，而没有站在用户的角度来思考问题。

在成熟度上的不足

soc更像是个概念性的东西，而且厂家还尚未把这个概念摸透就匆匆上马抢占市场，其实都是半成品，糊弄不懂的还可以。可以说soc中的各个模块距离成熟都还很远，更别说这整个的系统了。

在易用性上的不足

soc所呈现所提供的界面、模块，出现的报警信息，都还不能做到傻瓜化，门槛较高，本来都该soc提供的分析功能，全都变成要人来判断了，那么soc还有什么意义

差异化造成的问题

由于企业的不同，soc必然会结合企业的主要业务、安全组织架构、流程来进行差异化，这导致每个soc必然要有大量的单独开发过程，模块的重用比较低，影响厂家的研发速度和升级换代，对厂家的利润空间进行了挤压。而开发并不能深入了解企业的业务，导致系统和业务的贴合不够紧密

恶性竞争

虽然soc刚刚起步，但国内的各大安全厂商纷纷来抢夺这块大蛋糕，某省的电信企业招标，竞标之激烈超出企业的想象，最后夺标的压价之低差不多就是赔本作。这种不从自身做起，而只靠打价格战的做法，实在是对整个行业都不利的

soc的问题太多，不是短时期能解决的，我有个想法，以后会和大家交流

===================================

SOC和SIEM这两个概念大家已经说了很多了，之间的区别其实很大，根本不是一个概念上的东西！SOC是一个安全运营组织，SIEM是一个以安全信息和安全事件为基础的技术管理平台，因此区别是首先表现在构成上就是很大不同，当然相同之处都是安全策略工具的组成部分！

首先SOC（传统意义上的安全运营中心）不是任何客户都适用的，它有很多重要的功

能不是产品技术能解决和实现的（就像大家了解到的流程、人员等），它的基本结构往往都是由于客户本身的实际需求和自身条件不具备等原因，导致SOC的畸形和失效！！！就像很多电信运营商建立了所谓的SOC却得不到应有的期望一样，就其原因还是自身条件不具备、实际需求不具备等，例如组织梯队不健全，很多省级电信运营商负责安全的专职人员也就1到2人，甚至兼职！因此你可以想象一下安全运营工作由谁来执行，由谁来改进，由谁来审核...，所以更不用说SOC其它重要组成部分的缺失了。从国外发展的历程我们可以发现，SOC做得好的企业往往都是服务管理发展得很好的企业，安全运营管理已经成为他们最为

重要的生产力（如：对外能提供成熟SLA的MSS服务供应商或对内提供成熟OLA的国际大型企业，如：IBM等），持续性的改进和整合其相关的安全资源（安全人员、安全技术工具、安全服务流程等）。

其次SIEM也是现在大家说的很多的一个词（很多还误称为SOC!)。大家都是知道SIEM的基本原理是四化（标准化、整合化、关联化和可视化），最主要的作用是监控识别

关键风险、加速安全响应（最近又推出了很多针对合规性的解决方案等）等，所以大家就认为SIEM这个平台级的产品能帮助我们自动、精确地找到和发现绝大部分的关键风险事件

（只要产品厂商能提供丰富的关联规则库和安全响应案例库等即可，就像IDS和防病毒的特征签名库一样），可最终结却事与愿违！

其实无论是何种安全解决方案或产品技术(包括各种安全服务），就其实质都是安全策略实现的工具或工具集，而它们的有效性必须取决于安全策略这个根本，我们知道安全策略本身是动态的，因为它会随时间、环境等因数会有差异性的，因此通过大家多年来的工作实践发现通过“PDCA”的方法可以帮助我们基本接近或实现安全策略，所以无论任何安全工具或工具集

都不可能绕过这个最佳实践，SOC和SIEM也是如此，就像大家经常提到SIEM的关联分析一样，由于威胁场景、业务路径、资产价值等的不同，没有一成不变的关联规则！并且SIEM本身就是一个平台型产品，它需要集成、融合其它安全工具和策略，才能找出可能的关键风险！例如：楼主提到的关于路由器的问题（?分析方面:对于路由器的日志分析不出什么有用的东西出来,关联分析什么的更别说了,一句话有用的东西太少?），不是为了监控路由器的日志而去做监控，可以基于以下思路进行：

首先评估出所需监控的风险;

其次分析和发现风险发生的路径和风险可视点;

最后找到或集成能记录风险行为的日志设备，并再进行监控和收集！

例如：我们以前有一个风险监控需求就是要发现局域网的arp相关的攻击，因此我们针对其风险路径做了分析后，发