SOC的几点问题

1、如今的SOC是怎么作的

现有市面上的SOC产品在功能上各有各的特色，可是总的说来，核心功能都是以统一收集日志（主要是 syslog日志，也有SNMP拿到的信息，有些还能收集NetFlow/NetStream/S-Flow等日志）为基础，再将收集上来的日志加以标准 化进行存储，再对这些日志进行一些处理（如归并、根据策略进行关联等），再加以呈现（能够是实时呈如今屏幕上，也能够生成报表）。

以上是SOC的核心功能，在此以外通常还会有工单管理功能，也即一条告警过来之后就造成工单，让管理员和各级主管能够跟踪一个安全事件的处理过程。至关于集成了一个OA系统。

有些SOC还会集成一些工具，好比漏洞扫描工具或者集成IDS配套。事实上，不少SOC的原型都是厂家IDS的管理端，在IDS管理端上增长收集其余厂家其余类型产品的功能，再作关联分析而成。

除了产品设计之外，现有SOC在实施过程当中还有一个很是重要的工做，就是作日志接口的开发。因为市面上的安 全产品种类繁多，品牌繁杂，又没有统一的日志标准，好比天融信的防火墙，其不一样版本的日志格式都不同。故此任何产品都不可能兼容全部产品，那么在实施的 时候，为了把客户现有的产品都归入进来就必须进行接口的二次开发。不然必然会有一部分产品的日志收集不上来，或者收集上来之后识别不出。

2、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系统自己的定位不清则是使用的问题。

3、技术的SOC和管理的SOC

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

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

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

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

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

4、一个简单的SOC的模型

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

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

“决策”主要是根据SOC系统分析出的事件缘由和处理意见进行决策。由于可能须要多部门配合（好比网络管理部门和系统管理部门配合），所以“决策”其实是一个协调过程。

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

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

5、谁来使用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外包的管理工具。后者的功能就主要是对安全事件的整个处理过程加以监控了。

6、SOC的实施

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

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

【小结】

总的说来，要想用好SOC，不能把SOC只当成一个和其余安全设备配套造成解决方案的产品来看。相比于配套 解决方案，其实SOC其实更适合做为安全咨询服务的后续工做来作。如今客户每每分不清安全咨询服务和风险评估服务的缘由，其实就是二者的输出太接近了，都 是一套相似的解决方案。而有SOC做为基础，安全咨询在解决方案以外的不少东西就能够落地了。