[[342565]]

0x01摘要

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

0x02簡介

​ 通過云范式中的虛擬化，可以在構建和運行信息與通信技術(ICT)服務中實現敏捷性和成本效益。 但是，與當前的舊版部署不同，它們帶來了更多的安全問題。

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

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

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

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

0x03 ASTRID結構

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

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

​ 通用控制平面的主要優點之一是可以從不同子系統(磁盤，網絡，內存，I / O)獲得數據，而不是像如今的通用做法那樣依賴單一信息源。 由于從多個來源收集數據很容易導致過多的網絡開銷，因此根據實際需要調整檢查，監視和收集過程非常重要。 因此，數據平面必須支持單個組件的重新配置及其虛擬化環境的編程，才能更改報告行為，包括每個應用程序特征的參數(日志，事件)，網絡流量，系統調用，遠程過程調用 (RPC)指向遠程應用程序。 編程還包括將輕量級聚合和處理任務卸載到每個虛擬環境的功能，從而減少了帶寬需求和延遲。

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

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

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

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

0x04 數據平面的抽象層

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

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

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

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

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

0x05 實現

​ 如上一節所述，數據平面是體系結構中負責差異操作的部分：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提供了用于搜索和分析數據的可視界面。

0x06 結論

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

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