安全資訊與事件管理 (SIEM) 平台是大多數安全運營中心 (SOC) 的核心。它們彙總日誌、關聯事件，並呈現分析師必須進行分級和調查的告警。本指南將引導你完整的核心操作工作流程，讓你能夠開始像 SIEM 分析師一樣思考，無論你的組織使用哪個平台（Splunk、Elastic、Microsoft Sentinel、QRadar 等）。
SIEM 實際上的作用
SIEM 的核心執行三項工作：從端點、網路設備、應用程式和雲端服務收集日誌；將該資料正規化為一致的結構；以及使用偵測規則關聯事件以產生告警。分析師隨後透過分級和調查生命週期處理這些告警。理解這個管線可以幫助你診斷問題，例如資料看起來不對或告警似乎遺失時。
設定日誌來源
在任何偵測邏輯發揮作用之前，你需要可靠的資料。常見的來源包括：
- 端點遙測 (EDR 代理、透過 Sysmon 的 Windows 事件日誌)
- 網路資料 (防火牆日誌、DNS 查詢、代理日誌、NetFlow)
- 身份驗證日誌 (Active Directory、VPN、SSO 提供者)
- 雲端稽核日誌 (AWS CloudTrail、Azure Activity Logs、GCP Audit Logs)
上線新來源時，請驗證時間戳準確性、確認欄位解析正確無誤，並檢查擷取量是否符合預期基準。配置錯誤的解析器會無聲地破壞偵測，而不會拋出錯誤，因此應定期對照原始事件與已解析的欄位進行抽樣檢查。
編寫和調整偵測規則
大多數 SIEM 使用某種形式的關聯搜尋或偵測規則語法。Splunk 的 SPL 中一個簡單的範例可能如下所示：
index=auth sourcetype=windows EventCode=4625
| stats count by user, src_ip
| where count > 10這會標記擁有超過 10 次失敗登入嘗試的帳戶，這是典型的暴力攻擊指標。建置規則時：
- 從較窄的範圍開始，然後根據誤判率擴大。
- 將每個規則對應到 MITRE ATT&CK 技術，以用於內容和涵蓋範圍追蹤。
- 記錄規則的意圖、預期的資料來源和已知的誤判場景。
- 設定實際的閾值 — 過於敏感會導致分析師被噪音淹沒；過於寬鬆會導致真實的威脅溜過。
告警分級工作流程
告警觸發後，分析師的工作是回答：這是惡意的嗎，以及是否需要升級？一個實務的分級檢查清單：
- 驗證告警 — 確認基礎事件確實發生，而不是解析人工製品。
- 以背景資訊豐富內容 — 檢查資產關鍵性、使用者角色、來源 IP 地理位置，以及同一主機上最近的相關告警。
- 檢查是否存在模式 — 在更寬的時間視窗中透過使用者、IP 或雜湊進行樞紐分析，以查看這是孤立的還是更廣泛活動的一部分。
- 分類 — 真正正面、誤判，或良性真正正面（真實活動，但不是惡意的，例如管理員的合法指令碼）。
- 升級或關閉 — 無論哪種方式都記錄你的理由；已關閉的告警仍然需要明確的審計理由。
建置有效的儀表板
儀表板應該回答具體的操作問題，而不只是看起來令人印象深刻。有用的範例包括：
- 過去 24 小時內失敗身份驗證來源排名前列
- 按嚴重程度和分析師指派的告警數量
- 資料來源健全性（擷取延遲、掉線）
- 對應到 ATT&CK 戰術的偵測涵蓋範圍
避免儀表板擴張 — 少數幾個高信號視圖勝過二十個很少檢查的面板。
處理誤判疲勞
告警疲勞是 SOC 中最大的操作風險之一。通過以下方式對抗它：
- 定期檢查已關閉的告警，以識別重複出現的誤判模式。
- 使用已記錄的例外（不是全面禁用規則）來抑制已知良性活動。
- 追蹤分級平均時間和回應平均時間作為指標，以捕捉瓶頸。
- 輪換偵測規則審查週期，使陳舊、雜亂的規則被細化或淘汰。
文件和交接
每項調查都應該留下紙質軌跡：什麼觸發了告警、檢查了什麼、得出了什麼結論，以及任何後續行動。這對於班次交接、合規審計以及建置在分析師流動中倖存下來的機構知識很重要。簡單的運行手冊範本（針對每種告警類型）— 調查步驟、升級聯絡人和預期證據 — 在壓力下可以節省大量時間。
獲得親身實踐
建置 SIEM 熟練度的最快方式是重複：擷取範例日誌、針對已知的攻擊技術編寫少數幾個偵測規則，並實踐完整的分級週期端到端。免費資料集和開源 SIEM 堆棧（如 Elastic Stack）是此類工作的絕佳低成本環境。
準備好更深入地探索藍隊基礎知識了嗎？探索 Korra Studio 相關的日誌分析、事件回應工作流程和偵測工程段落，持續提升你的 SOC 技能組合。