Anton以自己在跟客户沟通中了解到的信息作为佐证，说包括一些财富50强在内的企业在几年前自建的所谓安全分析项目耗费了大量资源，但收效甚微。有的客户表示“我宁愿希望我们从未听说过Hadoop这个东东，我们浪费了数年时间在企图基于Hadoop构建安全分析能力之上”(we wish we’d never discovered Hadoop – we wasted years of trying to make a security analytics capability out of it.)

　　Anton进一步探讨了可能的失败原因，包括：

　　1)大数据池中充斥者垃圾数据;【我注：安全数据湖变成了安全数据臭水塘】

　　2)收集数据其实是个坑;【我注：没错，要知道，SIEM/SOC厂商用了N年时间才差不多掌握收集数据的种种坑，自建大数据安全分析平台，那么这些坑还要重走一遍，flume, logslash并不像看上去那么easy】

　　3)数据访问有问题。好不容易将数据导入湖中了，但是如何调出这些数据去进行分析?基本做的很失败，包括hadoop自身存在的问题。所以Facebook的人说“是时候停止用hadoop来做分析了”!hadoop做存储和批处理是OK的，但是不适合用于做分析。这篇文章进行了详细的论证。

　　4)大部分项目止步于收集完数据，填满了大数据湖。后续的分析工作举步维艰。

　　5)如果说还有什么分析功能的话，其实基本就是关键字全文搜索【注：当初说好的高级安全分析呢?】

　　6)没有检测出什么威胁。大部分平台搭建好后，集成了各种分析工具，ML库，但是安全分析场景呢?对不起，没有。安全分析场景的构建远比想象中的更难。

　　7)安全分析师匮乏【注：别指望什么AI，自动分析，没有安全分析师，平台的价值难以体现】

　　结果呢，很多所谓成功的大数据安全分析项目其实就是装个ELK，把日志装进去，做个全文检索。这与当初的设想相去甚远。

　　Anton对于在今年内自建大数据安全分析或者基于开源大数据安全分析平台(metron,spot等)的尝试都不看好。【我基本赞同这个观点，metron是从Cisco的OpenSOC而来，还处于孵化阶段，远未成熟。而自建平台需要通晓大数据技术和安全领域知识的跨界人才，要能将复杂的工程技术与深厚的攻防对抗能力结合起来，目前来看，这个要求太高】

　　Anton的这个论断一出，立即引发了很多争论。我觉得Anton这么提也是为了振聋发聩，引起业界的重视。但无论如何，我们看看上面那些失败的可能因素分析，的确足够引起我们深思。

　　放眼中国，我有些许“欣慰”，原来国内企业和组织的遭遇老外们甚至财富50强们也都正愁着呢。也许有些互联网公司会说自己就有自建的大数据安全分析平台，那么，请对照上面的内容自我检讨一下，无则加勉。

　　那么怎样才是建设大数据安全分析平台的正确姿势呢?Anton没有明确提出来。不过，我个人认为，在近几年内，开放的混合架构可能是一个稳妥的选择。混合，也就是指混合商业的软件和开源的软件，有的部分用开源的，有的部分用商业化产品/组件，各施所长。开放，也就是说这个平台软件架构必须是开放可扩展的架构，能够将开源的组件和商业化的组件进行组合、扩展、替换。

　　此外，在底层技术支撑架构的设计方面，要慎用Hadoop，千万不要觉得有个hadoop就多么牛掰，“言大数据必称hadoop”的思想很危险，spark也不是什么善茬儿。hadoop到底需要不需要?It depends，放到安全分析的情境之下，其实还有很多细致的考量。

　　还有，大数据安全分析平台的工程化远比画一张设计图纸要难得多。从验证到投产更是对工程化的严峻考量。

　　别忘了，构建这个平台本身不是目标，用起来，分析出安全问题才行。而这不是仅有平台就Ok的，还需要配套的组织和流程，以及——人!大数据安全分析非但没有降低对人的技能要求，反而大大提升了对人的能力要求。

　　最后，其实不仅是将大数据应用于安全分析遇到的阻碍，在大数据的各个应用领域，都不是一帆风顺。之前Gartner已经警告过：大数据泡沫可能即将破裂。而在年初的Gartner数据与分析峰会上，同样也表达了对大数据项目的悲观预测，称“2017年部署的Hadoop系统中有多达70%将无法实现预期的成本节省或创造营收的目标”。

　　Anyway，大数据安全分析平台必须做，做下来才能发现问题，才能去解决问题，系统才能不断进化，这是大势所趋，困难都将被克服。但是具体落地需要谨慎，don’t boil the whole ocean，不要盲目求新，要在继承的基础上去发展，以往其实有很多好的实践经验，不要扔掉。

　　各位对此有何想法，欢迎交流。

作者：叶蓬

来源：IT168

原文链接:Garnter:自建大数据安全分析平台恐失败