來源：《Machine Learning for Encrypted Malware Traffic Classification：Accounting for Noisy Labels and Non-Stationarity》KDD 2017 Applied Data Science Paper， KDD’17, August 13–17, 2017, Halifax, NS, Canada
1介紹
通過被動地監控網絡流量來發現威脅在部署的易用性方面有很多優勢，在工業和學術文獻中都有研究[32,35]。除了被動的監視需求之外，還需要準確地識別基于會話級別的惡意網絡流量，因為它允許網絡設備(比如路由器和交換機)有效地執行網絡策略。為了使潛在的解決方案更加復雜，使用加密的網絡流量的百分比一直在快速增長，而且，正如預期的那樣，惡意軟件作者也利用這種趨勢來規避基于簽名的檢測。使用中間人對交通進行解密，然后利用傳統技術來檢測威脅并不理想，這是由于隱私問題，而且由于法律和技術原因，這并不總是可行的。
考慮到以上的約束條件，在加密的網絡會話的元數據上進行機器學習是一種自然的解決方案。雖然不直接用于檢測加密交通中的威脅，但這一機器學習和網絡元數據的基本公式已經得到了充分的研究[6,24,31]。不幸的是，這些解決方案在現實世界的威脅檢測中作為可行的方法已經變得非常緩慢，一些批評家已經正確地質疑了機器學習在這個問題領域的適用性[25,37]。
在對新的威脅上仍然保持著很高的正確識別率同時，保持適當的誤識率，一直是困難的。在本文中，我們重點介紹了這一情況的兩個主要原因:網絡數據中不準確的實際情況和非平穩性。最直接的方法是使用一個沙箱環境來運行惡意軟件，并收集樣本的相關數據包捕獲文件，以獲取有正標記的惡意數據，并監控網絡，并收集所有負標記的、無害的數據的連接。對于良性的情況，即使使用IP黑名單過濾數據集[13]，通常會有不可忽略的網絡流量百分比，這將被認為是可疑的。對于惡意的案例，惡意軟件樣本經常執行連通性檢查，或其他固有的良性活動。要識別所有這些情況幾乎是不可能的，在使用監督學習時必須考慮到這一點。
影響分類精度的第二個因素是網絡數據的非平穩特性。在用戶層面上，網站和服務的受歡迎程度經常發生變化。例如，將云托管存儲從box.com轉移到google.com/drive/將對所觀察到的加密傳輸模式產生影響。在網絡和協議級別上，當新協議如TLS 1.3[34]或HTTP/2[3]發布時，可以引入變更點。這些修改可以明顯地影響握手和應用層消息的結構，影響用于分類的數據特性。
我們設計并進行了實驗，測試六種常見的算法在面對不準確的真實情況和在網絡安全域中演進的數據流時的表現。我們發現，一些算法更容易受到加密網絡流量分類的挑戰。例如，我們展示了邏輯回歸的性能隨著時間的變化是不穩定的，而標準的支持向量機在網絡流量和損壞的標簽的情況下表現不佳。
除了研究幾種算法之外，我們還提供了一個用于此問題的標準特性集與自定義特性集之間的比較，該特性集是在領域專家的幫助下開發的。對可用特征的迭代經常被忽略，但典型地提供最顯著的性能提高[19]。進一步遵循這一思路，我們發現修改數據收集過程來生成專家指導的、更具表達性的特性集對測試的所有分類器的性能都有顯著影響。例如，使用更具表達性的特性集的線性回歸在我們所考慮的所有標準上使用標準網絡連接表示[39]的情況下，很容易勝過隨機森林方法。總的來說，對數據的深入理解和對數據生成過程的迭代是非常有價值的。
另外值得注意的是，額外的數據特性可以減輕一些關于精確地真相標簽的負擔。惡意軟件通常通過訪問一個標準網站來執行連通性檢查，例如https://www.google.com。使用標準的特征表示，這是不可能區別于一個良性客戶端到https://www.google.com。但是，如果包含關于連接的其他特性，比如TLS握手元數據，那么就可以區分這兩種情況，因為TLS特性提供了關于原始客戶機的信息。
最后，考慮到網絡安全領域所帶來的現實挑戰以及我們在實驗中所觀察到的有效性，我們針對算法和數據特征提供了具體的建議，以正確和有力地對加密的惡意軟件通信進行分類。我們的分析是基于從一個商業惡意軟件沙箱和兩個地理上截然不同的大型企業網絡中收集的數百萬個TLS加密會話。我們將重點放在傳輸層安全(TLS)協議[18]，因為它被廣泛采用。
2、背景
TLS[18]是確保許多明文應用程序協議的主要協議，例如，HTTPS是對TLS的明文HTTP協議。圖1提供了一個簡單的TLS會話的圖形表示。客戶端首先發送一個ClientHello消息，該消息為服務器提供了一個cipher套件列表和客戶端支持的一組TLS擴展。cipher套件列表是由客戶端的優先級排序的，每個密碼套件定義了一組用于TLS操作的加密算法。擴展的集合向服務器提供了附加的信息，以方便擴展的功能，例如，服務器名稱指示擴展指示客戶端試圖連接的服務器的主機名，這對于虛擬主機非常重要。如第4節所述，本文使用的所有TLS數據特性都取自未加密的ClientHello消息。
在ClientHello之后，服務器發送一個ServerHello消息，其中包含所選的密碼套件，從客戶的報價列表中選擇，它定義了一組加密算法，用于保護交換的應用程序數據。ServerHello消息還包含一個服務器支持的擴展列表，其中這個列表是客戶端支持的一個子集。此時，服務器還發送包含服務器證書鏈的證書消息，該證書鏈可用于對服務器進行身份驗證。
然后客戶端發送一個ClientKeyExchange消息，該消息建立了TLS會話的premaster secret。然后，客戶端和服務器交換ChangeCipherSpec消息，指示將來的消息將通過協商的加密參數進行加密。最后，客戶機和服務器開始交換應用程序數據。在圖1中，紅色文本表示未加密的消息，藍色文本表示加密消息。當前的TLS 1.2握手協議提供了許多有趣的、未加密的信息。為了增強隱私，TLS 1.3將對更多的握手進行加密，例如，證書消息將被加密，但是本文中使用的數據特性仍然可用。為了簡潔起見，省略了許多重要的細節，但是相關的RFC提供了完整的規范[18,34]。
由于TLS對許多特定于應用程序的特性進行了加密，因此使得傳統的深度數據包檢查變得不可行的，許多研究人員利用側向通道信息對TLS通信進行了有用的推斷[38]。這些數據特性通常是由加密會話的單個包長度和包的跨到達時間構造的。通常使用的特性包括數據包長度的平均值，n-gram或Markov鏈的特性，這些特征來自于數據包長度的序列，或者類似于時間信息的構造特征。
4、數據
4.1收集環境和工具。
我們為我們的數據收集利用了三個環境:兩個企業網絡，每個都有500- 1000個活躍用戶和一個惡意軟件分析沙箱。對于企業網絡，我們被動地實時監控所有出站網絡流量。我們使用HTTP用戶代理來確定這些網絡中45%的機器運行Windows 7和Windows 10, 40%的機器運行OS X 10。剩下的機器要么是移動設備，要么運行各種各樣的Linux或Windows XP。這些網絡中大約50%的端點是未管理的。
惡意軟件分析沙箱允許用戶提交可疑的可執行文件，并且每個提交的樣本被允許運行5分鐘。為每個示例收集并存儲完整的包捕獲。由于硬件的限制，這些示例只允許在Windows XP或Windows 7(32位或64位)的虛擬機中運行5分鐘。用戶選擇操作系統，默認為Windows XP。我們收集的惡意軟件流量中有75%是使用Windows XP，剩下的樣本使用的是Windows 7的變種。
這些數據收集方法很簡單，但是可能會導致我們的實驗中出現一些偏差，我們現在已經明確地說明了這一點。這兩個企業網絡位于不同的大陸上，但都是同一家公司的分支機構。因此，雖然網絡流量具有許多獨特的地理特征，但由于類似的端點配置，也會有許多重疊的會話。因為惡意軟件沙箱將樣本運行時間限制為5分鐘，因此在此初始窗口之后的任何活動都不會被捕獲。另外，任何與選定的Windows版本不兼容或缺乏關鍵依賴的惡意軟件樣本都不會運行。
我們編寫了一個基于libpcapc的開源包，Joy[30]，來處理實時通信和包捕獲文件。Joy將網絡數據轉換為JSON格式，其中包含所有相關的數據特性，這使得用標準工具分析這些數據變得微不足道。對于所有的實驗，我們僅使用完成了完全TLS握手并且發送了應用數據的TLS會話。Joy匿名化了企業流量的所有內部IP地址，我們沒有保留未處理的原始數據。
4.2數據集
表1提供了我們收集的、按月分割的數據的摘要。我們從2015年8月開始收集惡意pcap文件，每月收集1-3萬次TLS會話。我們在2016年4月開始監控一個企業網絡，Ent1。我們在2016年9月開始監測第二種，地理上不同的企業網絡，Ent2。我們使用一個受歡迎的黑名單來過濾企業流量[13]，其中黑名單每天都在更新。盡管如此，一些惡意的會話無疑仍然存在于企業數據集中。我們將在第6節中進一步研究這一結果。最后，對于每個企業網絡，我們隨機抽取數據，而不進行替換，以創建最終的數據集。
5數據特性
我們在實驗中引入了一個額外的軸:由領域專家開發的更具表現力的特性集的效果。與機器學習算法相結合的一組標準網絡流量特征的變化已經用于上一工作[6,39]。這些特性通常來自IPFIX[15]或NetFlow[14]，可以通過傳統的網絡設備導出。增強的特性獲得的效率較低，但也可以通過網絡設備導出[29]。所有特征歸一化，均為零均值和單位方差。標準和增強集分別有22個和319個數據特性。
5.1標準
對于標準的特性集，我們使用了文獻中常見的特性，特別是Williams等人提出的工作。這22個特征包括最小、平均、最大值和標準偏差:
?客戶->服務器的數據包長度
?服務器->客戶端包長度
?客戶->服務器包inter-arrival
?服務器->客戶端包inter-arrival
網絡連接的協議和連接時間，客戶－>服務器數據包數量和大小，以及服務器數量－>客戶端數據包數量和大小也被使用。Williams等[39]在其附錄C中提供了這些特性的完整列表:特征表。雖然大多數這些特性都存在于標準的NetFlow記錄中，但是數據包大小的信息卻不是。為了保持一致性，我們在實驗中包含了從包大小中提取的特性。
5.2增強
增強的特性集通過合并單獨的包長度和時間來擴展以前的工作，它提供了應用程序的行為概要的更詳細的視圖，以及TLS元數據，它提供了應用程序使用TLS庫的信息。為了提供一種直觀感受，在TLS惡意軟件檢測的背景下，領域專家用來確定哪些特性是有趣的，bestafera，一個以keylogging和data exfilter而聞名的特殊惡意軟件樣本，在我們描述深度增強的特性時呈現。
5.2.1數據包長度。圖2顯示了兩個不同TLS會話的包長度和間隔:圖2a中的谷歌搜索和圖2b中的bestafera啟動連接。x軸表示時間，向上的線表示從客戶機發送到服務器的數據包的大小，而向下的行表示從服務器發送到客戶機的數據包的大小。紅線代表未加密的消息，黑線是加密的application_data記錄的大小。
谷歌的搜索遵循了一個典型的模式:客戶的初始請求是在一個小的出站包里，然后是大量的mtu大小的數據包的響應。在用戶還在輸入的時候，谷歌試圖自動完成搜索，這是幾個交替的數據包。一旦谷歌對自動完成的結果有充分的信心，它就發送了一組更新的結果，結果顯示的是另一組mtu大小的數據包的響應。bestafera的服務器通過發送包含自簽名證書的包開始通信，這可以被看作是圖2b中的第一個向下的、細的紅線。在握手之后，客戶端立即開始向服務器發送數據。有個停頓，然后服務器發送了一個定時指令和控制信息。包長度和到達時間不能對會話的內容提供深入的了解，但它們確實有助于推斷會話的行為方面。
對于特定的特性，我們記錄一個會話的前50個包的有效負載的大小。然后我們將這些大小表示為一階馬爾可夫鏈。我們假設了一個1500字節的MTU，并創建了10個150字節的狀態，并估計了不同收集的數據包大小狀態之間的轉換概率。
5.2.2 TLS握手的元數據。TLS ClientHello消息提供了兩個特別有趣的信息片段，可以用來區分不同的TLS庫和應用程序。客戶端為服務器提供了一個適合客戶端排序的合適的密碼套件列表。每個密碼套件定義了一組方法，例如加密算法和偽隨機函數，它們將需要使用TLS建立連接和傳輸數據。客戶端還可以為一組TLS擴展做廣告，這些擴展可以為服務器提供密鑰交換所需的參數，例如[8]。
所提供的密碼套件可以在提供的唯一密碼套件的數量和每個密碼套件的優選組件中變化。類似地，擴展列表根據連接的上下文變化。因為大多數應用程序通常有不同的優先級，這些列表可以并且在實踐中包含大量的可區別信息。舉個例子，桌面瀏覽器傾向于更重量級，更安全的加密算法，移動應用程序更傾向于更高效的加密算法，而默認的密碼套件提供了與TLS庫捆綁的客戶端，通常提供更廣泛的密碼套件來幫助測試服務器配置。
大多數用戶級應用程序，以及通過擴展在野生環境中看到的大量TLS連接，使用流行的TLS庫，如BoringSSL (Chrome)、NSS (Firefox)或SChannel (Internet Explorer)。這些應用程序通常具有獨特的TLS指紋，因為開發人員將修改庫的默認值以優化其應用程序。為了更加明確，默認的OpenSSL 1.0.1r客戶端(s_client)的TLS指紋將很可能與使用OpenSSL 1.0.1r庫進行通信的應用程序不同。這也是為什么bestafera的TLS指紋既有趣又獨特:它使用OpenSSL 1.0.1r的默認設置來創建TLS連接。
在這個工作中，我們從提供的密碼套件和擴展列表中獲得特性。同樣，這些特性特別有趣，因為它們提供了啟動會話的客戶機的信息，即，兩個相同的會話可以基于客戶端應用程序進行區分。我們在數據中觀察了197個獨特的密碼套件和擴展。我們創建了一個長度為197的二進制向量，如果TLS會話支持相關的密碼套件或擴展，則將一個1分配給適當的條目。
