如何設計資訊保安領域的實時安全基線引擎

摘要：本文整理自奇安信集團高階技術專家覃永靖在 Flink Forward Asia 2021 行業實踐專場的分享。本篇內容主要分為四個部分：
什麼是安全分析
計算框架的選擇
引擎設計
實踐與展望

點選檢視直播回放 & 演講PDF

一、什麼是安全分析

近 10 年來，大資料技術發展日新月異。安全分析場景和方法也更新換代。目前，常用的安全分析流程大概分為三個流程：

日誌採集解析。通過各種方法，從伺服器、閘道器裝置、終端、資料庫或其它資料來源採集各種流量日誌、威脅日誌、執行日誌，和終端日誌等資料；
實時安全分析。分析過程主要有安全基線、關聯分析、安全規則、威脅情報，和安全知識庫；
安全運營和態勢感知。這個流程基於安全分析的結果來實現態勢視覺化、安全運營、多裝置安全聯動、安全編排等能力。

如上圖所示，安全領域主要有三個特點：

快速響應。因為安全事件經常是突發的，比如漏洞的披露、病毒的爆發等常常是在很短的時間突然發生，所以需要以非常有效和簡單易用的方式來快速的對突發的安全事件進行處理，能第一時間響應客戶的需求、應對各類安全事件；
場景定製。因為安全分析和常規的大資料分析場景會有一些不同，安全分析檢測的是異常而不是正常，還有領域獨有的一些需求，所以這裡會涉及到很多領域定製開發的需求。
資源受限。相比常規網際網路大資料平臺使用方式，安全分析可使用的資源會有很多的限制，通常使用者受限於預算和資源的限制，會盡可能的壓縮和優化可用計算和儲存資源規模，這會導致大量的元件採用混合部署的方式，且將來硬體和叢集擴充套件成本也很高，流程很長。

在實時資料安全方面，一共有五點需求：

第一是需要實時分析。安全檢測對時延要求嚴格，攻防雙方搶時間差，需要能第一時間檢測到異常。同時由於是安全事件驅動，要求解決方案上線快，響應及時，能在最短時間形成防護能力；
第二是需要提供非常豐富的分析語義。安全檢測的場景通常比較複雜的，需要提供豐富的安全分析語義，覆蓋大部分安全分析場景；
第三個是能靈活部署。因為客戶的環境非常複雜，需要能支援各種大資料平臺，比如客戶自建的，或者是他購買的一些雲平臺，並且還要有最大的版本相容性；
第四是需要實現最小的資源使用。支援部署從一到幾十甚至上百臺節點的叢集，在資源佔用儘可能小的同時支援大規模，比如上千條分析規則或安全基線同時執行；
最後是執行穩定。安全產品部署在客戶側，需要 7×24 小時不間斷執行，需要提供極高的執行穩定性，儘可能減少人工維護和介入，讓客戶無感知。

傳統的安全分析方法一般是基於先驗知識，採用基於特徵檢測技術來進行異常檢測，一般是通過分析檢測物件的資料或日誌特點，然後人工歸納和統計出可檢測特徵，建立安全模型，比如安全規則、威脅情報等。這種方式比較簡單和可靠，可以很好的應對已有的攻擊方法，但是它對未知的沒有對應檢測特徵的攻擊方法則不能有效的進行檢測。

安全基線採用基於行為的檢測方法，使用檢測物件資料和日誌，採用各種方法學習出行為特徵，建立安全基線，並用於異常檢測。

為了讓大家能更好的理解安全基線的使用場景，這裡列了三個真實場景：

場景一，DBA 使用者賬號登入異常。比如登入位置異常，登入時間異常，使用資料庫的行為異常等。比如一個 DBA 使用者，通常是在某些時間、某些 IP 或是某些地點登入，但是某天突然在另外一個地方登入了，且時間也不是通常登入時間，那這可能就是一個異常，需要生成異常事件；
場景二，郵件傳送附件數量超過常規值。比如安全基線學習部門或者整個公司傳送郵件的行為資料，發現某一個使用者傳送附件的數量和歷史學習資料有較大出入，那這可能是一個異常；
場景三，最近賬號登入 VPN 服務的次數異常。通過學習使用者賬號 VPN 歷史登入行為，構建安全基線，如果將來發現賬號登入異常，則產生異常事件。

二、計算框架的選擇

目前主流實時計算框架主要有兩個，Spark 和 Flink。我們當初設計這個引擎是在 2018 年左右，當時我們研究了 Storm、Spark、Flink 這三個計算框架，綜合各方面因素最終選擇了 Flink 作為底層計算框架。當時使用的 Flink 是 1.4 版本左右，是一個比較成熟的版本，相比其它框架，它的 API 以及它的底層分散式和流計算實現方式比較符合我們的使用場景。

Flink 的優勢點比較突出，它是分散式計算框架，部署靈活，適配目前常見大資料平臺。它擁有很好的處理效能，能達到高吞吐低延遲，這非常適合進行實時安全分析。它還提供靈活的 DataStreaming API，方便實現定製化需求。另外，還支援簡單易用的檢查點和儲存點機制。並且，作為目前非常熱門的計算框架，社群活躍，有豐富的文件和場景樣例。

雖然Flink有很多優勢，但當企業資源受限，規則集數量上千規模的情況下。Flink 在滿足業務及效能需求上遇到了很多問題。比如無大規模規則語義/流優化，缺乏安全場景定製視窗和邏輯，無安全基線相關運算元以及無資源保護機制等。

三、引擎設計

引擎應用框架分為三層：

底層是部署層，通常是一個大資料叢集；
第二層是安全分析層，基於 Flink DataStreaming API 來構建安全基線引擎，Flink 負責底層的分散式計算和事件流傳送，具體的業務計算由安全基線引擎來完成。安全基線引擎向使用者提供的使用介面為規則和 DSL，使用者通過介面來下發規則 DSL 給引擎，引擎根據規則和 DSL 來對事件流進行分析和計算，同時根據規則語義使用外部的資料，比如知識資料、威脅情報、資產和漏洞等；
使用者通過第三層的應用層來管理和使用引擎。並基於引擎資料結果態勢分析，安全運營，資源監控等具體安全業務。

引擎的業務流程分為三塊，即使用者介面，引擎服務和引擎分析任務。使用者通過使用者介面來進行規則配置、基線管理和執行監控。引擎服務以 RESTfull API 的方式向使用者提供規則下發、基線下發、狀態監控等服務。引擎服務在接收到使用者的規則下發請求後需要對下發的規則集進行解析、優化之後生成分析任務程式碼包，分析任務程式碼提交大資料叢集執行，分析任務在執行過程中接收引擎服務的基線發下資料，對執行時基線進行增刪改操作。分析任務還向引擎服務報告任務執行狀態，引擎服務將任務執行狀態對映成業務監控資訊，提供給使用者查詢和分析使用

由於大部分使用者不是研發人員，所以需要提供一種針對安全分析場景，進行特定優化的安全分析語言。它需要具備以下幾點：

簡單易用，學習成本低，易上手，一個沒有研發背景的人也能經過簡單學習之後就能上手使用，且符合安全分析人員的直覺思維；
需要提供豐富的資料型別，首先要提供豐富的基礎資料型別，其次是安全分析常用的資料比如 IP，各類時間、資產、漏洞、威脅情報、地理位置等提供直接支援，使用者可以不做任何定製就能直接使用各類資料；
提供豐富的語義，尤其對安全分析語義進行增強和定製；
支援擴充套件，雖然提供的安全分析語義比較全面，支援大部分安全分析場景，但還是會遇到一些無法直接支援的特殊場景，此時就需要以擴充套件的方式來支援這類需求。

安全分析語言需要設計一個專門的編譯器來對安全分析人員設計的安全分析語句和規則進行編譯和優化。編譯器需要提供一些特性和優化的支援：

公共表示式優化。對分析語句中相同語義邏輯進行優化，降低重複計算和計算複雜度；
引用資料表優化。一個規則集中可能有上千條分析語句和規則，它們會大量的引用外部資料表資料，需要對錶計算進行計算優化，比如 hash 匹配、大規模 IP 匹配優化、大規模正則匹配和串匹配優化等；
常量表示式優化。提高執行效能；
表引用優化。包含引用示例歸併和引用語義歸併兩個部分，降低引用表的資源佔用。

分析語句和規則編譯之後生成執行子圖，每一條語句和規則對應一個子圖，此時需要集中所有規則進行圖優化，分為四個流程：

第一步是圖融合，圖融合涉及子圖融合，即將規則集中所有子圖融合成一個執行圖，然後進行圖節點語義融合、時間視窗歸併、引用公共資源優化；
第二步是資料流優化，降低圖規模，減少傳輸資料量，主要進行 Key 前置、語義等價節點融合、網路吞吐均衡，減少資料傾斜、節點歸併，大幅壓縮超大圖節點數量等操作；
第三步是欄位裁剪，降低傳輸事件大小，進而降低網路 IO 壓力，主要包含圖上欄位推導和裁剪以及欄位歸併；
最後是程式碼生成，將分析語句和規則語義生成程式碼，並將執行圖對映到 Flink DataStream API。

實時計算一個核心要素是時間，不同的時間處理方法和實現方案會帶來差異很大甚至完全不同的計算結果。實時分析中，時間主要影響兩個功能，即時間視窗和時間線。

在安全分析場景裡，時間視窗需要支援通用滑動時間視窗、也要支援自然時間滑動時間視窗，比如每年，每月，每星期等自然，甚至是變長時間、需要支援層疊視窗重複資料融合，降低資料儲存量、能自動進行重複計算消除，避免重複告警、時間定時器歸併、事件亂序正確處理，避免事件亂序引起錯誤計算。

時間線可分為事件發生時間和時間處理兩類，進而延伸出時間精度，不同的時間精度會對處理效能和儲存造成很大的壓力，比如需要對時間進行排序的場景。由於實時分析中事件可能是亂序的，因此需要支援延遲時間，解決大部分因為亂序而造成的計算不準確問題。部分計算場景涉及系統時間<->事件時間之間的相互轉換，需要能提供兩種時間的轉換計算方法。由於執行圖是大量子圖融合而來，因此需要同時支援對全域性和區域性時間水位進行管理，保證圖上時間線能正確推進。

安全基線分為三類：

第一類是統計類安全極限，包含常見的時間類、頻率類、空間類、範圍類和多級統計類的安全基線；
第二是序列類，比如指數平滑類和週期類安全基線；
第三是機器學習類的安全基線，比如使用一些聚類演算法的安全基線，決策樹類安全基線等。

基線處理流程主要分為三個部分：基線學習、基線檢測和基線路由，其中穿插事件過濾、時間視窗、基線降噪、基線管理等流程。基線學習流程包含從訊息佇列和儲存中讀取事件流，經過事件過濾和時間視窗聚合，事件流中可能包含噪音資料，還需進行資料降噪流程，最後基線學習流程學習輸入的事件流程，生成對應的安全基線。學習完成的安全基線在進行基線管理流程之後用於異常檢測，用於預測和異常檢測，如果發現異常行為，則產生異常事件，輸出到後續的處理流程，用於後續的業務的使用。使用者在使用過程中可能需要修改或刪除一些學習好的基線或者自己新建一個基線，這些基線的增刪改操作通過基線路由功能來完成，基線路由流程將使用者編輯的基線在圖上路由之後正確的分發到對應的圖節點例項中。

基線的週期分為 learn，ready，close，expire 四個階段：

learn 表示學習階段，在這個階段基線學習輸入的事件流；
ready 階段表示當前時間線已經到了基線的學習截止時間，但是因為延遲時間，基線需要等待一個延遲時間，在這個時間段基線可以繼續學習延遲的事件，同時基線可以用於異常檢測；
close 表示當前時間線到了延遲時間，此時基線不再學習輸入的事件，只用於異常檢測；
expire 表示當前時間線到了基線超時時間，需要基線停止進行異常檢測，並刪除。

基線的計算由兩種情況觸發：

第一種是事件觸發計算，每條事件到達之後會觸發一次異常檢測計算；
第二種是時間觸發計算，基線週期會註冊時間定時器，時間定時器觸發之後會觸發相關基線計算流程。

基線的輸出分為基線異常事件輸出和基線內容輸出：

基線異常事件輸出發生於基線異常檢測過程，當發現異常事件時需要輸出對應的事件；
基線內容輸出發生於基線學習完成之後需要將基線本身進行輸出，用於基線編輯和基線本身異常分析。

使用者在使用過程中，可能會經常編輯已有基線或者自己根據一些分析和資料來新建特定場景的安全基線。基線編輯之後需要能下發到基線引擎中，這就涉及如何線上編輯和更新基線。

首先需要基線是可編輯的，要求分析語言支援基線編輯相關語義，同時基線資料結構的設計需要支援基線編輯的語義，最後是要提供一套基線編輯視覺化流程，包含基線展示、修改、刪除等功能，使用者可以直接在頁面進行基線的編輯和下發；
第二是要求基線是可路由的，分析語句和規則在經過編譯和圖優化之後的真實執行圖和頁面顯示的規則執行會有很大的不同，一個可路由的基線要求實現編譯時構建全域性基線更新流圖、一套執行時基線路由方法，包含執行流圖的路由流構建，廣播和定向路由的支援，最終實現精確的基線資料分發；
最後還要求基線是可更新的，需要有一套清晰的基線更新語義，定義基線執行週期和計算方法，然後在你基線更新過程中，任何一個位置都可能會發生異常導致更新失敗，此時需要設計一套機制能在任何位置失敗後將資訊反饋使用者，用於錯誤判定和問題修復。

在基線學習過程中，通常學習週期是比較長的，比如最近一週、最近一個月等，長週期的學習通常會面臨一個資料割裂的問題，比如學習最近一週的資料，但是現在是星期三，也就是說最近一週的資料分成兩個部分，其中從星期一到星期二的資料是儲存在歷史資料儲存中，星期三及之後的資料是實時發生的，這裡會涉及歷史和實時資料融合學習的問題。這裡可以分為三種情況：

第一是待學習資料全部是歷史資料，這需要支援歷史資料學習範圍探測，和線上基線更新；
第二是待學習的資料全部是實時資料，這要求支援基線自動學習、基線自動檢測和基線自動更新；
第三種是剛才舉例的這種，也是最複雜的情況，即歷史和實時資料融合，這需要支援歷史和實時資料邊界劃分、基線融合、重複資料消除。

基線學習的資料中通常會有一些噪音，這些噪音可能是某一次異常操作，比如使用者某一次的異常登入，也可能是資料採集的過程中引入的錯誤資料，因此需要對噪音進行消除，來增加基線準確性，減少誤報。

資料降噪根據資料型別可以簡單分為數值類資料降噪和非數值類資料降噪兩種，這兩種處理方式會有不同。噪音的判定主要有四種：

第一種是相對於本週期的資料來判斷，即與本週期其他資料進行對比，判斷是否是噪音；
第二是相比上一個週期，與最近一個週期的資料進行對比，判斷是否是噪音；
第三個是相比歷史資料，與歷史上所有的資料來進行對比來判斷是否是噪音；
最後是使用者自定義一個噪音判定邏輯，比如設定大於多少小於多少它是噪音。

資料降噪時候通常會需要儲存相關資料，比如要用歷史的資料來進行噪音判定，那麼就需要儲存一些歷史的關鍵資料，歷史資料通常非常多，為了降低儲存，需要進行優化降噪資料結構的優化，比如最小化降噪關鍵資料，欄位裁剪等。

引擎執行中一個非常重要的部分是如何監控以及保護資源。涉及到三個方面的內容：

第一個是穩定性增強，需要動態監控基線執行過程中記憶體的佔用，引擎中可能同時執行了幾百上千基線規則，需要能監控每條基線規則記憶體佔用有多少，對於記憶體佔用異常的規則，需要採取記憶體保護的措施，比如刪除一些資料或者將它隔離出來，防止影響其它正常規則的執行，刪除的時候可以採用資源優先順序的管理，如果優先順序比較低，且同時佔用大量的資源，就可能會把資源給減少甚至停用規則的執行。引擎同時還對基線計算過程進行監控，監控過程如果發現嚴重影響圖處理效能的慢路徑，則採用子圖隔離的方式將慢路徑對應的子圖隔離出來，防止對其它分析流程造成影響；
第二是狀態監控，狀態監控包含兩個部分，第一部分是引擎將執行圖所有計算節點的狀態資料，比如 CPU、記憶體、磁碟、輸入輸出等資訊報告給監控服務；第二部分是監控服務將執行圖的執行資訊處理之後對映為規則狀態資訊，完成圖狀態到業務狀態的轉換。對於大規模執行圖和高併發執行的分析任務需要對圖狀態報告流程進行優化，降低資源佔用；
第三是流量控制，引擎的下游業務可能是一些處理能力比較慢的流程，比如資料庫寫等，此時需要支援流量控制，防止較快的處理流程向較慢的處理流程輸入過多的資料而引起資源過度消耗和卡頓，流量控制需要支援主動流量控制、被動流量控制以及時間視窗相關的流量控制，通過使用者配置或自動處理來解決前後處理效能不一引起的資料丟失和系統不穩定問題。

使用者在使用過程中經常要對規則進行操作，這些操作會引起執行任務的啟停，啟停過程中資料需要前後保證一致，不能因為啟停而導致儲存的資料丟失。

Flink 本身支援任務重啟時重新載入資料，但是在基線引擎這裡問題會比較複雜，因為使用者可能會停用、啟用或者修改規則，這會引起規則集發生變化，進而引起執行圖發生變化，為了保證任務重啟時不變的規則能正確從 savepoint 載入到到正確的資料，需要支援圖區域性狀態穩定，即在圖優化過程中圖區域性變化不影響其它子圖，同時在程式碼生成過程中保證穩定子圖生成穩定的執行程式碼，變化規則隻影響與其相關的子圖，其它不變的規則不受影響。

基線學習過程中通常儲存大量的中間資料，為了加快 savepoint 和 checkpoint 速度，需要對複雜資料結構的序列化和反序列化進行優化，還需支援增量狀態。引擎服務通常需要對多使用者提供分析服務，因此還需對多使用者多工的狀態進行管理，保證每個任務都能準確關聯到其對應的狀態資料。

四、實踐與展望

分析引擎提供的實時安全分析能力服務於公司大部分大資料產品，比如大資料與安全運營平臺、態勢感知、EDR、雲安全、工控網際網路、智慧安全等。隨著這些產品部署了近千個客戶，包括央企、政府、銀行、公安等，同時還支援常見國產化系統和各類私有云。部署的環境從一到幾百臺叢集規模，事件量從幾百到上百萬 EPS，還參加和支援了上百次部委和央企的專項行動。

隨著知識的擴散和各類安全漏洞的頻發，各種攻擊手法和安全威脅也層出不窮，這對安全分析能力的要求也越來越高，需要引擎能持續進行更新和優化，以提高對安全攻擊的檢測能力，後續需要繼續將更多更好的行為學習演算法和技術與安全基線整合，提高安全基線的檢測能力。同時期望能將引擎的一些實踐通過某些渠道回饋到社群，讓更多的人能使用其中好的設計和實踐。