本文將簡單介紹基于圖的入侵檢測系統(tǒng)，拋磚引玉，期望能有更多優(yōu)秀人才參與挖掘圖與安全的結(jié)合應(yīng)用。

入侵檢測的現(xiàn)狀與挑戰(zhàn)

主流入侵檢測系統(tǒng)

入侵檢測一直是安全研究的一大方向，青藤的萬相和蜂巢兩套產(chǎn)品分別為基于主機(jī)和容器的主機(jī)入侵檢測產(chǎn)品，它們的原理都類似，如下圖。

Agent 埋在主機(jī)/容器側(cè)，接收服務(wù)端下發(fā)的規(guī)則結(jié)合采集的原始事件（進(jìn)程/網(wǎng)絡(luò)連接/文件讀寫等），通過安全專家編寫規(guī)則，比如：進(jìn)程文件 MD5/文件 MD5/執(zhí)行命令行/機(jī)器學(xué)習(xí)等特征，命中當(dāng)做告警報出來，相關(guān)告警上報到服務(wù)端；另外全量的原始事件也上報給服務(wù)端日志收集系統(tǒng)，入庫保存到 SIEM 系統(tǒng)。

這套系統(tǒng)一旦告警上報到服務(wù)端，安全人員會拿當(dāng)前告警相關(guān)信息到 SIEM 中查詢告警發(fā)生時刻前后相關(guān)的事件，必要時登錄相關(guān)機(jī)器查看相關(guān)信息，綜合判斷當(dāng)前攻擊告警是否有效并做相關(guān)處置。

這套系統(tǒng)是當(dāng)前入侵檢測的主流架構(gòu)，但是也存在諸多問題：

1. 基于單事件+規(guī)則做單點檢測，可能造成大量誤報（規(guī)則太松）或漏報（規(guī)則太嚴(yán)）
2. 同一次攻擊觸發(fā)的告警可能過多，安全分析人員分析溯源工作量巨大
3. 同一次告警相關(guān)原始事件需要借助 SIEM 人工分析，缺乏可視化手段

圖與安全研究方向

其實，可以看到這里的幾個問題點本質(zhì)上都是獨立去看待每個告警和事件，實際上一次攻擊相關(guān)的告警/事件應(yīng)該是彼此關(guān)聯(lián)的，這里很自然想到用圖去把這些原始事件/告警關(guān)聯(lián)起來整體分析。事實上，這也是當(dāng)前安全研究的一個熱門方向——溯源圖，借助溯源圖我們做如下多方面的安全分析和檢測：

1.圖檢測

傳統(tǒng)安全解決的類似 IOC 檢測，也就是單點判斷，針對進(jìn)程/網(wǎng)絡(luò)連接/文件等實體判斷是不是安全的；實際攻擊面臨的問題，可能各個點都檢測不出來，但實際行為是危險的——1 個規(guī)則寫不全，就算規(guī)則能寫出來，比如命中某個命令行，但是觸發(fā)告警很多，最終也無法應(yīng)用。也就是要綜合判斷各種組合關(guān)系，這是圖擅長的事情，也就是安全中圖檢測的問題——把所有相關(guān)的事件放在一張圖中來綜合判斷分析是否為有效攻擊。

圖檢測研究很早，但是面臨計算量和算法的雙重挑戰(zhàn)，目前行業(yè)應(yīng)用很少，基本上組合判斷都還是序列檢測方式。問題是序列規(guī)則能寫多少確定規(guī)則，規(guī)則太多也有問題，無法應(yīng)用；剛才提到確定規(guī)則，無法很好模糊匹配，也就是挖掘，安全中規(guī)則太確定就可以被繞過，黑客很聰明且借助自動化攻擊更容易繞過這些規(guī)則。

2.圖關(guān)聯(lián)和溯源

剛才提到告警，也就是當(dāng)前所有安全產(chǎn)品面臨的另一個問題——要不是規(guī)則命中不了，要不就是規(guī)則命中太多，我們叫告警淹沒，安全運營處理能力有限，可能一天 100 個告警還好，如果一天甚至一小時 10000 條告警就沒法處理了，那和沒告警沒差別。

這其實是一個安全中關(guān)聯(lián)分類和溯源的問題：

1. 一次攻擊會產(chǎn)生很多告警，比如：暴力破解登錄，用了惡意文件，執(zhí)行了惡意命令等等，關(guān)聯(lián)分類把一次攻擊中相關(guān)的告警關(guān)聯(lián)在一起，這是圖擅長的事情。這些告警關(guān)聯(lián)在一起，還可以綜合評判也就是多個告警聯(lián)合判斷當(dāng)前攻擊是否有效；
2. 每個告警只會告訴你當(dāng)前你是進(jìn)程、文件、網(wǎng)絡(luò)有問題，那這個問題是如何發(fā)生的，黑客是怎么進(jìn)來的，文件是從哪里下載的，先干了什么后干了什么。安全產(chǎn)品需要幫助客戶完成這個分析過程，目前行業(yè)是借助 SIEM/THP/SOC 等安全產(chǎn)品，所有原始事件都上傳保存，找安全專家，從告警開始查原始事件日志，看告警前發(fā)生了什么，哪些有關(guān)系可能導(dǎo)致攻擊，這個過程短則幾分鐘，長甚至數(shù)個小時。安全是個對抗過程，早就是優(yōu)——越早發(fā)現(xiàn)越早對抗，封禁或隔離，否則就算發(fā)現(xiàn)也為時過晚?？梢园严嚓P(guān)的原始事件實體（進(jìn)程/網(wǎng)絡(luò)等）入圖，借助圖可以可視化探索和溯源整個攻擊過程，這就是圖溯源的過程，學(xué)術(shù)叫因果圖、溯源圖。

3.圖知識圖譜和預(yù)測

我們知道當(dāng)前安全從根本上講還是基于規(guī)則或者說先驗知識，每種漏洞/木馬/攻擊工具/攻擊過程/攻擊組織都有它的特征，前幾種規(guī)則還比較好描述，攻擊過程、攻擊組織等就很難完整描述了。

目前的主流做法是基于安全框架構(gòu)建知識庫，當(dāng)前主流有 Kill Chain/ATT&CK 等框架，這是美國國防部主導(dǎo)的網(wǎng)絡(luò)攻擊戰(zhàn)爭相關(guān)兩家公司提出的安全分析框架，相當(dāng)于劃分了攻擊的戰(zhàn)術(shù)和具體攻擊技術(shù)的映射，這個具體如何實施比較難。安全學(xué)術(shù)界，比如：伊利諾伊大學(xué)/普渡大學(xué)近兩年都在研究類似問題，也就是安全知識庫（安全知識圖譜）的構(gòu)建。有了這個完善的知識庫，就可以完成安全的終極設(shè)想，比如：我知道你的攻擊過程/攻擊組織，是不是就可以在攻擊真正開始前，好比你打仗剛拿起槍沖到陣地上，判斷你是要朝我開槍，預(yù)判直接擊斃。

國內(nèi)外現(xiàn)狀

目前基于圖的入侵檢測系統(tǒng)，真正率先投入到實戰(zhàn)中的是美國的安全明星公司——Crowd Strike，它完全基于圖構(gòu)建安全系統(tǒng)，現(xiàn)在相當(dāng)于做了圖檢測和圖關(guān)聯(lián)溯源這兩塊的事情，目前估值 670 億美元。云計算巨頭 AWS 和 Azure 都在跟進(jìn)它的方法。國內(nèi)基于圖做入侵檢測系統(tǒng)的，目前有公開資料的是微步在線和深信服，他們相當(dāng)于做了部分圖關(guān)聯(lián)和溯源的工作。

青藤云安全的萬相和蜂巢在入侵檢測深耕多年，已經(jīng)取得了行業(yè)認(rèn)可的安全檢測能力，所以選擇從圖關(guān)聯(lián)和溯源入手，基于 NebulaGraph 結(jié)合圖技術(shù)開發(fā)的下一代實時入侵檢測系統(tǒng)，先重點解決告警淹沒和關(guān)聯(lián)溯源的痛點問題。

青藤云安全下一代入侵檢測系統(tǒng)

檢測原理架構(gòu)圖

如下，核心是上報的攻擊告警和部分原始事件統(tǒng)一在圖中實時關(guān)聯(lián)。

產(chǎn)品效果

經(jīng)過關(guān)聯(lián)引擎關(guān)聯(lián)處理輸出的就是攻擊事件，一個攻擊事件可能關(guān)聯(lián)多個攻擊告警并可視化呈現(xiàn)出來，當(dāng)前產(chǎn)品效果圖如下：

同一次攻擊利用惡意文件和木馬

敏感容器掛載

自定義腳本檢測

NebulaGraph 的優(yōu)勢

選擇 NebulaGraph 主要基于如下考慮：

1. 圖查詢的剛需，特別是關(guān)聯(lián)和溯源時多級進(jìn)程關(guān)系查詢，借助 Cypher查詢圖數(shù)據(jù)庫能夠比借助 SQL 在關(guān)系數(shù)據(jù)庫中查詢多級關(guān)系容易多；
2. 大規(guī)模存儲，涉及到大量事件和告警的存儲；
3. 高性能查詢場景需求，關(guān)聯(lián)需要保證近實時，當(dāng)前相關(guān)查詢都在 ms 級別；

得益于 NebulaGraph 的良好性能，關(guān)聯(lián)引擎以近實時的方式入圖和計算關(guān)聯(lián)，入圖部分是青藤自己基于 Flink 打造的實時入圖組件，只需要更改配置文件即可完成圖點邊映射入圖。

下一步研究方向和計劃

當(dāng)前青藤云安全新入侵檢測主要支持單機(jī)和部分多機(jī)場景的關(guān)聯(lián)和溯源，下一步重點是借助圖支持更多多機(jī)關(guān)聯(lián)的場景，特別是一些典型的安全攻擊場景（反彈/橫移），進(jìn)一步以圖賦能安全，為客戶提供更好的服務(wù)。

當(dāng)然，當(dāng)前在將 NebulaGraph 應(yīng)用到圖安全應(yīng)用過程中，也遇到了很多問題，提一些建議供參考。

1.下推優(yōu)化

在開發(fā)過程中，極關(guān)心查詢效率問題。我們在使用過程中，最大的問題就是下推優(yōu)化，比如一顆發(fā)散的進(jìn)程樹，同時指定根節(jié)點和葉子節(jié)點，語句書寫順序不同就可能導(dǎo)致查詢從葉子節(jié)點開始還是根節(jié)點開始，查詢效率千差萬別，最后不得不只指定葉子節(jié)點條件強(qiáng)制從葉子節(jié)點開始查。

MATCH 性能本質(zhì)上也是下推優(yōu)化問題，這個問題遇到也很多，目前我們的做法是對于部分已經(jīng)查詢過語句維持一個緩存池，也注意到官方企業(yè)版其實提供了部分緩存功能，這個點要是能考慮加到社區(qū)版就好了，是一個實際應(yīng)用剛需。

2.實時場景一些技術(shù)需求點

因為我們是基于 NebulaGraph 做實時關(guān)聯(lián)，一個較大的問題是如何實現(xiàn)一致性和速度的平衡——因為目前 NebulaGraph 實現(xiàn)的是最終一致性，寫入圖后其實是不知道到底是否真實入圖完成。在實際應(yīng)用中，關(guān)聯(lián)引擎需要在下游輪詢等待判斷當(dāng)前的點邊是否真正的入圖完成。這個對于實際使用和性能都會造成一定影響，是否有更好的方式值得思考。

另一塊其實還是效率相關(guān)的問題，我們可以看到一些競品 TigerGraph/TuGraph 都提供了自定義匹配/遍歷算法和能力，比如：在我們多機(jī)關(guān)聯(lián)場景中就遇到這種需求，目前只能通過拆分多條路徑然后拼接起來的實現(xiàn)方式，效率和速度無疑是打折扣的。

3.TOB 部署

另一個，感受較深的是 NebulaGraph 對 TOB 部署的痛點。安全這個行業(yè)，目前國內(nèi)還是走現(xiàn)場部署的較多，特別是國企和政務(wù)相關(guān)對上 SaaS 相對敏感，那么面臨的問題就是效率和成本的問題——

第一個是單機(jī)部署，默認(rèn)生產(chǎn)版本是為云設(shè)計的存算分離分布式部署方式，對于 TOB 部署還是太繁瑣，且資源占用相對也較其他數(shù)據(jù)庫多。

第二個是 HDD 部署，成本考慮，很多公司特別中小公司安全預(yù)算有限，很難提供 SSD 環(huán)境，更別說官網(wǎng)要求的大容量 SSD 高配置機(jī)器，也就是針對 HDD 和低配機(jī)器的優(yōu)化上需要考慮更多。

以上，為青藤云安全團(tuán)隊工程師文洲帶來的分享。