卡耐基梅隆根據美國能源部部署的蜜罐系統，通過鑽石威脅模型對蜜罐數據進行了分析以及對手能力評估。文中從數據來源、工具、模型、方法等方面對於蜜罐數據分析進行了全面的闡述，最後對plcscan.org定義爲HT1級別。
目錄
3.5. Palo Alto Networks的威脅情報報告... 7
蜜網(Honeynets)是一種誘捕網絡，利用多個蜜罐通過網絡連接在一起模擬一個看似易受***的計算機網絡，利用其中一部分主機吸引******，另一部分主機部署監控系統，通過監測、觀察***過程，一方面調查***者的來源，另一方面考察用於防護的安全措施是否有效。是一種用在各種網絡環境中收集威脅情報的技術。因此，組織【注：指美國能源部】已經開始使用這種方法來保護網絡化的工業控制系統（ICS）。希望通過該環境觀察到企圖破壞他們工業系統的***活動和路徑，從而對真實的生產網絡部署相對應的緩解方案以加強工業網絡安全，並防止新出現的威脅活動。
該報告提供了一種分析方法，利用這種方法將從ICS蜜網系統中收集捕獲的大約16GB字節的完整數據包進行分析以瞭解***的活動和路徑。這些數據是在其他公開來源的背景下進行分析的，這些信息是已知的對ICS的威脅，以瞭解對手是如何與網絡進行交互的以及他們嘗試過的***類型。爲了提供更嚴謹的方法來描述這些威脅行爲，該研究採用了著名的***分析鑽石模型。她應用這個模型來定義和分類在數據中觀察到的幾個潛在的威脅行爲者。該研究還評估了蜜網作爲一種ICS威脅情報工具的有效性。此外，該報告還包含幾個關於部署的建議，並強調主動與外部主機進行交互可以產生更高質量的研究數據。
保護工業控制系統（ICS）對於保護關鍵基礎設施至關重要。考慮到在網絡安全漏洞事件中發生物理影響的可能性很高，“ICS網絡”的捍衛者必須瞭解他們的對手和這些行爲者的能力。此外，由於許多組織採用這些工業系統的規模，在部署有效的威脅情報和安全監測時，優先考慮的一個主要問題是感知威脅。支持這一使命的寶貴工具是蜜網，這是一個沙盒式網絡，表面上看起來很脆弱，但實質上是利用蜜罐主機模擬工業網絡上的生產機器。通過對蜜網系統的正確配置，其可以觀察到針對特定環境的高度特定的***活動，比如針對工業環境中的工業網絡威脅，這些可能的威脅被蜜網系統捕獲併產生可以對網絡維護者或安全研究者有價值的數據。但是，這些系統提供的數據量可能非常大，令人生畏，並且在這些數據中提取或生成可操作的有價值的信息變得十分困難。
這個研究分析了一個來自ICS蜜網的非保密數據，試圖從數據中生成有用的威脅情報和優先級。我們應用了Caltagirone，Pendergast和Betz（Caltagirone，Pendergast和Betz 2013）首先描述的***分析鑽石模型。該模型允許我們根據多個維度來描述事件，每個維度都有潛在的數據點。在這樣分析過程中，我們有可能發現看似不相關的數據元素之間的關係，從而更好地瞭解組織的威脅概況，並提供基於這些情報驅動的防禦。
這個研究的主要數據集是一個完整的網絡數據包捕獲(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.1.活動記錄不完整
蜜網和外部主機之間的網絡交互是一個非常有用的來源，但是用於此分析的PCAP數據有時缺乏上下文。利用這類型的完整數據包有助於在流量中觀察到的某些活動以進行更深入的理解。例如，當觀察到受***的惡意軟件命令和控制(C2)流量時，沒有和外部的網絡交互包不可能觀察到初始的協商流量。通過對基於外部交互流量的分析，在第一個PCAP接收到的時間，或者在一個加密的連接上最初的協商發生時間，我們就可以觀察到這樣的初始協商流量。但是作爲從一個較大的正在進行的項目中選擇的數據，它缺少了所述的流量上下文。也許對基於主機的數據包的分析可能會解釋這一點，但是這超出了本報告的範圍。總的來說，本次分析的數據集相當豐富，爲分析提供了足夠的流量。
3.2.2.缺乏蜜網配置數據
儘管已經提供了一些關於蜜網的基本細節，並且其他的一些基本上可以通過從包有效載荷的數據中推斷出來(見第7.1節)，但本研究把蜜網本身視爲一個黑匣子。主機的配置是不明顯的，也不可能可靠地確定他們是如何監聽或響應網絡流量的。這反過來又使對對手***鏈的理解變得更加複雜，因爲蜜網可能不會以某種方式迴應對手探測，從而促使進一步的網絡偵察或監視。這在所有類型的蜜網操作中都是一個常見的技術難題，不限於本次研究的這個特定例子。儘管在這個數據集中，效果是非常明顯的。
一個相關的特定於ICS的問題是，很難確定網絡試圖仿效哪些設備（如果有的話）。雖然這個PCAP數據來源於一個明確的基於ICS的蜜網系統，但沒有其他具體的配置細節可用。這對使用鑽石模型來分析***事件提出了挑戰，因爲這個框架使用受害者的數據作爲分析的一個組成部分。 然而，從PCAP數據得出的信息使我們能夠對受害者作出某些假設，儘管信心較低。
3.2.3.需要手動分析某些數據
由於這項研究尋求對ICS的新興威脅，因此很難將數據分析中的許多步驟自動化。Caltagirone及其同事指出，這可能是鑽石模型的一個侷限性，因爲沒有現成的方法來自動分析每一種情況（Caltagirone，Pendergast和Betz 2013）。ICS防禦是一個新興領域，需要對許多專有或專門的協議進行分析；很少有自動化工具能夠滿足本研究的目標。因此，這項研究包括了手動數據分析，特別是在檢查包有效載荷時。儘管有可能針對協議的特徵開發出專門的簽名，並以此進行自動的有效負載分析，但是在這種簽名被開發出來之前，它通常不是一個選項。即使有這種可能性，自動化分析的價值也很有限，因爲負載、流量類型和數據來源的主機的具有相當多樣性。最好的方法是結合手工分析和自動化分析的方式，雖然我們可能會從手工分析中得出有用的結論，但合併更多的自動化可能有助於我們發現孤立的數據或微妙的模式，這些模式對研究是有價值的。
在識別蜜網數據中存在的主機時，我們查詢了各種WHOIS和DNS數據庫。這些公開的信息收集將主機名與IP地址相關聯，並標識出與該地址空間和域名相關的組織。最終維護這些信息的組織是ARIN和RIPE等區域互聯網註冊管理機構; 我們採用了在線工具來彙總來自各種開放數據庫的信息，包括RobTex和DomainTools等服務。這些服務還爲各種DNS數據庫，自主系統編號（ASN）和許多主機的黑名單信息提供交叉引用。
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）。
各種公開可用的文檔爲PCAP數據提供了上下文和分析。這些文件包括安全供應商和研究人員的報告，這些報告包含了惡意軟件家族、威脅行爲者以及所涉及的C2領域的信息，這些領域促進了對某些網絡工作流量的分析。供應商文檔和通過互聯網研究獲得的其他公開數據提供了關於應用程序和設備的默認配置的基本信息(比如ICS設備使用的默認端口)。
許多工具有助於快速分析和描述這個大數據集的成員。分析主要發生在Linux環境中，由大量用於網絡流量分析的開源工具支持。使用開源數據庫進行的研究完善了這些工具生成的工件。這種分析和研究提供了所必需的信息，用以創建使用鑽石模型進行分析所需的數據元組。
各種GNU核心實用程序（如grep，cut和cat）在處理大量的網絡流量數據方面都很有用。 由於PCAP數據作爲單獨的文件分發，因此使用這些工具特別有助於對這些文件中的許多或所有文件進行整體分析。
“SiLK”是一套用於分析網絡流量的工具，由卡內基梅隆軟件工程學院(軟件工程研究所)的CERT部門開發的。在整個研究過程中，我們使用了各種各樣的SiLK工具。SiLK可以查詢大量的網絡流量數據，並瞭解外部主機與蜜網相互作用的總體情況，特別是在時間、服務、協議和端口方面。反過來，這個分析也幫助在鑽石模型的上下文中對主機和事件進行了描述。在這項研究中最常用的SiLK工具包括：rwfilter、rwstats和rwsetbuild。我們使用了rwp2yaf2silk工具來從PCAP數據中生成流記錄。
另一個由CERT部門開發的工具super_mediator使我們能夠按比例處理來自PCAP文件的有效負載數據。我們使用super_mediator與YAF組合，通過嚮應用程序提供Berkeley包過濾器（BPF）規則來提取特定的有效負載數據。該技術作爲圖形協議分析器（如Wireshark）的替代方案，用於流量的應用層分析（Software Engineering Institute 2016）。
我們使用GNU Bash中實現的shell腳本自動分析了我們數據集的一些部分。例如將批量的PCAP轉換爲流記錄，從流記錄中提取事件元組，組織數據集，以及一次從數據集解析或轉換多個項目。
***分析的鑽石模型提供了一種正式和標準的方式來描述網絡***（Caltagirone，Pendergast和Betz 2013）。鑽石模型得名於它用來描述***事件的基本數據結構：對手、能力、基礎設施和受害者的四個連接特性圖，如圖1所示。每個元素本身都是各種數據點的元組，可以根據正在進行的特定分析進行定製。一般來說，元組包括組織/行爲者（如果已經知道）、IP地址、應用程序、源/目標端口等相關元素（Caltagirone，Pendergast和Betz 2013）。至關重要的是，每個元素形成一個具有置信水平的有序對，這有助於使用該模型來開發分析產品。此外，一個活動還包括開始和結束時間、階段、結果、方向、方法和資源等元功能（Caltagirone，Pendergast和Betz 2013）。爲了理解PCAP數據，我們創建了一些事件（包括其必要的子組件）來描述和關聯潛在威脅行爲者的活動。***分析的鑽石模型對元組的使用補充了SiLK使用五元組來捕獲網絡流元數據，在生成事件數據時促進了這些信息的集成。
圖1：鑽石模型事件（Caltagirone，Pendergast和Betz 2013）
該模型的架構師將分析主元描述爲一個過程，它允許分析師通過將四種主要元組中的數據與其他情報來源(Caltagirone、Caltagirone和Caltagirone 2013年)的數據結合起來，從而獲得丟失的信息。分析主元是這項研究的中心：它使我們能夠收集蜜網所揭示的威脅的細節，使之成爲可用的信息。在許多情況下，除了一個數據元組在一個事件中是很明顯的，也會有存在數據不完整的情況發生。爲了獲得丟失的信息，我們使用在看似完全不同的事件中共享數據並以此進行推論。
我們使用了6.3節中描述的兩個方法來枚舉和連接這些數據。
鑽石模型架構師將活動組(AG)描述爲“由特徵或過程中的相似性相關的鑽石事件和活動線索以及信任加權”(Caltagirone、Betz和Caltagirone2013)。從本質上說，AG是一種將許多事件聯繫起來的方法，以便掌握明顯相關的活動的含義，並通過對潛在的威脅行爲者的完全理解來發展有效的防禦。特別是在考慮這麼大的數據集時，有一個快速關聯事件的方法是很重要的。通過使用突出的特徵來形成一個潛在的威脅行爲者的整體特徵，對分析的支持進行補充。這個過程也使得有可能建立有針對性的、健壯的網絡防禦系統。
我們的研究並不試圖提供威脅歸因，僅僅是對與ICS網絡防禦相關的可觀察活動的描述。此外，我們缺乏將PCAP數據中的技術指標與特定的個人或組織聯繫在一起的證據。雖然在創建AG時可能會有一些事件，但事件本身完全缺乏新的數據來繼續支撐並推演下去。Caltagirone及其同事指出，這種缺乏數據的情況是大多數鑽石模型分析的可能情況。
表1列出了本研究中使用的變量及其描述。
表1：鑽石模型變量
變量 | 描述 |
Adv | 對手：參與事件的可疑威脅行爲者 |
AGC | 活動組創建功能 |
AGS | 事件空間中所有活動組的集合 |
Cx | 特徵x的置信度，用作加權因子 |
Cap | 能力：對手使用的工具，技術和程序 |
E | 事件：由對手，能力，基礎設施和受害者定義的向量 |
ET | 在數據中設置所有事件和事件線程 |
FVPR | 滿足分析問題（PR）的特徵向量 |
Inf | 基礎設施:用於支持對手的虛擬和物理資源 |
PR | 分析問題 |
Vic | 受害者:在某一事件中被對手***的組織或個人 |
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數據獲得。
在爲我們的鑽石模型應用程序定義事件元組之後，我們提取有用的事件數據，並嘗試通過分析主元來查找相關的特徵。分析主元的最終目標是創建用於威脅優先級的AG。儘管分析人員通常可以自由地定義事件元組，但是很難確定哪些事件可能與一個事件相關聯。爲了簡化這些工作，我們選擇了兩種主要的方法來識別可操作的事件數據。以主機爲中心的方法從一個已知的主機（或一組主機）開始，該主機（或一組主機）被認爲具有相關性並且在第3層數據中尋找關聯，例如IP地址和主機名。以端口爲中心的方法圍繞第4層數據（主要是目標TCP和UDP端口組），以瞭解某些監視和利用活動的目標。這兩種技術的例子都在第7.2節中提供。
6.3.1.主機爲中心的方法
以主機爲中心的分析主元方法主要通過檢查流量模式或特徵來尋找外部主機之間的關係。它可能產生相當大的數據，特別是在能力和基礎設施方面。以主機爲中心的方法通常要求有效載荷數據是有效的，因爲它依賴於發送和接收數據之間的關係。儘管如此，它是分析主元的更有效的方法之一。它有助於通過其活動來對主機進行歸類，並提供主機之間更高可信度的關聯，而不是通過通用基礎設施（其中許多行爲者，惡意軟件和其他方式可能共享）進行交互。鑽石模型允許我們協同使用這些特徵來發現額外的威脅行爲者。
6.3.2.以端口爲中心的方法
當我們缺乏足夠的信息來進行以主機爲中心的分析主元時，我們可以利用端口之間的關係作爲起點。這對於ICS網絡特別有用，ICS的通信設備通常包含在專用端口上，而這些設備使用的端口很少被其他服務使用。因此，以端口爲中心的方法可以幫助我們瞭解對手的能力，特別是其ICS意識水平。
我們的研究的基本目標是定義一系列的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。 這些未分組的事件被認爲是異常值。 這個數據集中的大多數事件都屬於這個範例，因爲絕大多數的外部主機只向蜜網機器發送了幾個數據包，與其他行爲者沒有明顯的關係。由於缺乏數據，很難以任何有意義的方式對這些主機進行分類。
我們沒有蜜網的配置詳細信息。相反，我們從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) |
正如前面所討論的，我們在分析中合併了分析主元，作爲一種關聯可變的事件數據項的方法，這些數據項在初次檢查時可能不會出現。通過提供用於確定特徵向量的高質量數據，從而促進了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威脅的收集情報。
現在我們已經列舉了在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#%#/ˠ%”#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）。對於蜜網數據，這當然是一個審慎的建議。。
蜜網爲我們提供了一個豐富的數據集供我們參考研究。這些數據爲我們提供了一個機會來查看與成千上萬的外部主機交換的超過16 GB的流量的各種不同的活動。由於這一努力的重點是對ICS的威脅的列舉和描述，因此值得討論這些威脅是如何在被分析的數據中體現出來的。值得注意的是，雖然數據顯示了各種惡意流量，但是幾乎沒有觀察到ICS特有的威脅。絕大多數流量是通用掃描一些最常用的端口，如Telnet、安全Shell（SSH）、虛擬網絡計算（VNC）、服務器消息塊（SMB）和其他協議。雖然這與ICS網絡防禦相關，但它並沒有必要顯示ICS特定的威脅。
分析主元和AG創建揭示了對ICS的潛在威脅。檢查通用ICS端口上交換的流量以及參與以ICS爲中心的掃描活動的主機是有幫助的。雖然掃描活動可以表明威脅潛力，但它最終會在一定程度上暴露出對手的能力。PCAP對於與ICS設備進行交互，利用漏洞或安裝惡意軟件的特定嘗試，包含的數據很少。一個可能的解釋是對手不會直接從互聯網泄露ICS設備。大多數ICS***活動遵循兩階段的方法（Assante和Lee 2015）。這導致了第二種可能性：由於蜜網的配置交互性，沒有吸引對ICS更深層次的***。
這樣的配置對其低資源的優勢是有利的，同時也降低了拒絕***者的機會，即使是這個孤立的網絡也有機會妥協。然而，爲了這些好處所做的權衡是，低交互的蜜網通常提供稀疏的***數據。他們不太可能捕捉到“零日”或其他高價值信息(Holz和Holz 2008)的證據。
鑑於缺乏以ICS爲重點的監控，特別是在PCAP數據中觀察到的***，似乎沒有優化蜜網來收集這種類型的數據。如上所述，分析流量顯示了幾個重要的細節，主要是一些主機似乎是標準的Windows或Linux機器，沒有明顯的ICS目的。有些具有未知配置詳細信息的主機可能正在仿真ICS設備。然而，數據集中沒有足夠的證據支持這一觀點。根據在數據集中觀察到的主機的配置和行爲，看起來這個蜜網是一個“低交互”蜜罐。也就是說，蜜罐機器對外部主機的請求提供很少甚至沒有任何響應，因此對手通常不會危及主機。 Provos和Holz觀察到，這樣的配置對其低資源的優勢是有利的，同時也降低了拒絕***者的機會。然而，爲了這些好處而做出的權衡是低交互性蜜罐通常提供較少的***數據。他們不太可能獲得零日漏洞或其他高價值信息（Provos和Holz 2008）。
雖然證據支持這一觀點認爲這是一種低交互的蜜網，但並不意味着它不會產生關於ICS***的可行信息。我們突出強調以ICS爲中心的網絡掃描和明顯的惡意軟件C2的證據，表明PCAP文件中存在各種有用的威脅數據。然而，似乎很少有關於ICS防禦的新信息可以從蜜網中獲得。系統的低交互特性可能導致掃描和枚舉工具報告這不是ICS網絡。此外，對開源掃描工具的源代碼進行粗略的檢查表明，這些工具希望來自主機的非常具體的響應，以確認它是否涉及有問題的設備。這可能會阻止外部行爲者進一步採取行動，並進一步可能的試圖破壞ICS設備嘗試。
這種蜜網的配置在ICS威脅上產生了相對較少的有用情報。一個有效的ICS蜜網應該採用技術來說服潛在的對手，它真正地託管了ICS設備。這可能需要與我們在PCAP數據中觀察到的與外部主機的更高級別的交互。也很可能是爲了有效，一個ICS的蜜網必須忠實地模擬實際的ICS設備和協議。一個被動的主機可以收集關於掃描和自動***的信息，但這並不能提供豐富的特定於ICS的威脅情報。另一種選擇是將實際的ICS設備放置在蜜網內，這可能是收集真實***數據的最大概率。任何一種選擇都可能產生有用的信息。而仿真大大增加了配置和維護蜜網的複雜性，而使用真正的ICS設備可能會比無源或仿真設置帶來顯着更高的成本。然而，這可能反映了使用蜜網固有的困難，這是一種被證實的網絡威脅技術。鑑於這種限制，防禦者可能希望權衡在獲得的數據價值和維護一個有效的ICS蜜網的複雜性中間進行取捨。
考慮到使用蜜網來防禦ICS和鑽石模型在生成威脅情報方面的應用，爲我們提供了許多有趣的未來研究方向。本研究之後的一個自然問題是我們的模型是否可以應用於由實際或仿真的ICS設備組成的高互動性蜜罐中生成數據。如果這產生了關於***模式，開發技術和惡意軟件的附加信息，我們可以用更多信息和更高的置信度來填充我們模型中的數據元組。這又可用於創建通過特定***技術，共享基礎架構和其他功能鏈接的AG。進一步調查的另一種可能性將是從PCAP數據中產生ICS威脅指標。這將需要更多的信息，用於對手試圖***ICS網絡的戰術，技術和程序。可能從上述高度互動蜜罐獲取這些數據。這樣一個項目對於它可能產生的相當大的威脅情報將是有價值的。
這項研究探討了一個蜜網能對ICS網絡產生威脅情報的方法。利用提供的16 GB PCAP數據以及各種開源數據，我們應用了***分析的鑽石模型，試圖理解和推測一個假設的ICS網絡的威脅。諸如WHOIS數據庫、VirusTotal和來自安全廠商的資源等來源幫助我們建立了一個瞭解觀察到的流量的重要性的環境。有了這些信息，我們派生了數據元組，這些元組充分地描述了在數據中觀察到的事件，並將其置於一個恰當地表示其威脅的AG中。
雖然我們開發了一種利用鑽石模型對ICS蜜網進行威脅分析的方法，但我們發現該領域的特殊性質爲成功提供收集數據的特定要求提出挑戰。最主要的是缺乏與外部主機的互動，從而限制了收集到的數據的潛在有用性，特別是在利用漏洞和惡意軟件交付方面。在未來的蜜網部署中，我們認爲，與外部主機進行更高層次的互動和ICS設備的高保真仿真（如果不是在隔離網絡上實際控制系統的直接放置）將是有用的。
我們希望這項研究提供了一個有用的方法來分析從ICS蜜罐收集的數據，以及如何收集這些數據的方式，使其成爲威脅情報來源最有用的方式。雖然適當部署所固有的困難可能會降低ICS蜜網在某些情況下的價值主張，但是那些對ICS威脅信息有很高需求的組織很可能會發現我們的技術是有用的。