关于某SOC地一点讨论.doc

实用标准文案 精彩文档 HYPERLINK /2011/01/02/%e5%85%b3%e4%ba%8esoc%e7%9a%84%e4%b8%80%e7%82%b9%e8%ae%a8%e8%ae%ba/ 关于SOC的一点讨论 【缘起】在飞熊的《 HYPERLINK /2011/01/02/2010/12/27/%e9%9d%a2%e5%90%91%e6%b3%95%e8%a7%84%e4%b8%8e%e4%ba%ba%e6%9c%ac%e7%9a%84%e6%96%b0%e4%b8%80%e4%bb%a3%e4%bf%a1%e6%81%af%e5%ae%89%e5%85%a8%e6%9e%b6%e6%9e%84/ 面向法规与人本的新一代信息安全架构》中，willchen提到了SOC在方案中的核心地位。正好研究过一点这方面的问题，不好在别人的地盘跑题跑太远。在这里写一点个人的看法。 【正文】 一、现在的SOC是怎么做的 现有市面上的SOC产品在功能上各有各的特点，但是总的说来，核心功能都是以统一收集日志（主要是syslog日志，也有SNMP拿到的信息，有些还能收集NetFlow/NetStream/S-Flow等日志）为基础，再将收集上来的日志加以标准化进行存储，再对这些日志进行一些处理（如归并、根据策略进行关联等），再加以呈现（可以是实时呈现在屏幕上，也可以生成报表）。 以上是SOC的核心功能，在此之外一般还会有工单管理功能，也即一条告警过来以后就形成工单，让管理员和各级主管可以跟踪一个安全事件的处理过程。相当于集成了一个OA系统。 有些SOC还会集成一些工具，比如漏洞扫描工具或者集成IDS配套。事实上，很多SOC的原型都是厂家IDS的管理端，在IDS管理端上增加收集其他厂家其他类型产品的功能，再做关联分析而成。 除了产品设计以外，现有SOC在实施过程中还有一个非常重要的工作，就是做日志接口的开发。由于市面上的安全产品种类繁多，品牌繁杂，又没有统一的日志标准，比如天融信的防火墙，其不同版本的日志格式都不一样。故此任何产品都不可能兼容所有产品，那么在实施的时候，为了把客户现有的产品都纳入进来就必须进行接口的二次开发。否则必然会有一部分产品的日志收集不上来，或者收集上来以后识别不出。 二、SOC目前的问题 SOC在客户那里最大的问题就是用不起来，很多客户也觉得SOC说的很好，实际用起来完全不是那么回事。个人分析，主要问题有以下几个： 由于日志来源本身的可用性问题，导致SOC不适用于安全的事前和事中处理。无论是IDS还是防病毒又或者IPS的日志，都存在误报和漏报的问题。对于误报，SOC其实没有很好的方法加以识别。没有可信的来源，在此基础上所给出的建议等也就成了无本之木。而另外一些可信的日志来源也存在问题，比如防火墙日志尽管可信，但是信息量太少，在出现问题后追查时倒是可用，但是用于事前判断攻击往往没什么意义。而IPS报出的高危日志（假设不是误报）往往都已经直接进行过阻断，没必要对其进一步处理。综上，由于日志来源的问题，SOC基本上不适用于安全的事前和事中处理。 受限于客户的技术水平和其他因素，导致关联分析很难用起来。SOC的一个故事就是通过关联分析发现攻击行为，分析攻击结果并定位攻击路径。但是关联分析的使用是有很多限制的。首先是要知道分析什么，或者说监视什么问题，否则都不知道该把哪些日志关联起来，这就决定了SOC的关联分析不可能处理未知问题。其次定制管理分析策略需要对整个系统的日志有着详细的了解，同一个问题在不同环境下关联分析的策略是不同的。举个例子，我们曾经给客户定制过发现ARP病毒的关联分析模板，其策略是利用Cisco交换机的MAC冲突日志，具体策略是当10s内冲突超过3次即认为网内有ARP病毒，但是如果当时客户有防病毒系统的话，直接引用防病毒系统的日志就OK了。分析环境定制关联策略是需要非常高的技术水平的，不要说客户的工程师，即使是厂家工程师，也不可能将所有设备的日志都研究清楚。因此，关联分析策略是需要有一定技术能力的工程师进行长期磨合和调整的，而受限于成本，厂家和客户都不可能长期搞这种事情。 对SOC系统本身的定位不清由于厂家的忽悠或者其他原因，客户经常会对SOC系统抱有过高的期望，这使得客户见到实际产品时往往很失望。这是对SOC的功能定位不清。另外，如果SOC牵扯了工单管理，也即进入了客户的管理流程，这和客户的部门职能，甚至组织架构都是有关系的，这也使得这部分功能要不需要重新做二次开发，要么很难用起来。这是对SOC的应用定位不清。 以上是我分析SOC目前使用不好的主要问题，前两条是主要的技术问题，其实技术问题还有很多，如NTP的问题等等，但是以上两条是我认为最主要的两条。而对SOC系统本身的定位不清则是使用的问题