創作人：馮钰妍
審稿人：李捷
本文将介紹如何使用 Elastic Stack 在網絡安全分析領域中的實際應用
Elasticsearch 做為一款功能強大的分布式搜尋引擎，支援近實時的存儲、搜尋資料，具有擴充性好，檢索速度快等優勢，依托于 Elasticsearch 的這些優勢，其不僅廣泛地應用于各種搜尋場景，如日志檢索，聚合分析等，在安全分析等領域也開始逐漸展現其強大的能力。
在傳統安全領域，企業通常會借助防火牆，防毒軟體等，為企業構造起一套固若金湯的安全防禦體系，然而即使在如此嚴密的防護之下，仍然無法完全保證内部資料的安全，尤其是當面臨内部威脅時。
這時，根據已有安全資料進行安全分析，及時發現并處理威脅，就需要使用到可以大量實作實時日志存儲及資料可視化于一體的平台——Elastic Stack。
然而，現代企業的安全資料，已随着日益蓬勃發展的資訊網絡技術而迅速膨脹，對海量安全資料的采集，處理，存儲，查詢等正日益困擾着企業安全分析團隊。而 Elasticsearch 正是為應對海量資料的采集和檢索而生的，将 Elasticsearch 應用于安全分析領域，可以非常便捷高效地解決安全分析領域，海量資料的存儲和檢索問題。
- 第一部分是先配置好不同安全産品或伺服器的監控日志的 syslog 轉發；
- 第二部分則是将監控資料從監控系統中收集到 Logstash 或 Beat，它還負責對監控資料進行拆分、轉換的職責；
- 第三部分是用于存儲監控資料的到Elasticsearch叢集，我們借助 Elasticsearch 冷熱模型，延長了監控資料的儲存時間；
- 第四部分是将處理過的資料進行可視化展示，通過分析和關聯多種安全産品資料，将龐大的安全事件降噪為真實的威脅事件，并且實作定時或實時告警，友善企業的安全運維人員可以在第一時間發現威脅并采取相應處理措施。
資料收集
安全分析的第一步當然是建立各類資料收集，而資料來源的多種多樣，決定了我們收集時使用的方式。
輕量級的資料采集工具 Beat
Elastic Stack 中的 Beat 工具包含了豐富的資料采集工具，可以十分輕量且便捷的應用于各種資料的采集場景，下表是目前安全分析中需要采集的各類資料對應該采用的 Beats 方式：
| 資料類型 | 來源 | 采集方式 |
|---|---|---|
| 網絡資料 | 網絡監控，抓包等 | Packetbeat, Filebeat |
| 應用資料 | 日志 | Filebeat |
| 雲端資料 | 接口，日志 | Functionbeat, Filebeat |
| 系統資料 | 系統調用，日志 | Metricbeat,Auditbeat, Winlogbeat, Filebeat Osquery module |
| 裝置運作狀态資料 | Heartbeat |
Elastic 的開源性質決定了它沒有太大的局限性，是以 Elastic 不僅僅提供了官方 Beats，還有大量的社群貢獻的 Beats，使用者還可以根據自己的需要開發自定義Beats，完全可以滿足安全分析對各種資料源的采集需求。
ELK 中不可或缺的L（Logstash）
在網絡安全中資料的多種多樣，往往會分散或集中地存在于不同的系統中，或常見或不常見的。Logstash 作為一個日志聚合器，可以收集和處理來自幾乎任何資料源的資料，它可以過濾、處理、關聯，并且增強它收集的任何日志資料。
以下是一段360天擎的日志。
<6>{"version":"\u5929\u64ce6.6.0.4000","log_name":"\u6f0f\u6d1e\u7ba1\u7406","log_id":"82a40dbab698e5b6049d22071db2c517","create_time":"2020-02-28 10:40:11","ip":"42.101.64.215","report_ip":"192.168.1.107","mac":"3cf0117b5d27","gid":16777228,"work_group":"abfchina.local","content":{"name":null,"type":null,"action":"\u7528\u6237\u5378\u8f7d\u6f0f\u6d1e\u8865\u4e01","kbid":"4504282"}}
{
"version": "天擎6.6.0.4000",
"log_name": "漏洞管理",
"log_id": "82a40dbab698e5b6049d22071db2c517",
"create_time": "2020-02-28 10:40:11",
"ip": "42.101.64.215",
"report_ip": "192.168.1.107",
"mac": "3cf0117b5d27",
"gid": 16777228,
"work_group": "bayu.local",
"content": {
"name": null,
"type": null,
"action": "使用者解除安裝漏洞更新檔",
"kbid": "4504282"
}
} 針對這種未解碼的 JSON 嵌套的日志，首先我們可在資料進去時，設定好解碼格式，再使用到JSON 子產品進行對字段的拆分，再選擇存放到 Elasticsearch 中，解析如下：
nput {
syslog {
timezone => "UTC"
port => "514"
tags => "syslog"
codec => plain{
charset=>"GBK"
}
}
}
filter {
grok {
match => ["message", "<\d?>%{GREEDYDATA:log_json}"]
}
json {
source => "log_json"
}
mutate {
add_field => {"[source][ip]" => "%{report_ip}"}
add_field => {"[destination][ip]" => "%{report_ip}"}
}
}
output{
elasticsearch {
index => "360tq-%{+yyyy.MM}"
hosts => ["localhost:9200"]
user => "xxxx"
password => "xxxx"
}
} 資料标準化
不同來源的資料中表示相同含義的字段，在名稱、類型上各不相同，這就導緻了在進行資料檢索分析時，為了檢索不同資料源中的同類資料，可能要相容性地寫多個查詢條件，這給資料分析帶來了不小的麻煩。
為了解決這個問題，Elastic 建立 ECS(Elastic Common Schema) 項目，采用專業的分類方法，對字段進行統一命名，且 Elastic 生态相關元件，均遵循這一命名規格，使得對不同資料源的檢索得以簡化。
同樣是以上 360 天擎的日志，其日志字段被 Logstash 的 JSON 解析器拆分之後的字段與 ECS 後的字段對比如下
| 原生字段 | ECS後 |
|---|---|
| create_time | event.created |
| log_id | event.id |
| log_name | event.category |
| ip | source.nat.ip |
| client_name | host.name |
| login_user | user.name |
經過對字段的處理，字段的統一命名，便大大的提高了各類日志源之間的關聯性。
ECS 不僅對字段的名稱進行了規範，對字段的類型也進行了定義。在安全分析中，對IP的關聯查詢頻次較高，以下是 ECS 對 source 的部分字段的定義
| 字段 | 定義 | 類型 |
|---|---|---|
| source.ip | IP address of the source (IPv4 or IPv6). | |
| source.port | Port of the source. | long |
| source.domain | Source domain. | keyword |
| source.mac | MAC address of the source. |
威脅事件與告警
實作異常自動發現，最直接的方式便是基于門檻值規則的監控和告警。
Kibana Detection 子產品：
Elastic 官方在 Kibana v7.3 之後推出了 SIEM APP後，更名為 Security app ，為安全分析團隊提供了一個專用的內建化互動工作空間，資料可通過 Beats 子產品和 Endpoint agent 發送到 Elasticsearch。使用 Detection 功能建立和管理規則，并檢視這些規則觸發的告警。
除了可以使用 Elastic 預先建構的規則之外，還可以自定義規則，建立規則警報時，可以使用 Kibana 的 Alerts 和 Actions 發送通知，通知可以通過 Email、PagerDuty、Slack 和 Webhook 發送。
IXtra郵件告警：
最早期為了實作定期查詢 Elasticsearch 資料、判斷是否滿足特定條件、發送HTML郵件，衍生了 IXtra Web 應用。
IXtra 應用是由一組郵件告警 Python 腳本發展而來，經過不斷地更新疊代，現階段 IXtra 的主要功能是事件監控，通過連接配接多個不同的 Elasticsearch 叢集，可以集中地對這些叢集進行監控和告警。
當叢集内某個索引滿足告警門檻值内條件時，即産生告警。但一旦這些告警産生大量噪音時，IXtra的聚合門檻值型查詢（聚合後重複出現次數大于門檻值），則可以發揮到降噪作用。
除此之外 IXtra 也可以在一個 Elasticsearch 叢集内建立兩個查詢（同時滿足），進行組合型查詢。并且所有查詢後的結果，都會自動根據預設的規則分組、影響程度、緊急程度和标簽等通知到安全運維人員，另外 Ixtra 還可将告警的内容寫入至指定索引、自動将告警内容，送出到威脅情報庫進行調查，并且可以自動将告警事件通過 API 方式在工單（Trello、Jira等）系統建立 ticket 等功能。
具體的工作流程圖如下：
大大簡化了安全運維人員的手動操作部分、提升安全運維人員的工作效率。
扮演的角色
經過以上的闡述，希望您大緻可以了解到，其實 Elastic Stack 本身并不是一個傳統意義上的SIEM（Security information and event management）平台，而是我們這些具有專業素養的安全服務行業的人員，利用 Elasticsearch 本身的性質，DIY 搭建一個具有 SIEM 基礎功能的平台。完整的 SIEM 解決方案，包含從各種資料源收集資訊，長時間保留資訊，在不同僚件之間關聯，建立關聯規則或警報，分析資料并使用可視化和儀表闆監控資料的能力。
随着安全資料的不斷暴增，傳統的安全分析方法，對于企業安全問題的定位和解決越來越顯得力不從心。Elastic 作為目前主流的大資料存儲和檢索引擎，由于開源具有最佳的價格，其優勢使得其對解決目前安全分析領域面臨的問題，有得天獨厚的優勢。
它簡化了安全操作工作流程，并通過從業人員驅動的關聯性，幫助從業人員最大化資料見解。
安全團隊受益于涵蓋廣泛安全用例的多種檢測和調查方法。将基于 EQL（彈性安全檢測引擎中進階關聯背後的技術）的關聯與基于機器學習的檢測，名額比對類型檢測規則，以及雲規模的第三方上下文相結合，可以實作更全面的安全政策。
而 Elastic 團隊也在這方面不斷發現、提供了一套完整的解決方案，使得安全分析團隊在使用Elastic 進行安全分析變得更得心應手。
結語
無論一款工具多麼強大，都可能存在這樣或那樣的不足，從來都不存在可以“一勞永逸”的工具。想要真正最大化實作工具的性能，還需要根據自身需求和具備的實際條件來進行選擇，而Elastic Stack 則更适合那些擁有員工，技能和耐心的企業，自行建立解決方案。
當然，尋找一個實力相當的 SIEM 供應商，提供的全面 SOCaaS（SOC-as-a-Service）的快速部署和響應事件，也是個不錯的選擇。
近來，越來越的企業為避免過多一次性投資的基礎上，實作全方位全時段的安全保障，更願意尋求第三方安全托管機構的 724 SOCaaS 服務。同時，由于夜間被打擾的機率更小，其實 724SOCassS 服務更适合做一些專注需求高的特殊工作，例如漏洞的深度分析、網絡情報分析等。
另外，中型市場公司與大型企業，具有相同的安全需求，而沒有大型團隊和預算，SOC 可以很好的解決這一難題。