游侠在2011年3月到思福迪（LogBase）之后，因为公司的业务重点问题，关注点开始转移到：日志管理综合审计系统、数据库安全审计系统、运维操作审计系统（内控堡垒主机），也经常在网上搜一些相关的资料。
这不是，搜到一篇不错的，原文是《SOC理解》，但是很可惜没找到作者，那在这里向原作者致敬了。正文开始：
1.在soc的用途方面大家理解上的偏差
对于用户，关心的是自己网络或者业务所面临的安全风险，以及利用soc整合人员、流程应对安全事件，更好、更全面的了解现状和快速做出反应。
对于soc提供商，关心的是自己的技术如何，拥有多少的模块，支持多少的设备，漏洞库的数目等等，而没有站在用户的角度来思考问题。
2.在成熟度上的不足
soc更像是个概念性的东西，而且厂家还尚未把这个概念摸透就匆匆上马抢占市场，其实都是半成品，糊弄不懂的还可以。可以说soc中的各个模块距离成熟都还很远，更别说这整个的系统了。
3.在易用性上的不足
soc所呈现所提供的界面、模块，出现的报警信息，都还不能做到傻瓜化，门槛较高，本来都该soc提供的分析功能，全都变成要人来判断了，那么soc还有什么意义
4.差异化造成的问题
由于企业的不同，soc必然会结合企业的主要业务、安全组织架构、流程来进行差异化，这导致每个soc必然要有大量的单独开发过程，模块的重用比较低，影响厂家的研发速度和升级换代，对厂家的利润空间进行了挤压。而开发并不能深入了解企业的业务，导致系统和业务的贴合不够紧密
5.恶性竞争
虽然soc刚刚起步，但国内的各大安全厂商纷纷来抢夺这块大蛋糕，某省的电信企业招标，竞标之激烈超出企业的想象，最后夺标的压价之低差不多就是赔本作。这种不从自身做起，而只靠打价格战的做法，实在是对整个行业都不利的
soc的问题太多，不是短时期能解决的，我有个想法，以后会和大家交流
========== =========================
SOC和SIEM这两个概念大家已经说了很多了，之间的区别其实很大，根本不是一个概念上的东西！SOC是一个安全运营组织，SIEM是一个以安全信息和安全事件为基础的技术管理平台，因此区别是首先表现在构成上就是很大不同，当然相同之处都是安全策略工具的组成部分！
首先SOC（传统意义上的安全运营中心）不是任何客户都适用的，它有很多重要的功能不是产品技术能解决和实现的（就像大家了解到的流程、人员等），它的基本结构往往都是由于客户本身的实际需求和自身条件不具备等原因，导致SOC的畸形和失效！！！就像很多电信运营商建立了所谓的SOC却得不到应有的期望一样，就其原因还是自身条件不具备、实际需求不具备等，例如组织梯队不健全，很多省级电信运营商负责安全的专职人员也就1到2人，甚至兼职！因此你可以想象一下安全运营工作由谁来执行，由谁来改进，由谁来审核…（网路游侠：其实我在运营商里面不敢提到SOC，因为失败的案例太多了……从2002年左右国内就有厂家在运营商做SOC，但是一直到现在，还基本都是失败的例子，在运营商提到SOC基本就被X了。对安全运营要求如此之高的运营商尚且如此，更何况一般的政府、企业？！），所以更不用说SOC其它重要组成部分的缺失了。从国外发展的历程我们可以发现，SOC做得好的企业往往都是服务管理发展得很好的企业，安全运营管理已经成为他们最为重要的生产力（如：对外能提供成熟SLA的MSS服务供应商或对内提供成熟OLA的国际大型企业，如：IBM等），持续性的改进和整合其相关的安全资源（安全人员、安全技术工具、安全服务流程等）。
其次SIEM也是现在大家说的很多的一个词（很多还误称为SOC!)。大家都是知道SIEM的基本原理是四化（标准化、整合化、关联化和可视化），最主要的作用是监控识别关键风险、加速安全响应（最近又推出了很多针对合规性的解决方案等）等，所以大家就认为SIEM这个平台级的产品能帮助我们自动、精确地找到和发现绝大部分的关键风险事件（只要产品厂商能提供丰富的关联规则库和安全响应案例库等即可，就像IDS和防病毒的特征签名库一样），可最终结却事与愿违！
其实无论是何种安全解决方案或产品技术(包括各种安全服务），就其实质都是安全策略实现的工具或工具集，而它们的有效性必须取决于安全策略这个根本，我们知道安全策略本身是动态的，因为它会随时间、环境等因数会有差异性的，因此通过大家多年来的工作实践发现通过“PDCA”的方法可以帮助我们基本接近或实现安全策略，所以无论任何安全工具或工具集
都不可能绕过这个最佳实践，SOC和SIEM也是如此，就像大家经常提到SIEM的关联分析一样，由于威胁场景、业务路径、资产价值等的不同，没有一成不变的关联规则！并且SIEM本身就是一个平台型产品，它需要集成、融合其它安全工具和策略，才能找出可能的关键风险！例如：楼主提到的关于路由器的问题（‘分析方面:对于路由器的日志分析不出什么有用的东西出来,关联分析什么的更别说了,一句话有用的东西太少 ’），不是为了监控路由器的日志而去做监控，可以基于以下思路进行：
1.首先评估出所需监控的风险;
2.其次分析和发现风险发生的路径和风险可视点;
3.最后找到或集成能记录风险行为的日志设备，并再进行监控和收集！
例如：我们以前有一个风险监控需求就是要发现局域网的arp相关的攻击，因此我们针对其风险路径做了分析后，发现和确定路由器和交换机可以作为我们其中一个风险可视点，因此我们就自定义写了一个关于路由器arp表和交换机MAC表的日志脚本，对其进行收集和关联分析！
所以很多需求和问题不是简简单单靠SIEM产品本身就自动或智能实现的，需要策略的咨询分析、安全工具等资源的整合，以及更为重要的PDCA改进！！！现在很多行业都不断地有安全信息管理或安全监控的需求，很可惜的是大家还是把绝大部分的精力放在了SIEM产品本身的关注上（无论是前期的调研、还是项目招标选型等），而忽略了安全信息事件管理或安全监控管理的其它重要组成部分，希望我们大家能从失败的案例中好好总结，从意识形态上进行一定的转变。
另外个人愚见认为关联对SIEM来说是很重要，但不是全部！因为关联的有效性取决于很多方面，收集的广度和深度，事件升级和KB关联等映射耦合度，SIEM和其它安全产品工具的集成能力，以及专家支持力量和改进能力等等，所以对于很多企业来说，刚开始不一定要从SIEM开始，其实LOG MANAGEMENT相对来说是一个更容易理解和使用的安全产品工具，更容易维护和运营些，正所谓好的安全管理就是简单的安全
