從EDR到威脅情報運營——淺談終端化的情報部署

來自專欄關於二進位和查戶口的那些不得不說的事兒12 人贊了文章

0x00 前言

emmm，一個多月沒更新專欄了，主要原因是因為工作太忙了（在乙方舒服慣了到了甲方真的有些不適應）。由於工作的原因，目前在威脅情報的投入時間基本上也就投入了20%，剩下的時間都砸給了一件之前想都不敢想的難度的事兒上。boss說讓搞安全得向全地球最牛逼的互聯網公司Google看齊，於是乎20%的就放在這了。

0x01 站在風口上的豬——EDR

今年如果關注了RSAC2018的話，相信你一定觀察到了EDR是名副其實的站在風口上的豬，實際上從2017年開始，無論是國內還是國外，各家安全廠商都在鼓吹EDR的重要性。所謂的EDR就是終端檢測與響應的縮寫（Endpoint Detection and Response），也就是關注與終端，保證終端的安全。那麼威脅情報作為一項安全技術（而非數據），是不是也會跟站在風口上的豬一樣終端化呢？有人肯定會說，你娃又在這裡瞎扯淡了，威脅情報不就是一堆數據么，怎麼處理這些數據和數據源才是重點，且不說放到終端上有沒有用，就問你打算髮什麼放到終端上就是個很大的問題，所以終端化對於威脅情報就是扯淡，數據才是王道懂么？！那麼威脅情報就真的不能終端化了么？

0x02 威脅情報與EDR——Alienvault Endpoint Threat Hunter

實際上在今年年初的時候，筆者最看好的威脅情報平台之一Alienvault OTX就已經上線了Endpoint Threat Intelligence的產品，名為Endpoint Threat Hunter，入口：AlienVault - Open Threat Exchange，這個產品的產品邏輯很簡單：

1. 首先你先要註冊一個OTX賬號（廢話）
2. 在你的伺服器上安裝Alienvault的Agent
3. 部署完了之後在控制台上啟動Agent然後進行預查詢
4. 等結果吧

在這裡就可以使用rpm/deb/msi安裝agent（實際上是基於OSQuery開發的），識別的方式為你的API_KEY。通過他們的描述我們大概就知道了，Alienvault的這個產品就是為了給匹配IOC，然後在終端上直接完成了檢測，這樣的話就完成了威脅情報的終端化。Agent將會收集設備數據並存儲在OTX中，包括計算機名稱，主機名稱，外部IP，操作系統類型和版本。掃描返回其他數據，這些數據完全顯示在「掃描結果」視圖中。 這可能包括文件路徑，IP地址和埠（源和目標），正在運行的進程的命令行，進程ID，進程工作目錄，系統文件（SHA-1，SHA-256，MD5）上的文件散列。

Alienvault這樣做的原因我大概推測了一下，可能是受到EDR思路和威脅情報生命周期的特性的影響，下一部分我們將討論威脅情報的生命周期和運營。

0x03 威脅情報的生命周期和運營

上面說了這麼多，就目前看來，絕大多數人搞威脅情報乾的實際上就是一件事情——收集信息，這樣的話就變成了：我們有威脅情報平台，我們關注了全球所有的N多安全信息源，關注了oss-security，關注了各種漏洞平台的漏洞情報，我們數據全球No.1。但是實際上這麼做的話犯了一個很嚴重的誤區，首先在企業安全裡面任何的安全措施都必須要閉環（這是我boss說的，雖然我認為他說的沒錯），只有措施閉環了，才能談運營，所以在安全運營環節比如漏洞響應跟進修復都是標準的workflow和生命周期的。所以威脅情報也是有生命周期的，那麼威脅情報的生命周期是什麼樣的呢，我用一句話概括：一個中心，五個階段。具體的話先上圖：

左邊待會兒在解釋，先看右邊。右邊這個model實際上就是威脅情報的生命周期，大概來簡述一下吧：

1. 制定情報計劃，確定我們需要交付何種類型的情報
2. 按照情報計劃，收集我們需要情報數據和原始數據
3. 對原始情報信息進行預處理和應用場景分析，確定適用的範圍和目標
4. 按照情報計劃，分析與處理之後的數據，生產最終的情報（也就是所謂的FINTEL）
5. 輸送FINTEL至客戶（也就是安全運營團隊）並使用情報
6. 情報有效期結束，重新制定或修正現有的情報計劃，進入下一個循環

所以威脅情報按照生命周期的話，核心應該是制定計劃，然後完成收集、處理、分析生產、輸送、完善修正現有情報計劃的一個流程，這個也就是所謂威脅情報運營閉環。

好，現在說了那麼多，我們再來強調另一個點：威脅情報的落地是case驅動而非是數據驅動的，所謂的case就是威脅情報的模型（比如攻擊者的攻擊套路）。如果你把威脅情報當作數據去理解的話，可能上述內容理解起來較為困難，在這裡我希望大家把威脅情報當作facility和operation的結合去理解，你就會理解上面的內容了。

接下來我們看slide的左邊，左邊其實和右邊是沒有關聯的，只是為了單純方便排版。左邊的幾個point說明的實際上是對威脅情報團隊考核的幾個點（也就是KPI），由於本文不討論詳細的運營步驟和方式，所以這裡說的簡單一些：情報源、應用場景、FINTEL、情報計劃、運營workflow這些是評估威脅情報運營能力的幾個點。

0x04 面向終端的情報輸送

本文的題目是威脅情報的終端化，所以按照前面我們說的生命周期，我們在輸送情報的時候實際上就兩種情況：面向機器和面向人，面向機器是直接把相對應的規則推送到機器上實現點對點的情報署，面向人就是直接輸送給人，讓人去處理。當然在這裡我們討論的是前者，因為後者實際上也是輸送到機器，只是輸送的成品會變成二次加工的FINTEL。

我們在製作輸送模型的過程中應考慮以下幾個問題：

• 我需要輸送何種類型的情報：YARA規則？MD5？IPtables規則？etc.？hotfix補丁？
• 我需要輸送面向何種目標的情報：中間件？核心技術？etc.？
• 我需要收集目標的何種信息：中間件版本？操作系統版本？所用技術的名稱和版本？
• 我需要用何種介質輸送終端情報：Agent？規則列表？運維腳本？

弄清楚了這些問題，你也就製作完成了一個對應的情報輸送的計劃，我們緊接著就是收集這些相關的情報，這裡你可以選擇爬蟲、購買、自己獲取等方式，取決於你的成本和你的精力。我們的理想情況是捕獲到重要的情報，安全運營的同學在評估完畢後可以手動推送情報到終端，完成布防。

插一句：這裡的情報不一定是一種，可以是一個完整的package集合，甚至是可以源自於一起安全事件，輸送的實際上也就是所謂的case。舉個例子，我現在截獲了一個情報，有一批喪心病狂的人利用redis的漏洞挖礦，他們的主要手段和某安全社區裡面提供的套路如出一轍，我們這樣就可以直接在終端上部署一些我們對他們攻擊行為分析的針對性情報：比如掃描特徵、樣本YARA規則、C&C伺服器、礦池地址等，一旦檢測到了，立刻就可以調用case的預案，完成對同類型事件的免疫。

0x05 總結

在威脅情報實際上有很多時候適合常規的安全運營模式一樣有完整的閉環，我們不應該一味的追求數據上的大多，而忽視了一些實際上會用到的情況，只要有效，技術再lowbee也是值得的，無效但高大上的技術，往往做出來也就是個玩具（你懂的）。畢竟安全不是PR主導，而是實打實的效果檢驗。

推薦閱讀：