一、现在的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系统本身的定位不清则是使用的问题。

三、技术的SOC和管理的SOC

SOC在刚推出时，主要理论依据是“三分技术、七分管理”理论，认为SOC是技术和管理的结合点。而如前面分析，SOC其实即没有解决技术问题，也没有解决管理问题，这其实就是SOC的定位问题。

在定位方面，有技术的SOC和管理的SOC两种。SOC究竟应该是技术的？还是管理的？笔者认为厂家的SOC产品应该是技术的，客户的SOC系统应该是管理的。听起来有点和稀泥，但是却是最符合现实的。

从厂家角度说，以及从客户对厂家提供的SOC产品的期望角度来说，SOC产品应该是技术的，主要提供的应该 是对系统日志的统一收集管理，如果有可能则做一点安全设备的集中配置管理。也就是说在解决方案中，SOC应该提供的应该是日志审计+配置管理的职能，如果 做不到配置管理，那就做纯粹的日志审计使用。这也是SOC实施成功的第一要件，降低客户期望。

从客户应用角度说，SOC应该为客户的安全管理起到作用，也就应该起到安全OA的作用，但是如前所述，这可 能牵扯到客户部门职能和组织架构的问题，因此应该和其他OA系统一样，根据实际情况做定制开发。不排除可以先提供一个比较普适性原型，然后在这个原型上做 开发，但是这部分的定制开发可以说是必要的。

通过标准性的日志审计+配置管理，结合定制开发的安全OA系统，最终可以给客户提供一个管理的SOC。

四、一个简单的SOC的模型

安全事件的处理流程可以简化为：“触发”-》“决策”-》“处理”的循环，在加上一个全过程的“审计”或者“监控”。

其中“触发”不只是靠日志收集和告警，原因就是前面说的日志源的可用性问题，应是人工触发和SOC日志触发相结合。但是“触发”以后，需要在SOC系统里面快速汇总相关日志，分析事件原因，并形成处理意见提供给“决策”。

“决策”主要是根据SOC系统分析出的事件原因和处理意见进行决策。因为可能需要多部门配合（比如网络管理部门和系统管理部门配合），因此“决策”实际上是一个协调过程。

“处理”就是根据“决策”的结论，各个部门进行技术操作，化解安全事件，恢复系统到正常状态。

而对“触发”、“决策”和“处理”的全过程应该有一个“监控”和“审计”的部分，留存证据，分清责任。

五、谁来使用SOC

这其实是SOC能否起到作用的关键。一万个客户就会有一万个不同的SOC，搞清楚谁来使用SOC也是决定一个SOC成败的关键。笔者认为可以分为以下几种：

* 客户的安全管理部门
这是要达到目前我们宣称的SOC作用的最佳使用者。这个部门的权限一定要高，才能将SOC系统的最大效能发挥。此时SOC可以实现“触发”、“决策”、“处理”和“监控”的全部内容。
顺便说一下我对客户IT部门架构的理解。随着CIO地位的提升，CIO下属应该有三个主要的部门，需求分析 部门（主要负责和业务部门沟通，分析IT需求），IT维护部门（负责日常的运维），IT审计部门，有能力的大型企业可能还有自己的开发部门，负责一般性的 业务系统的开发。安全管理部门应该隶属于审计部门，不负责安全设备的维护。而安全设备的管理和运维则应该根据设备形态归属于不同的IT维护部门，比如防火 墙应该属于网络运维，CA和主机加固软件则应该属于系统管理等。
这种情况应该是理想情况，但实际上好像没有任何一个地方是这么做的，应该是非常高的IT应用水平才会出现这种架构，呵呵！如果是另外一个极端，客户IT水平很低，IT部门甚至没有下属分支，其实也属于这种情况，也可以这么用，只不过系统本身会简单的多。
* 客户的运维部门
有些客户有专门的安全部，负责防火墙等设备的运维。有些则是将安全划分在网络下面，属于网络运维的一个分 支。不管哪种情况，这种SOC往往不需要“决策”，甚至无法有效的“处理”。原因很简单，因为这个部门没有足够的权限去驱动其他部门（如系统管理部门）去 动作。此时要做的，是推动一个能够统管全局的领导（分管IT的副总）作为一个独立的决策点，这样也能实现SOC的全过程，只不过这时，非重大的安全事件其 实也不能走这个流程，毕竟没人愿意处理个终端病毒问题而去麻烦副总。因此，这种情况下，事件的分级处理就显得非常重要。如果连推动分管领导都很难做到，那 么SOC主要的作用，其实就是形成报表，并在出现安全事件时能够辅助分析事件原因。
* IT外包的运维
此时SOC即可以作为IT外包的服务工具（功能与情况一基本类似），也可以作为对IT外包的管理工具。后者的功能就主要是对安全事件的整个处理过程加以监控了。

六、SOC的实施

前面提到，现在的SOC在实施过程中，都需要对接口进行开发，这是绕不过去的。除此以外，应该对集成的安全 OA进行基于原型的二次开发。这样才能形成一套客户用起来还比较顺手的SOC。除此以外，SOC在实施过程中还有一个重要的内容就是关联策略的定制，在收 取一定费用的前提下，厂家可以派一个有经验的工程师对客户现网设备日志进行一次比较全面的分析，并和客户沟通其所关心的问题，定制出一套客户所需要的关联 策略。这个过程不可能太短，至少需要1个月，要想真正做好甚至可能需要2个月。这其实也是考验厂家能力的地方。但是最重要的是，在SOC实施之前，要告诉 客户在它的环境下，SOC究竟能做到什么样子，让客户对SOC有一个合理的预期是SOC实施成败的关键。

通过这样的一个SOC的实施过程，对前面所提到的SOC所存在的问题可以基本上做到规避。比如，不让客户以 为通过SOC可以发现未知***，而把 SOC作为事后处理的工具就可以规避日志来源可用性的问题。通过收费的策略定制服务，也可以规避关联分析所带来的问题。而根据客户部门的职能和组织架构提 出的针对性的SOC功能和二次开发则可以明晰SOC的定位。

【小结】

总的说来，要想用好SOC，不能把SOC只当成一个和其他安全设备配套形成解决方案的产品来看。相比于配套 解决方案，其实SOC其实更适合作为安全咨询服务的后续工作来做。现在客户往往分不清安全咨询服务和风险评估服务的原因，其实就是两者的输出太接近了，都 是一套类似的解决方案。而有SOC作为基础，安全咨询在解决方案之外的很多东西就可以落地了。