SIEM一般被認為是一個日志聚合的設備。然而，SIEM的主要能力是提供威脅檢測，最好還能夠實現事件調查、加速事件響應時間，同時還能有統一、整體的基礎設施視角。SIEM只是保護和監控網絡和系統的拼圖之一;而從Michael Oberlaender看來，這塊拼圖由十層堆棧組成(OSI七層，加上用戶、管理和金錢)，在剛開始的時候，會看上去很嚇人。

[[429426]]

在一個略微更加深入的層面，一個SIEM一般會提供以下能力：

• 事件與日志收集：從網絡中各個來源聚合事件和日志數據，從而更方便監控。
• 面板：頻繁地從收集到的數據處做出表格，從而更容易地識別環境模式以及非正常活動。
• 關聯：基于常見屬性將事件連接到一起，從而將數據轉化為能夠關聯的有價值組合。
• 告警：自動化分析關聯事件，提供可持續的驗證、趨勢與審計。• 取證分析：能夠基于特定的標準，在不同的階段和時間段上搜索全日志。
• 合規：：自動化收集應用中的合規數據，基于現有的安全、治理以及審計流程生成相對應的報告。
• 留存：長時間存儲歷史數據，使長時間的數據關聯更為容易;同時滿足應用合規。
• 映射：將計算機化的術語轉化為可讀的數據，更便于展示，并且能夠映射到用戶以及廠商定義的分類和方法中。

SIEM不應該是一個購入以后就被遺忘的設備。如果企業做的僅僅是購買了SIEM，連上網，然后認為SIEM將所有的安全需求都達成了——那就會陷入許多哦麻煩中。SIEM只是一個為事件響應團隊與數字取證團隊標準化安全工作流的工具而已——這些團隊的成員會使用SIEM來確保網絡的安全。

這只是使用SIEM的原因之一，其他部署SIEM的原因還包括：

• 滿足HIPAA、SOX、PII、NERC、COBIT 5、PCI、FISMA等合規要求。
• ISO 27000、ISO 27001、ISO 27002和ISO 27003等認證。
• 日志管理與留存。
• 事件響應與持續監控。
• 事例管理以及工單系統。
• 策略實施驗證以及監測策略違反情況。

許多企業過去部署SIEM的主要原因是為了合規。SIEM的功能不僅僅能保護敏感信息，還提供一種能夠滿足合規要求的手段。企業可以通過SIEM避免審計失敗，因為SIEM的存留和報告功能能夠驗證自身的合規情況是否和法律法規的要求一致。

然而，就像之前提到的那樣，一個企業不能單純地部署了SIEM，讓員工去監測SIEM的情況，然后就再也不關心系統了。要讓一個SIEM有用哪個，尤其是對于事件響應和威脅檢測系統有用，其告警以及事件和日志收集流程必須進行調整。如果告警太多，相關團隊會錯過關鍵數據，迷失在噪音之中;如果告警太少，那嚴重的安全事故可能永遠也無法被檢測到。這一條調整的過程需要在人工側發生，需要依賴那些十分熟悉網絡環境，并且盯著SIEM以及其監測的系統，然后基于業務和網絡需求進行更新。這一周期，可以參考Gartner的預測、預防、檢測和響應的四階段模型。

簡而言之，SIEM遵從GIGO原則(garbage in, garbage out;輸入的如果是垃圾，輸出的也是垃圾)。SIEM會反應出用戶以及用戶安全團隊對其的輸入內容——缺乏對SIEM必要的審閱、觀察、調整，SIEM就會停滯，并最終成為一個負擔。SIEM解決方案應該由業務驅動，以流程為核心——像ITIL框架這樣的就可以協助決定哪些流程或者進程可以被合并、修改、或者完全舍棄。

那么從哪里開始?試著用一個服務目錄，如果自己沒有，就用一些基礎的用例，從那里開始，沒有必要從零開始。

就像SIEM的使用需要持續的適應，這些方式也一樣，以下這些內容也會不斷改變：

• 合規要求
• 流程
• 進程
• 威脅
• 脆弱點和CVE
• 人員
• 客戶/用戶期望
• SLA

每個企業應用SIEM的方式不一定會相同，甚至自身的競爭對手或者同類企業的使用方式都會大相徑庭——最終還是需要看哪些適合自己的環境和業務。創建一個路線圖作為向導可能會有所幫助——從“為什么”或者使用SIEM的目的開始，會更容易識別相關資產以及優先級。

在確定了資產和優先級以后，下一步就是定義范圍。這事確保SIEM解決方案能適合的關鍵。SIEM的能力范圍在除了支持和保護業務之外，還需要能夠助力業務。

高效的技術、網絡運營以及安全運營團隊在某種進程和流程之下協作來識別：

• 數據分類
• 關鍵資產
• 進出點(包括網絡和物理層面)
• 必須的合規要求
• 內部IP機制

一旦有了這些，還必須有一些流程，包含責任和追責制度。另外，還需要有固定的來源，對一些問題進行回答，或者能夠獲得答復：可以是人、團隊，甚至可以是一個內部的頁面。

為了確保實踐一致性，可以將SOC或者SIEM圍繞ITIL實踐展開;并且鑒于ITIL專注于管理，可以將其作為一個向導或者路線圖。

戰略管理

定義自己對SIEM的愿景，或者SIEM解決方案可以整體提供的服務。這個定義可以是簡單的，也可以是復雜的，但最好從一些簡單的東西開始，定義一些對象的“常識”。十個常見用例可以在早期聯系起來，作為一個好的開始。

服務設計

一旦分析了業務需求，就可以開始將SIEM/SOC的期望以及部署的初心和業務關聯。這里的目標是創建一個“SIEM服務目錄”，用一系列的指標作為SIEM在業務中的核心功能。

服務與技術管理實踐

SOC或者SIEM運維人員需要注意環境中的變化。這看似是一個很顯而易見的事，但需要真正落地。SOC或者SIEM的運維人員如果不知道一個新的PC加入了網絡，或者某個數據中心暫時下線了，會導致誤報、審計失敗、無效的報告等。

這一步驟也需要實踐在“服務設計”階段中描述的功能，包括定義責任、溝通、SLA，甚至OLA等。這一步尤其需要標注趨勢、修復行為、每日活動，以及配置和存貨改變。

持續改進

這一步對企業而言經常是最困難的一步，但也是最必要的一步。在這一階段，數據會被審閱，并且用于之前建立的指標來重新定義或者改善服務、流程和進程。這一階段是確認和驗證人工或者GRC收集的數據的大好機會。使用持續改進記錄也能提供一定幫助。

到這里，應該能夠了解為什么需要SIEM，以及理解它能夠給業務帶來的許多價值中的一部分。但是要記得，優先級、方式和方案都會基于環境而改變——從簡單的 開始，隨著對SIEM的理解逐漸開始增加復雜性。使用已經被證明有效的框架和已經被證明有價值的資源作為輔助工具，可以幫助在一些最初的需求上做需求。

點評

SIEM的價值在于通過對于各類事件的整合，進行安全分析，從而實現對威脅的發現、對安全問題的響應、對已發生攻擊的溯源取證等等。而另一反面來看，SIEM也是一個“難對付”的產品：需要通過一系列的流程和制度，才能有效地使用其各種功能;需要根據業務不斷地調整相關的配置，才能將其功能的價值發揮到最大。