供安全工程師實用的SOC模型

1、背景

---

---

現在，安全概念滿天飛，什麼安全運營中心（SOC）、威脅情報（TI）、態勢感知等等不一而足，這些概念及其背後表明的安全思想都很好，不過不少產品爲了迎合國內的工做彙報都作成了不少Dashboard，一來很酷炫，二來確實能看出趨勢，方便決策。可是自己不適合工程師去處理問題，不適合一線工做人員處理具體的安全事件。因此簡單的參考和設計了一個SOC模型，用來便於一線的安全人員去工做。

2、總體架構

---

---

架構圖

---

名詞解釋

---

傳感器

---

傳感器在這裏是各類常見的網絡安全設備（例如IDS、WAF、FW、UTM、漏掃設備等等），或者各類應用系統或者蜜罐的日誌輸出模塊，再或者鏡像流量保存設備。總之就是和安全相關的各類告警、日誌、流量數據均可以傳到數據統一接收清洗平臺，在這個地方箭頭從傳感器指向數據統一接收清洗平臺，但不必定是傳感器外發信息（例如syslog），也能夠是開發者本身構造數據拉取引擎，經過原設備開放的API接口獲取數據傳輸到數據統一接收清洗平臺。
這裏常見的傳感器有：

• IDS（開源的Suricata，Snort，國內廠商啓明優點產品）；
• FW（天融信的優點產品，國外平底鍋的）；
• WAF（開源的ModSecurity，國內綠盟優點產品，國外的Rapid7的）；
• 漏掃設備（Nessus、Nexpose、國內綠盟的優點產品）；
• 應用系統輸出模塊就不在贅述；
• 鏡像流量類設備（360企業安全天堤）；
• APT調查類設備（360企業安全天眼、態勢感知，神州網雲網鏡等）
• 蜜罐（開源的Dionaea、Glastopf、ElasticPot，Cowrie）
• 終端安全軟件（360安全衛士、天擎等）

數據統一接收清洗平臺

---

數據統一接收清洗平臺的做用就是接收數據，清洗數據，而後把清洗好的數據打入數據存儲平臺。爲何要清洗，是由於多來源數據的格式不一樣、字段名稱不統一，只有清洗後才能統一存入數據存儲平臺，便於後面分析。因此整個流程中通常須要兩個Logstash實例，一個消息隊列。固然第一個Logstash實例也能夠用帶有數據清洗範式化功能的collector程序代替。因此這個地方通常的架構以下圖。消息隊列（Kafka、RabbitMQ）也能夠用緩存數據庫Redis。Logstash能夠輕鬆的輸入數據到消息Kafka和Redis，從兩者中消費數據，監控新數據也很簡單。

數據存儲平臺

---

這裏其實是一個大數據存儲平臺，爲了方便檢索和開源，選擇Elasticsearch或是Splunk皆可。通常基於ELK總體解決方案，能夠選擇Elasticsearch。

智能分析平臺

---

這是整個架構最核心的部分，通常是自研的分析引擎，從Elasticsearch中讀取數據，按照自定義的規則分類、聚合、分析，而後再輸出到一個消息隊列中，而後再起一個Logstash實例去消費消息隊列中的數據，反存入數據存儲平臺。這一步其實就是爲了解決紛繁複雜的告警沒法處理的問題，在這裏能夠過濾，檢查、去重、篩選、聚合，輸出最終能夠處置運維的告警信息，完全解放淹沒在告警海洋中的安全工程師。

數據展現平臺

---

這裏我選擇Kibana，由於也是基於ELK總體解決方案。Kibana方便展現，數據分析、適合工程師使用，也能夠生成數據Dashboard，方便彙報和領導決策。