大數(shù)據(jù)技術(shù)在網(wǎng)絡(luò)威脅情報系統(tǒng)的應(yīng)用研究

◆黃必棟

大數(shù)據(jù)技術(shù)在網(wǎng)絡(luò)威脅情報系統(tǒng)的應(yīng)用研究

◆黃必棟

（南京鐵道職業(yè)技術(shù)學院智能工程學院 江蘇 210000）

本文結(jié)合威脅情報系統(tǒng)的設(shè)計、開發(fā)和運維經(jīng)驗，系統(tǒng)研究了流式數(shù)據(jù)處理、交互式數(shù)據(jù)分析、數(shù)據(jù)湖以及分布式數(shù)據(jù)處理等大數(shù)據(jù)技術(shù)在威脅情報系統(tǒng)中的應(yīng)用。分析和總結(jié)了在威脅情報系統(tǒng)建設(shè)場景中，大數(shù)據(jù)技術(shù)的選擇、大數(shù)據(jù)產(chǎn)品的選型以及大數(shù)據(jù)平臺的設(shè)計，為基于大數(shù)據(jù)技術(shù)的應(yīng)用系統(tǒng)的設(shè)計和開發(fā)提供參考。

威脅情報；流式數(shù)據(jù)處理；交互式數(shù)據(jù)分析；數(shù)據(jù)湖

在網(wǎng)絡(luò)安全防護中使用威脅情報發(fā)現(xiàn)和阻止網(wǎng)絡(luò)攻擊，即通過分析已知網(wǎng)絡(luò)攻擊、惡意軟件的行為，提取可用于識別網(wǎng)絡(luò)威脅的關(guān)鍵特征，使用關(guān)鍵特征進行匹配，從而發(fā)現(xiàn)和阻止網(wǎng)絡(luò)攻擊行為?？捎糜谧R別網(wǎng)絡(luò)威脅的關(guān)鍵特征即威脅情報，包括惡意文件的哈希值、C&C地址、攻擊手法、攻擊組織和攻擊意圖等[1]。威脅情報數(shù)據(jù)符合大數(shù)據(jù)特征：數(shù)據(jù)量大、數(shù)據(jù)來源和種類多樣、數(shù)據(jù)增長快以及數(shù)據(jù)價值密度和可信度相對較低。因此大數(shù)據(jù)技術(shù)廣泛并深入應(yīng)用于威脅情報系統(tǒng)中，其中包括了大數(shù)據(jù)存儲、大數(shù)據(jù)離線分析與挖掘、大數(shù)據(jù)實時處理、大數(shù)據(jù)在線查詢統(tǒng)計等。由于大數(shù)據(jù)技術(shù)種類繁多、同一類技術(shù)存在多個開源系統(tǒng)以及開源系統(tǒng)存在不成熟和不穩(wěn)定的問題，使得不同組織的威脅情報系統(tǒng)差異較大，沒有統(tǒng)一的數(shù)據(jù)處理平臺。本文結(jié)合威脅情報系統(tǒng)的設(shè)計、開發(fā)和運維經(jīng)驗，系統(tǒng)研究了大數(shù)據(jù)技術(shù)在威脅情報系統(tǒng)中的應(yīng)用。分析和總結(jié)了在威脅情報系統(tǒng)建設(shè)場景中，大數(shù)據(jù)技術(shù)的選擇、大數(shù)據(jù)產(chǎn)品的選型以及大數(shù)據(jù)平臺的設(shè)計。

1 威脅情報系統(tǒng)介紹

威脅情報系統(tǒng)是安全防御的后臺系統(tǒng)，提供威脅情報用于網(wǎng)絡(luò)威脅檢測。使用威脅情報的效果，取決于組織擁有情報的可靠性、完整性和及時性。而網(wǎng)絡(luò)攻擊持續(xù)發(fā)生，覆蓋范圍廣，攻擊形式和方法變化多端，惡意軟件數(shù)量也持續(xù)增長，這些特征決定了組織應(yīng)通過情報共享、安全大數(shù)據(jù)分析與挖掘、實時數(shù)據(jù)處理、情報生成自動化等方法來確保威脅情報的質(zhì)量。情報共享使得組織在無法掌握所有攻擊活動和惡意樣本的情況下，盡可能掌握更多的攻擊信息。安全數(shù)據(jù)分析與挖掘能夠豐富與完善情報信息，通過安全數(shù)據(jù)的關(guān)聯(lián)分析找出攻擊特征與規(guī)律，進一步生成更多的威脅情報，提高情報的可靠性。實時數(shù)據(jù)處理確保了威脅情報的時效性，以及情報生成的高效性。情報自動化生成能夠提高威脅情報生成的效率，確保威脅情報的按時生成。

威脅情報系統(tǒng)的架構(gòu)如圖1所示，虛線框中為威脅情報系統(tǒng)，收集各種情報相關(guān)數(shù)據(jù)進行處理，生成情報并分發(fā)至安全產(chǎn)品，整個過程以自動化的方式進行，使情報持續(xù)穩(wěn)定的輸出[2]。整個系統(tǒng)圍繞安全數(shù)據(jù)的收集、處理、存儲、分析和生成而進行，安全分析師和研究員使用系統(tǒng)對情報相關(guān)數(shù)據(jù)進行分析和評估，以及調(diào)整情報生成相關(guān)算法。流式數(shù)據(jù)處理技術(shù)確保了情報數(shù)據(jù)處理的及時性和高效性；交互式數(shù)據(jù)查詢和分析技術(shù)使得安全分析人員能夠高效、快速地查找和分析安全數(shù)據(jù)；數(shù)據(jù)湖技術(shù)使得大量安全數(shù)據(jù)能夠安全可靠地存儲，配合分布式數(shù)據(jù)處理引擎，能夠進行高效的數(shù)據(jù)處理和分析，并支持運行復雜的情報生成算法。

圖1 威脅情報系統(tǒng)

2 流式數(shù)據(jù)處理技術(shù)的應(yīng)用

2.1 數(shù)據(jù)處理需求

一些情報數(shù)據(jù)具有量大、價值密度低的特點，如蜜罐數(shù)據(jù)、樣本行為數(shù)據(jù)等，須在落入數(shù)據(jù)倉庫前進行數(shù)據(jù)處理，以確保數(shù)據(jù)處理的效率。此類數(shù)據(jù)處理要求復雜，除了常規(guī)的數(shù)據(jù)變換、篩選、去重等處理之外，還需進行定制化的復雜處理，例如對數(shù)據(jù)中的IP地址進行實時指紋查詢，并依據(jù)查詢結(jié)果打標簽；實時解析域名的IP地址或者IP地址的反向查詢等。流式數(shù)據(jù)處理技術(shù)能滿足相應(yīng)的要求，即能進行常規(guī)的數(shù)據(jù)處理，也能支持用戶定制化的數(shù)據(jù)處理要求。

2.2 技術(shù)選型

滿足數(shù)據(jù)處理要求的開源流式處理系統(tǒng)有：Spark Streaming[3]、Storm[4]和Flink[6]，其技術(shù)對比如表1所示。Storm是較早推出的流式處理系統(tǒng)，具有較好的實時性，但是吞吐能力、狀態(tài)管理以及窗口處理能力較弱。Spark Streaming是目前主流的流式處理系統(tǒng)，具有較好的吞吐能力、狀態(tài)管理、編程語言支持，但由于micro batch的處理方式，實時性相對較弱，為近實時數(shù)據(jù)處理[5]。Flink是目前流行的流式處理系統(tǒng)，具有較好的實時性、吞吐能力、狀態(tài)管理以及窗口處理能力，在流式處理方面功能支持完善，性能較好[6]。但是Flink的批處理和Python支持相對較弱，生態(tài)也不及Spark完善。

表1 Flink、Spark Streaming、Storm技術(shù)對比

FlinkSpark StreamingStorm 分布式處理是是是 支持UDF是是是 窗口處理能力強一般弱 處理吞吐能力強強一般 處理延時實時近實時實時 處理方式process at arrivemicro batchprocess at arrive 處理語義at-least-onceexactly-onceat-least-onceexactly-onceat-least-onceat-most-once 開發(fā)語言Java，PythonScala，Java，PythonJava SQL支持完整較完整部分 支持批處理是是否

綜合分析得出Flink和Spark Streaming都能滿足情報處理系統(tǒng)流式數(shù)據(jù)處理的要求。Flink雖然性能較優(yōu)，但是批處理和Python支持較弱；Spark Streaming雖然是近實時數(shù)據(jù)處理，實時性不及Flink，但是在批處理和Python支持方面較強?？紤]到系統(tǒng)中還需要數(shù)據(jù)分析批處理功能，并且Python是數(shù)據(jù)分析的主流語言，首選Spark Streaming作為情報系統(tǒng)的流式處理引擎。

2.3 系統(tǒng)設(shè)計

圖2 數(shù)據(jù)處理架構(gòu)

數(shù)據(jù)處理架構(gòu)如圖2所示，由數(shù)據(jù)緩沖、流式處理以及數(shù)據(jù)處理管道組成[2]。輸入的數(shù)據(jù)首先寫入Kafka緩沖并持久化，確保數(shù)據(jù)可靠落地。Spark Streaming程序讀取Kafka相應(yīng)的topic，執(zhí)行完處理后再輸出至Kafka特定的topic，輸出的topic可以作為中間結(jié)果被其他的Spark Streaming程序讀取，也可以通過數(shù)據(jù)處理管道分發(fā)至數(shù)據(jù)存儲。Logstash提供數(shù)據(jù)處理管道功能，其功能完善穩(wěn)定，擁有可擴展的插件生態(tài)系統(tǒng)，支持輸出至多種數(shù)據(jù)存儲，支持輕量的數(shù)據(jù)處理能力和數(shù)據(jù)豐富化功能，能實時的解析和轉(zhuǎn)換數(shù)據(jù)[7]。

3 交互式數(shù)據(jù)查詢和分析技術(shù)的應(yīng)用

3.1 數(shù)據(jù)處理需求

為使安全分析人員能夠高效、快速的查找和分析安全數(shù)據(jù)，系統(tǒng)須提供即席查詢、數(shù)據(jù)儀表盤以及數(shù)據(jù)報表等功能?？焖俨樵兒头治龅臄?shù)據(jù)為系統(tǒng)的熱數(shù)據(jù)，即近期落入系統(tǒng)的數(shù)據(jù)和常用的基礎(chǔ)數(shù)據(jù)。查詢時要求具有較好的人機交互功能，能快速響應(yīng)用戶的查詢和統(tǒng)計分析。

3.2 技術(shù)選型

分析型數(shù)據(jù)庫（OLAP數(shù)據(jù)庫）能滿足查詢和統(tǒng)計分析的要求，目前主流的開源OLAP數(shù)據(jù)庫有：ClickHouse[9]、Druid、ElasticSearch[8]、Kylin，其技術(shù)對比如表2所示。這幾款數(shù)據(jù)庫的實現(xiàn)原理各有不同，Druid和Kylin都采用了預聚合技術(shù)，但對明細數(shù)據(jù)的查詢支持較弱；ElasticSearch采用了倒排索引，具有全文檢索功能[8]；ClickHouse是列式存儲數(shù)據(jù)庫，單機性能優(yōu)秀[9]。Kylin的預聚合使用了數(shù)據(jù)立方體方法，聚合過程復雜且耗時，存在導入的數(shù)據(jù)在較長時間才能查到的問題，難以滿足實時性要求。Druid的預聚合處理相對輕量，雖然滿足實時性要求，但是在查詢明細數(shù)據(jù)方面還存在不足，無法滿足系統(tǒng)要求。ClickHouse和ElasticSearch基本上都滿足系統(tǒng)的查詢和統(tǒng)計要求，考慮到ElasticSearch可以配合開源的數(shù)據(jù)可視化和探索工具Kibana[10]，能提供靈活易用的數(shù)據(jù)探索和分析功能，并且支持全文檢索功能，而ClickHouse在數(shù)據(jù)可視化分析方面還不夠成熟，ElasticSearch作為OLAP數(shù)據(jù)庫的首選。

表2 OLAP數(shù)據(jù)庫技術(shù)對比

ClickHouseDruidElasticSearchKylin 分布式集群支持支持支持支持 支持數(shù)據(jù)量大大中等大 實時性強強強弱 SQL支持中等弱弱標準 查詢性能高高較高高 并發(fā)能力中高中高 預處理否是否是 全文檢索不支持支持支持不支持 原始數(shù)據(jù)查詢支持不支持支持不支持

3.3 系統(tǒng)設(shè)計

交互式數(shù)據(jù)查詢與分析的系統(tǒng)架構(gòu)如圖3所示，ElasticSearch和Kibana為交互式數(shù)據(jù)分析的核心，ElasticSearch提供了數(shù)據(jù)存儲、查詢、統(tǒng)計分析的功能，Kibana提供了交互式分析的人機界面功能。導入ElasticSearch的有兩類數(shù)據(jù)，一類數(shù)據(jù)來自流式數(shù)據(jù)處理，通過Logstash導入；另一類數(shù)據(jù)來自數(shù)據(jù)批處理，通過Spark程序?qū)搿?/p>

圖3 交互式數(shù)據(jù)查詢與分析系統(tǒng)架構(gòu)

圖4 蜜罐最近1小時實時數(shù)據(jù)展示

流式數(shù)據(jù)中帶有時間戳屬性，導入ElasticSearch中可進行時間序列的統(tǒng)計分析，如數(shù)據(jù)的歷史變化趨勢、異常流量分析等。ElasticSearch數(shù)據(jù)庫具有良好的實時性，導入的數(shù)據(jù)可以近實時地被查詢到（亞秒-秒級），通過數(shù)據(jù)儀表盤可以近實時地展示系統(tǒng)的輸入以及數(shù)據(jù)處理的運行情況。圖4所示為蜜罐最近1小時的實時數(shù)據(jù)趨勢，包括數(shù)據(jù)詳細信息的展示。通過查詢條件可以篩選過濾數(shù)據(jù)，查詢條件使用靈活的ElasticSearch DSL語法，可以進行關(guān)鍵字匹配，也可以使用復雜的邏輯組合，數(shù)據(jù)查詢功能完善。

Kibana提供了強大的數(shù)據(jù)可視化和探索功能，可以不用編程而直接使用界面配置出各種類型的圖表，方便了安全分析人員進行數(shù)據(jù)分析。圖5和圖6為系統(tǒng)的部分統(tǒng)計分析圖，圖5展示了最近15天內(nèi)每日情報數(shù)據(jù)的變化趨勢和分布，清晰的展示出系統(tǒng)輸出情報的概況；圖6展示了最近一段時間蜜罐的流量分布，以及每個蜜罐的具體流量值。

圖5 最近15天情報數(shù)據(jù)的趨勢和分布

圖6 蜜罐流量分析

4 數(shù)據(jù)湖和分布式數(shù)據(jù)處理技術(shù)的應(yīng)用

4.1 系統(tǒng)存儲和離線數(shù)據(jù)分析需求

存放在分析型數(shù)據(jù)庫中的數(shù)據(jù)為系統(tǒng)的熱數(shù)據(jù)，其數(shù)據(jù)量為GB～TB級別。而系統(tǒng)的全量數(shù)據(jù)的數(shù)據(jù)量為TB～PB級別，需要通過數(shù)據(jù)湖技術(shù)進行存儲管理。數(shù)據(jù)湖能夠支撐TB～PB級的存儲，并提供類似傳統(tǒng)數(shù)據(jù)庫的表Schema管理、高效率的數(shù)據(jù)更新和刪除以及ACID特性?？紤]到系統(tǒng)的成本和數(shù)據(jù)安全性問題，數(shù)據(jù)湖須搭建在本地的多臺通用服務(wù)器上，底層的數(shù)據(jù)存儲使用Hadoop分布式文件存儲系統(tǒng)HDFS。數(shù)據(jù)湖結(jié)合分布式查詢引擎能進行高效的數(shù)據(jù)查詢和分析，能支持交互式數(shù)據(jù)分析、離線分析以及應(yīng)用復雜的數(shù)據(jù)處理算法進行數(shù)據(jù)挖掘。

4.2 技術(shù)選型對比

目前主流的開源數(shù)據(jù)湖有：Iceberg、Delta Lake和Hudi。Iceberg最初由Netflix公司開發(fā)，之后發(fā)展為Apache開源項目。Netflix最初為了替換Hive，解決Hive的缺陷而開發(fā)了Iceberg，設(shè)計抽象和通用性較好。Delta Lake由Databricks開發(fā)，有商業(yè)版本和開源版本，最初為了解決Lambda架構(gòu)流批處理場景中所存在的問題，隨后發(fā)展為功能完善的數(shù)據(jù)湖[11]。Hudi最初由Uber公司開發(fā)，之后發(fā)展為Apache開源項目。Hudi最初是為解決快速upsert存量數(shù)據(jù)問題和流式增量消費問題，后來發(fā)展為功能完善的數(shù)據(jù)湖。三種數(shù)據(jù)湖技術(shù)對比如表3所示，Iceberg在數(shù)據(jù)更新和刪除、流式數(shù)據(jù)寫入方面支持較弱；Delta Lake雖然和Spark計算引擎強綁定，但對Spark以及流批統(tǒng)一處理架構(gòu)的支持較強；Hudi則在各方面技術(shù)較為均衡。

表3 數(shù)據(jù)湖技術(shù)對比

IcebergDelta LakeHudi upsert和delete數(shù)據(jù)片重寫支持支持 表Schema管理支持支持支持 底層存儲HDFS、S3HDFS、S3、Azure Data Lake Storage Hadoop、S3 ACID語義支持支持支持 Time travel支持支持支持 上層引擎Hive、Spark、PrestoSpark強綁定Hive、Spark、Presto 流式數(shù)據(jù)寫入支持弱支持支持 小文件合并支持弱支持支持

支持上述三種數(shù)據(jù)湖技術(shù)的主流開源查詢引擎有：Hive、Spark[5]和Presto。Hive是Hadoop生態(tài)中出現(xiàn)較早的結(jié)構(gòu)化查詢引擎，早期由于使用Map-Reduce作為計算引擎性能欠佳，但后期加入了Tez和Spark作為計算引擎，以及使用CBO和緩存技術(shù)，性能有所提升，目前還是一種主流的結(jié)構(gòu)化分布式查詢引擎。Spark是近年來發(fā)展較為迅速的計算平臺，早期為非結(jié)構(gòu)化的Spark RDD計算模型，后期發(fā)展為Spark SQL結(jié)構(gòu)化查詢引擎，在性能方面優(yōu)化較大，并且生態(tài)完善。Presto是由Facebook開源的分布式SQL查詢引擎，其設(shè)計目標是結(jié)束數(shù)據(jù)分析的兩難選擇：速度快但價格貴的商業(yè)方案和消耗大量硬件的慢速免費方案。這三個分布式查詢引擎對比如表4所示。

表4 分布式查詢引擎技術(shù)對比

Hive TezSpark SQLPresto SQL查詢語言支持支持支持 交互式查詢能力一般一般強 編程語言以SQL為主，其他語言支持較弱Python，Scala，R，Java以SQL為主，其他語言支持較弱 內(nèi)存計算支持支持支持 ETL能力中等強弱

4.3 系統(tǒng)設(shè)計

由于系統(tǒng)需要具備較強的ETL批處理能力，并且除了支持SQL語言之外還需支持適合于數(shù)據(jù)分析的Python語言，Spark SQL是分布式查詢引擎的首選。數(shù)據(jù)湖方面，Delta Lake與Spark SQL緊密集成，并且在數(shù)據(jù)湖其他特性上支持完善，Delta Lake為數(shù)據(jù)湖方案的首選。設(shè)計方案如圖4.1所示，底層存儲使用分布式文件系統(tǒng)Hadoop HDFS，分布式查詢引擎運行于Hadoop Yarn之上，Delta Lake作為Spark插件與Spark緊密集成，用戶可以使用SQL、Python和Scala等編程語言進行數(shù)據(jù)操作。Python是目前比較流行的數(shù)據(jù)分析語言，深受數(shù)據(jù)分析師和開發(fā)人員的喜愛，而PySpark支持在Spark平臺上使用Python，并且提供了與數(shù)據(jù)分析庫之間良好的轉(zhuǎn)換接口，因此PySpark是數(shù)據(jù)批處理、數(shù)據(jù)探索分析、ETL以及數(shù)據(jù)建模的首選工具。

圖7 數(shù)據(jù)湖和分布式查詢引擎方案

5 結(jié)論

網(wǎng)絡(luò)威脅情報系統(tǒng)是一個復雜的典型的大數(shù)據(jù)處理系統(tǒng)，涉及大數(shù)據(jù)技術(shù)領(lǐng)域的多個關(guān)鍵技術(shù)。在流式數(shù)據(jù)處理中，F(xiàn)Link和Spark Streaming都是成熟可靠的產(chǎn)品，歷經(jīng)多年的版本迭代和演化。在實時性和吞吐能力方面FLink有著明顯的優(yōu)勢，這來自設(shè)計上的差異；Spark由于使用Micro Batching處理方法，實時性上稍微偏弱。而Spark生態(tài)完整、豐富，批處理方面做得更好，在實際應(yīng)用中若流批需求共存，加上Python語言在數(shù)據(jù)分析中的流行，Spark方案通常為首選方案。在數(shù)據(jù)存儲方面，以往的直接文件存儲（基于分布式文件系統(tǒng)或?qū)ο蟠鎯ο到y(tǒng)）顯露出越來越多的弊端，如文件修改不方便、并發(fā)寫沖突、數(shù)據(jù)Schema難以維護等問題。數(shù)據(jù)湖技術(shù)是近幾年來發(fā)展出的技術(shù)，目標是解決直接文件存儲方法存在的問題，這些問題出現(xiàn)在各個公司的不同應(yīng)用場景下，急待解決。本文使用的Delta Lake是Databricks公司的開源產(chǎn)品，支持的特性較為完善，是當前穩(wěn)定可靠的一種數(shù)據(jù)湖方案。Iceberg和Hudi同樣也是優(yōu)秀的數(shù)據(jù)湖方案，他們的區(qū)別在于設(shè)計之初的目標和設(shè)計方案上的區(qū)別，目前都是活躍的項目，未來的發(fā)展可能在于目標的統(tǒng)一和多樣化的發(fā)展。在數(shù)據(jù)可視化和探索領(lǐng)域，Elastic Stack是一款明星開源產(chǎn)品，來自商業(yè)公司，安裝維護方面做得比較完善，易于使用。Elastic Stack項目比較活躍，版本更新較快，不斷有新功能的加入，在OLAP數(shù)據(jù)庫、數(shù)據(jù)可視化、數(shù)據(jù)探索需求共存的場景下，通常成為首選方案。由于研究時間和作者的水平有限，本研究可能存在不夠全面、深度不足等問題，若有問題希望讀者給予指正。

[1]360威脅情報中心. 威脅情報的上下文、標示及能夠執(zhí)行的建議[EB/OL]. http://www.secrss.com/articles/6062，2018.

[2]黃必棟. 網(wǎng)絡(luò)威脅情報處理系統(tǒng)的設(shè)計與開發(fā)[J]. 網(wǎng)絡(luò)安全技術(shù)與應(yīng)用，2020（8）：61-63.

[3]Structured Streaming Programming Guide[EB/OL]. http://spark.apache.org/docs/latest/structured-streaming-programming-guide.html.

[4]Apache Storm [EB/OL]. https://storm.apache.org/.

[5]Michael Armbrust，Tathagata Das，Joseph Torres. Structured Streaming：A Declarative API for Real-Time Applications in Apache Spark[J]. SIGMOD，2018.

[6]Apache Flink[EB/OL]. https://flink.apache.org/.

[7]How Logstash Works[EB/OL]. https://www.elastic.co/guide/en/logstash/current/pipeline.html.

[8]Elasticsearch Reference[EB/OL]. https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html.

[9]ClickHouse[EB/OL]. https://clickhouse.tech/.

[10]Kibana Guide[EB/OL]. https://www.elastic.co/guide/en/kibana/current/index.html.

[11]Delta Lake[EB/OL]. https://docs.delta.io/latest/index.html.