經過蜜網和鑽石模型對ICS威脅進行分析

蜜網(Honeynets)是一種誘捕網絡，利用多個蜜罐經過網絡鏈接在一塊兒模擬一個看似易受***的計算機網絡，利用其中一部分主機吸引******，另外一部分主機部署監控系統，經過監測、觀察***過程，一方面調查***者的來源，另外一方面考察用於防禦的安全措施是否有效。是一種用在各類網絡環境中收集威脅情報的技術。所以，組織【注：指美國能源部】已經開始使用這種方法來保護網絡化的工業控制系統（ICS）。但願經過該環境觀察到企圖破壞他們工業系統的***活動和路徑，從而對真實的生產網絡部署相對應的緩解方案以增強工業網絡安全，並防止新出現的威脅活動。

該報告提供了一種分析方法，利用這種方法將從ICS蜜網系統中收集捕獲的大約16GB字節的完整數據包進行分析以瞭解***的活動和路徑。這些數據是在其餘公開來源的背景下進行分析的，這些信息是已知的對ICS的威脅，以瞭解對手是如何與網絡進行交互的以及他們嘗試過的***類型。爲了提供更嚴謹的方法來描述這些威脅行爲，該研究採用了著名的***分析鑽石模型。她應用這個模型來定義和分類在數據中觀察到的幾個潛在的威脅行爲者。該研究還評估了蜜網做爲一種ICS威脅情報工具的有效性。此外，該報告還包含幾個關於部署的建議，並強調主動與外部主機進行交互能夠產生更高質量的研究數據。

II 簡介

保護工業控制系統（ICS）對於保護關鍵基礎設施相當重要。考慮到在網絡安全漏洞事件中發生物理影響的可能性很高，「ICS網絡」的捍衛者必須瞭解他們的對手和這些行爲者的能力。此外，因爲許多組織採用這些工業系統的規模，在部署有效的威脅情報和安全監測時，優先考慮的一個主要問題是感知威脅。支持這一使命的寶貴工具是蜜網，這是一個沙盒式網絡，表面上看起來很脆弱，但實質上是利用蜜罐主機模擬工業網絡上的生產機器。經過對蜜網系統的正確配置，其能夠觀察到針對特定環境的高度特定的***活動，好比針對工業環境中的工業網絡威脅，這些可能的威脅被蜜網系統捕獲併產生能夠對網絡維護者或安全研究者有價值的數據。可是，這些系統提供的數據量可能很是大，使人生畏，而且在這些數據中提取或生成可操做的有價值的信息變得十分困難。

這個研究分析了一個來自ICS蜜網的非保密數據，試圖從數據中生成有用的威脅情報和優先級。咱們應用了Caltagirone，Pendergast和Betz（Caltagirone，Pendergast和Betz 2013）首先描述的***分析鑽石模型。該模型容許咱們根據多個維度來描述事件，每一個維度都有潛在的數據點。在這樣分析過程當中，咱們有可能發現看似不相關的數據元素之間的關係，從而更好地瞭解組織的威脅概況，並提供基於這些情報驅動的防護。

III 數據來源

3.1. ICS蜜網捕獲的數據包

這個研究的主要數據集是一個完整的網絡數據包捕獲(PCAP)數據的集合，它是由一個未公開的組織(截止2016未披露)的數據收集而來的。該蜜網系統模仿了一個美國能源領域的公司網絡並利用該網絡進行工業領域的威脅情報收集活動。在必定程度上，咱們觀察到在蜜網上的主機包括Windows和Windows Server機器。除此以外，PCAP數據包沒有提供更多的信息使咱們獲知這個網絡裏面的其餘設備的配置。

這個網絡環境中的傳感器捕捉到的全部傳入和傳出的流量，都是由tcpdump和Wireshark這樣的應用程序所使用的標準libpcap格式。這個匿名的數據集顯示了在虛擬的0.0.0.0/24子網中由地址表明的10個蜜罐主機，而且網絡外部的全部網絡協議（IP）地址仍然被網絡傳感器捕獲。PCAP數據集的收集時間範圍從2015年6月23日開始，到2016年2月29日結束。在此期間，該蜜網系統數據包捕獲機制幾乎持續運行，而且將天天的數據包做爲單獨文件交付保存。總的來講，這些文件包含大約16 GB的數據。數據集包含來自至少66,936個經過傳輸控制協議(TCP)、用戶數據報協議(UDP)和因特網控制消息協議(ICMP) 進行通訊的獨特主機的通訊量，這些數據集總共佔據了超過99.999%的數據包。

3.2. 數據問題

3.2.1.活動記錄不完整

蜜網和外部主機之間的網絡交互是一個很是有用的來源，可是用於此分析的PCAP數據有時缺少上下文。利用這類型的完整數據包有助於在流量中觀察到的某些活動以進行更深刻的理解。例如，當觀察到受***的惡意軟件命令和控制(C2)流量時，沒有和外部的網絡交互包不可能觀察到初始的協商流量。經過對基於外部交互流量的分析，在第一個PCAP接收到的時間，或者在一個加密的鏈接上最初的協商發生時間，咱們就能夠觀察到這樣的初始協商流量。可是做爲從一個較大的正在進行的項目中選擇的數據，它缺乏了所述的流量上下文。也許對基於主機的數據包的分析可能會解釋這一點，可是這超出了本報告的範圍。總的來講，本次分析的數據集至關豐富，爲分析提供了足夠的流量。

3.2.2.缺少蜜網配置數據

儘管已經提供了一些關於蜜網的基本細節，而且其餘的一些基本上能夠經過從包有效載荷的數據中推斷出來(見第7.1節)，但本研究把蜜網自己視爲一個黑匣子。主機的配置是不明顯的，也不可能可靠地肯定他們是如何監聽或響應網絡流量的。這反過來又使對對手***鏈的理解變得更加複雜，由於蜜網可能不會以某種方式迴應對手探測，從而促使進一步的網絡偵察或監視。這在全部類型的蜜網操做中都是一個常見的技術難題，不限於本次研究的這個特定例子。儘管在這個數據集中，效果是很是明顯的。

一個相關的特定於ICS的問題是，很難肯定網絡試圖仿效哪些設備（若是有的話）。雖然這個PCAP數據來源於一個明確的基於ICS的蜜網系統，但沒有其餘具體的配置細節可用。這對使用鑽石模型來分析***事件提出了挑戰，由於這個框架使用受害者的數據做爲分析的一個組成部分。然而，從PCAP數據得出的信息使咱們可以對受害者做出某些假設，儘管信心較低。

3.2.3.須要手動分析某些數據

因爲這項研究尋求對ICS的新興威脅，所以很難將數據分析中的許多步驟自動化。Caltagirone及其同事指出，這多是鑽石模型的一個侷限性，由於沒有現成的方法來自動分析每一種狀況（Caltagirone，Pendergast和Betz 2013）。ICS防護是一個新興領域，須要對許多專有或專門的協議進行分析；不多有自動化工具可以知足本研究的目標。所以，這項研究包括了手動數據分析，特別是在檢查包有效載荷時。儘管有可能針對協議的特徵開發出專門的簽名，並以此進行自動的有效負載分析，可是在這種簽名被開發出來以前，它一般不是一個選項。即便有這種可能性，自動化分析的價值也頗有限，由於負載、流量類型和數據來源的主機的具備至關多樣性。最好的方法是結合手工分析和自動化分析的方式，雖然咱們可能會從手工分析中得出有用的結論，但合併更多的自動化可能有助於咱們發現孤立的數據或微妙的模式，這些模式對研究是有價值的。

3.3. WHOIS和DNS數據

在識別蜜網數據中存在的主機時，咱們查詢了各類WHOIS和DNS數據庫。這些公開的信息收集將主機名與IP地址相關聯，並標識出與該地址空間和域名相關的組織。最終維護這些信息的組織是ARIN和RIPE等區域互聯網註冊管理機構; 咱們採用了在線工具來彙總來自各類開放數據庫的信息，包括RobTex和DomainTools等服務。這些服務還爲各類DNS數據庫，自主系統編號（ASN）和許多主機的黑名單信息提供交叉引用。

3.4. VirusTotal

VirusTotal是一個開源的文件分析數據庫，其中包含了衆多商業反惡意軟件解決方案的檢測引擎。除了文件名分析以外，VirusTotal還會掃描和記錄各類域和主機上的信息，以跟蹤可能源自它們的任何惡意軟件。這些信息幫助咱們肯定在蜜網數據中出現的主機是否與惡意軟件發佈或C2有關係。VirusTotal數據庫還包括對相關文件和主機的引用，以及社區提交的信息和可提供其餘信息的報告，這些信息和報告能夠提供額外的信息(VirusTotal 2016)。

3.5. Palo Alto Networks的威脅情報報告

在2015年底，Palo Alto Networks的42組發佈了兩篇簡短的報告，描述了代號爲「Bookworm」的威脅行爲者。據報道，這名威脅行爲者使用的惡意軟件主要針對泰國國內的政府組織。「Bookworm」的惡意軟件和信息結構具備高度的模塊化和技術複雜性。題爲「Bookworm***：模塊化架構模型」和「泰國治理Bookworm病毒***運動」提供了「Bookworm」***的報告，對該組織的戰術、技術和程序提供了深刻的分析。此外，它們還包括諸如散列值和域名的折中指標（Scott，Falcone和Cortes 2015）。

3.6. 其餘開源信息

各類公開可用的文檔爲PCAP數據提供了上下文和分析。這些文件包括安全供應商和研究人員的報告，這些報告包含了惡意軟件家族、威脅行爲者以及所涉及的C2領域的信息，這些領域促進了對某些網絡工做流量的分析。供應商文檔和經過互聯網研究得到的其餘公開數據提供了關於應用程序和設備的默認配置的基本信息(好比ICS設備使用的默認端口)。

IV 工具

許多工具備助於快速分析和描述這個大數據集的成員。分析主要發生在Linux環境中，由大量用於網絡流量分析的開源工具支持。使用開源數據庫進行的研究完善了這些工具生成的工件。這種分析和研究提供了所必需的信息，用以建立使用鑽石模型進行分析所需的數據元組。

4.1. GNU核心工具

各類GNU核心實用程序（如grep，cut和cat）在處理大量的網絡流量數據方面都頗有用。因爲PCAP數據做爲單獨的文件分發，所以使用這些工具特別有助於對這些文件中的許多或全部文件進行總體分析。

4.2. SiLK和super_mediator

「SiLK」是一套用於分析網絡流量的工具，由卡內基梅隆軟件工程學院(軟件工程研究所)的CERT部門開發的。在整個研究過程當中，咱們使用了各類各樣的SiLK工具。SiLK能夠查詢大量的網絡流量數據，並瞭解外部主機與蜜網相互做用的整體狀況，特別是在時間、服務、協議和端口方面。反過來，這個分析也幫助在鑽石模型的上下文中對主機和事件進行了描述。在這項研究中最經常使用的SiLK工具包括：rwfilter、rwstats和rwsetbuild。咱們使用了rwp2yaf2silk工具來從PCAP數據中生成流記錄。

另外一個由CERT部門開發的工具super_mediator使咱們可以按比例處理來自PCAP文件的有效負載數據。咱們使用super_mediator與YAF組合，經過嚮應用程序提供Berkeley包過濾器（BPF）規則來提取特定的有效負載數據。該技術做爲圖形協議分析器（如Wireshark）的替代方案，用於流量的應用層分析（Software Engineering Institute 2016）。

4.3. Shell腳本

咱們使用GNU Bash中實現的shell腳本自動分析了咱們數據集的一些部分。例如將批量的PCAP轉換爲流記錄，從流記錄中提取事件元組，組織數據集，以及一次從數據集解析或轉換多個項目。

V ***分析鑽石模型

5.1. 核心概念

***分析的鑽石模型提供了一種正式和標準的方式來描述網絡***（Caltagirone，Pendergast和Betz 2013）。鑽石模型得名於它用來描述***事件的基本數據結構：對手、能力、基礎設施和受害者的四個鏈接特性圖，如圖1所示。每一個元素自己都是各類數據點的元組，能夠根據正在進行的特定分析進行定製。通常來講，元組包括組織/行爲者（若是已經知道）、IP地址、應用程序、源/目標端口等相關元素（Caltagirone，Pendergast和Betz 2013）。相當重要的是，每一個元素造成一個具備置信水平的有序對，這有助於使用該模型來開發分析產品。此外，一個活動還包括開始和結束時間、階段、結果、方向、方法和資源等元功能（Caltagirone，Pendergast和Betz 2013）。爲了理解PCAP數據，咱們建立了一些事件（包括其必要的子組件）來描述和關聯潛在威脅行爲者的活動。***分析的鑽石模型對元組的使用補充了SiLK使用五元組來捕獲網絡流元數據，在生成事件數據時促進了這些信息的集成。

圖1：鑽石模型事件（Caltagirone，Pendergast和Betz 2013）

5.2. 分析主元

該模型的架構師將分析主元描述爲一個過程，它容許分析師經過將四種主要元組中的數據與其餘情報來源(Caltagirone、Caltagirone和Caltagirone 2013年)的數據結合起來，從而得到丟失的信息。分析主元是這項研究的中心：它使咱們可以收集蜜網所揭示的威脅的細節，使之成爲可用的信息。在許多狀況下，除了一個數據元組在一個事件中是很明顯的，也會有存在數據不完整的狀況發生。爲了得到丟失的信息，咱們使用在看似徹底不一樣的事件中共享數據並以此進行推論。

咱們使用了6.3節中描述的兩個方法來枚舉和鏈接這些數據。

5.3. 活動組建立

鑽石模型架構師將活動組(AG)描述爲「由特徵或過程當中的類似性相關的鑽石事件和活動線索以及信任加權」(Caltagirone、Betz和Caltagirone2013)。從本質上說，AG是一種將許多事件聯繫起來的方法，以便掌握明顯相關的活動的含義，並經過對潛在的威脅行爲者的徹底理解來發展有效的防護。特別是在考慮這麼大的數據集時，有一個快速關聯事件的方法是很重要的。經過使用突出的特徵來造成一個潛在的威脅行爲者的總體特徵，對分析的支持進行補充。這個過程也使得有可能創建有針對性的、健壯的網絡防護系統。

咱們的研究並不試圖提供威脅歸因，僅僅是對與ICS網絡防護相關的可觀察活動的描述。此外，咱們缺少將PCAP數據中的技術指標與特定的我的或組織聯繫在一塊兒的證據。雖然在建立AG時可能會有一些事件，但事件自己徹底缺少新的數據來繼續支撐並推演下去。Caltagirone及其同事指出，這種缺少數據的狀況是大多數鑽石模型分析的可能狀況。

VI 方法

6.1. 鑽石模型使用的變量

表1列出了本研究中使用的變量及其描述。

表1：鑽石模型變量

變量	描述
Adv	對手：參與事件的可疑威脅行爲者
AGC	活動組建立功能
AGS	事件空間中全部活動組的集合
Cx	特徵x的置信度，用做加權因子
Cap	能力：對手使用的工具，技術和程序
E	事件：由對手，能力，基礎設施和受害者定義的向量
ET	在數據中設置全部事件和事件線程
FVPR	知足分析問題（PR）的特徵向量
Inf	基礎設施:用於支持對手的虛擬和物理資源
PR	分析問題
Vic	受害者:在某一事件中被對手***的組織或我的

6.2. ICS蜜網數據的分區和識別

6.2.1.使用SiLK描述網絡流量

因爲在數據集中識別出大量惟一的外部主機（近67,000個），所以必須以對可能產生有用事件的數據進行優先排序的方式對數據集進行分區。最簡單最直接的方法是消除與蜜網沒有交換大量流量的主機。請注意，這並不徹底從數據集中排除這些主機。最初排除產生10個或更少流量記錄的外部主機將會減小90%以上的設置。

爲了進一步減小數據集，咱們檢查了最常聯繫的主機。咱們使用WHOIS數據來肯定聯繫蜜網的前10名外部主機，包括Google公共域名系統（DNS）服務和各類Microsoft更新服務器。雖然源IP地址可能被欺騙，但對有效載荷數據的粗略檢查顯示，來自這些主機的流量彷佛是合法的。

6.2.2.檢查HTTP POST數據

除了使用SiLK對網絡流量進行高級特徵描述外，咱們還檢查了咱們認爲可能產生有用信息的流量數據。其中一個類別是源於蜜罐主機的超文本傳輸協議（HTTP）的POST請求。咱們把分析集中在這些請求上，由於它們常常被用於惡意軟件C2的通訊。在正常的PCAP中指出這樣的流量是很困難的，由於惡意的POST請求會被包含在合法的POST請求中。然而，因爲這個蜜網的性質，觀察到的POST請求要少得多。所以，咱們能夠檢查由YAF和super_mediator生成的這些請求的有效載荷，以肯定它們是否包含網絡上C2流量或其餘惡意活動的證據。

6.2.3.對通用ICS端口的流量檢查

主要供應商使用的通用的ICS端口也是檢查流量的重要參數。在進行開源研究以生成常見ICS端口列表以後，咱們使用SiLK來快速發現那些外部主機常常聯繫到的這些端口。而後咱們使用super_mediator獲取有效載荷數據（相關的數據），並檢查這些數據是否存在活動的跡象。

6.2.4.鑽石模型事件定義

要正確使用鑽石模型，必須定義字符的特定特性，即事件的四個要素。如上所述，事件包括四個要素：對手、能力、基礎設施和受害者，每個都與相應的置信水平配對。

除了Caltagirone及其同事提供的事件的基本定義外，咱們能夠自由選擇與咱們分析相關的數據元組。咱們將事件功能定義以下。首先看對手，這個功能在本研究的上下文中是一個空集。

咱們對能力的定義提供了某些特性的定義，這些特性突出了鑽石模型的可擴展性。反過來又將其做爲防護專業網絡的工具時也頗有用。咱們經過端口掃描使用、開發利用、惡意軟件使用、C2使用和ICS意識來定義能力。

能力元組的前四個特徵適用於許多網絡威脅，而不只僅是針對ICS的網絡。用來對付ICS網絡的能力與用來對付傳統網絡的能力有很大的重疊。正如Assante和Lee所說，ICS***鏈每每採用雙級方法，其中第一種方法基本上反映了傳統企業網絡的***（Assante和Lee 2015）。因爲這個緣由，咱們還包含了一個ICS特性，顯示對手明顯的區分傳統網絡與ICS網絡的能力。咱們能夠經過檢查諸如ICS特定端口的大量掃描或使用針對控制系統的漏洞的指標來評估此能力。

對於基礎設施，咱們包括了一些功能，這些功能說明了典型的威脅行爲者所使用的資源，包括那些具備高級功能的人。這些資源包括IP地址、源端口、操做系統、域名或主機名、主機(託管)類型和代理使用。

這些細節描述了對手使用的資源的基本屬性。在一些分析中，基礎設施還能夠包括***者使用的物理資產。這確定與ICS威脅的分析有關。例如，一個設法***到特定組織場所的高級***者能夠根據收集的信息安裝該組織所具備的ICS硬件或軟件。這可能與檢查蜜網流量無關。雖然定義基礎設施的大部分功能相對簡單，但主機（託管）類型值得進一步描述。Caltagirone和他的同事們觀察到，有兩種主要類型的基礎設施：1類是「徹底由對手控制或擁有」，2類徹底由第三方提供基礎設施（不管是合法獲取仍是被對手侵佔））。

與對手不一樣的是，咱們對受害者持有大量數據。全部有目標的基礎設施都有明確的定義，並有一個單一操做人員。蜜網再次適用於鑽石模型的分析，由於它提供了一組已知的常數，有助於進一步探索。在此分析的目的中，咱們根據組織、目標IP地址、目標端口和目標系統來描述受害者。

這些細節再次成爲威脅行爲者所針對的組織的標準描述。第一個特徵（Org）是恆定的，由於全部有目標主機都出如今一個由單個（未公開）組織操做的蜜網內。其餘三個特徵（目標IP、目標端口和系統）相對容易從PCAP數據得到。

6.3. 分析主元(Pivoting)

在爲咱們的鑽石模型應用程序定義事件元組以後，咱們提取有用的事件數據，並嘗試經過分析主元來查找相關的特徵。分析主元的最終目標是建立用於威脅優先級的AG。儘管分析人員一般能夠自由地定義事件元組，可是很難肯定哪些事件可能與一個事件相關聯。爲了簡化這些工做，咱們選擇了兩種主要的方法來識別可操做的事件數據。以主機爲中心的方法從一個已知的主機（或一組主機）開始，該主機（或一組主機）被認爲具備相關性而且在第3層數據中尋找關聯，例如IP地址和主機名。以端口爲中心的方法圍繞第4層數據（主要是目標TCP和UDP端口組），以瞭解某些監視和利用活動的目標。這兩種技術的例子都在第7.2節中提供。

6.3.1.主機爲中心的方法

以主機爲中心的分析主元方法主要經過檢查流量模式或特徵來尋找外部主機之間的關係。它可能產生至關大的數據，特別是在能力和基礎設施方面。以主機爲中心的方法一般要求有效載荷數據是有效的，由於它依賴於發送和接收數據之間的關係。儘管如此，它是分析主元的更有效的方法之一。它有助於經過其活動來對主機進行歸類，並提供主機之間更高可信度的關聯，而不是經過通用基礎設施（其中許多行爲者，惡意軟件和其餘方式可能共享）進行交互。鑽石模型容許咱們協同使用這些特徵來發現額外的威脅行爲者。

6.3.2.以端口爲中心的方法

當咱們缺少足夠的信息來進行以主機爲中心的分析主元時，咱們能夠利用端口之間的關係做爲起點。這對於ICS網絡特別有用，ICS的通訊設備一般包含在專用端口上，而這些設備使用的端口不多被其餘服務使用。所以，以端口爲中心的方法能夠幫助咱們瞭解對手的能力，特別是其ICS意識水平。

6.4. 分組潛在的威脅行爲者

咱們的研究的基本目標是定義一系列的AG，這些AG反映了數據集中的各類行爲者可能對目標組織構成的特定威脅。值得注意的是，咱們並無以一種屬性的方式來定義研究的AG。換句話說，單個AG可能包含許多不一樣的行爲者及其所表明的威脅類型，而不是他們共享的控制、基礎設施或技術。

6.4.1.定義活動組建立功能

Caltagirone及其同事根據三個從屬變量定義了活動組建立（AGC）功能：分析問題，與考慮的分析問題對齊的特徵向量以及構成各類AG的事件集。這種組合產生一組全部的AG。使用標記，鑽石模型定義了以下一集（Caltagirone，Pendergast和Betz 2013）。

如前所述，本研究旨在解決分組威脅行爲者的分析問題，由於它們潛在地對ICS網絡產生不利影響。在這方面，最重要的特徵之一是ICS意識。若是一個威脅行爲者的行爲表現出對ICS的關注，那麼相對於那些對這些系統沒有明顯興趣的人來講，他的潛在威脅就更大了。除此以外，能力屬性的另外一個特性，能夠幫助肯定AG，是一個或多個C2、惡意軟件、利用嘗試或端口掃描。這組特性有助於根據嚴重程度對事件進行排序，由於它們按降序對應於網絡***鏈中的步驟。這意味着，擁有C2的行爲者在本質上是一個比僅僅從事端口掃描的人具備更高的威脅性。

雖然來自「能力」屬性的這兩組功能提供了潛在威脅行爲者的清晰描述，但咱們能夠經過某些基礎設施特性進一步闡明潛在的威脅。IP地址和域名在這裏尤爲相關，由於它們對應於已知(或可疑的)威脅行爲者所使用的基礎設施。這個信息是在該數據集內的特徵對於咱們有所幫助。

再次使用標記，咱們爲此分析問題定義特徵向量以下

咱們將函數的最終組成部分ET定義爲整個蜜網數據集。請注意，AGC功能不須要將每一個事件放入AG。這些未分組的事件被認爲是異常值。這個數據集中的大多數事件都屬於這個範例，由於絕大多數的外部主機只向蜜網機器發送了幾個數據包，與其餘行爲者沒有明顯的關係。因爲缺少數據，很難以任何有意義的方式對這些主機進行分類。

VII 結果

7.1. 蜜網配置

咱們沒有蜜網的配置詳細信息。相反，咱們從PCAP數據推斷其配置。在蜜網內有10個可觀察的主機。每一個都有0.0.0.0/24範圍內的匿名IP地址。在全部的實例中，每一個蜜罐機運行的操做系統都不清楚。爲了進一步研究這個問題，咱們檢查了來自蜜罐主機的流量和其餘外部主機的流量，能夠對這些細節提供分析。最終，它構成了咱們對鑽石模型背景下受害者理解的一個組成部分。

此外，值得注意的是，這些主機在網絡交互方面的明顯行爲。雖然從數據中不清楚蜜網上的主機是如何與更普遍的互聯網通訊的，但彷佛大部分收到報文的數據包都沒有獲得回覆。例如，在明顯的端口掃描活動中觀察到的大多數SYN包都沒有接收到應答(ACK)包，也沒有像一般預期的那樣被從新設置(RST)。如一般所預期的那樣。咱們從UDP流量中收集到更豐富的數據，由於該協議的無鏈接特性意味着不須要成功的握手就能看到交換的大部分流量。蜜網通常不會對它收到的任何數據進行響應，這可能會阻止進一步的數據傳輸。

從檢查流量中能夠清楚地看到，許多蜜網主機正在運行微軟的Windows。於這些主機交互的流量證明了這一點。這包括已知的Windows更新服務器和Teredo服務(一般在Windows Vista中默認啓用，但在其餘操做系統上不太常見)。有幾個主機生成這種類型的通訊，高度置信地表示它們正在運行的是相似的Windows版本。另一個主機彷佛也充當一個服務器，由於它向端口80上的一些外部主機發送HTTP Stauth Code 200 OK響應。該機器的網絡流量頭顯示它正在運行Microsoft Internet Information Services（IIS）版本7.5。Microsoft IIS的版本與Windows Server 2008 R2或做爲服務器的Windows 7主機對齊。默認狀況下，兩個Microsoft操做系統版本都支持此版本的IIS。

主機0.0.0.20是惟一一個生成足夠流量來推斷其配置的服務器，而且彷佛不是基於windows的。依據是其餘主機向該服務器發出Bro網絡安全監控系統的信號數據的請求，Bro系統僅在類unix操做系統上可用。而且該主機生成的其餘通訊量，如在線證書狀態協議(OCSP)和網絡時間協議(NTP)，與Windows主機發出的請求不一樣。這些協議能夠在多個不一樣的平臺上實現。

剩下的5個主機沒有生成足夠的流量來從PCAP文件中肯定它們的配置。雖然這些主機中的幾個主機對從外部網絡接收的流量作出響應，但所觀察到的流量主要由ICMP回覆響應組成。ICMP的應答幾乎沒有透露給定主機的底層操做系統或軟件。

主機及其相關配置詳細信息的摘要如表2所示。

表2：蜜網主機配置

主機	疑似OS /配置
0.0.0.2	Microsoft Windows Server 2008 R2 / Windows 7 (Microsoft IIS 7.5)
0.0.0.3	Unknown
0.0.0.4	Unknown
0.0.0.5	Microsoft Windows (Vista or later)
0.0.0.6	Unknown
0.0.0.7	Unknown
0.0.0.8	Unknown
0.0.0.9	Microsoft Windows (Vista or later)
0.0.0.20	Linux
0.0.0.21	Microsoft Windows (Vista or later)

7.2. 經過分析主元描述威脅行爲者

正如前面所討論的，咱們在分析中合併了分析主元，做爲一種關聯可變的事件數據項的方法，這些數據項在初次檢查時可能不會出現。經過提供用於肯定特徵向量的高質量數據，從而促進了AG的建立。

7.2.1.以主機爲中心的方法

在本研究中使用的以主機爲中心的分析方法的一個例子是被認爲與惡意軟件C2相關的流量的特徵。這是最初在對捕獲的全部HTTP POST請求的檢查時發現的。咱們使用一個shell腳本對這些數據進行隔離，該腳本使用YAF和super_mediator自動從80和8080端口上的全部POST請求中提取100個字節的應用程序層數據。

HTTP主機頭中，帶有一個長編碼URI和不熟悉主機名的POST請求代表，這多是值得研究的惡意流量。在VirusTotal的搜索領域中，搜索域名顯示了可能與Palo Alto Networks以代號爲「Bookworm」（Scott，Falcone and Cortes 2015）報道的***運動的基礎設施鏈接。目前還不清楚這一流量是否與同一名威脅行爲者有關，爲在公佈其活動時，一些***羣體傾向於放棄基礎設施。儘管如此，它仍是提供了一種以分析方式進行分析的方法的起點。。

基於此信息，咱們構建了進一步的查詢來調查PCAP中的活動，並發現更多關於潛在對手的信息。咱們使用了Palo Alto Networks在其報告中提供的IP地址列表，咱們準備了一套用於SiLK的rwfilter工具（Scott，Falcone和Cortes 2015）的文件。而後，咱們搜索了這組用於其餘可疑主機的列表，如表3所示。

表3：PCAP數據中觀察到的「Bookworm」主機

源IP地址	SiLK 流記錄	％的記錄	累計％
87.106.149.145	58	84.06	84.06
87.106.20.192	9	13.04	97.10
213.165.83.176	2	2.90	100.00

很明顯，PCAP數據中的三個主機可能潛在地涉及到這個懷疑的流量中。使用YAF和super_mediator簡要檢查有效載荷數據有助於證明這一點。這一通訊代表，另外一個主機經過安全套接字層/傳輸層安全性(ssl/tls)與潛在的惡意服務器通訊，除了編碼C2以外，還進行加密通訊。此外，查詢公開的WHOIS IP地址數據庫顯示，虛擬主機公司擁有這些數據，提供有關該主機基礎結構的詳細信息。

總而言之，以主機爲中心的方法使得有可能進行分析主元，這種分析只在經過使用惡意軟件和C2（能力要素）和單個外部主機（基礎設施）的低置信度狀況下才開始。它揭示了兩個附加的主機以及對手的能力的進一步信息，包括使用加密。

7.2.2.以端口爲中心的方法

咱們使用SiLK來識別可能正在嘗試監視或利用ICS設備和流量到通用ICS端口的外部主機（也就是不屬於蜜網的主機）。該過程開始於查看與端口20000通訊的頂級外部主機，總結在表4中。該端口主要用於DNP，這是SCADA網絡中使用的一種通用協議。如下SiLK查詢顯示了許多與此端口進行通訊的主機，主要是看起來是與掃描相關的活動。

表4：在端口20000上進行通訊的主機

源IP地址	SiLK 流記錄	％的記錄	累計％
66.240.192.138	12	3.592814	3.592814
71.6.135.131	12	3.592814	7.185629
80.82.70.198	12	3.592814	10.77844
62.75.207.109	12	3.592814	14.37126
71.6.165.200	12	3.592814	17.96407
8.8.8.8	10	2.994012	20.95808
198.20.69.98	9	2.694611	23.6527
41.74.182.170	9	2.694611	26.34731
94.102.49.210	8	2.39521	28.74252
60.209.5.30	8	2.39521	31.13773

來自表4中的主機的PCAP數據可能不是特別有用，由於它不包括有效負載數據或甚至TCP標誌的信息。經過使用以端口爲中心的方法，咱們可能會查詢其餘常見的ICS端口，開始構建更完整的針對蜜網的偵察活動。第二個SiLK查詢檢查端口102上的流量。可編程邏輯控制器（PLC）的主要品牌一般將該端口用於控制通訊。咱們交叉引用了與端口20000通訊的主機的輸出。

表4中存在的主機在表5中的IP地址旁邊顯示一個星號。

表5：在端口102上進行通訊的主機

源IP地址	SiLK 流記錄	％的記錄	累計％
188.138.1.218	32	6.299213	6.299213
80.82.70.198*	30	5.905512	12.20472
125.97.246.5	27	5.314961	17.51969
52.88.94.127	19	3.740157	21.25984
198.20.69.98*	16	3.149606	24.40945
94.102.49.210*	14	2.755906	27.16535
120.119.31.1	14	2.755906	29.92126
71.6.135.131*	13	2.559055	32.48032
131.107.13.100	13	2.559055	35.03937
66.240.192.138*	13	2.559055	37.59843

一樣，這種分析方法幫助咱們將可能具備較高的ICS意識的主機優先排序，並相應地提升潛在的威脅級別。好比第一個具備較多ICS端口的主機80.82.70.198，咱們利用SiLK工具將可能的ICS端口都進行了枚舉。其中一些端口具備ICS功能，包括表6中列出的幾乎全部端口，這些端口描述了外部主機所聯繫的已知的與ICS相關的端口。

表6：數據集中觀察到的常見ICS相關端口

TCP端口	設備或協議
102	Siemens PLC
502	Modbus protocol
1962	Phoenix Contact ILC PLC/ProConOS
2404	IEC 60870-5-104
2455	Wago I/O System
4592	Advantech/Broadwin
4840	Certec Atvise SCADA
9600	Omron PLC
10001	RS-485 to Ethernet
18245	GE PLC
20000	DNP (SCADA/ICS common protocol)
20547	ProConOS/MultiProg PLC
44818	Rockwell Automation Ethernet/IP
49320	Kepware KEPServerEX

主機80.82.70.198僅聯繫了19個端口，遠遠低於通用網絡映射器（Nmap）工具掃描的目標，該工具掃描一般掃描多達1000個端口。經過使用YAF和super_mediator檢查流量有效負載也顯示這些僅是TCP Synchronize（SYN）數據包，沒有進一步的通訊量，這是一種常常與端口掃描活動相關聯的技術。掃描的端口中有超過70％具備與ICS的關聯性，其餘可能與較不知名或有記錄的ICS協議有關。

外部主機80.82.70.198專一於這些端口，顯示出高度的ICS意識，有助於描述威脅行爲者的能力。然而，這個特定的主機彷佛並無惡意。它是一箇中國項目的一部分，「ICS/SCADA/PLC Protocol GlobalCensus,」，正在對通用ICS端口進行掃描。該項目已經對ICS設備進行了研究，包括與表6中列出的端口相關的一些設備。它容許組織經過電子郵件向研究團隊發送聲明，不對其進行掃描。

這個案例研究顯示了以端口爲中心的方法的好處。經過使用端口之間的已知關聯，分析主元顯示對ICS網絡的潛在新興威脅。分析人員能夠擴展和自動化此技術，以簡化ICS威脅的收集情報。

7.3. 使用蜜網數據來分組威脅行爲者

如今咱們已經列舉了在AGC中使用的整個功能空間和特徵向量，咱們能夠提供相關的威脅行爲者分組。這樣能夠以知足分析問題的方式在PCAP數據中提供快速，可操做的行爲者特徵。整體過程與本研究的目標一致，制定了基於鑽石模型對ICS網絡的威脅進行分類的完整方法。

7.3.1.主動威脅行爲者

咱們將活動的威脅行爲者定義爲實體，他們的行爲提供了一個高可信度的指示，代表他們正在積極地***網絡。這與專一於ICS無關，儘管在這個AG中，一個活躍的、以ICS爲中心的***是最嚴重的事件類型。在這一類別中，對手必須證實交付惡意軟件或創建C2通訊。

在數據中識別的活動威脅行爲者的一個例子是表7所示的對手(前面討論過)。它被懷疑在蜜網中創建了C2(全部主機的20%)。目前還不清楚這個行爲者的目標是什麼：其中的一些C2流量是通過加密的，而且沒有基於主機的數據可用。然而，這一流量的存在代表了對網絡的高度信任。

儘管這是生成可操做的威脅數據的最有用的組，但矛盾的是，咱們的事件最少。一個可能的解釋是可能缺少來自蜜罐機器的互動所致。正如第7.1節中提到的，蜜網並無與外部主機進行大量的交互。它也不接受任何端口上的TCP傳入鏈接請求。在這種狀況下，若是***者彷佛不多或沒有幾個端口在監聽鏈接，那麼從邏輯上來講，不多會有人對其進行***。在***者看來，這個服務上不存在該端口的任何服務監聽以及鏈接，也找不到任何防火牆存在的證據。

表7：選定的主動威脅行爲者

威脅行爲 ID	屬性	分組的理由	事件時間表
	IP {87.106.149.145, 87.106.20.192,	High confidence indication	12/16/2015 19:41 -
AT1	213.165.83.176}; Port {80, 443}; Domain {bkmail[.]blogdns[.]org} Malware; C2;	of malware C2 traffic	12/16/2015 20:08
	Proxy; Type 2 Infrastructure

7.3.2.高風險威脅行爲者

咱們可能會考慮到高風險行爲者的表現或懷疑對ICS網絡產生不利影響的能力。這多是因爲一些積極但不成功的嘗試企圖，這些嘗試既表現出對ICS的興趣，又或者對受害者的網絡工做很熟悉。彷佛發送普通***相關的流量的行爲者並不必定是高風險的威脅行爲者。無數的僵屍網絡和其餘惡意的主機都在不停地引誘那些沒有補丁的主機。這不能表明一個組織的高度風險，並適當地採起適當的基線安全措施。

偵察也能夠表明高水平的風險。表8中的主機的活動將把它放在高風險的類別中。這個主機(80.82.70.198)被認爲是在7.2.2節中提到的「ICS項目」的收集數據。雖然這個特定的主機彷佛與研究活動有關，但事件響應者應該優先考慮這樣的主機，以便進一步審查和分類。這種類型的網絡活動可能表明了實際***的早期階段。若是這種有針對性的端口掃描確實是惡意的，它會爲事件響應者提供有價值的情報，以對抗對手的能力和利益。

表8：選定的高風險威脅行爲者

威脅行爲 ID	屬性	分組的理由	事件時間表
	IP {80.82.70.198}; Port {[19 common ICS	Focused scanning of known	7/8/2015 05:19 -
HT1	ports]}; Domain {icsresearch[.]plcscan[.]org}; ICS; Port scan	ICS ports without clear mali- cious objective	2/17/2016 16:49

7.3.3.中等風險威脅行爲者

中等風險的行爲者構成了具備最低風險水平的AG，該風險保留了對網絡產生影響的潛力。這些行爲者沒有積極地嘗試利用網絡上的主機，而是從事偵察活動。因爲許多方面的因素，許多懷有各類目的而開展的掃盲活動激增，許多主機和其餘組織都屬於中度風險類別。

一組中等風險的行爲者是大量參與端口掃描活動的主機的一部分。因爲它們都傾向於從端口6000開始掃描活動，所以咱們能夠經過以端口爲中心的方法進行連接。子網和ASN還以主機爲基礎鏈接這些行爲者。這些組中的全部主機來自與中國相關的地址空間。當這並非說這些主機是來自中國的，由於這些主機的直接來源能夠很容易經過代理或虛擬主機的方式使用。這一關聯代表，至關多的流量在基礎設施和能力方面具備共同的從屬關係。

剩下的高風險行爲者都在進行自動化的嘗試，以利用衆所周知的漏洞。咱們只給這些行爲者分配了適度的風險，由於咱們相信他們不會對絕大多數企業構成重大威脅。補丁能夠普遍用於修復這些全部利用的漏洞，而且大多數安全解決方案能夠在網絡邊界上檢測和阻止這些漏洞。這三個角色(MT2、MT3和MT4在表10中)仍然值得一看，以瞭解他們活動的特徵。

MT2多是這個集合中最有趣的三個部分中的一個。這個組中的主機產生兩種不一樣類型的流量。第一個是明顯的利用有效負載，一個HTTP GET請求(請參閱表9以得到完整的請求)。開源研究並無指出這一流量的性質。一些安全博客和論壇推測，這是一種掃描或***Apache服務器的嘗試，儘管目前尚不清楚這是不是一種有效的***。咱們觀察了這些包的主人185.130.5.224。這個活動彷佛沒有對服務器產生影響，多是由於它運行的是Microsoft IIS，而不是Apache。

另外一種由這個主機產生的流量(以及其餘經過主機集中分析)產生的流量，最初相似於嘗試利用「Shellshock」漏洞(CVE-2014-6271等)。可是，彷佛這個漏洞利用字符串(見表9)實際上可能代表惡意軟件試圖破壞設備。如下字符串中的變體彷佛是Linux命令，在PCAP中出現了屢次。儘管包的有效負載相似於一個Shellshock的利用字符串，但它是不一樣的，由於它的目標是UDP端口53413，而不是TCP端口80或8080(端口最多見的端口是基於web的Shellshock***)。UDP 53413與任何已創建的服務沒有關聯。

然而，這與2014年披露的Netcore/Netis品牌路由器的漏洞有關，該漏洞能夠經過該端口( Yeh 2014)容許遠程shell訪問該設備。

表9：觀察到的MT2***嘗試

描述

利用字符串

未知的利用字符串，可能針對Apache服務器

GET /server- status?HTTP_POST=%」%6346#%#/&#736%」#423|;&HTTP_CGI

_GET=GRESYYK」K&J#L523D2G23H23 HTTP/1.1

可能的Netis/Netcore利用，在gafgy/bashlite惡意軟件中發現的字符串

busybox tftp –g –r m.sh 185.130.5.201|| tftp –g –r m.sh 185.130.5.201; busybox chmod +x m.sh

考慮到這個路由器漏洞，咱們在公開分析了一個名爲「Bashlite」或「Gafgyt」（VirusTotal 2016）的惡意軟件家族附屬的惡意軟件樣本以前，咱們發現了這個字符串。 Avast的研究人員將此惡意軟件與由Lizard Squad威脅行爲者（Kalnai和Horejsi 2015）發起的分佈式拒絕服務（DDoS）***相關聯。這項研究和安全記者Brian Krebs的分析代表，該組織開發了一款惡意軟件，經過利用家庭路由器（Krebs 2015）的已知漏洞來傳播。它從這些設備中建立了一個僵屍網絡，而後被用來運行一個非法的在線服務，爲僱傭者進行DDoS***（Kalnai和Horejsi 2015）。根據這個惡意軟件家族（Malwr Posts 2015）的開源列表，咱們搜索了CERT /協調中心（CERT / CC）的工做目錄來匹配樣本；並發現9個相似樣本。咱們在其中8個樣本中遇到了Busybox命令，而且在4個樣本中遇到了與PCAP中發現的字符串幾乎相同的字符串，從而增長了所觀察到的流量與Bashlite或Gafgyt有關的信心。

這一組中的另外兩個威脅行爲者正在試圖利用流行的技術來利用已知的漏洞。第一名威脅行爲者MT3發送了試圖利用CVE-2013-5122的流量特徵。這是Linksys路由器的遠程管理界面中的一個漏洞，這種漏洞有助於稱之爲「TheMoon」的蠕蟲病毒的傳播。鑑於此流量是企圖泄漏Linksys漏洞的一個簡單過程。流量有效載荷包含頁面tmUnblock.cgi的HTTP POST請求，這與此漏洞密切相關。AG MT4包含試圖利用舊版PHP中的幾個相關漏洞的主機，容許任意代碼執行。其次，利用字符串包含HTTP POST請求，這些請求是利用漏洞的嘗試的特徵。

在蜜網操做的環境中，建議識別這些主機以供進一步調查。若是將其視爲僅僅是網絡的常規掃描的一部分，這不太可能構成進一步的威脅，實施阻止這些流量的主機防火牆規則將提升數據集中的信噪比。可是，只有分析人員瞭解了這些主機對於數據集的影響深度和程度，纔會考慮刪除這些主機。

表10：選定的中等風險威脅行爲者

威脅行爲 ID	屬性	分組的理由	事件時間表
MT1	IP {[Numerous China-based IP ad- dresses]}; Port {TCP 6000 (source), [Nu- merous common destination ports]}; Port scan IP {185.130.5.224, 185.130.5.201, 46.28.207.30}; Port {TCP 80, UDP 53413};	Extensive scanning of com- mon TCP ports Automated scanning / ex- ploitation attempt targeting	7/8/2015 05:19 –2/17/2016 16:49
MT2	Exploit; Malware IP {69.164.231.228, 77.70.58.205}; Port	Apache Web servers; possi- ble attempted exploitation of ‘Shellshock’ vulnerability (CVE-2014-6271 etc.) Automated attempts to ex	12/23/2015 23:07– 2/22/2016 05:34
MT3	{80}; Port scan; Exploit	ploit TheMoon vulnerability (CVE-2013-5122) in Linksys devices	11/22/2015 17:13– 12/18/2015 19:07
MT4	IP {117.21.226.160, 119.235.66.243}; Port {TCP 23, 80, 8081}; Port scan; Exploit	Automated attempts to ex- ploit CVE-2012-1823/CVE-2012-2311/CVE-2012-2336 in PHP	7/9/2015 03:01 –10/3/2015 12:28

5.3.4.未知風險的威脅行爲者/異常值

正在考慮的最後一組事件並不直接構成一個AG。取而代之的是，它包含了全部其餘組以外的數據集：異常值。咱們須要瞭解如何解決威脅潛力的一組異常值。在一組異常值中，許多事件極可能是非惡意的。在PCAP數據中觀察到的大量流量鏈接到用於軟件更新，標準DNS查詢和WHOIS查找。可是這種傳播可能與惡意活動相對應，所以，咱們不該該單獨在這種狀況下捨棄它。然而，對這一流量的評估強烈地代表，它並不表明威脅。

與異常值組區別的是另外一大組事件，被稱爲「未知風險」流量。因爲缺乏給定主機、端口或應用程序的事件數據，或者由於不可能將特定事件可靠地連接到數據集中的其餘人，所以該數據主要屬於此類別。將這些數據視爲無用或將其分類爲確定是非惡意的是不明智的。當更多的信息可用時，從新訪問數據集是很重要的。所觀察到的流量事件的重大變化可能會嚴重影響支撐AGC功能的假設。Caltagirone及其同事建議按期審查數據和更新功能，以保持信息的最新和可行性（Caltagirone，Pendergast和Betz 2013）。對於蜜網數據，這固然是一個審慎的建議。。

VIII 討論

8.1. ICS的具體威脅

蜜網爲咱們提供了一個豐富的數據集供咱們參考研究。這些數據爲咱們提供了一個機會來查看與成千上萬的外部主機交換的超過16 GB的流量的各類不一樣的活動。因爲這一努力的重點是對ICS的威脅的列舉和描述，所以值得討論這些威脅是如何在被分析的數據中體現出來的。值得注意的是，雖然數據顯示了各類惡意流量，可是幾乎沒有觀察到ICS特有的威脅。絕大多數流量是通用掃描一些最經常使用的端口，如Telnet、安全Shell（SSH）、虛擬網絡計算（VNC）、服務器消息塊（SMB）和其餘協議。雖然這與ICS網絡防護相關，但它並無必要顯示ICS特定的威脅。

分析主元和AG建立揭示了對ICS的潛在威脅。檢查通用ICS端口上交換的流量以及參與以ICS爲中心的掃描活動的主機是有幫助的。雖然掃描活動能夠代表威脅潛力，但它最終會在必定程度上暴露出對手的能力。PCAP對於與ICS設備進行交互，利用漏洞或安裝惡意軟件的特定嘗試，包含的數據不多。一個可能的解釋是對手不會直接從互聯網泄露ICS設備。大多數ICS***活動遵循兩階段的方法（Assante和Lee 2015）。這致使了第二種可能性：因爲蜜網的配置交互性，沒有吸引對ICS更深層次的***。

8.2. 配置ICS-蜜網的挑戰

這樣的配置對其低資源的優點是有利的，同時也下降了拒絕***者的機會，即便是這個孤立的網絡也有機會妥協。然而，爲了這些好處所作的權衡是，低交互的蜜網一般提供稀疏的***數據。他們不太可能捕捉到「零日」或其餘高價值信息(Holz和Holz 2008)的證據。

鑑於缺少以ICS爲重點的監控，特別是在PCAP數據中觀察到的***，彷佛沒有優化蜜網來收集這種類型的數據。如上所述，分析流量顯示了幾個重要的細節，主要是一些主機彷佛是標準的Windows或Linux機器，沒有明顯的ICS目的。有些具備未知配置詳細信息的主機可能正在仿真ICS設備。然而，數據集中沒有足夠的證據支持這一觀點。根據在數據集中觀察到的主機的配置和行爲，看起來這個蜜網是一個「低交互」蜜罐。也就是說，蜜罐機器對外部主機的請求提供不多甚至沒有任何響應，所以對手一般不會危及主機。 Provos和Holz觀察到，這樣的配置對其低資源的優點是有利的，同時也下降了拒絕***者的機會。然而，爲了這些好處而作出的權衡是低交互性蜜罐一般提供較少的***數據。他們不太可能得到零日漏洞或其餘高價值信息（Provos和Holz 2008）。

雖然證據支持這一觀點認爲這是一種低交互的蜜網，但並不意味着它不會產生關於ICS***的可行信息。咱們突出強調以ICS爲中心的網絡掃描和明顯的惡意軟件C2的證據，代表PCAP文件中存在各類有用的威脅數據。然而，彷佛不多有關於ICS防護的新信息能夠從蜜網中得到。系統的低交互特性可能致使掃描和枚舉工具報告這不是ICS網絡。此外，對開源掃描工具的源代碼進行粗略的檢查代表，這些工具但願來自主機的很是具體的響應，以確認它是否涉及有問題的設備。這可能會阻止外部行爲者進一步採起行動，並進一步可能的試圖破壞ICS設備嘗試。

8.3. 防護ICS網絡的意義

這種蜜網的配置在ICS威脅上產生了相對較少的有用情報。一個有效的ICS蜜網應該採用技術來講服潛在的對手，它真正地託管了ICS設備。這可能須要與咱們在PCAP數據中觀察到的與外部主機的更高級別的交互。也極可能是爲了有效，一個ICS的蜜網必須忠實地模擬實際的ICS設備和協議。一個被動的主機能夠收集關於掃描和自動***的信息，但這並不能提供豐富的特定於ICS的威脅情報。另外一種選擇是將實際的ICS設備放置在蜜網內，這多是收集真實***數據的最大機率。任何一種選擇均可能產生有用的信息。而仿真大大增長了配置和維護蜜網的複雜性，而使用真正的ICS設備可能會比無源或仿真設置帶來顯着更高的成本。然而，這可能反映了使用蜜網固有的困難，這是一種被證明的網絡威脅技術。鑑於這種限制，防護者可能但願權衡在得到的數據價值和維護一個有效的ICS蜜網的複雜性中間進行取捨。

IX 將來工做

考慮到使用蜜網來防護ICS和鑽石模型在生成威脅情報方面的應用，爲咱們提供了許多有趣的將來研究方向。本研究以後的一個天然問題是咱們的模型是否能夠應用於由實際或仿真的ICS設備組成的高互動性蜜罐中生成數據。若是這產生了關於***模式，開發技術和惡意軟件的附加信息，咱們能夠用更多信息和更高的置信度來填充咱們模型中的數據元組。這又可用於建立經過特定***技術，共享基礎架構和其餘功能連接的AG。進一步調查的另外一種可能性將是從PCAP數據中產生ICS威脅指標。這將須要更多的信息，用於對手試圖***ICS網絡的戰術，技術和程序。可能從上述高度互動蜜罐獲取這些數據。這樣一個項目對於它可能產生的至關大的威脅情報將是有價值的。

X 結論

這項研究探討了一個蜜網能對ICS網絡產生威脅情報的方法。利用提供的16 GB PCAP數據以及各類開源數據，咱們應用了***分析的鑽石模型，試圖理解和推測一個假設的ICS網絡的威脅。諸如WHOIS數據庫、VirusTotal和來自安全廠商的資源等來源幫助咱們創建了一個瞭解觀察到的流量的重要性的環境。有了這些信息，咱們派生了數據元組，這些元組充分地描述了在數據中觀察到的事件，並將其置於一個恰當地表示其威脅的AG中。

雖然咱們開發了一種利用鑽石模型對ICS蜜網進行威脅分析的方法，但咱們發現該領域的特殊性質爲成功提供收集數據的特定要求提出挑戰。最主要的是缺少與外部主機的互動，從而限制了收集到的數據的潛在有用性，特別是在利用漏洞和惡意軟件交付方面。在將來的蜜網部署中，咱們認爲，與外部主機進行更高層次的互動和ICS設備的高保真仿真（若是不是在隔離網絡上實際控制系統的直接放置）將是有用的。

咱們但願這項研究提供了一個有用的方法來分析從ICS蜜罐收集的數據，以及如何收集這些數據的方式，使其成爲威脅情報來源最有用的方式。雖然適當部署所固有的困難可能會下降ICS蜜網在某些狀況下的價值主張，可是那些對ICS威脅信息有很高需求的組織極可能會發現咱們的技術是有用的。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。