ELK Stack可以用于SIEM嗎

前言

ELK實際上是三個工具的集合，Elasticsearch + Logstash + Kibana，這三個工具組合形成了一套實用、易用的監控架構，很多公司利用它來搭建可視化的海量日志分析平臺。

Kibana是一個優秀的前端日志展示框架，它可以非常詳細的將日志轉化為各種圖表，為用戶提供強大的數據可視化支持。

4. ELK Stack

對于日志來說，最常見的需求就是收集、存儲、查詢、展示，開源社區正好有相對應的開源項目：logstash（收集）、elasticsearch（存儲+搜索）、kibana（展示），我們將這三個組合起來的技術稱之為ELKStack，所以說ELKStack指的是Elasticsearch、Logstash、Kibana技術棧的結合。

1、日志收集

如上所述，SIEM系統涉及匯總來自多個數據源的數據。這些數據源將根據你的環境而有所不同，但是你很可能會從應用程序，基礎結構級別（例如服務器，數據庫），安全控制（例如防火墻，***），網絡基礎結構（例如路由器，DNS）和外部安全數據庫（例如線程供稿）。

這需要ELK Stack非常適合處理的聚合功能。結合使用Beats和Logstash，你可以構建由多個數據管道組成的日志記錄體系結構。 Beats是輕量級日志轉發器，可以用作邊緣主機上的代理以跟蹤和轉發不同類型的數據，最常見的beat是用于轉發日志文件的Filebeat。然后可以使用Logstash匯總節拍中的數據，對其進行處理（請參閱下文），然后將其轉發到管道中的下一個組件。

由于涉及的數據量很大，并且要利用不同的數據源，因此很可能需要多個Logstash實例來確保更靈活的數據管道。不僅如此，還需要部署一種排隊機制以確保處理數據突發，并且管道中各個組件之間的斷開連接不會導致數據丟失。 Kafka通常是在此上下文中使用的工具，安裝在Logstash之前（也使用其他工具，例如Redis和RabbitMQ）。

因此，僅ELK堆棧就無法滿足你的業務需求，并且生成的數據會不斷增長。打算將ELK用于SIEM的組織必須了解，將需要部署其他組件來增加堆棧。

2、日志處理

收集數據并轉發數據當然只是Logstash在記錄管道中完成的工作的一部分。在SIEM中，另一項至關重要的任務（也是一項極為重要的任務）是處理和解析數據。

上面概述的所有那些數據源類型均以不同的格式生成數據。為了在下一步（搜索數據和分析數據）中取得成功，需要對數據進行規范化。這意味著將不同的日志消息分解為有意義的字段名稱，在Elasticsearch中正確映射字段類型，并在必要時豐富特定字段。

不能過分夸大這一步驟的重要性。如果沒有正確的解析，則當你嘗試在Kibana中分析數據時，數據將毫無意義。 Logstash是支持此關鍵任務的強大工具。 Logstash支持大量不同的過濾器插件，可以分解你的日志，用地理信息豐富特定字段，例如，放置字段，添加字段等。

同樣，諸如SIEM系統所需的日志記錄架構可能會變得復雜。具體來說，將Logstash配置為處理各種日志類型將需要多個Logstash配置文件和Logstash實例。復雜的過濾器配置導致繁重的處理過程會影響Logstash性能。監視Logstash管道很重要，并且監視API（例如用于標識具有高CPU的Java線程的熱線程API）可用于此目的。

3、儲存和保留

從不同數據源收集的日志數據需要存儲在數據存儲中。就ELK而言，Elasticsearch扮演著數據索引和存儲的角色。

實際上，Elasticsearch是當今最受歡迎的數據庫之一，它是僅次于Linux內核的第二大下載開源軟件。受歡迎的原因有多種-開源，相對容易設置，快速，可擴展，并且擁有龐大的社區來支持它。

當然，部署Elasticsearch集群只是第一步。由于我們正在談論要建立索引的大量數據，這些數據很可能會隨著時間的推移而增加，因此用于SIEM的任何Elasticsearch部署都必須具有極好的可擴展性和容錯性。

這需要許多特定的子任務。我們已經提到使用排隊機制來確保在斷開連接或數據突發的情況下不會丟失數據，但是你還需要關注關鍵的Elasticsearch性能指標，例如索引率以及節點JVM堆和CPU。同樣，有監視API可用于此目的。容量規劃也很重要，如果你部署在云上，則最有必要使用自動擴展策略來確保你有足夠的資源來建立索引。

另一個考慮因素是保留。

為了進行事后高效的取證和調查，你將需要長期的存儲策略。例如，如果你發現來自特定IP的流量激增，你將需要比較這些歷史數據以驗證其是否為異常行為。有些攻  擊可能會在幾個月后緩慢發展，作為分析人員，擁有歷史數據對于成功檢測模式和趨勢至關重要。

不用說，ELK堆棧不支持開箱即用的歸檔功能，因此你將需要弄清楚自己保留數據的體系結構。理想情況下，不會對你的組織造成財務上的損失。

4、查詢方式

在Elasticsearch中收集，解析和索引數據后，下一步就是查詢數據。 你可以使用Elasticsearch REST API進行此操作，但是很可能你將為此使用Kibana。

在Kibana中，使用Lucene語法查詢數據。 例如，常見的搜索類型是字段級搜索。 例如，假設我正在尋找組織中某個人執行的操作所生成的所有日志消息。 因為我在所有數據源中標準化了一個名為``用戶名''的字段，所以可以使用以下簡單查詢：

用戶名：“ Daniel Berman”

我可以將此搜索類型與邏輯語句結合使用，例如AND，OR，NOT。

用戶名：“ Daniel Berman”并且輸入：登錄ANS狀態：失敗

同樣，如果你想使用ELK Stack for SIEM，則需要利用Logstash的解析能力來處理數據-而且你執行此操作的效果如何會影響你所點擊的多個數據源的查詢容易程度 成會。

5、儀表板

Kibana以其可視化功能而聞名，它支持各種不同的可視化類型，并允許用戶以自己喜歡的任何方式對數據進行切片和切塊。 你可以創建餅圖，圖形，地理地圖，單個度量標準，數據表等，并且結果非常有效。

這是在Kibana中為AWS環境構建的SIEM儀表板的示例：

在Kibana中創建儀表板不是一件容易的事，它需要你對數據以及構造日志消息的不同字段有深入的了解。 更重要的是，Kibana中缺少某些特定功能，例如可視化中的動態鏈接。 有解決方法，但是內置功能將是巨大的好處。

Kibana還不支持對象的安全共享。 如果你發現安全漏洞并希望與同事共享儀表板或單個可視化文件，則不會標記Kibana中的共享鏈接。 你可以在Kibana（X-Pack）之上或可以使用的開源解決方案之上實施一些商業附加組件。

6、相關性

SIEM中的另一個關鍵要素是事件關聯。 正如我們在上一篇文章中已經定義的那樣，事件關聯是將來自不同數據源的信號連接成一種模式，該模式可能表示安全漏洞。 相關規則定義形成此模式的事件的特定順序。

例如，可以創建一條規則來識別在特定的時間內從特定IP范圍和端口發送多于x個請求的時間。 相關規則的另一個示例將查找異常數量的失敗登錄以及特權帳戶的創建。

這些關聯規則由各種SIEM工具提供或針對不同的攻   擊場景進行了預定義。 ELK Stack當然沒有內置的關聯規則，因此分析人員可以根據使用Logstash進行的解析和處理，使用Kibana查詢在事件之間進行關聯。.

7、快訊

沒有警報，關聯規則毫無意義。 SIEM系統中的關鍵要素是，在識別到可能的攻  擊模式時被提醒。

繼續上面的示例，如果你的系統記錄了來自特定IP范圍的大量請求，或者異常數量的失敗登錄，則需要將警報發送給組織中的正確人員或團隊。 速度至關重要-發出通知的速度越快，成功緩解的機會就越大。

ELK Stack以其開放源代碼形式，沒有附帶用于警報的內置機制。 要添加此功能，需要使用警報插件或附件來增強ELK Stack。 同樣，X-Pack是一種選擇。 另一個選擇是添加ElastAlert-一個可以在Elasticsearch之上添加的開源框架。

8、事件管理

發現問題，分析師提醒。 現在怎么辦？ 你的組織對事件的響應程度將決定結果。 SIEM系統旨在幫助安全分析人員采取進一步的措施-包含事件，在必要時將其升級，緩解并掃描漏洞。

ELK Stack在幫助分析人員識別事件但管理事件方面無能為力時非常有用。 即使在堆棧的頂部實現了用于警報的附加組件，也需要一種用于管理已觸發警報的方法，以進行有效的事件管理。 否則，可能會淹沒警報并在重要事件中丟失。 自動化升級過程和創建票證對于有效的事件處理也很重要。

9、總結

那么，ELK堆棧可以用于SIEM嗎？

這個問題的答案很簡單。 由Logstash，Elasticsearch，Kibana和Beats組成的原始形式-ELK Stack并不是SIEM解決方案。

讓我們總結以上要點：

盡管ELK Stack是用于集中式日志記錄的功能非常強大的工具，但它不能按原樣用于SIEM。 缺少內置的警報功能，關聯規則和緩解功能-ELK Stack無法完成安全分析師所需的完整工具箱。

當然，ELK Stack可以增加其他平臺和服務。 這正是市場上幾種開源SIEM解決方案所做的。 但這需要組織進行巨大的工程壯舉。 將ELK Stack與其他附加組件和平臺融合在一起所需的大量資源和技術知識，更不用說財務成本了，因此選擇了商用SIEM。