基于大數據的安全分析在國內已經火了一段時間，不同行業都在這方面有不少的投入，自建的大數據安全平臺項目也屢見不鮮。具體有多少會如Gartner的分析師Anton Chuvakin認為的那樣，大概率歸于失敗(Why Your Security Data Lake Project Will FAIL：

http://blogs.gartner.com/anton-chuvakin/2017/04/11/why-your-security-data-lake-project-will-fail/ )，這是我們無法知道的。但是否有一條穩妥、堅實的路徑可以到達目標，也許更值得討論。

需要思考的問題

在曾經由被動防御主導的建設階段里，企業采購了很多防御性安全產品(FW、IPS、WAF、漏洞掃描等)，其目的更多的是防御或加固自身。威脅態勢的發展告訴企業，當前已經不能一味的停留在這個階段。持續投資在防御上，不斷加高水桶的木板高度并不是最經濟、最有效的策略，蓄意的攻擊者總是能夠發現新的攻擊面，進入到企業內部。如何能夠盡早的發現這種有效滲透攻擊，進行響應分析、及時處理并進一步有針對性的彌補防御的短板，這些將成為組織面對的新目標。此時大家注意到大數據這顆冉冉上升的新星，就把希望寄托在這上面。不可否認，數據驅動確實是新時期安全建設的一個關鍵因素，但我們也需要認識到，這種從單純防御向防御、檢測、響應、預防全周期轉變的過程，涉及到數據、工具和使用工具的人三方面的提升，是個相對復雜的系統工程。必須理清幾方面的問題：

• 要監控的關鍵威脅是什么?
• 涉及的分析方法有哪些、這些分析方法又需要哪些數據?
• 需要什么樣的平臺系統來支持分析工作，平臺選擇的關鍵能力指標有哪些?
• 現有技術能力下建立起的平臺，適合怎樣的人來使用，是否已經具備這樣的人員，是否能夠·購買相應的安全服務?
• 采集數據和人員水平受限情況下，如何選擇切實的目標保障有實際的效果?

在實際工作中，對這幾方面的認識往往需要一個實踐摸索的過程，難以做到一步到位，就如Facebook就在數據平臺上有過不斷的摸索過程(It’s Time to Stop Using Hadoop for Analytics：https://www.interana.com/blog/stop-using-hadoop-analytics/ )。因此分階段實施，由易到難也許是一個更好的方式。下面介紹可能涉及到的幾個階段，在實際工作中也許可以多個階段并行，但應該很難出現跳躍式的發展。

IOC情報階段

質量優秀的IOC情報(也稱失陷主機檢測情報)具有及時、全面、精準、具備相關性且提供指導響應活動的上下文這些特點。利用這類情報我們能夠盡早地檢測內部的失陷主機(無論來自情報機關、網絡犯罪團伙或者網絡恐怖主義團體)，并且基于情報的上下文(攻擊團伙、惡意類型、目的、危害等)確定合理的優先級，及時的給予響應處置。

利用這種失陷IOC進行檢測發現，對組織的數據采集要求較低(一般就是HTTP 代理日志、DNS日志或者較完整的流量日志);而一旦發現失陷主機，利用情報信息可以較容易的進行優先級排序、響應方案選擇等工作(情報的上下文會清楚地告訴安全響應人員，這是一個針對個人用戶的網銀木馬，或者是一個具有定向性質的竊密木馬，又或者只是一個黑客用來進行DDoS攻擊的僵尸網絡)，因此它對于大多數組織而言，是一個相對容易而又實實在在的進步。

利用成熟安全分析解決方案

利用IOC情報能力建設階段，可以在數據積累、安全響應分析方面積累一定的能力，獲得相應的經驗，再進一步就向前深入，就是利用較好的產品或解決方案來實現一些典型場景下的安全分析工作，這樣做的好處是聚焦問題的解決、有機會學習到業界成熟的經驗并且免于將自己陷入到工程開發細節的泥潭中。

這里面講的較好，有兩個層次：

• 內置典型的分析場景：每個場景需要包括怎樣發現線索、怎樣排查確認、如何確定攻擊范圍和性質這些基本的步驟，簡單的說它就是將資深分析師的工作經驗集成到了產品當中，使安全運維人員在產品的引導下可以逐步學習、探索安全分析的世界。

• 進一步提供基于線索的優先級排序：線索不是真正的攻擊事件，線索排查中會有一些對于組織的環境而言是不需要特別注意的，因此如果能基于一定的方式(規則組合、ML、貝葉斯算法)對不同線索出現后，標識出線索聚合的風險程度，這對于分析人員無疑是非常有價值的。可以直接聚焦到高危報警。

這兩個層面可以說對應這安全分析的兩代產品，第一代中的典型代表是Splunk的企業安全應用，而第二代則是Exabeam這樣的UEBA產品(之前介紹UEBA的一篇文章 [淺析UEBA]：http://www.jianshu.com/p/a8b5e1c31f59 )。組織基于自身關注的問題、數據能力以及人員水平，從某幾個典型威脅場景出發，選擇適合并有強擴展性的產品，就可以進行建立初步的平臺了。需考慮的是，解決某些問題的數據源，也許不是短時間就能采集到的，比如內部沒有很成熟的出差審批流程和電子流，就難以將差旅信息作為UEBA的一個分析數據源，但成熟的產品會考慮這種情況下如何檢測和判定風險級別。

利用運營級威脅情報階段

安全是一個動態的過程，即使在采購階段選擇了較好的產品，但是針對新的攻擊方式我們還是需要建立新的分析場景，同時也包括一些關鍵威脅暫時沒有現成的分析場景可以覆蓋，也需要擴展分析場景。這個過程就需要建立從運營級威脅情報(威脅相關的技術、方法、過程的情報)到分析數據以及分析方法的映射。舉一個簡單的例子：在2014年以前，可能很少有人會考慮分析Powershell日志的情況，并且也是Powershell 5.0才引入了增強日志功能，早期版本沒有太多的日志能力。

因此在平臺選型階段，需要考量產品/方案的開放性與可擴展性，同時也需要考慮建立自身的運營級情報收集能力。對比IOC情報，運營層面的威脅情報，現階段市場上并沒有足夠成熟的產品生態圈。如何及時獲取到有效的運營級情報，如行業分享、國家層面的通報共享或商業來源，是這個階段的一個重點。而數據和工具方面應該不再成為這個階段的重要挑戰。

自動化階段

在整個安全分析平臺運營過程中，會發現其中很多工作是高度一致的重復勞動，這種工作如何能夠自動化進行，就是這個階段考慮的事情。這里面就包括更智能的事件調查，以及自動化的遏制(個人認為不是清除)。到了這個數據、檢測能力、ML能力都比較成熟的階段，我們也許可以將一個攻擊可能的攻擊鏈、影響范圍通過自動化方式給出大致的范圍，極大縮短分析人員的工作強度。也有可能基于成熟的處置流程，明確地知道哪類事件可以通過自動化配置網絡和終端設備，達到自動化遏制的目的。這樣可以讓安全運營人員從既有的、缺乏挑戰的工作中釋放出來。這個階段可以使重要安全事件的響應時間和質量有巨大的提升。

小結

大數據安全分析能力建設是一個分階段、逐步提升的過程，對于一些有實力的組織可以同時進行多個階段的建設，但如果想一步到位無疑是不現實的。整個過程最關鍵的是問題思維：現階段要解決的問題是什么，深入思考這個問題才能設立合理的階段性目標。威脅情報作為一條主線貫穿建設過程中，如果說數據是安全分析的基礎，那么情報則是它的靈魂。