OSSIM架構與組成綜述
一、背景
如果運維工程師缺乏高效的管理工具支持，就難以迅速處理故障。市面上有許多運維監控工具，如商業版的Solarwinds、ManageEngine以及WhatsUp等，還有開源的MRTG、Nagios、Cacti、Zabbix、OpenNMS、Ganglia等。
由於它們生成的數據彼此之間沒有關聯，無法共享，即便部署瞭這些工具，很多運維人員並沒有真正解脫。成千上萬條警告信息堆積在一起，很難找到問題的根源，結果被海量日志所淹沒，無法解脫束縛。 而且在傳統的運維環境中，查看各種監控系統需要多次登錄，瀏覽繁瑣的界面。絕大多數工作主要依賴手工操作，即使是簡單的系統變更，運維人員也需要逐一登錄系統。一旦遇到問題，管理員就得在各種平臺之間來回查詢，或者憑借個人經驗搜索關鍵故障詞。這種方式重復繁瑣，令人厭煩。 企業需要一個集成安全的運維平臺，以滿足專業化、標準化和流程化的需求，實現運維工作的自動化管理。通過關聯分析及時發現故障隱患。這一優秀的開源平臺名為OSSIM，即開源安全信息管理系統（Open Source Security Information Management）。接下來，讓我們瞭解一下OSSIM的基本結構和組成。
在結構上，OSSIM系統被視為一個開放框架，其核心價值在於集成各種開源軟件的創新優勢。它包含瞭C/S架構與B/S架構的模塊。然而，作為最終用戶，您主要會使用OSSIM的WebUI，它采用瞭B/S架構，並且使用瞭Apache作為Web服務器。OSSIM系統的結構示意圖如圖1所示。
圖1 OSSIM系統結構
第1層 數據采集層，利用各種采集技術來獲取流量信息、日志和各種資產信息，經過歸一化處理後傳送到核心層。該層展示瞭安全事件的來源，包括入侵檢測、防火墻以及重要主機發出的日志，它們根據發出機制被分為兩類：模式偵查器和異常監控（兩者都采集警告信息，其功能相互補充）。這些安全事件由它們采集後，再由Agent轉換為統一的格式發送至OSSIM服務器，這一層即是Sensor所完成的工作。
第二層 核心處理層，主導各類數據的深度處理，涵蓋運行監控、安全分析、策略整理、風險評定、聯系分析、安全角色管理、易受攻擊性掌管、事件排佈、報表整理等功能。在此層中，OSSIM 服務器獨領風騷，擔當主角。OSSIM 主服務器，其主要職能是匯集安全事件並對其進行聯系分析、風險評定以及嚴重性標註等。所謂“匯集”就是將所有系統產生的安全事件告警信息（Alarms）根據統一格式組織起來並將所有的網絡安全告警事件存儲到數據庫，由此完成瞭對網絡中產生事件的全面視閾。通過事件序列關聯及啟發式算法關聯，系統獲得瞭更優的誤報識別和偵查攻擊的能力。
OSSIM本質上通過對各種探測器和監控產生的告警進行格式化處理，再進行關聯分析，通過後期這些處理能提高檢測性能，即減少告警數量，減小關聯引擎的壓力，從整體上提高告警質量。
第3層 數據展現層，主要負責完成與用戶之間的交互，達到安全預警和事件監控、安全運行監控、綜合分析的統一展示，形式上以圖形化方式展示給用戶。Web框架（Framework）的控制臺界面，即為OSSIM的Web用戶界面，也就是OSSIM系統對外的門戶網站，主要由儀表盤、SIEM控制臺、警報控制臺、資產漏洞掃描管理、可靠性監控、報表以及系統策略等部分所組成。
二、 主要模塊的關系
OSSIM系統主要使用瞭PHP、Python、Perl和C等四種編程語言，從軟件層面上看OSSIM框架系統包括五大模塊：Agent模塊、Server模塊、Database數據庫模塊、Frameworkd模塊以及Framework模塊，邏輯結構圖見2所示。
圖2 Ossim系統邏輯結構
五個模塊之間的數據流向如圖3所示：
圖3 五大模塊的數據流向
① Agent至Server：來自各個傳感器的安全事件被對應Agent格式化後，以加密字符串傳給Server。
② Server至Agent：發送有關請求命令（request command），以字符串方式向Agent傳送，主要是要求Agent完成插件的啟動停止及獲取信息等。
③ Server至Frameworkd:發送請求命令，要求Frameworkd針對Alarm采取相應操作，例如執行外部程序或發出Email來通知管理員。
④ Framework至Server：發送請求命令至Server。要求Server通知Agent對插件（Plugins）進行啟動、停止等操作。
⑤ Framework至Frameworkd:發送請求命令，要求Frameworkd啟動OpenVas掃描進程。
⑥ Frameworkd至Framework:傳送OpenVas掃描結果在前端頁面中顯示。
⑦ Database至Agent和Server：向Agent和Server提供數據。
⑧ Server至Database：Server需要將Events、Alarms等數據存入數據庫並索引或更新操作。
⑨ Database至Frameworkd:在Frameworkd中的Openvas掃描和動作需要用調用數據庫裡的數據。
⑩ Frameworkd至Database：在Frameworkd執行過程中將Openvas掃描結果存入數據庫。
⑾Database至Framework:PHP頁面顯示需要調用數據庫的告警事件。
⑿Framework至Database：用戶參數設置信息需要存入數據庫。
三、安全插件（Plugins）
OSSIM系統中插件繁多，超乎你的想象，大致可將它們分為采集（Collection）插件和監視（Monitor）插件。每個插件都有又細分為ID和SID。采集插件主要通過SNMP、Syslog、WMI等協議進行采集，在Sensor中常見采集插件有ossec-single-line、ssh、syslog、wmi-system-logger等，其中SNMP與WMI協議需要Agent采集數據時主動進行所采集數據的抓取；Syslog協議則被動接收采集數據。具體如圖4所示。
圖4 查看插件
監控插件包括malwaredomainlist、nessus、nmap、ntop、ocs、ossim等，如圖5所示。
圖5 設置監控插件
當這些插件加載完畢之後，我們可以到Web UI中Configuration→Deployment→Components→Sensors欄目下的“Sensor Status”查看所添加的監控插件的工作狀態，如圖6所示。
圖6 查看Sensor監控插件工作狀態
註意：監控器相當於“督戰隊”，誰（關鍵服務進程）要是“罷工”瞭就會在設定的時間內重啟進程，這樣可以保護關鍵進程。
UNIX/Linux環境下，大部分系統都安裝有SNMP與Syslog工具。如果采集數據的目標系統為Windows，那麼考慮使用WMI協議，此時隻需要在Windows上進行相關配置，以便能夠遠程訪問，無需安裝額外的工具軟件。
四、 采集與監控插件的區別
在OSSIM系統的Sensor端包含瞭采集（Collection）和監控（Monitor）這兩類插件統稱為安全插件，它們都安裝在Sensor上。雖然都稱為插件可工作原理卻不同，檢測插件（Detector）是檢測器信息產生後，由代理自動向服務器發送，包括Snort、Apache等。而檢測器插件需要主動采集安全設備接口上的信息，這類插件可分為Snort、P0f、Prads、Arpwatch、Apache、SSH、Sudo等。
監控(Monitor)插件，必須由服務器主動發起查詢請求。監控插件中定義瞭需要主動采集的安全設備接口，該模塊接收控制中心發出的命令和查詢，在OSSIM系統中典型Monitor插件有Ntop、Nmap、Nessus等。讀者可在Alienvault控制臺的Sensor配置中（Configure Monitor Plugins）查看。OSSIM主要安全插件如表1所示。
表1 OSSIM主要插件分佈情況
對OSSIM插件位置的說明：在安裝時系統將支持的插件，全部復制到目錄/etc/ossim/agent/plugins/目錄中，如Nagios插件的擴展名為“.cfg”的文本文件，可以用任何編輯器修改，在每個插件配置文件中最難理解的當屬理解正則表達式(RegExp)。OSSIM下主要插件如圖7所示。
圖7 規則與插件路徑
在今後安裝過程中，選擇多少插件系統就在開機時加載多少（插件加載越多越占用內存）。具體查看插件詳情，訪問/etc/ossim/agent/config.cfg配置文件，而且在系統/etc/ossim/ossim_setup.conf中的[sensor]項中也詳細列出瞭監控插件（monitors）和檢測插件(detector)分別包含瞭哪些內容。在插件這方面，OSSIM默認提供瞭上百個插件，涉及8個大類，在表1-2中僅列出瞭一小部分，從插件分佈和數量來看，OSSIM系統幾乎包含瞭常用的插件類型。例如運維設備Cisco、CheckPoint、F5、Fortigate、Netscreen、Sonicwall、Symantec等，如果遇到無法識別設備的插件，隻能自己編寫插件，後續內容會詳細講到，已加載插件如圖8，圖9所示。
圖8 查看傳感器啟用的插件情況
從圖中看出，此Sensor系統中啟用瞭9個插件，如何在Web上展示出來呢？如圖所示總共184個插件在Plugins enabled中啟用瞭9個插件。
圖9 查看加載插件詳情
從圖10看出這裡顯示9個插件，我們可打開/etc/ossim/ossim_setup.conf文件查看。
圖10 從Ossim配置文件中查看插件
五、 檢測器（Detector）
OSSIM下的檢測器起到收集資源信息及監聽當前網段數據包的作用，主要包括ntop、prads、suricata、ossec等，相關內容在後續章節裡會詳細介紹。
六、 代理（Agent）
代理進程（由於Agent采用Python語言編寫，所以無需編譯就能在Python Shell環境運行）將運行在多個主機上，負責從安全設備采集相關信息（比如報警日志等），並將采集到的各類信息統一格式，最後將這些數據傳至Server。
從采集方式上看，Agent屬於主動采集，可以形象理解為由OSSIM Server安插在各個監控網段的“耳目”，由它們收集數據，並主動推送到Collector中，然後Collector又連接著消息隊列系統、緩存系統及存儲系統。
OSSIM中的這些代理腳本位於/usr/share/alienvault/ossim-agent/目錄下，腳本經過加密，以.pyo為擴展名。
列如OSSIM代理(ossim-agent)直接讀取存儲在/var/log/suricata/unified2.alert.1428975051日志。
suricata的報警輸出文件是/var/log/suricata/unified2.alert,這是由/etc/suricata/suricata.yaml配置文件在111行 # alert output for use with Barnyard2定義，所以ossim-agent直接讀取該文件就能顯示在SIEM控制臺中。
Agent的主要功能是接收或抓取Plugins發送過來或者生成的日志，經過歸一化處理，然後有序地傳送到OSSIM的Server，它的功能很復雜，因為它的設計要考慮到如果Agent和Server之間的網絡中斷、擁堵、丟包等情況。
在免費版的OSSIM系統中，其日志處理大部分情況下不能達到實時，但可以達到準實時（Firm Real-Time），通常會在Agent端緩存一段時間才會發送到Server端去。Agent會主動連接兩個端口與外界通信，一個是連接Server的40001端口（在/etc/ossim/agent/config.cfg配置文件的選項[output-server]中端口設置能看出通訊端口為40001），而另一個是連接數據庫的3306端口。如圖11所示。
圖11 日志歸一化處理、收集與存儲
原始日志被分成若幹段填充到相應的域中，這些字段如下：
l date、sensor、interface、plugin_id、plugin_sid、priority、protocol、src_ip、src_port、dst_ip、dst_port
l username、password、filename、userdata1、userdata2、userdata3、userdata4、userdata5、userdata6、userdata7、userdata8、userdata9
其實Sensor的輸出數據就是Ossim Server的輸入“原料”，我們可在WebUI中查看Sensor的output情況。如圖12所示。
圖12 Sensor輸出
七、報警格式的解碼
報警信息的接收過程中，為瞭應對報警信息格式的變化，OSSIM采用基於正則表達式的方法對報警信息進行匹配，解析報警事件獲取關鍵信息。正則表達式是一串記錄文本規則的代碼組合，它的作用是用來進行文本匹配。例如對空白字符、數字字符、中英文字符、IP和 E-mail地址等匹配，簡單的說它就是一個普通的字符查找串。
例如，下面對一段Snort報警信息進行正則表達式的匹配。
5/26-01:02:17.670721 [**] [1:1419:9] SNMP trap udp [**] [Classification: Attempted
Information Leak] [Priority: 2] {UDP} 20.20.13.17:162 -> 20.20.20.78:162
<ids>
<name>snort</name>
<method>net_socket</method>
<regex>^(d+/d+-d+:d+:d+).d+s+[**] [d:(d+):d+] .+[Classification: (.+)]
[Priority: (d)] {(.+)} (d+.d+.d+.d+)p*(d*)->(d+.d+.d+.d+)p*(d*)</regex>
<order>time,id,classtype,priority,protocol,srcip,srcport,dstip,dstport</order>
<mapping>snort_classtype,snort_id</mapping>
</ids>
這樣通過正則表達式可以提取時間、id、分類、報警級別、協議、源IP、源端口、目的IP 和目標端口等信息。接著再將這些字段逐個存儲為標準化的表中，最後通過Web界面展現。
八、OSSIM Agent
Agent運行在Sensor中，負責從各安全設備、安全工具的插件中采集相關信息(比如IIS服務日志、Snort報警日志等)，並將采集到的各類信息統一格式，再將這些數據傳至Server，例如將Snort系統產生的報警信息收集並存儲在OSSIM Server中。
OSSIM Agent中所有腳本采用Python編寫，相關目錄在/etc/ossim/agent/，代理插件目錄在/etc/ossim/agent/plugins/，配置文件路徑：/etc/ossim/agent/config.cfg，OSSIM系統的代理信息查看方法，通過Analysis→Detection下的HIDS標簽中Agents查看。結構如圖13所示。
圖13 Agent結構
- 40002/tcp： 監聽服務器的原始請求。
- Listener： 接收服務器連接請求。
- Active： 接收服務器輸入並且根據請求掃描主機。
- Engine： 管理線程，處理監視器請求。
- Detector Plugin：讀取日志和進行歸一化處理。
- Monitor Plugin：請求監視器數據。
- DB-Connect： 連接到本地/遠程OSSIM數據庫。
- Watchdog： 監視進程啟動/停止進程，檢查各插件是否已經開始運行，如遇意外，它會發現並重啟相關進程，它自動檢查時間為180秒，重啟進程時間為3600秒，其值可以在/etc/ossim/agent/config.cfg配置文件中修改。
註意：OSSIM系統中出瞭引入HIDS（通過OSSEC實現），還引入瞭NIDS（通過suricata實現），因為基於主機的入侵檢測系統還無法完全滿足網絡安全需要，NIDS可以捕捉和分析網絡數據包也分析協議。NIDS可以部署在各個網段，隻對監控網段進行監聽，不會影響網絡的運行。但做為Sensor也有缺點，如果網絡流量一旦超過閾值，就會導致丟包。
OSSIM中定義的大部分插件其日志都默認存放在/var/log/syslog中，所以自定義插件式往往需要修改日志的存放位置，在本書後面的例子中將詳細講解。
表2分析瞭目錄/etc/ossim/agent/plugin/中主要插件的日志輸出情況，通過該表我們能夠很容易的瞭解正則表達式的匹配情況。我們進入/etc/ossim/agent/plugings/目錄，其下有197個插件，如何能瞭解每個插件的日志的匹配情況呢？例如SSH插件對應的文件為ssh.cfg，記錄的日志文件為/var/log/auth.log，匹配的詳情我們通過以下命令實現(在OSSIM 4.4之後的版本中已去除瞭regexp.py調試腳本，大傢可以到作者博客下載該腳本 ，以便完成後續試驗)。
下面看個Apache訪問日志的例子，首先在/var/log/apache2/access.log中的兩條日志如下：
圖14 Apache日志實例
插件檢測格式：
./regexp.py log_filename regexp modifier
- y:顯示不匹配的行
- v: 顯示匹配的行
- lq: 隻顯示摘要
如同在Linux定義別名一樣，在regexp.py腳本中也定義瞭別名，區別是它采用aliases定義，詳情如下：
圖15 定義別名
為瞭方便插件內容的定義，插件中使用瞭經常用到的內容來定義別名，這樣做的好處是當今後在定義某一插件內容時，便可使用已定義的別名代替那個元素，比如用IPV4代替d{1,3{.d{1,3}.d{1,3}d{1,3}的定義。由此可知，插件中定義的Apache訪問日志的正則表達式為：
regexp=(IPV4) (S+) (S+) [(?P<date>(dd)/(www)/(dddd):(dd):(dd):(dd)).+"(?P<info>.+)" (?P<sid>d+) (S+)
通過插件匹配的詳細結果如下：
圖16 Apache匹配結果
由此可見，經過處理後的日志內容並沒變，為瞭適應SIEM事件顯示需要，實際日志中各項的排列順序發生瞭改變，目的是方便閱讀，方便更好的展示在SIEM控制臺上。再接著看SSH和Snare的日志。
#/usr/share/ossim/scripts/regexp.py /etc/ossim/agent/plugins/ssh.cfg /var/log/auth.log q
圖17 SSH匹配結果
又例如：
#/usr/share/ossim/scripts/regexp.py /var/log/snare2.log /etc/ossim/agent/plugins/landesk.cfg q
Multiple regexp mode used, parsing /etc/ossim/agent/plugins/landesk.cfg
—————————————————————————–
Rule: Landesk-sync-job-successed
Matched 273 times
Counted 274 lines.
Matched 273 lines.
瞭解OSSIM的其他插件，我們參看下方的列表：
九、 代理與插件的區別
初學者常混淆代理和插件的概念，Sensor（傳感器）指軟件和硬件的傳感器被安裝在網絡中收集和發送數據，而代理是運行在傳感器上，用來收集和發送數據到服務器的一段腳本，一個插件需要瞭解特定系統的日志格式（例如防火墻、IDS），並通過插件來采集數據。
系統中如果啟用插件越多，那麼采集到網絡中各種數據就越全面，在Sensor中加載過多的插件，將會占有OSSIM Server的數據庫空間，下面的這條經驗值需要讀者瞭解，OSSIM系統中每條事件，約占用1KB存儲空間，而1millions的事件量，大約占1.5GB空間。
十、 傳感器（Sensor）
傳感器（Sensor）俗稱探針，用來收集監控網段內主機的信息，它工作在網卡的嗅探模式。
傳感器工作在一臺Debian Linux主機上，通過ISO鏡像安裝，對於新手來講非常容易操作，他的目的是收集信息，發送給OSSIM Server。在一個分佈式OSSIM系統平臺上，可以有十多個傳感器協同工作。傳感器可以收集來自多個數據源的數據包，包括來自主機的，也包括來自網絡的數據包，另外傳感器除瞭收集數據（比如SPAN，Agent）以提供分析之外，還具有過濾功能可以通過Agent裡面的plugin實現過濾冗餘和無效數據的功能，已達到減少OSSIM Server端數據量，提高數據速度的效果。舉個例子在對於來自同一個IP地址的數據，傳感器可以通過模式匹配的方法來判斷冗餘數據，最終聚合成很少量的數據傳送給OSSIM Server。
另外要主機，傳感器能夠和本地代理（比如Ossec agent,Snare），事件收發器通訊，但傳感器之間並不直接通訊。
OSSIM系統中，把Agent和插件構成的一個具有網絡行為監控功能的組合稱為一個傳感器，Sensor的功能范圍主要有：
- 入侵檢測(最新版已換成支持多線程的Suricata)
- 漏洞掃描(OpenVas、Nmap)
- 異常檢測(P0f、Prads、ARPWatch等)
Arpwatch主要監視網絡中新出現的MAC地址，它包含1個監視庫，名為arp.dat，在OSSIM中位於/var/lib/arpwatch/arp.dat，所以它同樣是AIDE監控的對象。
OSSIM具有強大的網絡威脅監控，流量監測的功能，但無法將威脅阻斷，所以不能將其串聯在防火墻鏈路，最佳方法是作為旁路鏈接使用,這一點就像部署審計設備一樣。
在OSSIM系統的傳感器的狀態可在Configuration→Deployment→Components→Sensors中查看詳情，如圖18所示。
圖18 多傳感器詳情
在OSSIM分佈式應用中有多個傳感器，這時在圖182中可以查看每個傳感器的工作狀態，包括IP地址、名稱、優先級、工作狀態等信息。
OSSIM系統發展到4.3版本之後，傳感器查詢方式發生瞭變化，路徑為Configuration→Deployment→Alienvault Center→Sensor Configuration→Detection，而且啟動程序也發生些的變化，由Suritata代替瞭Snort，如圖1-23所示。OSSIM Server默認就啟動ntop、ossec、prads、suricata這4項，Snort為停止狀態。這5個檢測器的狀態無法通過Web界面直接進行修改。
圖19 傳感器詳情
大傢如果使用OSSIM4.1系統，查看系統檢測插件時，Snort為啟動狀態，但OSSIM 4.2後的系統Snort是關閉狀態，代替它的是性能更強大的Suricata系統，同一個系統中兩者隻能任選其一。而Prads（Passive RealTime Asset Detection System）是OSSIM 4.2之後又一款被動實時資產探測系統，它的主要功能就是被判斷資產特征，如同一個指紋庫，保存瞭各種系統特征，可以識別資產的操作系統類型、由ARP發現新增資產，根據開放端口判斷打開的網絡應用，因為各種設備和服務打開狀態並不是一成不變，所以需要用Prads來監控變化後的狀態，有關它的實際應用參考OSSIM中主動與被動探測工具（arpwatch+p0f+pads）組合應用
十一、關聯引擎
關聯引擎（Server）是OSSIM安全集成管理系統的核心部分，它支持分佈式運行，負責將Agents傳送來的歸一化安全事件進行關聯，並對網絡資產進行風險評估。其工作流程見圖1-24所示。
圖20 關聯引擎的工作流程
OSSIM服務器的核心組件功能包含：事件關聯、風險評估和確定優先次序和身份管理、報警和調度、策略管理、IP信譽管理等，其配置文件在/etc/ossim/server目錄中，文件分別為：
- alienvault-attacks.xml
- alienvault-bruteforce.xml
- alienvault-dos.xml
- alienvault-malware.xml
- alienvault-network.xml
- alienvault-scan.xml
- alienvault-policy.xml
以上這些文件由開源OSSIM免費提供，策略為84條，在USM中則具有2千多條，這一數量遠高於國內的IDS硬件設備，在OSSIM中它們采用XML編寫易於理解，維護簡單。
圖21 關聯引擎的結構
關聯引擎結構如圖21所示，其工作過程由下面6個步驟組成：
1）.40001/tcp:Server首先監聽 40001/tcp 端口，接收Agent 連接和Framework請求。該端口大小由OSSIM系統在配置文件/etc/ossim/ossim_setup.conf中定義。
我們在OSSIM系統中通過以下命令可以清晰查看到其工作端口。
#lsof –Pnl +M –i4 |grep ossim-ser
2）. Connect:當連接到端口為40002指定的Agent時，連接到端口為40001的其他Server 對采集事件進行分配和傳遞。該端口大小在/etc/ossim/agent/config.cfg文件的[output-idm]項配置，不建議更改。
3）. Listener:接收各個Agent的連接數據，並細分為Forwarding Server連接、Framework連接。
4）.Connect:主要是OSSIM DB連接、Snort DB連接和OSSEC DB連接
5）. Agent Connect:啟動Agent連接，Forwarding Server連接。
6）. Engine:事件的授權、關聯、分類。
在OSSIM系統關聯引擎的狀態可在Configuration→Deployment→Components→Servers中查看，如圖22所示。
在OSSIM系統關聯引擎的狀態可在Configuration→Deployment→Components→Servers中查看，如圖22所示。
圖22 關聯引擎模塊工作狀態
關聯引擎啟動
OSSIM系統會啟動關聯引擎，有時系統調試也需要用到手工啟動方式，命令如下：
#ossim-server -d -c /etc/ossim/server/config.xml
OSSIM-Message: Entering daemon mode…
關聯引擎+關聯規則能發揮多大作用，大傢參考日志聚合與關聯分析技術實例視頻演示
查看Ossim Server版本
#ossim-server -v
Alienvault OSSIM Server Version : 5.1.1.free.commit:(1:5.1.1-31) (c) 2007-2013 AlienVault
十二、 數據庫
Ossim關聯引擎（簡稱OSSIM Server）將事件關聯結果寫入數據庫。系統用戶可通過Framework(Web前端控制臺)對Database進行訪問。數據庫中alienvault.event表是整個系統事件分析和策略調整的信息源。OSSIM從總體上將其劃分為事件數據庫(EDB)、知識數據庫(KDB)、用戶數據庫(UDB)。OSSIM數據庫用來記錄與安全事件關聯及配置等相關的信息，對應於設計階段的KDB和EDB的關聯事件部分；在Framework中使用ACID/BASE來作為Snort數據庫的前端控制臺，對應於設計階段的EDB。此外ACL數據庫相關表格可包含在OSSIM數據庫中，用來記錄用戶行為，對應於設計階段的UDB庫。
Ossim數據庫分關系型數據庫和非關系型數據庫。OSSIM系統默認使用的MySQL監聽端口是3306，為增其其處理性能，在Alienvault USM中采用MongoDB作為非關系型數據庫。2013年將OSSIM 4.2發行版中用Percona_server5.5替換瞭原來的MySQL 5.1，由於使用瞭XtraDB存儲引擎，而且對MySQL進行瞭優化和改進，使其在功能和性能上明顯提升。在2015年底的最新版本USM 5.2中將Percona_server升級為功能強大的5.6.25。
如果大傢對OSSIM的架構和組成的瞭解還意猶未盡，敬請參閱由清華大學出版的《開源安全運維平臺OSSIM最佳實踐》一書。
參考資料：
1. 李晨光.開源安全運維平臺OSSIM最佳實踐【M】北京：清華大學出版社，2016.1
該書前言、目錄PDF下載地址：《開源安全運維平臺-OSSIM最佳實踐》文前
查看3D圖書： OSSIM最佳實踐3D.zip
2.《Ossim應用指南》入門篇 《Ossim應用指南》入門篇
3.最新開源可視化安全管理平臺Ossim5.0使用
最新-開源可視化安全管理平臺Ossim5.0使用「預覽」
4.詳解Ossim 4.3控制臺 詳解Ossim 4.3控制臺
5.OSSIM讓網絡攻擊無所遁形 OSSIM讓網絡攻擊無所遁形
6.OSSIM中主動與被動探測工具（arpwatch+p0f+pads）組合應用 OSSIM中主動與被動探測工具（arpwatch+p0f+pads）組合應用
7.基於OSSIM平臺的漏洞掃描詳解 基於OSSIM平臺的漏洞掃描詳解
全文PDF下載：OSSIM架構詳解