近年來態勢感知、威脅情報等等新詞不斷出現， 其實萬變不離其宗， 它們都是利用已知的資料來判斷風險， 甚至預知未發生的威脅。 這如同一個老練的探險者孤身穿行在原始叢林， 他能輕巧自然地避開蛇蟲鼠蟻， 用腳印來預知猛獸的威脅。 這一切都依賴於他那顆善於思考， 經驗豐富的大腦。
在網路安全的原始森林裡， SIEM就扮演這樣一個威脅感知大腦的角色。 如何在合理成本下打造一個最為強大、合適的 SIEM 系統， 是許多安全人員頭疼的問題。 雷鋒網有幸邀請到了擁有十年安全產品經驗的百度安全專家兜哥，
嘉賓簡介
兜哥， 百度安全專家， 具有十年雲安全產品經驗， 主要研究方向為機器學習、僵屍網路、威脅情報、沙箱技術、具有多年企業安全建設經驗， 擁有安全方向相關專利多項；發表多篇安全學術論文。
【百度安全專家-兜哥】
公開課內容整理▼
雷鋒網按
前言
在RSA2017會議上， 應用大資料技術在安全領域， 挖掘深入的攻擊行為依然是一個熱點。
SIEM簡介
市場調研機構IDC預計， 未來全球資料總量年增長率將維持在50%左右， 到2020年， 全球資料總量將達到40ZB。 一個中型互聯網公司一天產生的資料量通常可以超過幾T甚至幾十T。 傳統的盒子形式的安全產品已經沒有能力處理如此大量的資料。
SIEM（security information and event management）， 顧名思義就是針對安全資訊和事件的管理系統。 SIEM通過統一搜集、格式化、存儲、分析企業內部的各類日誌、流量資料， 挖掘攻擊行為。
完整的SIEM至少會包括以下功能：
漏洞管理
資產發現
入侵偵測
行為分析
日誌存儲、檢索
報警管理
酷炫報表
其中最核心的我認為是入侵偵測、行為分析和日誌存儲檢索。
SIEM的發展
對比 Gartner2009 年和 2016年的全球SIEM廠商排名， 可以清楚看出， 基於大資料架構的廠商Splunk迅速崛起， 傳統四強依託完整的安全產品線和成熟市場管道， 依然佔據領導者象限， 其他較小的廠商逐漸離開領導者象限。 最重要的存儲架構也由盤櫃（可選）+商業資料庫逐漸轉變為可橫向擴展的大資料架構， 支援雲環境也成為趨勢。
開源SIEM
常見的開源SIEM主要有 OSSIM 和 OPENSOC， 其中 OPENSOC 完全基於大資料架構， 更適合目前的中大型企業。 OPENSOC 是思科2014年在 BroCon 大會上公佈的開源專案， 但是沒有真正開源其原始程式碼， 只是發佈了其技術框架。 我們參考了 OPENSOC 發佈的架構， 結合公司實際落地了一套方案。
OPENSOC 完全基於開源的大資料框 架kafka、storm、spark 和 es 等， 天生具有強大的橫向擴展能力。 本文重點講解的也是基於 OPENSOC 的 SIEM 搭建， 以及簡單介紹如何使用規則和演算法來發現入侵行為。
SIEM架構
上圖是Opensoc給出的框架， 初次看非常費解， 我們以資料存儲與資料處理兩個緯度來細化， 以常見的 linux 伺服器 ssh 登錄日誌搜集為例。
資料搜集緯度
資料搜集緯度需求是搜集原始資料， 存儲， 提供使用者互動式檢索的UI介面， 典型場景就是出現安全事件後， 通過檢索日誌回溯攻擊行為， 定損。
logtash其實可以直接把資料寫es， 但是考慮到 storm 也要資料處理， 所以把資料切分放到 logstash， 切分後的資料發送 kafka，提供給 storm 處理和 logstash 寫入 es。資料檢索可以直接使用 kibana，非常方便。資料切分也可以在 storm 裡面完成。
這個就是大名鼎鼎的ELK架構。es比較適合存儲較短時間的熱資料的即時檢索查詢，對於需要長期存儲，並且希望使用hadoop或者spark進行大時間跨度的離線分析時，還需要存儲到hdfs上，所以比較常見的資料流程圖為：
資料處理緯度
這裡以資料即時流式處理為例，storm 從 kafka 中訂閱切分過的ssh登錄日誌，匹配檢測規則，檢測結果的寫入 mysql 或者 es。
在這個例子中，孤立看一條登錄日誌難以識別安全問題，最多識別非跳板機登錄，真正運行還需要參考知識庫中的常見登錄IP、時間、IP情報等以及臨時存儲處理狀態的狀態庫中最近該IP的登錄成功與失敗情況。比較接近實際運行情況的流程如下：
具體判斷邏輯舉例如下，實際中使用大量代理IP同時暴力破解，打一槍換一個地方那種無法覆蓋，這裡只是個舉例：
擴展資料來源
生產環境中，處理安全事件，分析入侵行為，只有ssh登錄日誌肯定是不夠，我們需要盡可能多的搜集資料來源，以下作為參考：
linux/window系統安全性記錄檔/操作日誌
web伺服器訪問日誌
資料庫SQL日誌
網路流量日誌
簡化後的系統架構如下,報警也存es主要是查看報警也可以通過kibana，人力不足介面都不用開發了：
訊息佇列：kafka
Kafka是一種高輸送量的分散式發佈訂閱消息系統，有如下特性：
通過O(1)的磁片資料結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。
高輸送量 ：即使是非常普通的硬體Kafka也可以支援每秒數百萬的消息。
支持通過Kafka伺服器和消費機集群來分區消息。
支援Hadoop並行資料載入。
流式處理：storm
Apache Storm 是一個免費開源的分散式即時計算系統。簡化了流資料的可靠處理，像 Hadoop 一樣實現即時批次處理。Storm 很簡單，可用於任意程式設計語言。
Storm 有很多應用場景，包括即時資料分析、連線學習、持續計算、分散式 RPC、ETL 等。Storm 速度非常快，一個測試在單節點上實現每秒一百萬的組處理。
storm拓撲支援python開發，以處理SQL日誌為例子：
假設SQL日誌的格式是
"Feb 16 06:32:50 " "127.0.0.1" "root@localhost" "select * from user where id=1"
一般storm的拓撲結構：
簡化後 spout 是通用的從 kafka 讀取資料的，就一個 bolt 處理 SQL 日誌，匹配規則，命中策略即輸出”alert”:”原始SQL日誌”。
資料搜集：logstash
Logstash是一款羽量級的日誌搜集處理框架，可以方便的把分散的、多樣化的日誌搜集起來，並進行自訂的處理，然後傳輸到指定的位置，比如某個伺服器或者檔。
當然它可以單獨出現，作為日誌收集軟體，你可以收集日誌到多種存儲系統或臨時中轉系統，如MySQL，redis，kakfa，HDFS, lucene，solr等並不一定是ElasticSearch。
logstash的配置量甚至超過了storm的拓撲腳本開發量，這裡就不展開了。
即時檢索：ElasticSearch
ElasticSearch是一個基於Lucene的搜索伺服器。它提供了一個分散式多使用者能力的全文檢索搜尋引擎，基於RESTful web介面。Elasticsearch是用Java開發的，並作為Apache許可條款下的開放源碼發佈，是當前流行的企業級搜尋引擎。設計用於雲計算中，能夠達到即時搜索，穩定，可靠，快速，安裝使用方便。
資料來源
生產環境中，處理安全事件，分析入侵行為，我們需要盡可能多的搜集資料來源，以下作為參考：
資料庫日誌搜集
常見的資料日誌搜集方式有三種：
鏡像方式
大多數資料庫審計產品都支援這種模式，通過分析資料庫流量，解碼資料庫協定，識別SQL預計，抽取出SQL日誌
代理方式
比較典型的就是db-proxy方式，目前百度、搜狐、美團、京東等都有相關開源產品，前端通過db-proxy訪問後端的真實資料庫伺服器。SQL日誌可以直接在db-proxy上搜集。
用戶端方式
通過在資料庫伺服器安裝用戶端搜集SQL日誌，比較典型的方式就是通過logstash來搜集，本文以用戶端方式進行講解，其餘方式本質上也是類似的。
logstash配置安裝
開啟mysql查詢日誌
mysql查詢日誌
配置logstash
運行logstash
命令：bin/logstash -f mysql.conf
日誌舉例
常見攻擊特徵
分析攻擊特徵，下列列舉兩個，更多攻擊特徵請大家自行總結：
特徵一：
使用聯集查詢枚舉資料時會產生大量的NULL欄位。
特徵二：
枚舉資料庫結構時會使用INFORMATION_SCHEMA，另外個別掃描器會使用GROUP BY x)a)
注意的是：
生產環境中的規則會比這複雜很多，需要你不斷補充，這裡只是舉例
單純只編寫map會有大量的重複報警，需要開發reduce用於聚合
應急回應時需要知道SQL注入的是那個庫，使用的是哪個帳戶，這個需要在logstash切割欄位時補充
應急回應時最好可以知道SQL注入對應的連結，這個需要將web的accesslog與SQL日誌關聯分析，比較成熟的方案是基於機器學習，學習出基於時間的關聯矩陣
用戶端直接搜集SQL資料要求mysql也開啟查詢日誌，這個對伺服器性能有較大影響，我知道的大型公司以db-prxoy方式接入為主，建議可以在db-proxy上搜集。
基於規則識別SQL注入存在瓶頸，雖然相對web日誌層面以及流量層面有一定進步，SQL語義成為必然之路。
CASE：後門識別
這裡介紹如何用圖演算法是被webshell。
webshell特徵
webshell特徵其實很多，從統計學角度講，有如下特點：
入度出度均為0
入度出度均為1且自己指向自己
neo4j
neo4j是一個高性能的,NOSQL圖形資料庫，它將結構化資料存儲在網路上而不是表中，因其嵌入式、高性能、羽量級等優勢，越來越受到關注。
導入資料
可生成有向圖如下：
查詢入度為1出度均為0的結點或者查詢入度出度均為1且指向自己的結點，由於把ref為空的情況也識別為"-"結點，所以入度為1出度均為0。
優化點：
生產環境實際使用中，我們遇到誤報分為以下幾種：
主頁，各種index頁面
phpmyadmin、zabbix等運維管理後臺
hadoop、elk等開源軟體的控制台
API介面
這些通過短期加白可以有效解決，比較麻煩的是掃描器對結果的影響，這部分需要通過掃描器指紋或者使用高大上的人機演算法來去掉干擾。
兜哥後記
使用演算法來挖掘未知攻擊行為是目前非常流行的一個研究方向，本文只是介紹了其中比較好理解和實現的一種演算法，該演算法並非我首創，不少安全公司也都或多或少有過實踐。篇幅有限，這裡不再一一講解。演算法或者說機器學習本質是科學規律在大資料集集合上趨勢體現，所以很難做到精准報警，目前階段還是需要通過各種規則和模型來輔助，不過對於挖掘未知攻擊行為確實是一支奇兵。
公開課視頻
課後答疑整理
以下內容為公開課後宅客頻道讀者提問答疑記錄：
1.宅客：自己用開源專案搭建SIEM系統時，容易遇到哪些坑？哪些環節需要額外注意？
兜哥：容易遇到的是性能問題，還有對開源軟體不太熟悉，因為確實我們剛接觸時都是比較新的東西，幫助文檔比較少，容易造成理解上的問題。
其次是攻擊建模，這個很靠經驗，傳統SIEM就是誤報特別多。我們的做法是：先離線訓練規則，誤報可控後直接在storm即時處理，基本最後能做到分鐘級發現。
另外，在流量搜集上挑戰很大，傳統的 libpcap 性能差，基本只能處理幾十兆頻寬，需要使用 pf-ring ，基本可以單機處理 2-6G 頻寬（全量處理）
2.宅客：公司自己人搭建一個SIEM和買商業SIEM產品如何選擇，適用於哪類規模的公司？（考慮實際人力、時間成本和效益）
兜哥：中型（1000人左右的）公司，可以有3個人以上投入時，可以自己搭建 opensoc 這種。如果公司規模小些，只能投入一個人建議用ossim , 每天資料量幾十G的，ossim 可以搞定。
整個搭建成本，時間一般三個月可以搞定，但是規則的積累是個長期過程。我們差不多搞安全這麼多年，一直都在豐富模型和規則，出現漏洞還要及時跟進。
3.在檢索威脅情報這一塊，有什麼特殊的資訊收集手段嗎？
兜哥：Openioc 可以訂閱開源的情報，量已經非常大了。國內的威脅情報廠商比較多，比如微步線上。呃……黑產庫的積累其實比較靠人緣，合法性其實一直是個灰色地帶，你懂得。
4.宅客：威脅情報這塊，百度的人工智慧有什麼應用嗎？
兜哥：應用比較多，比如從雲端的海量資料中，針對一直威脅的樣本 dns 使用聚類等演算法，識別潛在的有關聯的，未知的樣本 dns。
通過安全運營中心的人工識別，挖掘未知攻擊行為，然後以可機讀的方式推送給我們的 WAF、ADS、IDS , AI 一大應用就是從已知樣本以及海量資料中挖掘未知，這個演算法應用很多。
4.宅客：neo4j 將結構化資料存儲在網路上，資料量打了會不會搞不定？
兜哥：會的，這裡（公開課直播）只是演示，可以用 sparkx，而且 neo4j 也有集群方案，不過問題其實還好，因為我們是動態請求去重，抽象後才入庫，量其實不大，1T資料量入庫可能不到100M。
5.宅客：能不能提供一些SIEM具體應用場景，資料分析模型，或者推薦一下在那裡獲得？
分析webshell 用有向圖效果不錯，其他web攻擊，尤其是攻擊載荷在請求參數裡面的用隱式瑪律可夫可以。
6.宅客：網路設備的設備接入的資料價值大嗎？有必要接嗎？
兜哥：網路設備系統日誌可以監控對網路設備的暴力破解、違規操作等，netflow可以輔助判斷蠕蟲、ddos等。
8.宅客：網路入侵偵測（ network instusion detection ) ,你們有啥好演算法？
兜哥：關聯演算法 apriori 圖演算法、異常分析演算法比如hmm 隱式瑪律可夫。
切分後的資料發送 kafka，提供給 storm 處理和 logstash 寫入 es。資料檢索可以直接使用 kibana，非常方便。資料切分也可以在 storm 裡面完成。
這個就是大名鼎鼎的ELK架構。es比較適合存儲較短時間的熱資料的即時檢索查詢，對於需要長期存儲，並且希望使用hadoop或者spark進行大時間跨度的離線分析時，還需要存儲到hdfs上，所以比較常見的資料流程圖為：
資料處理緯度
這裡以資料即時流式處理為例，storm 從 kafka 中訂閱切分過的ssh登錄日誌，匹配檢測規則，檢測結果的寫入 mysql 或者 es。
在這個例子中，孤立看一條登錄日誌難以識別安全問題，最多識別非跳板機登錄，真正運行還需要參考知識庫中的常見登錄IP、時間、IP情報等以及臨時存儲處理狀態的狀態庫中最近該IP的登錄成功與失敗情況。比較接近實際運行情況的流程如下：
具體判斷邏輯舉例如下，實際中使用大量代理IP同時暴力破解，打一槍換一個地方那種無法覆蓋，這裡只是個舉例：
擴展資料來源
生產環境中，處理安全事件，分析入侵行為，只有ssh登錄日誌肯定是不夠，我們需要盡可能多的搜集資料來源，以下作為參考：
linux/window系統安全性記錄檔/操作日誌
web伺服器訪問日誌
資料庫SQL日誌
網路流量日誌
簡化後的系統架構如下,報警也存es主要是查看報警也可以通過kibana，人力不足介面都不用開發了：
訊息佇列：kafka
Kafka是一種高輸送量的分散式發佈訂閱消息系統，有如下特性：
通過O(1)的磁片資料結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。
高輸送量 ：即使是非常普通的硬體Kafka也可以支援每秒數百萬的消息。
支持通過Kafka伺服器和消費機集群來分區消息。
支援Hadoop並行資料載入。
流式處理：storm
Apache Storm 是一個免費開源的分散式即時計算系統。簡化了流資料的可靠處理，像 Hadoop 一樣實現即時批次處理。Storm 很簡單，可用於任意程式設計語言。
Storm 有很多應用場景，包括即時資料分析、連線學習、持續計算、分散式 RPC、ETL 等。Storm 速度非常快，一個測試在單節點上實現每秒一百萬的組處理。
storm拓撲支援python開發，以處理SQL日誌為例子：
假設SQL日誌的格式是
"Feb 16 06:32:50 " "127.0.0.1" "root@localhost" "select * from user where id=1"
一般storm的拓撲結構：
簡化後 spout 是通用的從 kafka 讀取資料的，就一個 bolt 處理 SQL 日誌，匹配規則，命中策略即輸出”alert”:”原始SQL日誌”。
資料搜集：logstash
Logstash是一款羽量級的日誌搜集處理框架，可以方便的把分散的、多樣化的日誌搜集起來，並進行自訂的處理，然後傳輸到指定的位置，比如某個伺服器或者檔。
當然它可以單獨出現，作為日誌收集軟體，你可以收集日誌到多種存儲系統或臨時中轉系統，如MySQL，redis，kakfa，HDFS, lucene，solr等並不一定是ElasticSearch。
logstash的配置量甚至超過了storm的拓撲腳本開發量，這裡就不展開了。
即時檢索：ElasticSearch
ElasticSearch是一個基於Lucene的搜索伺服器。它提供了一個分散式多使用者能力的全文檢索搜尋引擎，基於RESTful web介面。Elasticsearch是用Java開發的，並作為Apache許可條款下的開放源碼發佈，是當前流行的企業級搜尋引擎。設計用於雲計算中，能夠達到即時搜索，穩定，可靠，快速，安裝使用方便。
資料來源
生產環境中，處理安全事件，分析入侵行為，我們需要盡可能多的搜集資料來源，以下作為參考：
資料庫日誌搜集
常見的資料日誌搜集方式有三種：
鏡像方式
大多數資料庫審計產品都支援這種模式，通過分析資料庫流量，解碼資料庫協定，識別SQL預計，抽取出SQL日誌
代理方式
比較典型的就是db-proxy方式，目前百度、搜狐、美團、京東等都有相關開源產品，前端通過db-proxy訪問後端的真實資料庫伺服器。SQL日誌可以直接在db-proxy上搜集。
用戶端方式
通過在資料庫伺服器安裝用戶端搜集SQL日誌，比較典型的方式就是通過logstash來搜集，本文以用戶端方式進行講解，其餘方式本質上也是類似的。
logstash配置安裝
開啟mysql查詢日誌
mysql查詢日誌
配置logstash
運行logstash
命令：bin/logstash -f mysql.conf
日誌舉例
常見攻擊特徵
分析攻擊特徵，下列列舉兩個，更多攻擊特徵請大家自行總結：
特徵一：
使用聯集查詢枚舉資料時會產生大量的NULL欄位。
特徵二：
枚舉資料庫結構時會使用INFORMATION_SCHEMA，另外個別掃描器會使用GROUP BY x)a)
注意的是：
生產環境中的規則會比這複雜很多，需要你不斷補充，這裡只是舉例
單純只編寫map會有大量的重複報警，需要開發reduce用於聚合
應急回應時需要知道SQL注入的是那個庫，使用的是哪個帳戶，這個需要在logstash切割欄位時補充
應急回應時最好可以知道SQL注入對應的連結，這個需要將web的accesslog與SQL日誌關聯分析，比較成熟的方案是基於機器學習，學習出基於時間的關聯矩陣
用戶端直接搜集SQL資料要求mysql也開啟查詢日誌，這個對伺服器性能有較大影響，我知道的大型公司以db-prxoy方式接入為主，建議可以在db-proxy上搜集。
基於規則識別SQL注入存在瓶頸，雖然相對web日誌層面以及流量層面有一定進步，SQL語義成為必然之路。
CASE：後門識別
這裡介紹如何用圖演算法是被webshell。
webshell特徵
webshell特徵其實很多，從統計學角度講，有如下特點：
入度出度均為0
入度出度均為1且自己指向自己
neo4j
neo4j是一個高性能的,NOSQL圖形資料庫，它將結構化資料存儲在網路上而不是表中，因其嵌入式、高性能、羽量級等優勢，越來越受到關注。
導入資料
可生成有向圖如下：
查詢入度為1出度均為0的結點或者查詢入度出度均為1且指向自己的結點，由於把ref為空的情況也識別為"-"結點，所以入度為1出度均為0。
優化點：
生產環境實際使用中，我們遇到誤報分為以下幾種：
主頁，各種index頁面
phpmyadmin、zabbix等運維管理後臺
hadoop、elk等開源軟體的控制台
API介面
這些通過短期加白可以有效解決，比較麻煩的是掃描器對結果的影響，這部分需要通過掃描器指紋或者使用高大上的人機演算法來去掉干擾。
兜哥後記
使用演算法來挖掘未知攻擊行為是目前非常流行的一個研究方向，本文只是介紹了其中比較好理解和實現的一種演算法，該演算法並非我首創，不少安全公司也都或多或少有過實踐。篇幅有限，這裡不再一一講解。演算法或者說機器學習本質是科學規律在大資料集集合上趨勢體現，所以很難做到精准報警，目前階段還是需要通過各種規則和模型來輔助，不過對於挖掘未知攻擊行為確實是一支奇兵。
公開課視頻
課後答疑整理
以下內容為公開課後宅客頻道讀者提問答疑記錄：
1.宅客：自己用開源專案搭建SIEM系統時，容易遇到哪些坑？哪些環節需要額外注意？
兜哥：容易遇到的是性能問題，還有對開源軟體不太熟悉，因為確實我們剛接觸時都是比較新的東西，幫助文檔比較少，容易造成理解上的問題。
其次是攻擊建模，這個很靠經驗，傳統SIEM就是誤報特別多。我們的做法是：先離線訓練規則，誤報可控後直接在storm即時處理，基本最後能做到分鐘級發現。
另外，在流量搜集上挑戰很大，傳統的 libpcap 性能差，基本只能處理幾十兆頻寬，需要使用 pf-ring ，基本可以單機處理 2-6G 頻寬（全量處理）
2.宅客：公司自己人搭建一個SIEM和買商業SIEM產品如何選擇，適用於哪類規模的公司？（考慮實際人力、時間成本和效益）
兜哥：中型（1000人左右的）公司，可以有3個人以上投入時，可以自己搭建 opensoc 這種。如果公司規模小些，只能投入一個人建議用ossim , 每天資料量幾十G的，ossim 可以搞定。
整個搭建成本，時間一般三個月可以搞定，但是規則的積累是個長期過程。我們差不多搞安全這麼多年，一直都在豐富模型和規則，出現漏洞還要及時跟進。
3.在檢索威脅情報這一塊，有什麼特殊的資訊收集手段嗎？
兜哥：Openioc 可以訂閱開源的情報，量已經非常大了。國內的威脅情報廠商比較多，比如微步線上。呃……黑產庫的積累其實比較靠人緣，合法性其實一直是個灰色地帶，你懂得。
4.宅客：威脅情報這塊，百度的人工智慧有什麼應用嗎？
兜哥：應用比較多，比如從雲端的海量資料中，針對一直威脅的樣本 dns 使用聚類等演算法，識別潛在的有關聯的，未知的樣本 dns。
通過安全運營中心的人工識別，挖掘未知攻擊行為，然後以可機讀的方式推送給我們的 WAF、ADS、IDS , AI 一大應用就是從已知樣本以及海量資料中挖掘未知，這個演算法應用很多。
4.宅客：neo4j 將結構化資料存儲在網路上，資料量打了會不會搞不定？
兜哥：會的，這裡（公開課直播）只是演示，可以用 sparkx，而且 neo4j 也有集群方案，不過問題其實還好，因為我們是動態請求去重，抽象後才入庫，量其實不大，1T資料量入庫可能不到100M。
5.宅客：能不能提供一些SIEM具體應用場景，資料分析模型，或者推薦一下在那裡獲得？
分析webshell 用有向圖效果不錯，其他web攻擊，尤其是攻擊載荷在請求參數裡面的用隱式瑪律可夫可以。
6.宅客：網路設備的設備接入的資料價值大嗎？有必要接嗎？
兜哥：網路設備系統日誌可以監控對網路設備的暴力破解、違規操作等，netflow可以輔助判斷蠕蟲、ddos等。
8.宅客：網路入侵偵測（ network instusion detection ) ,你們有啥好演算法？
兜哥：關聯演算法 apriori 圖演算法、異常分析演算法比如hmm 隱式瑪律可夫。