網路安全可程式設計性的資料日誌管理分析

導讀	在本文中，我們提出了用於訪問安全上下文的靈活抽象層概念。它旨在透過部署在雲應用程式和IoT裝置中的輕量級檢查和執行掛鉤來程式設計和收集資料。

近年來，考慮到網路攻擊的複雜性和多樣化，安全裝置正變得更加重要和嚴峻。當前的解決方案非常笨拙，無法在虛擬服務和物聯網(IoT)裝置中執行。 因此，有必要發展到更優秀的模型，該模型從大量的異構源中收集與安全相關的資料，以進行集中分析和校正。 在本文中，我們提出了用於訪問安全上下文的靈活抽象層概念。它旨在透過部署在雲應用程式和IoT裝置中的輕量級檢查和執行掛鉤來程式設計和收集資料。 透過回顧主要軟體元件及其作用，我們對其實現進行了描述。 最後，我們透過對PoC實施的效能評估來測試此抽象層，以評估從虛擬服務和IoT收集資料/日誌以進行集中式安全性分析的有效性。

透過雲正規化中的虛擬化，可以在構建和執行資訊與通訊技術(ICT)服務中實現敏捷性和成本效益。 但是，與當前的舊版部署不同，它們帶來了更多的安全問題。

物理和虛擬服務類似於相同的開發結構。 在基礎設施即服務(IaaS)模型中，常見的做法是將每個軟體應用程式部署在不同的虛擬化環境中，虛擬化環境可以是虛擬機器，也可以是軟體容器。然後透過虛擬網路連結將它們互連。 這樣，單個虛擬機器的故障就不必影響整個服務。 應用程式可以輕鬆打包並以雲映像形式交付。

虛擬化基礎架構中安全機制的侷限性，例如分散式防火牆和安全組; 在跨雲部署中協調它們的難度; 第三方提供的信任安全服務的典型差異促使人們越來越傾向於在虛擬服務的拓撲結構中插入遺留的安全裝置。 與此相反，這種方法有幾個問題：i)每個裝置都有自己的檢查鉤; ii)由於協議和應用程式的數量和複雜性，檢測需要大量的計算資源; iii)複雜的安全裝置無法抵抗錯誤和漏洞。

考慮到這些方面，需要新的體系結構範例來建立虛擬服務的態勢感知。 這樣，透過將細粒度的資訊與有效的處理，彈性與魯棒性，自主性與互動性相結合，就可以克服上述侷限性。 因此，有必要從獨立的安全裝置過渡到更協作的模型。 對於協作模型，我們指的是一種集中式體系結構，其中從給定域內的多個來源收集安全資訊，資料和事件，以進行公共分析和關聯。 對於所有主要的網路安全應用程式供應商而言，這是當今的趨勢，這些供應商正越來越多地為企業開發安全事件和資訊管理以及安全分析軟體，並利用機器學習和其他人工智慧技術進行資料關聯和識別攻擊。 它們被設計為現有安全應用程式的整合工具，並要求在每個主機上執行重量級的程式。 因此，它們不適用於虛擬服務。 另外，集中式體系結構提高了檢測率，同時減少了每個終端的開銷。 另一方面，由於上下文不斷變化，因此服務圖的安全性管理是一項艱鉅的任務。 將安全裝置整合到服務圖設計中並不是最佳解決方案，因為它需要手動操作。 取而代之的是，應該透過定義描述要求的內容而不是如何實現的策略和約束來抽象地描述安全性。

在本文中，我們描述了抽象層的定義，以為檢測邏輯提供對虛擬化服務的異構安全上下文的統一和雙向訪問。 我們工作的新穎性在於在核心或系統庫中抽象了輕量級的可程式設計鉤子，而無需在VM內部署複雜而繁瑣的安全裝置或在整體服務圖中將其部署為單獨的元件。 對安全性上下文的收集和強制性規則的配置(這是雙向訪問的手段)進行程式設計的能力，只是對已經作為商業或開源實現可用的log 7收集工具的數量的重大改進。 本文的其餘部分安排如下。 我們將在第2節中描述整個ASTRID體系結構。然後，在第3節中詳細說明抽象層的概念及其體系結構設計，同時在第4節中討論當前的實現，並對所選技術進行詳盡的描述。 然後，在第5節中，我們提供了概念驗證實施的功能驗證和廣泛的效能評估，包括與本地監視/執行代理的整合。

圖1顯示了組織ASTRID多層體系結構的三個互補平面。 儘管我們的體系結構與網路運營商沒有直接關係，但我們使用網路術語。 ASTRID是一種多層體系結構，在該體系結構中，公用，可程式設計且普及的資料平面可提供一組強大的多供應商檢測和分析演算法(業務邏輯)。 一方面，挑戰在於透過實時收集來自多個毛細血管來源的大量事件，在多個站點上集合廣泛的知識，同時保持諸如轉發速度，可伸縮性，自治性，可用性，容錯性之類的基本屬性。 ，抵制妥協和響應能力。 另一方面，其目標是透過空間和時間上的域間和域內資料關聯來支援更好和更可靠的態勢感知，以便及時檢測和響應甚至更復雜的多向量和跨學科網路攻擊 。

資料平面是虛擬化環境中部署的體系結構的唯一部分。 它收集安全上下文，即包括事件，日誌，措施的知識庫，可用於檢測已知攻擊或識別新威脅。

通用控制平面的主要優點之一是可以從不同子系統(磁碟，網路，記憶體，I / O)獲得資料，而不是像如今的通用做法那樣依賴單一資訊源。 由於從多個來源收集資料很容易導致過多的網路開銷，因此根據實際需要調整檢查，監視和收集過程非常重要。 因此，資料平面必須支援單個元件的重新配置及其虛擬化環境的程式設計，才能更改報告行為，包括每個應用程式特徵的引數(日誌，事件)，網路流量，系統呼叫，遠端過程呼叫 (RPC)指向遠端應用程式。 程式設計還包括將輕量級聚合和處理任務解除安裝到每個虛擬環境的功能，從而減少了頻寬需求和延遲。

對執行環境進行程式設計的靈活性有望潛在地導致所收集資料的種類和詳細程度上的巨大異質性。 例如，某些虛擬功能可能報告詳細的資料包統計資訊，而其他功能可能僅報告應用程式日誌。 另外，對於每個執行環境，報告的頻率和粒度可能有所不同。 資料在時間和空間維度上的相關性自然會導致針對不同的時刻和功能併發請求相同型別的資訊。 最後，最後一個要求是執行快速查詢和查詢的能力，還包括某些形式的資料融合。 應該允許客戶端定義所需資料的結構，並從伺服器返回完全相同的資料結構，從而防止返回過多的資料。 當需要了解不斷變化的情況並識別攻擊的能力要求檢索和關聯超出典型查詢模式的資料時，這可能會變得有用。

控制平面是邏輯上和集中式演算法的集合，用於檢測攻擊和識別新威脅。 每種演算法都從公共資料平面檢索所需的資料。 這代表了所提出的框架背後的一項主要創新：的確，每種演算法都對整個系統具有完全的可見性，而無需在每個虛擬功能中部署本地代理，這些代理通常執行相同或類似的檢查操作。 控制平面還應包括程式設計功能，以將本地處理任務配置和解除安裝到資料平面，從而有效地平衡檢查深度與所產生的開銷。

除了單純地(重新)實現效能和效率方面的傳統裝置之外，ASTRID方法還專門為透過結合檢測方法(基於規則，機器學習)而為新一代檢測智慧鋪平了道路。 大資料技術; 目的是在圖形及其元件中定位漏洞，識別可能的威脅，並及時檢測正在進行的攻擊。對來自多個交織域的安全日誌，事件和網路流量的組合分析可以極大地增強檢測能力 能力，特別是在大型多向量攻擊的情況下。 在這方面，機器學習和人工智慧的應用將有助於檢查和關聯大量資料，事件和度量，這些資料，事件和度量必須進行分析才能可靠地檢測和識別甚至複雜的多向量攻擊。

管理平面的構想是使人員處於迴圈中。它會通知檢測到的攻擊和異常情況，以便在檢查過程中需要人員專門知識來補充人工智慧時，可以訪問整個上下文。 管理平面透過定義高階策略來支援快速有效的補救措施，然後將這些策略從控制平面轉換為特定的資料平面配置。 管理平面還與業務流程工具無縫整合，業務流程工具有望廣泛用於自動化虛擬服務的部署和生命週期操作。

抽象層的主要目的是提供對底層資料平面功能的統一訪問。 根據第2節中的一般描述，資料平面由異構檢查，測量和實施掛鉤組成，它們在虛擬化環境中實現。

這些掛鉤包括程式設計師在其軟體中開發的日誌記錄和事件報告，以及核心和系統庫中內建的監視和檢查功能，這些功能可檢查網路流量和系統呼叫。 它們是可程式設計的，因為它們可以在執行時進行配置，從而根據不斷髮展的環境來調整系統行為。 這意味著可以有選擇地在本地調整資料包篩選器，事件報告的型別和頻率以及日誌記錄的詳細程度，以獲取準確的知識量，而不會因不必要的資訊而使整個系統不知所措。 目的是在檢測到可能表示攻擊的異常或網路安全團隊發出有關剛剛發現的新威脅和漏洞的警告時，獲取關鍵或易受攻擊元件的更多詳細資訊。 這種方法即使在並行發現和緩解的情況下，也可以在風險較低的情況下以較低的開銷進行輕量級的操作，同時在異常和可疑活動的情況下切換到更深入的檢查和更大的事件關聯性。 即使對於最大的服務，這也可以隨著系統複雜性進行擴充套件。

抽象層涵蓋兩個主要方面：i)隱藏監視鉤的技術異質性; ii)抽象整個服務圖和每個節點的功能。

圖2為預想的抽象的示意圖。 在本地，在每個虛擬化框中，本地安全代理(LSA)為不同的鉤子提供了公共介面。 然後，將整個圖拓撲抽象為中心輻射圖。 在此模型中，每個節點代表一個虛擬功能，每個節點連結一條通訊路徑。 節點的附屬節點是安全屬性; 它們既包括監視/檢查功能(可以收集，測量和檢索的內容)，也包括相關資料(度量，事件，日誌)。 同樣，連結也具有與加密機制和利用率度量有關的屬性(儘管未在圖中明確顯示)。

為了提供綜合指標，還可以將資料融合作為整體抽象框架的一部分。 基本資料的預處理和聚合可以透過相同的查詢完成，因此可以最佳化抽象模型中的查詢。 抽象層還包括儲存功能，因此可以為線上和離線分析提供實時和歷史資訊。 在這種抽象中，總體拓撲和安全功能由協調器設定，而安全資料由LSA饋送。

如上一節所述，資料平面是體系結構中負責差異操作的部分：i)收集安全上下文(就事件，日誌，度量等而言)，以及ii)實施安全策略(就術語而言) 資料包過濾，執行環境的重新配置等)。

ELK堆疊提供的集中式日誌記錄可在中心位置搜尋所有資料。 它是開放原始碼軟體工具的多功能集合，這些軟體工具是基於分散式日誌收集器方法實現的，該方法可從資料更輕鬆地收集見解。 簡而言之，ELK堆疊由三個核心專案組成：i)作為搜尋和分析引擎的Elasticsearch，ii)用於資料處理和轉換管道的Logstash，以及iii)Kibana Web UI以視覺化資料。 它們共同構成了縮寫ELK。 之後，Elastic啟動了第四個專案Beats(輕量級和單用途資料託運人)，並決定將所有專案的組合重新命名為簡單的Elastic Stack。

圖3顯示了概念驗證(PoC)實施的體系結構。 生成各種型別的資料，例如系統日誌檔案，資料庫日誌檔案，訊息佇列生成的日誌以及其他中介軟體。 這些資料由安裝在所有虛擬功能(服務)上的Beats收集。 Beats以固定的時間間隔將日誌傳送到Logstash的本地例項。 然後，Logstash在進行一些輕量資料處理之後，將處理後的輸出傳送到Context Broker(CB)，後者是收集資料並儲存以進行集中分析和關聯的集中節點。 在CB內部，Kafka將資料傳送到Logstash的本地例項。 在處理之後，Logstash將資料傳送到Elasticsearch，Elasticsearch將對該資料進行索引和儲存。 最後，Kibana提供了用於搜尋和分析資料的可視介面。

在本文中，我們概述了抽象層的主要功能和初步設計，這些抽象層提供了對異構資訊和源集合的雙向訪問。 這種方法使大資料集可用於機器學習和其他人工智慧機制的應用，而機器學習和其他人工智慧機制目前是新一代威脅檢測演算法的主要研究領域。 與現有方法不同，我們的目標是公開執行環境的可程式設計功能，這些功能可用於對本地檢查和監視任務進行程式設計。

我們將詳細描述基於與Kafka訊息代理整合的ELK堆疊的體系結構，以及如何滿足收集用於網路安全分析的日誌的需求。 我們提供PoC實施的功能驗證和廣泛的效能評估，包括與本地監控/執行代理的整合。 結果表明，考慮到容量，該架構能夠在不使用最大資源的情況下立即收集資料。 在所用資源的限制下(當每秒的事件數等於1000，並且獨立於輪詢間隔值時)，虛擬函式中的拍子無法在不引入明顯延遲的情況下收集資料。

原文來自：