安全信息管理(SIM)是用于從日志文件和其他來源收集安全信息以檢測和響應安全事件的技術，SIM的應用正變得越來越廣泛。現在的服務器、網絡設備和應用產生海量日志數據和各種類型的信息，這些海量數據可以被分析、關聯和過濾，從而推動與安全、合規和應用性能相關的各種決策。雖然有很多可能的用途，但SIM解決方案必須專注，否則會被信息過載、性能問題“淹沒”，變得一無是處。

[[109146]]

為SIM設定有限目標

SIM的功能是在大量安全事件中尋找特定安全事件的“蛛絲馬跡”。簡單地說，SIM是在針堆里找針。這是一項艱巨的任務，然而，很多公司試圖使用SIM做太多工作，使“針堆”越來越大，“找針”的工作也越來越困難。

部署SIM第一項也是最重要的部分是專注于一個目標或者一組有限的目標。SIM是用來檢測入侵?用來尋找違規行為?還是專注于內部或外部攻擊?對于這么多可能的用途，企業很容易失去焦點，并試圖完成上述所有任務。你試圖通過SIM解決的問題越多，SIM解決這些問題中的任何一個問題的效率就越低。

你應該收集哪些日志?如果你為SIM設定了特定的目標，你就可以很容易確定需要收集的數據。例如，如果你決定關注支付卡行業數據安全標準(PCI-DSS)的合規性，那么，防火墻日志將是你必須收集和分析的首要數據。PCI是為數不多的規范性法規之一，因此，有很多關于日志收集的具體指導。但其他法規并沒有那么容易：例如，HIPAA要求你保護個人健康信息(PHI)，但對此你應該收集什么日志呢?

日志收集的常見錯誤是，安全專家在這個過程中過早地使用過濾。例如，在醫療機構，SIM被配置為僅收集失敗登錄嘗試的日志信息。其理由是，這種日志信息可能表明有人試圖入侵系統。然而，當發生數據泄露事故時，該公司發現攻擊者已經成功盜用了用戶密碼。攻擊者并沒有產生失敗登錄日志信息，他們使用合法用戶賬戶成功登錄了系統。但這些成功登錄信息并沒有被收集，負責分析該泄露事故的安全專家將無法看到攻擊者做了什么。

這是一個艱難的權衡：如果你不收集一些具體的細節數據，當你在數據泄漏事故后需要查看歷史數據時，你將無法看到這些數據。但如果你收集所有數據，你將會面臨性能和存儲增長問題。看似不重要的小細節可能是事故后需要的關鍵數據。

在數據泄露事故后，SIM不僅可用于對歷史數據進行取證分析。很多企業還將SIM解決方案作為安全運營中心(SOC)實時事件響應的基礎。實時事件響應和事件后歷史分析的區別很關鍵，因為這兩者的目標往往不一致--如果說不是直接矛盾的話。針對實時分析的SIM解決方案被調整為高性能相關性和過濾，盡量減少收集的信息。然而，為了提高SIM用于事故后歷史分析的可操作性，你必須以完全相反的方式對它進行調整，以最大化收集和存儲的信息。

可操作的結果是指可用于業務流程的結果。如果你的目標是合規性，那么，流程應該產生年度審計報告。如果你的目標是數據泄露檢測，那么，這種結果應該能夠允許分析師通過事件響應流程對安全警報進行調查。如果你試圖提高安全操作，那么，SIM結果應該支持變更和配置管理流程。如果沒有明確的目標以及你想實現的流程，SIM無法產生可操作的結果。#p#

讓SIM成為安全監管計劃的一部分

當你讓SIM專注于單個目標，并成功地將它整合到你的標準安全操作中，那么，你就可以開始逐漸轉移注意力去解決其他業務挑戰。這并不意味著收集更多數據，因為這只會讓SIM速度變慢和失去焦點。相反地，這意味著尋找新方法來重新使用SIM結果作為你的整體安全監管計劃的一部分。

很多公司正在逐漸將其注意力從合規轉移到風險管理。風險管理意味著查看企業面臨的風險，并根據對企業的風險優先安排安全控制和事件響應來管理風險。對于SIM解決方案，這意味著關聯安全事件信息和風險信息，例如：

用戶身份/角色：涉及或影響哪些用戶/角色

系統風險：受影響系統是否是關鍵業務系統

應用風險：受影響應用是否是業務關鍵應用

為了將風險管理添加到SIM產品中，你不一定要收集更多日志。在大多數情況下，你可以向現有日志數據補充關于應用、系統、用戶和角色的風險/關鍵程度的信息。例如，很多SIM產品讓安全分析師可以根據關鍵程度將服務器分為不同級別，可使用數字分數(例如1至5分，其中1為最關鍵，5為最不關鍵)或標簽(例如高級、中級或低級)。這些額外的屬性給你的結果添加了另一個視角，讓安全專業人員可以優先業務關鍵安全事件，而推后非關鍵事件。這里關鍵的區別在于，關鍵程度是業務屬性，而不是安全屬性。

同樣地，為了讓SIM適應法規合規性，你不一定需要更多日志。在很多情況下，你必須關聯現有SIM結果到特定審計報告要求或規則。大多數法規代表著行業需要部署的最小安全控制。如果你的SIM被設計為支持強大的安全程序，你可能已經收集了合規所需的所有日志。

一些企業可能想要部署實時響應到安全事件。毫無疑問，這是所有公司的宏偉目標。實時響應要求近乎完美的技術、流程和人員，這方面很少有公司是成功的。如果你試圖實現這個雄心勃勃的目標，請確保這是完善的成功的SIM部署的最終目標，而不是第一個目標。為了讓SIM適用于實時關聯和分析，你必須選出日志數據的一個子集來進行關聯。對太多日志數據進行實時分析會降低性能，而收集太少日志則會讓事故后分析無法實現，因為記錄中會有很多空白。成功的部署會將日志數據劃分到長期歸檔中，這能保證盡可能全面的日志數據，以及更少的日志數據用于關聯和警報。

成功的關鍵是漸進化：從有限的專注的目標開始，然后逐漸增加功能，同時確保SIM系統不會被數據淹沒。如果你將SIM解決方案作為廣泛的操作過程的一部分，你會發現最薄弱的環節并不是技術，而是操作者。如果你為SIM設定了過于宏偉的目標，你會看到，這個系統被日志數據覆蓋，并且，你的工作人員也會被日志結果淹沒。面對產生太多結果和警報的SIM的操作人員，他們只有兩個選擇：停止產生結果，這可能錯過安全事件;或者忽略警報。很多SIM部署項目會出現其中一種情況或兩種情況，在一段時間后，SIM最終不得不被廢棄或取消。#p#

安全kaizen：SIM用于持續質量改進

看待SIM的一個有趣方式是將它作為安全計劃的反饋環節。所有政策、配置和安全設備最終會以安全事件的形式來表達自己。SIM是風險管理程序的很好的良性循環機制，還可以用它來確定政策是否在合理運作。

為了將SIM變為強大的反饋機制，安全運營經理必須將其作為持續改進計劃的一部分。SIM生成的每個事件都預示著企業安全的成功或失敗。當安全專業人員查看安全事件時，他們有可能越過這個事件，并發現政策、流程或控制存在的根本問題。在日本制造業，持續質量改進的過程被稱為“kaizen”，對改善安全程序產生巨大影響的概念。

在檢查的第一級，安全事件可能突顯出日志收集過程中的遺漏或錯誤。在審查事件時，安全分析師會發現日志信息的關鍵部分沒有被收集。在很多情況下，企業對這種發現并沒有馬上采取行動，沒有帶來任何變化。而在持續改進過程中，安全分析師將能夠提交變更申請表以添加日志到收集中。

在審查安全事件的過程中，安全分析師會發現一個較早期的重要事件但沒有生成警報。這里，企業能夠通過添加警報模式到SIM來改進過程。例如，分析師會收到關于不恰當數據庫訪問模式的警報，如不尋常的SQL查詢。在調查該事件時，分析師發現不僅這個具體查詢不尋常，而且它是來自不同IP地址和數據庫用戶，而不是既定的地址和用戶。但SIM只針對這個奇怪查詢發出警報，而實際上，它可以針對奇怪的連接來源和登錄憑證發出警報。通過添加這個模式，分析師能夠確保在未來SIM會對這種事件發出警報，讓安全團隊更快響應。

大多數企業在業務流程和配套基礎設施方面持續進行著變革。我們都知道，變化是安全的頭號敵人，因為變化會帶來錯誤，而錯誤帶來安全風險。SIM通常是配置錯誤首先出現的位置，它們可能觸發安全警報或者只是不相關的看似虛假的日志信息。因此，安全人員應該密切關注SIM中與變更相關的事件，不僅因為變更可能帶來潛在的安全泄露，而且因為變更可能已經破壞了SIM的關聯和過濾模式。例如，應用中的常規升級可能將日志信息從“登錄失敗：未知用戶”改為“失敗登錄：無此用戶”。對于我們來說，這兩個消息沒什么區別，但對于SIM的字符串模式匹配引擎來說，這兩者完全不同。如果你在升級前收到警報，你將不會再收到警報。

然而，在最基本的層面，SIM讓你能夠改善政策和流程，而不只是技術。如果你收集不同的日志、更改模式或者引入新模式，你將會改進SIM。但如果你使用SIM來發現損壞或無效的過程，或誤用的安全政策，你會提高企業的整體安全性，而不只是SIM。

想要修復政策和流程，安全分析師需要的不僅僅是變更申請單。為了不斷改進，你必須執行事件后審查，并對流程改進有著明確目標。你需要查看安全事件，包括從員工無意的簡單政策違規行為到災難性破壞，以此審查你現有的政策和流程以尋求改進。

安全信息管理工具是安全企業武器庫的重要組成部分。這些工具具有很多功能，以至于很多公司都過于延伸，試圖快速做太多事情。其結果是，很多SIM部署失敗--因為性能問題、操作員過度勞累或者花費太多成本而沒有成效。為了避免這種結果，企業應該從小事做起，專注于單個目標，并逐步擴大范圍，直到成功。