下面以一家擁有 500 台計算機的中型企業為例，網絡安全產品每天產生的事件數量如表 1 所示。
表1 典型企業日誌輸出分析
安全目標
安全產品
原木產量（/天）
內網安全
桌面管理系統
超過 1000
防病毒系統
殺毒服務器、殺毒網管
50000
網絡安全
交換機、路由器
超過 1000
入侵檢測系統/IPS
超過 500000
防火牆、堡壘機
超過 200 萬
保護關鍵業務
主機審計、應用審計
超過 100,000
通過現有的日誌收集技術，我們收集這些日誌並不難。然而，安全人員很難在短時間內識別大量安全事件之間的內部線索，分析日誌的關聯性就更困難了。這時，我們就需要一種技術，可以幫助我們在對海量日誌數據進行處理分析後，自動獲取網絡異常告警，從而提高安全團隊發現網絡威脅的效率。
2、網絡相關性分析技術
面對上述問題，我們可以通過關聯分析平台來解決問題。該平台可以為我們提供網絡安全各個方面的概覽。它還提供實時監控和事件關聯、風險分析、報告和通知功能。全面管理和審計系統內的安全事務，大大提高識別網絡安全風險的能力。關聯分析平台依托關聯分析核心技術，重點關注日誌採集、日誌格式化（也稱歸一化）、日誌關聯分析三個方面。
1、日誌採集：SIM產品是否有優勢取決於日誌採集，是否支持更多類型，是否可以方便擴展，自動識別和支持未知設備日誌。比如需要支持的協議有syslog、snmp trap、windows log、database、file、xml、soap等。
2、日誌格式化：日誌採集完成後，需要進行統一的標準格式化。這些統一的格式會在原始日誌中添加風險值、可靠性、優先級等標籤，為後續的關聯分析做準備。如果格式不夠標準，則無法進行關聯分析。以下是規範化的格式：
下面是SSH原始日誌和標準化日誌的前後對比：
可以看出，SSH暴力攻擊事件的元素比原來的日誌要多很多，但是這些添加可以為以後的日誌關聯分析做準備。
3.日誌相關性分析
在日誌格式化的基礎上，利用一定的算法（上下文關聯、攻擊場景關聯等）從多個數據源獲取事件進行關聯分析，實現不同日誌的風險值，結合資產漏洞信息和入站和出站流量綜合計算網絡。資產受到威脅，最後發出警報提醒管理員。這大大降低了管理員分析海量日誌的難度。
為了達到對安全事件進行關聯分析的目的，需要有一個好的事件處理機制，比如上面提到的日誌採集的歸一化處理，以及一個好的關聯方法，而且關聯方法不止一種關聯多個實時 將這些方法組合在一起效果更好。大量標準化事件送入關聯引擎處理後，會經過事件分類處理、聚合、互相關、啟發式關聯等多種關聯方式。系統會根據數據庫中的安全事件進行統計分類。
我們來看一個相關性分析場景：
（1）比如VPN服務器日誌顯示，張三3:00從外網登錄到內網，3:05登錄FTP服務器，在FTP服務器上下載了某個文件。門禁系統的日誌顯示，張三不久前剛剛進入辦公區域，這三個日誌可以與一個安全事件相關聯。
(2) 某公司核心數據庫前端部署防火牆系統。一天，安防系統監控發現張三登錄了MySQL數據庫服務器，但是在防火牆日誌中沒有找到張三的訪問日誌，這說明張三很有可能繞過防火牆直接登錄數據庫服務器.
3）。在網絡中，OpenVas 掃描具有 Apache 2.2.x Scoreboard（繞過本地安全限制）漏洞的 Linux 主機。同時，NIDS 檢測到對主機漏洞的攻擊企圖。如果Linux服務器標有“如果打了相應的補丁”，則關聯分析結果為低風險值，不報警。如果沒有打補丁，審計系統會報警。
每個系統管理都有自己的安全保護措施，但它們只是安全孤島，但一切之間都必須有關係。將這些日誌鏈接在一起進行分析，就是我們上面介紹的相關性分析技術。
4. OSSIM關聯引擎
一、關聯引擎概述
OSSIM平台下實現的關聯分析技術的核心是關聯引擎。 OSSIM傳感器將大量標準化事件發送到關聯引擎進行處理後，會經過事件分類處理、聚合、互相關、啟發式關聯等多種關聯方法。系統會根據數據庫中的安全事件進行統計分類，找出安全事件的來源和經常被攻擊的端口。在這些階段將生成事件警報。安全事件關聯流程模塊如下圖所示。
管理引擎中的事件聚合模塊可以為後續關聯提供高質量的安全事件，提高關聯引擎的效率，分類處理可以直接升級已知安全事件，可靠性高，告警關注度高。此外，統計分類通過綜合分析告警庫、日誌庫、知識庫，生成受控網段內被攻擊頻率最高的主機和應用程序，統計同一數據源、同一目標端口的安全事件數量。客觀反映網絡異常。
在OSSIM系統中，關聯分析功能也是由關聯引擎實現的。關聯引擎策略文件定義位於/etc/ossim/server/，分析後的數據由探針採集。 Sensor（傳感器）每天從網絡上採集。有數以萬計的事件。如果不對這些海量的事件信息進行任何處理，直接生成事件是沒有意義的。在上報之前，可以通過相關性分析將這數千個事件濃縮（聚集）成幾十個甚至幾個事件，顯示在Web前端的SIEM中。簡單理解就是，OSSIM的網絡安全事件關聯分析可以去除不同功能的開源網絡安全檢測工具產生的誤報信息，從而挖掘出真實的網絡攻擊事件。
2.主要關鍵詞
OSSIM系統中的風險評估主要圍繞攻擊威脅（Threat）、漏洞（Vulnerability）、響應（Response，security measure）、資產（Asset）等。風險評估模型嵌入在 OSSIM 關聯引擎系統中。關聯引擎結合知識庫中的資產庫、漏洞庫和威脅庫，綜合考慮風險資產、漏洞和威脅三要素。
三、資產風險計算
風險=R（資產、漏洞、威脅）
將資產價值（Asset）、優先級（Priority）、可靠性（Reliability）三個參數結合起來計算風險，簡潔有效。 OSSIM系統中使用以下公式：
風險=資產*優先級*可靠性/25（風險模型計算公式1）
其中Asset（資產，取值範圍0~5）
優先級（優先級，取值範圍0~5）
Reliability（可靠性，取值範圍0~10）
每個警報事件的風險值由公式（1）計算，其中
Ø Asset的取值範圍為0到5，asset的默認值為2；在 OSSIM 系統中，資產的注意力等級分為 5 個等級，數值從低到高分別為 1、2、3、4、5。表面上可以理解，數字的大小決定了風險計算公式中風險值的大小，但也有其深層次的含義。比如普通工作站的資產等級是1，當它被DOS攻擊時，我們只需要一個簡單的端口網絡連接。如果是數據庫服務器，它的資產等級是5，數據庫服務需要實時在線，所以我們不能像工作站一樣處理DOS攻擊，而應該自動啟用備用IP地址並引導攻擊到網絡蜜罐系統。
Ø Priority的取值範圍為0~5，默認值為1。該參數描述了攻擊成功造成的傷害程度。數值越大，損壞程度越高；
Ø Reliability或Reliability的取值範圍為0到10。默認值為1。reliability參數描述了攻擊可能成功的概率。最高值為 10，表示 100% 的可能性。代表越不可靠，就越容易受到攻擊。
操作 OSSIM 時，在 Web UI 中打開 SIEM 控制台，觀察每個事件，可以發現風險值受資產價值優先級和可信度控制。網絡中的每一項資產都是有價值的，而這個價值的量化是通過資產價值來實現的。每個資產的默認值為 2（範圍 1~5）。在風險計算公式中可以分析出，風險計算不計算資產價值。作為影響風險結果的主要因素，比如一些數據庫服務器資產價值高，計算出來的風險值也會很大，而資產價值小的工作站在受到嚴重攻擊的節點上風險值小，所以很難失去原有的真實性，所以讓資產價值的範圍在1到5之間，風險值就小了。
場景示例：
一個主機連接到一個VLAN中5個不同IP地址的445端口，這可能是正常的網絡通信，如果有15台機器連接到445端口這是可疑的，如果有150個這樣的連接並且持續很長時間，它很可能被蠕蟲攻擊，需要人工進一步驗證。
4. Risk & Priority & Reliability 的關係例子
根據公式計算，任何人都可以做到。上述公式1中各個參數之間的內在關係是什麼？
在我們收集到的事件中，重複事件佔很大比例，其中風險主要是Risk=0。例如，以Cisco ASA的一個ICMP事件為例，它的PRIO=1，REL=1，ASET=2，根據上面的風險模型計算公式計算得出，大約等於0。
分析上圖可知，Reliability 系統在關聯規則中為它設置了一個初始值。想像一下，如果它是一個常數，在動態網絡攻擊中會產生大量的誤報。那麼，當引入互相關機制後，將網絡安全告警與具體網絡應用服務的漏洞信息、開放端口、開放端口進行空間關聯，判斷是否可以實現攻擊，所以可靠性值必須成為一個變量。包含無法存在的端口的安全事件直接丟棄（系統的KDB中有立即更新列表）。下圖是OSSIM關聯規則中可靠性參數的變化過程。
5. 事件聚合
我們知道，冗餘告警會嚴重干擾管理員對故障的判斷。此時，需要匯總這些信息。通過從海量告警中聚合一些類似告警，去除冗餘部分，減少告警數量。這大大減少了關聯模塊進行關聯分析的工作量。
合併冗餘告警信息主要從三個方面考慮：
(1) 合併基於主機的監控Ossec產生的冗餘告警事件。
(2) 合併基於網絡的監控 Snort/Suricata 產生的冗餘報警事件。
(3) 結合主機監控Ossec和網絡監控Snort告警信息進行同一攻擊。
Snort告警信息的屬性比較全面，具有明顯的特點。 Snort產生的告警事件合併過程可以採用基於屬性相似度的方法。對於Ossec的告警事件的合併，OSSIM採用了基於事件ID和告警類別信息相結合的方法。目前，Ossec 擁有 900 多條檢測規則，全部以 XML 格式存儲。經統計分析，根據告警行為可分為80個告警類別。常見的有：Syslog、Firewall、IDS、Web、Squid、Windows等。以OSSEC告警的事件ID作為入口，進行一級類和子類的匹配，實現匹配和合併的目的。
根據信息源分析，我們看到聚合對像是基於網絡的Snort/Suricata和基於主機的Ossec安全產品產生的告警數據。包含協議屬性，可以基於規則的方式進行聚合，可以保證在聚類過程中對告警信息進行正確分類。
Snort 支持多種協議，通過將警報事件聚類然後合併它們可以節省大量時間。並且由於其屬性的明顯特徵，冗餘信息的合併是基於其屬性的相似性進行的，因此合併誤差很小。對於Ossec產生的告警信息，以告警事件的ID為入口，按照告警類別逐步聚合，合併錯誤率低。按照以ID為入口的根類別進行合併的方法，省去了遍歷告警信息進行聚類的需要。是時候合併了。
OSSIM中使用主機監控軟件Ossec實現對主機的審計記錄、系統日誌和應用程序的收集和分析。它支持文件完整性監控、註冊表監控、端口監控、rootkit檢測和部分進程監控。同時，Snort 用於收集網絡上的數據包，完成實時流量分析和測試網絡上的 IP 包等，還可以進行協議分析、內容搜索和匹配，並可用於檢測各種攻擊和嗅探（例如緩衝區溢出和 ShellCode 攻擊）。
對於兩個事件，如果相似度高，則認為是同一次攻擊，合併；否則，它們被認為是不相關的攻擊。
我們可以從計算兩條警報消息之間的相似度開始。首先要考慮的是兩個警報的共同屬性。這些屬性包括攻擊源、目標（主機IP和端口）、攻擊類型、MAC地址、時間信息和事件ID等。據此，我們可以對告警事件的屬性進行抽象和形式化，將它們的屬性定義為一個事件屬性集。我們對冗餘告警事件採用的合併方法的出發點是同一攻擊行為的告警信息相似度高，不同攻擊行為的告警相似度低。我們在合併各個產品的冗餘告警信息時，還需要考慮兩個安全產品針對同一次攻擊產生的告警信息，盡量有效地壓縮所有重複的告警信息。
如果 Snort 發現基於目標 IP 的攻擊，則說明目標 IP 主機存在漏洞，其可靠性係數為 10（即 100% 攻擊成功）。下圖中REL的值為10，表示當前時間可靠性係數為10，因此風險值為4。這個值也可以在數據源中修改。
從上面可以看出，可靠性和優先級的數值決定了風險的大小。手動修改數據源REL/PRIO的方法如下圖所示。請注意，此修改在全局範圍內有效，而不是針對單個事件。通過傳感器將各個監控節點的數據關聯起來，形成一條數據鏈，然後關聯分析引擎和規則協同工作，分析黑客的攻擊行為，溯源，發出告警。下面分析其生成原理。
警報事件由關聯指令和規則生成。 Alarm中顯示的告警信息是通過關聯規則匹配大量事件得到的。 OSSIM 5以後，系統採用圖形顯示OSSIM系統。報警模式，便於管理員過濾大量安全事件的重要部分。告警事件生成流程如圖所示。
具體的Alarm生成步驟如下：
(1) 將日誌收集到 OSSIM；
（2）日誌統一規範化後，產生事件；
(3) 將這些事件導入關聯引擎；
(4) 根據關聯規則匹配新的事件。
通過上圖，即使是安全新手也可以輕鬆檢測出針對 SSH 服務的暴力攻擊。
在這張圖中，我們僅以系統入侵→蠕蟲感染→內部主機掃描警報為例。在系統損壞中，會出現內部主機的掃描行為。這種行為被懷疑是網絡蠕蟲的掃描。我們知道，掃描主機漏洞往往是通過蠕蟲傳播的。前提是蠕蟲經常被ICMP Ping包、TCP SYN、FIN、RST和ACK包檢測到，而且是隨機的。從圖中可以看出，系統定義了此類事件的風險值、掃描的持續時間以及源地址。 、目的地址、源端口、目的端口和關聯級別，OSSIM很容易發現這種異常行為。
5. 關聯規則說明
關聯分析的核心是由一個或一組關聯指令完成的。下面是一個 SSH 暴力破解的例子。 SSH蠻力破解（Brute Force）是從UNIX誕生之日就衍生出來的一種攻擊行為。據統計，大約50%以上的用戶名是root。低可靠性SSH服務器100次登錄成功，而高可靠性SSH服務器10000次登錄成功，則關聯引擎在一定時間內可以通過。 ，登錄次數，以及這些時間不同的源地址和相同的目的IP地址，以及這些IP地址來自哪些國家，以及他們的聲譽，以綜合判斷攻擊和應對。
檢測SSH暴力攻擊的關聯指令規則源代碼XML描述如下：
<directive id="50113" name="AV-FREE-FEED Bruteforce attack, SSH service authentication attack against DST_IP" priority="4">
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="1" occurrence="1" from="ANY" to="ANY" port_from="ANY" port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="2"occurrence="5"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="30"port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected"reliability="4"occurrence="10"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="60"port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="6"occurrence="50"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="300"port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="8"occurrence="500" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="36000"port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="10"occurrence="1000" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="86400"port_to="ANY" plugin_id="4003" plugin_sid="1"/>
<rule type="detector" name="SSH service authentication sucessful" reliability="10" occurrence="1" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="10" port_to="ANY" plugin_id="4003" plugin_sid="7"/>
</rules>
