為什麽你的安全數據湖項目會失敗
真搞不懂，一些團隊由於某些原因居然認為他們可以建立一個安全數據湖和/或他們自己的大數據安全分析工具。讓我來告訴你們會發生什麽——失敗。
提示一下數據沼澤笑話。想想數據浮渣。討論一下在數據池裏撒尿。結果是一樣的——不會成功。
好吧，讓我緩和一點來說說——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
本文出自 “川流不西” 博客，請務必保留此出處http://chuanflow.blog.51cto.com/12426207/1934680
為什麽你的安全數據湖項目會失敗