为什么你的安全数据湖项目会失败（译文）

真搞不懂，一些团队由于某些原因居然认为他们可以建立一个安全数据湖和/或他们自己的大数据安全分析工具。让我来告诉你们会发生什么——失败。

提示一下数据沼泽笑话。想想数据浮渣。讨论一下在数据池里撒尿。结果是一样的——不会成功。

好吧，让我缓和一点来说说——0.1%的人将会成功（即使这种成功只是一定程度上的）。（这个百分比是近似值，不是为了提供数据，意在增加这个“职位”戏剧性的影响。）

为什么我会对此如此坚持呢？在我们的UEBA研究期间，我们遇到了几个正在从DIY/定制安全分析迁移到COTS的组织（通常成熟的做法是迁移到UEBA）。令我们震惊的是，一些组织宣称他们确实曾经有一个运行了几年的定制安全分析项目，但目前已经由于“高投入——低价值”而终止了。更令人震惊的是，一些组织本属于“五十强”选手，大概是全球技术精英。但他们的项目甚至一点用都没有。QotD项目（后被修改为用来移除与客户端任何可能的关系）被认为“我们希望从未发现过Hadoop——我们因试图从中创造安全分析功能而浪费了数年。”

廉价硬件的使用，减少数据冗余（存储一份拷贝——NICE!）以及高级分析的承诺，人们受到这些鼓动并趋之若鹜……然而绝大部分情况都是——大写的“失败”。

失败或相对不那么成功的原因包括：

脏数据——你把东西放进去却不能使用；这是个头号的“失败原因”（一个相关的好故事，《怎样不雇佣你的第一个数据科学家》，https://hackernoon.com/how-not-to-hire-your-first-data-scientist-34f0f56f81ae）

收集数据的麻烦——SIEM供应商由于某个原因花费了十多年来调试他们的收集器……

访问数据的麻烦——数据钻进劣质酒——而且现在已经没有人知道如何把它们弄出来进行分析了（这里有个好故事，《是时候停止使用Hadoop来进行分析了》It's Time to Stop Using Hadoop for Analytics）

没有超越收集的价值——数据湖被创建然后被数据填满，然后它只是摆在那里以防万一（被人说没有？），然而后续的项目进程全都停止了

没有超越关键字搜索的价值——建立数据湖是为了实现高级分析，但最后仅仅提供了基础的日志关键字搜索

没有威胁检测价值——这发生在有人请一家大数据公司建立安全数据湖时，他们建造了所有的管道，并说“啊，安全用例？你自己做吧！”并转身离去

未能概念化以及定义安全分析用例——好了，我们现在将检测威胁了……好吧，如何进行？额，没人知道，也没时间去试验。再回头看看“一号”——脏数据

安全分析用例设计比预想的要难得多

更高的分析门槛和更高的对大数据专业技术人才的需求以及并未能获得那样的人才

（注意有些条目是重叠和/或相关的）

正如我们在这里所说，“考虑到数据湖技术特征的简单性，我们不应认为从这个概念中获得价值完全取决于高级编程的实现和分析技能的可用。”安全起见，你还需要加入威胁分析技能。

实质上，唯一成功的项目类型（然而从长期来看，这并不是真正的安全分析）是“安装ELK，接入日志，搜索关键字”。它工作的不错，但这并不是我们所追求的——差远了。甚至不在同一个领域。

总的来说，成功的定制大数据安全分析产品仍然寥寥无几，就像会飞的汽车。我在2012年的博文中充满希望——但遗憾的是并未奏效。对于这一点，我非常清楚，DIY或开源绝不是进行安全分析的方法。当然，我们会持续关注Spot和Metron，但坦率地说，在这一点上我深怀疑虑。

好，总结一下：开源——基于日志聚合，定制安全分析——只在极少的情形下能够工作的不错。如果你仍然想尝试，请随时查看本文来检验你的想法。

原文链接：Why Your Security Data Lake Project Will FAIL! - Anton Chuvakin 

作者：Anton Chuvakin