“关于SOC的一点讨论”有47个回复

1. 陈怀临 于 2011-01-02 9:07 下午

   写的不错。我觉得syslog的大量垃圾log是一个很hurt的东西。。。但这个问题的mining还特别难。。。

2. Will Chie 于 2011-01-02 9:43 下午

   顶，好文，对SOC没研究，学习了。

3. old_peter 于 2011-01-02 9:51 下午

   写的不错。看完之后非常有同感。。

4. willchen 于 2011-01-03 2:25 上午

   对于本文的前面需求分析部分，十分认同。
   在SOC刚出来时，因为种种原因，厂家的宣传对SOC的定位产生了偏差。这就导致该产品线始终得不到应有的地位并发挥其应有作用。谈到SOC，一般会翻译为“安全管理中心”或“安全管理平台”，其中的“管理”二字之理解，就如zero所说，厂商与用户是不一样的。从用户角度来说，一下子就理解为“管”，各种操作，对设备的管理、人员的管理等。而实际情况确实该产品的定位更类似于log产品的增强版。由期望不同而产生的使用效果很差就不足为奇了。
   文中有几个地方提出些不同意见：
   1、关于“审计”。文中提到了应由CIO下设的IT审计部门来完成。窃以为万万不可，这不就成了自己审自己了么。其实各大型企业都有单独的审计部门。传统上这个部门主要进行财务审计和采购审计等。我认为IT审计应该放在这个统一的审计系统中，而且审计的直接主管应与IT部门主管平级或高一级。这样才能更好的行使审计权力。我国的商业银行风险管理相关规定中也明确指出审计部门应对IT部门进行专项审计。
   所以，这个SOC，理想状态上应该如同ERP系统，不单单是企业内一个部门使用，而应贯彻在企业整体IT内控中去。
   2、关于SOC是否必须定制开发。这里其实牵涉到一个成本与需求取得最佳性价比的问题。
   我在前面那个回帖中将SOC简单进行了定位，其中瘦SOC既希望不进行定制开发，而实现必要使用功能即可。为什么这么定位，是因为并不是所有有SOC需求的用户都有资金和时间进行SOC定制开发。如果将SOC完全定义为一种定制开发产品，将极大地限制其应用和推广，不利于该产品线的自我生存和发展。
   如果能实现针对60%的用户采用标准化模块产品实现他们80%的需求，而其他的40%用户推荐定制化开发SOC，我认为是种理想状态。
   SOC的争论不会有谁对谁错，也应该有多种SOC形态并存。这就好比防火墙虽然挡不住UTM大潮，但其低廉的价格和通用、简单易部署特性使得其永远不会完全被UTM代替一样。

5. zeroflag 于 2011-01-03 3:21 上午

   to willchen：

   您所提的两点都是认同的，但稍微解释一下：

   1、我说的CIO下面的审计部门可能用词不是特别准确。这个部门不是企业的内部审计部门（比如SOX的审计部门），而应该是IT策略执行的监控部门。这个部门的职能应该是对CIO制定的企业IT策略在建设和运维过程中执行情况的监控。IT安全策略作为IT策略的重要组成部分，放在这个部门里面是合适的。而如果把安全部门完全独立于IT部门，挂在企业独立的审计部门之下，可能会离IT太远而造成一些别的问题。应该说各有优劣吧。

   2、所谓瘦SOC，我理解就类似于如“管家婆”的库管系统一类的通用管理软件，做的是一个比较通用的流程，对于中小企业客户来说，本身也没什么太严格的流程，用这些标准流程其实是对自身管理能力的一个提升，也就没有所谓应该“削足适履”还是“改履适足”的纠结。但是我只要是客户自发的SOC需求，往往都意味着客户自身有比较高IT水平，所谓瘦SOC能满足他们的需求吗？而对于非自发性的SOC需求，说实话，提供什么样的产品都没关系了。

6. zeroflag 于 2011-01-03 3:32 上午

   另：其实我在研究SOC的时候，还有一点很纠结的地方，就是SOC和其他管理系统的关系，比如网络管理系统，虚拟机管理系统等等，数据库管理系统等等。我们会发现很多地方都有交叉，每个系统也都有日志汇总管理，总之很纠结。

   也许只有基于IBM的Tivoli进行定制化开发，将各个不同的系统进行整合，这样的大一统系统才能提供完整的IT管理解决方案。不过，从内心上讲，我非常不喜欢大一统的解决方案的复杂性，我更愿意用一堆可以互通的简单系统来实现所需要的功能。

7. willchen 于 2011-01-03 6:24 上午

   to：zeroflag
   其实国外对SOC发展的方向只可以做个参考。国外没有统一的SOC定义，一般分为以产品出发的SIEM和以服务出发的MSSP。
   要说以产品为出发点，arcsight恐怕比IBM做得更为专业和全面。好像天融信和其他几个公司都OEM过或正在OEM。其缺点么。。。价格太高，并且没法定制化。毕竟是国外产品。
   如果以服务为出发点，赛门铁克是国内最为熟知的国外知名厂商。
   但个人以为国外的SOC发展方向只能参考，不能直接复制。因为国情差别太大了。特别是管理制度和管理思想。中国的特色其实是件好事儿，可以让中国厂商有机会开发出中国特色，独占市场的产品。就好像用友及QQ一样。看谁能真正的发现并很好的进行市场开拓了。
   作为紧贴市场的人，我还想从另一个角度建议SOC产品线的发展。一个产品经理应不只考虑技术能做到什么程度。对产品定位及推广方式有时候应甚于对技术的关注。
   SOC产品在不同厂家做法和定位也应该很不同。比如联想网御和天融信应该更着眼于产品方向，将SOC更好地与自有产品线融合。而启明和绿盟应该更着眼于服务方向，将SOC与服务团队，服务能力紧密结合。这一点国外已有先例，我前面提过不必重复。
   SOC在中国沉寂已经有一段时间了，但我始终深信SOC一定会重振旗鼓。这是信息安全发展的必然。

8. 飞熊 于 2011-01-03 6:56 上午

   好文。
   举一个我碰到的例子，某银行客户，IT部门、安全部门、审计部门都是独立的，互不隶属，之上有一个IT的总经理。引入SOC之后，放到安全部门，碰到了如下问题：
   （1）各部门之间如何驱动，难免会存在扯皮，安全部门拿出的报告会遭到IT部门的质疑， IT部门指出的安全问题会被安全部门漠视，最后问题还要汇总的总经理，没有产生效率。这其实是组织架构的问题。最后还是通过虚拟团体+CIO解决的。
   （2）一万个客户有一万个SOC，深有同感。客户曾希望SOC输出一个指标，这个指标能标识当前整网的安全状态，类似于360的体检值，例如0.9表示很安全，0.1表示很不安全。这个问题hurt我们2个月的时间，最后通过最简单的指数+权重解决了这个问题，但是为了保证实用，学习了半年的数据，不断地修正调整，最后还加了一个神经网络前向反馈的函数。即使这样，我们自己心里也忐忑。不过好歹，客户满意了。记得天融信有一个部门，好像专门做通用策略模板，不同的用户场景不同的策略模板，或许能减少这种二次开发。
   个人感觉，SOC一开始的忽悠点就是“三分技术，七分管理”，但是因为不同的设备、真假难辨的日志、二次开发、不同用户场景导致难以推广。个人不成熟的思路是抓紧数据挖掘+专家系统，思考中。

9. 陈怀临 于 2011-01-03 7:11 上午

   同意，log分析技术变得很重要。。。

10. 理客 于 2011-01-03 8:58 上午

    个人建议可以先从客户的关键需求开始，定义SOC中各个功能的实现模型，类似pattern。同时支持从一些业界标准的日志/netflow等提取数据，通过模型算出结果。同时提供开放的接口，用于客户实际使用的其他各种安全产品的log/alam类信息提取。长此以往，形成一个良性循环的SOC平台产品，应该有自己一小片独特的小地盘

11. slopover 于 2011-01-03 10:49 上午

    好文，对soc的描述说的很明白，当下soc主要是要用起来，看的多用的少就没意思了

12. droplet 于 2011-01-03 6:11 下午

    SoC很重要的一个功能是policy管理，这个和网管不太一样。一般网管都是snmp，SoC用的是私有协议吧。在安全管理里面，区域划分，角色，权限定义，以及策略，都是难点。

13. zeroflag 于 2011-01-03 6:37 下午

    to 飞熊、首席：

    log数据的深度挖掘究竟该怎么做，现在想不清楚。

    可以提出的困难中，第一的还是日志本身的可用性问题，可以说基于L4～7层安全设备的日志做数据挖掘没什么意义。如果能准确识别，那么一般都可以同步做自动处置，不管是IPS自动阻断，防病毒自动杀毒，还是P2P自动限流，只要识别出来就可以顺手处理了。如果不能准确识别，那么这种存疑的报警如何认定其是否为误报？漏报更不用提了，干脆没有日志。

    所以要从log分析出问题，那么可用的日志源其实是网络设备、操作系统、数据库、中间件还有业务系统本身的日志。而怎么从这些日志里面挖掘出问题，个人认为不是算法能够解决的问题，算法能够解决的是给定的问题，而各种系统的日志千奇百怪，而且随时可能变动，又不是基于XML的，如何让计算机理解这些日志本身就是一个挑战，更不要说再让计算机去分析了。

    因此，现有的通过人工针对特定问题制定关联策略可能是目前工程上的唯一可行解。

    另外：飞熊你那个打分的做法虽然可以让客户暂时满意，但是如果有一天客户的网站被攻击了，而你的SOC打分还显示是0.9，那尴尬就不是一点半点了。而出现这种情况其实并不是你的SOC本身做的如何，而是你的信息源本身就提供不了准确可用的信息。

14. zeroflag 于 2011-01-03 6:45 下午

    to droplet:

    事实上，SOC一般都没有所谓的Policy管理的功能。我接触的第一款SOC，是基于我当时公司的IDS的管理端开发的，只可以给那个IDS做Policy管理，对其他产品无能为力。后面接触的几个，如eIQ，干脆什么设备的Policy也管不了。

    说到这个问题，就又回到标准化的问题了，各个厂家的设备功能不同，理念和特性不同（如基于Iptalbes的防火墙其实是没有安全域的概念的），配置界面也不同。如果都是WEBUI也还好，还有很多是需要专门的Client的，基本上这个问题是没有搞定的可能。连做统一的策略备份和恢复功能的可能性都很低，更不用说做配置了。

15. zeroflag 于 2011-01-03 6:51 下午

    其实SOC这个话题如果讨论技术，往往越说越丧气。你会发现，这个东西除了做日志收集然后展现（实时和报表）以外，真的真的可以做的事情不多。集成OA可能是另外一个可用的点，但是往往又和客户的实际情况有所区别，很痛苦。

16. jiaruifu 于 2011-01-03 7:14 下午

    To zeroflag
    海量log的综合分析是传统SOC的一个方向。
    但是要出彩，还是要有价值的、有个性的log，分析才会有意义。但是什么是有价值的log，各个IT系统本身就有输出（SOC被动接收数据，对数据进行加工，核心竞争力不突出，而且谁都能做），而且各个企业的要求还不一样。
    客户痛点是希望有产生有用log的安全系统。网络行为log，如session数、端口信息捕获比较实在，是一个发力方向。

17. droplet 于 2011-01-03 7:49 下午

    如果有强力客户，比如军队之类的，强制要求各厂商提供到中间policy的adapter，然后用一个统一的policy管各家的设备，我见过有人这么做。有个开源的gui, firewall builder，好像是，可以配置多种开源防火墙，比如iptables, ipfilter等等，这说明还是能抽象出共性的。个人任务，安全管理，难的还是policy。

18. jiaruifu 于 2011-01-03 10:54 下午

    To droplet
    同意你的意见。关键还是要有policy，以及完成和执行policy的设备。

19. zeroflag 于 2011-01-03 11:45 下午

    to jiaruifu：

    您说的这个方向，窃以为就是IDS换个名头的方向。通过部署可信的检测器，让SOC发挥作用。事实是，可以准确检出的东西，不论是攻击还是流量，都有专用的设备可以直接控制，不需要额外部署探测器。这个方法面临着和IPS/IDS和流控设备的竞争。

    to droplet：

    您说的这种策略部署也不是不可以，但是其实也是基于特定安全产品的（只不过是开源的而已）。普适的策略部署，现在看还没有很好的解决办法。

    现在能做的，恐怕就是提供WEBUI的接口了。更进一步就是通过接口开发，做配置文件的自动导出备份和恢复。而通过UI直接配置策略，再将这些策略转换成设备策略并下发到设备里面，现在不太现实。不是完全不能，而是部署时，客户现场开发的工作量太大。

20. willchen 于 2011-01-04 12:22 上午

    to:droplet、jiaruifu
    policy下发这件事儿，我的观点和zero一样。自己公司的产品还靠谱一点。而且就算是自己公司的产品，目前绝大部分公司也只能做到对单台设备的策略配置或下发。整体的策略配置只见过当年的netscreen出过可用版本。记得是基于SUN的硬件，java写的。
    之所以会出现这样的情况，有两个问题很棘手。拿防火墙举例：每台防火墙的策略不可能完全一样。因为部署位置不同，策略一定不同。这时候还必须根据每台设备的位置再手动更改策略，发现没省事儿。二是万一配错了，特别是端口参数配置错了，或者策略封禁了管理端口，那下发后乐子可就大了。全网不可管理，管理员跳河的心都有。
    至于军队干的那个SOC，我所知空军和总参都在搞。到现在应该有5年了吧？产品还没出。技术支撑的厂家好像是上海的。我很不看好。原因是：各安全厂商谁也不肯真的把接口完全开放。就连日志的解释都遮遮掩掩的。一是怕被别人知道了底细，二是自己知道报的很多日志其实都是垃圾，自己都看不懂。
    to：zero
    不用谈SOC就悲观。还是那句话，好的定位和市场营销才是双赢之路。一是自己别想多了，二是让客户别想多了。引导客户，引导技术。自然会有康庄大道。

21. jiaruifu 于 2011-01-04 12:37 上午

    To zeroflag
    您说得很对，soc没有合适的sensor，没有有效系统的支撑，什么都是空谈。皮之不存，毛之焉附？
    另外如果soc缺少ips/IDS的参与，soc会完整吗？当然ips/IDS也会发展，网络行为分析会整合进去，空间很大，钱途很光明。
    soc正走在统一和曲折发展的路上。未来soc是个什么形态，个人认为其首先应是一个平台。

22. zeroflag 于 2011-01-04 2:20 下午

    to jiaruifu：

    我和你观点正相反，这些sensor既然已经可以发现问题，为什么不直接处理？还要通过SOC来处理？如果发现了就直接处理了，那么SOC的价值何在？那不就是IPS和IPS Manager之间的关系吗？

23. jiaruifu 于 2011-01-04 4:53 下午

    To zeroflag
    冒昧问问：你提倡的soc的核心竞争力、核心产品或者核心买点是什么？
    我们对soc目前处于一个什么发展阶段有分歧。我认为还是初级阶段，你讲的是高级阶段的事情，如系统和系统log之间的关联事件分析等。
    如果饭都吃不饱，农民工怎么可能买别墅住豪宅了。soc还需要打好基础。我是站着说法不腰疼，感觉你在做这方面的产品，且面临某种选择和决策。

24. zeroflag 于 2011-01-04 6:06 下午

    to jiaruifu：

    我现在不做SOC，只是以前研究过一年，说说自己的看法而已。

    我认为在技术上或者规范上有重大突破以前，真正有价值的SOC恐怕很难打造出来。如果打造不出来，不如老老实实做好能做好的事情，承认自己是SIEM没什么丢人的，有能力帮客户做定制化开发更好。不要随便包装，把这个很好的概念给毁了。

    这么多年，安全都是盛产概念、理念、架构的一个圈子，但是这些概念、理念、架构又何曾有过真正意义上的创新？阿姆斯特朗在月球上的那一小步是人类的一大步，安全在自己家里兜圈子的步子，迈的多大都不是人类的一步。少些概念，少些浮躁，踏实的把自己已经宣称的东西做好，这才是安全之福。

25. jiaruifu 于 2011-01-04 6:56 下午

    To zeroflag
    目前soc可以是到什么山上唱什么歌，但是自己不能把自己给忽悠了。产品目标、方向、路标要规划好，要一步一个脚印做扎实。这条路还很长，而且也是安全系统未来绕不过的弯弯。
    soc绝对不能为他人做嫁衣，要有自己的核心竞争力。否则就是空中楼阁，就是一锤子买卖，无法基业长青。
    你研究soc一年，思路是否更清晰了？

26. F22 于 2011-01-04 7:01 下午

    国内一直都叫SOC,”安全运维平台”，解决的问题不光有“安全”还有“运维”，而运维的概念在这里就关系到客户企业的管理流程了。这是一个所谓的“管理系统”脱离不开的，这也是管理系统核心能力所在。
    既然SOC定位是一个管理系统，那么就注定其需要与客户企业的流程相符合，否则，其他一切技术都是浮云。但是企业流程是复杂的，千变万化，各有不同，又都万变不离其中。
    所以，SOC的需求，定位和问题，实际上是由企业流程决定的，解决这一问题，最好的方法就是向其他管理系统学习。
    怎么实现管理系统，在这里不是我想讨论的话题，其实管理系统业界有很多最佳实践，基本上就是基本功能组件化，流程可定制化，定制化二次开发等等。那么SOC是否能够采用相同的解决方案的，我认为是肯定的，也是必然的。
    其实，国外类似的系统一直都叫NSM（Arcsight、RSA等等），他的定位要小的多，只专注与日志收集，监控等功能。但是系统也是有独立组件构成的，针对不同客户需要定制开发，而对于管理功能实际上，只要做好与企业管理系统的接口即可，并不需要来实现一个完整本中的管理系统。这样的解决方案其实是很实际而且定位清晰的。值得国内的同行借鉴。
    所以对于安全运维这种大问题，不一定要在一处解决，将问题分解，各自解决，才能获得良好的效果。

27. jiaruifu 于 2011-01-04 7:49 下午

    to F22
    同意你的观点：分而治之。
    另外流程无非是一套告诉别人做事的方法。soc与流程有关，但流程和思想不是soc的全部，初级阶段来看也不是soc的关键和核心所在。方法需要不断探索和实践。借鉴可以，完全搞拿来主义是懒汉思想，鲁迅讲的舶来品，天上也不会掉馅饼。
    一直不愿意用文字整理自己的思想，今年想改变一下自己，文字还是沟通的关键工具。如有得罪各位专家和看官，谅解啊，小弟有礼了。

28. 张百川（网路游侠） 于 2011-01-05 3:30 上午

    SOC本身，至少就目前的技术而言，只能做个具备关联分析、具备流程管理的日志管理系统来用。

    很多人说的“管理”功能，实际上吹的多，几乎用不起来。不信你用A厂家的SOC去管理B、C、D厂家的IPS、FW、主机审计、防病毒软件试试看。

    业务的复杂性决定了这个产品在现阶段只能依照标准的SYSLOG和SNMP等来运行，别的，都是浮云。

    做SOC、MSSP、日志管理，其实很多用户是感兴趣的，但是却成单率很低，相当低。用户认可是一方面，另一方面产品自身的完善、稳定也是个问题。

    还有一个问题：用户网络具备IDS等设备的太少了……单纯靠交换机、路由器日志量太少了。

29. willchen 于 2011-01-05 6:43 上午

    讨论来讨论去，已经有些乱了。

30. jiaruifu 于 2011-01-05 7:35 上午

    乡下土路本来是拖拉机开的，你却买个奔驰来跑，当然也能开，关键还是摆阔。SOC就是目前这种现状。
    还是要抓基础设施的建设，通俗点就是多修路。

31. tom 于 2011-01-05 6:38 下午

    # old_peter 于 2011-01-02 9:51 下午

    写的不错。看完之后非常有同感。。
    老皮特，是你吗？还吃烤鱿鱼吗？哈哈！想不到你在这里见到，原来你也是弯曲的读者，真高兴。

32. Airain hou 于 2011-01-12 11:54 下午

    弱弱地说，我觉得，要论SOC,启明星辰的不错。

33. tom 于 2011-01-13 12:19 上午

    偷偷的说，启明的soc做的差远了，国内的厂商把产品叫soc，本身就是忽悠

34. Will Chie 于 2011-01-13 3:28 上午

    32楼是坏蛋，鼓动大家批判启明星辰。

35. Mopsec 于 2011-01-13 6:32 上午

    据说（注意是据说），启明除了网御的SoC团队外还得到了网神的SoC团队，要一统江湖了

36. fatalerr 于 2011-01-13 8:09 上午

    没进来之前还以为是在讨论System on chip呢。

37. willchen 于 2011-01-13 9:00 下午

    回35楼：
    网御就没有所谓的SOC团队。网御的SOC就是设备管理系统，没有任何日志分析能力。

38. 嗣同老乡 于 2011-01-13 11:01 下午

    日志关联分析利于复原事件现场，做事后追查。日志的即时呈现让IT能对网络运行状况有感性认识，这个是对掌控网络需求的满足。如果能在日志关联是做策略调整就更好了，比如idp发现问题通知firewall等等。不同的应用场合关注的焦点不同，我们是否可以简单地划分为两类:非外向型和外向型，即是否支持丰富的internet访问。对于非外向型，对于风险的预防，NAC会是一条出路。当然最好里头嵌入host check。像zeroflag说的，网络设备的日志关联是不够的，最好还能跟虚拟机，病毒管理等设备的日志关联。而外向型，就托管或者交给云吧，牵扯到云或者数据中心就犯晕了，说不好。

39. Abelard 于 2011-03-02 12:55 上午

    其实难就难在不同厂商设备之间的日志关联和分析，如果是同厂商的，那么就是MARS。
    其实我考虑等云技术成熟了完全可以做成一个依靠云平台的服务，SOC只作为日志统一收集的平台。但是客户保密和信任方面那时又是另外的问题了。

40. 理客 于 2011-03-02 1:52 上午

    所以要做一个middleware，把厂商的信息自动、半自动和手工的和自己平台间做translation

41. tom 于 2011-03-02 11:34 下午

    Arcsgiht 标准化和关联分析做的已经很好了，无论是标准化还是粒度目前看都已经是最好的！
    soc严格来说应该是siem，其核心价值在于：
    1 跨设备，跨系统的关联分析
    2 long-and-slow 攻击检测
    3 架起管理与设备的桥梁
    国内的soc产品就不做任何评论了

42. ballack 于 2011-03-03 11:24 上午

    sorry cannot tape in chinese

    that is really good ‘judge/evaluate’ doc about SOC and log analyse, very good pre-PLM

    anyway, for PLM and Dev lead, the most important goes to define and put the client messy thought into design principles one by one

    and there is one principle could be crazy for Dev guys, you have to match the client working procedure, they are different for each customer, so you have to make them all.

    from easy to hard
    some are: 1) save and analyze/search; the most stupid way
    some are: 2) reporting oriented, what would be significant reporting chart at all? how could the SOC give the indication of the status of the attack, and how the firewall performed of the defense, either suggest new configuration of even upgrade
    (so, ask the client to upgrade, haha)

    3) attack and defense analyze beyond single node itself,beyond immediate time,and I do not think arcsight do good enough in between multi devices,even you’d like to ask the same attack method, same attack source, just for one critia, make a distribution in 3-D per the time and devices, and how can you combine and show out with 4-D? did not see this in arc… heihei

43. chinomango 于 2011-04-27 12:02 下午

    很讨厌缩写一词两用，SystemOnChip用了多年，又来折磨个东东，当然作者只是引用，最初用的人够讨厌的。老美是否喜欢一词多用，还是文字贫乏？国家总统叫president,公司总裁学校校长也叫president,下次把下水道总开关也叫president得了。

44. 这个贴也需要说一下 于 2011-05-09 10:19 下午

    平心而论，从安氏大张旗鼓的2000多万搞某运营商soc项目开始，到现在所谓soc项目沦落到几十万一单，国内基本上没有成功意义的soc项目。

    我个人感觉，国内用户IT管理环境和厂商，各五十大板，平均负担责任。

    这几年也卖了上亿的soc了，光给GDP做贡献了，产品本身没有实质性提高，怨不得很多人说国内没有几个真正搞技术、搞产品的公司，环境使然啊！

45. tom 于 2011-05-10 8:01 下午

    soc，现在已经忽悠不下去了，换包装了

46. kevint 于 2011-05-10 8:28 下午

    各种增强8051和低端arm的soc搞的风生水起的，貌似也能养活不少人

47. iosnew 于 2011-05-13 9:40 下午

    岁岁年年人不同，风景相同。
    弄个外包装，接着忽悠的例子多了，淡定。