網絡威脅情報處理系統的設計與開發

◆黃必棟

（南京鐵道職業技術學院 江蘇 210031）

威脅情報在網絡安全防護中起著重要的作用，它是一種基于證據的知識，包括了情境、機制、指標、隱含和實際可行的建議，其描述了現存的或即將出現針對資產的威脅，可以用于通知主體針對相關威脅采取某種響應[1]。英國基礎設施保護中心（CPNI）將威脅情報分為四類[2]：戰略情報、可操作情報、戰術情報和技術情報。戰略情報為總結性的信息，站在全局的角度為決策層提供參考。通常為行業總覽、攻擊趨勢等比較宏觀的報告。可操作情報是針對特定組織即將發生的攻擊的情報。戰術情報通常指Tactics，Techniques，and Procedures（TTPs），TTPs是用來描述攻擊者如何進行攻擊的，包括攻擊者的方法，工具和策略。技術情報是特定惡意軟件或網絡攻擊的指標，包括文件哈希、域名和IP等，通常被稱為失陷檢測指標IOC（Indicator Of Compromise），可用于“威脅”自動化檢測和分析。戰術情報和技術情報的可操作性強，可直接應用于安全防護，在企業中經常使用到。戰術情報通常先要經過安全人員的分析，再轉化成可執行的防護措施，而技術情報可以直接配置到安全產品中用于檢測[3]。本文介紹了一種可以自動化生成技術情報的威脅情報處理系統，包括了系統的架構、大數據在系統中的應用、關鍵模塊設計等。

1 系統架構

1.1 系統結構

威脅情報處理系統是安全防御的后臺系統，通過收集不同來源和類型的情報數據，使用特定的情報生成算法生成情報，再把情報分發至各種安全產品。整個過程以自動化的方式進行，使情報持續的輸出并及時的應用于安全產品。系統結構如圖1所示，虛線框中為威脅情報處理系統，安全分析師和研究員使用威脅情報系統對情報數據進行分析、評估和情報相關算法的調整。

系統主要由數據收集、數據處理、數據存儲與分析、情報生成以及情報管理模塊構成。數據收集模塊根據數據類型和特征采用不同的收集方法，如DNS域名解析、Top域名、IP指紋等使用主動收集方法，如蜜罐數據、開源情報、安全產品反饋數據等使用被動收集方法，除了自動化數據收集方式還有人工提交數據功能。數據處理模塊提供了數據ETL功能，對收集來的數據進行提取、過濾、變換處理后，持久化至“數據倉庫”中。部分采集過來的數據經過數據處理即可直接生成情報，如開源情報、蜜罐數據等。數據存儲與分析模塊使用分布式文件系統、全文檢索數據庫、OLAP分析型數據庫以及分布式數據處理系統等大數據技術提供情報數據的存儲、查詢和統計分析功能。情報生成模塊是系統的核心模塊，使用各種情報生成模型，基于情報數據生成情報。情報管理模塊負責情報數據的存儲、查詢和分發。

圖1威脅情報系統

1.2 大數據技術在系統中的應用

系統中使用了各種大數據技術，按模塊分如圖2所示。數據處理模塊使用流式數據處理和數據處理管道技術，對收集來的數據進行過濾、格式轉換、復雜變換和數據豐富化等處理，使用數據管道再進行數據分發。數據流式處理使用Spark Structure Streaming，數據處理管道使用Logstash和Kafka。數據存儲使用基于Hadoop HDFS的數據倉庫Delta Lake，配合分布式數據處理引擎Spark進行數據分析和挖掘。全文檢索和分析型數據庫用于“熱數據”的搜索、統計和分析。云端對象存儲S3用于數據備份和中轉。技術棧的選擇并非唯一的，如數據流式處理可以選擇Flink、分析型數據庫可選擇ClickHouse等，最終的選擇根據實際使用需求、云平臺的使用以及開發和使用人員的技術偏好等因素綜合考慮。

圖2大數據技術在系統的使用

2 情報數據處理

2.1 數據處理要求

系統輸入的數據要進行適當的處理后才能用于數據分析和情報生成。數據處理方法有兩種[4]：（1）Data at Rest，數據落入數據倉庫后再進行處理；（2）Data in Motion，數據落入數據倉庫前進行處理，如圖3所示。方法1需要消耗額外的數據庫資源，使用批處理方法，處理速度比方法2慢。

一些情報數據具有量大、價值密度低的特點，如蜜罐數據、樣本行為數據等，若采用方法1將大大增加數據倉庫的負擔，且處理速度較慢。這類數據適合使用方法2進行處理，即在數據落入數據庫前使用流式處理方法。情報數據處理的要求有：（1）復雜數據處理能力。系統不僅要能進行過濾、去重和選擇等常規操作，還能使用自定義的函數處理數據，如對數據中的IP地址進行實時指紋查詢，并依據查詢結果打標簽。（2）近實時的數據處理能力。情報數據中有些屬性具有較強的時效性，如蜜罐數據中的IP地址和域名，對這些數據處理越快得到的結果越準確。（3）彈性擴展能力。由于輸入數據具有量大、不穩定等特點，系統要能按照輸入負載靈活擴展以保證數據處理的性能。（4）靈活的系統調整能力。情報系統的輸入不固定，隨時可能接入新的數據，或者原有的數據格式和內容發生變化，這要求系統能靈活地調整接入數據、處理內容和流程。

圖3 Data at Rest和Data in Motion

2.2 數據處理設計

開源流式處理系統雖然能滿足大部分的數據處理要求，但還要考慮數據的緩沖、分發以及系統調整能力。Spark Streaming支持讀取各種數據源，以及寫入多種數據存儲[5]。但還存在一些問題：1.數據源和存儲的更改不方便，更改時要調整代碼并重啟流式程序。2.并發寫入多種數據存儲時，穩定性欠佳。考慮到系統的穩定性和可靠性，Spark Streaming的數據源和輸出都為Kafka。通過不同Kafka topic區分不同的數據流，再通過Logstash數據管道分發至對應數據存儲中。

數據處理架構如圖4所示，由數據緩沖、流式處理以及數據處理管道組成。數據輸入先寫入Kafka緩沖并持久化，確保數據可靠落地。Kafka部署為集群模式，提供了數據緩沖的分布式處理能力，保證了系統的高可用性以及支持系統彈性擴展。Spark Streaming程序讀取Kafka topic，處理后再輸出至Kafka topic，輸出的topic可以作為中間結果被其他的Spark Streaming程序讀取，也可以通過數據處理管道分發至存儲。Logstash數據管道用于輕量的數據處理、數據豐富化以及數據分發，例如過濾選擇特定的消息、IP的地理位置信息的添加等。

圖4數據處理架構

圖5為一數據處理流程示例，展示了Spark流式程序如何消費、生產Kafka topic，以及如何通過數據管道分發數據。數據首先輸入至Kafka topic A，由Spark流式處理程序1消費處理，輸出處理結果至topic B。Spark流式處理程序2再消費處理topic B，輸出結果至topic C。Topic B和topic C的數據分別由Logstash的兩個數據處理管道收集，最后分發至存儲中。這個數據處理流程使用了兩個Spark流式處理程序和兩個數據處理管道，Spark流式處理程序負責復雜的數據處理任務，而數據處理管道負責數據的分發、落地以及輕量的數據處理任務。使用兩個流式處理程序，是由于中間處理結果需要進行導出存儲。

圖5數據處理流程示例

3 交互式數據查詢和統計分析

3.1 數據分析要求

交互式查詢與統計是系統的關鍵模塊，提供數據的即席查詢、數據儀表盤以及數據報表等功能以供安全分析人員使用。該模塊涉及的數據主要包括：系統近期處理的數據、最終情報數據以及部分關鍵數據。近期處理數據是近三個月內經過數據處理模塊落入系統的熱數據，查詢時要求具有近實時性，能夠查詢到秒級范圍內落入系統的數據。這類數據通過數據儀表盤可視化展示當前系統的運行狀況，通過數據報表展示近期數據的歷史趨勢和數據分布，并且可以查詢詳細的內容以方便進行數據分析和溯源。最終情報數據和部分關鍵數據是經常查詢的數據，需要方便地進行即席查詢和統計分析。

3.2 系統設計

系統架構如圖6所示，導入ElasticSearch的有兩部分數據，一部分數據來自數據處理模塊，以流式數據的形式通過Logstash導入；另一部分數據來自數據批處理，通過Spark程序導入。用戶使用Kibana訪問ElasticSearch，進行數據可視化探索與分析，包括數據檢索、數據儀表盤以及報表分析。

圖6系統架構

離線數據存儲于Hadoop分布式文件系統HDFS中，使用Spark進行離線數據分析的結果可以通過elasticsearch-hadoop組件寫入ElasticSearch中，即可以進行交互式數據查詢和分析。這種方法是Spark數據分析的補充，可充分利用Kibana與ElasticSearch的數據可視化與探索能力。Kibana提供了強大的數據可視化和探索功能，可以不編程而直接使用界面配置出各種類型的圖表，方便了安全分析人員進行數據分析。

流式數據中帶有時間戳屬性，導入ElasticSearch中可進行時間序列的統計分析，如數據的歷史變化趨勢、異常流量分析等。ElasticSearch數據庫具有良好的實時性[6]，導入的數據可以近實時的被查詢到（亞秒～秒級），通過數據儀表盤可以近實時的展示系統輸入以及數據處理的運行情況。

4 結束語

構建威脅情報系統的難度在于如何可靠穩定的收集、處理數據，如何提高情報的置信度，以及如何進行高效的情報數據管理。這問題的解決需要系統在運行過程中不斷地調整、優化，持續地進行改進。本文介紹的是經過多次優化的系統設計，由于篇幅有限僅介紹了整個系統的整體結構和關鍵設計，為類似系統的設計提供有價值的參考。