客製化裝置支援模組　QRadar擔綱資安守護者

目前IBM QRadar使用裝置支援模組（Device Support Module，DSM）來支援各式各樣的日誌來源，例如各種防火牆或路由器的日誌。正是有支援各裝置的DSM，QRadar才能扮演企業資安中心的角色，收集各日誌來源的資訊並回報資安事件。

IBM定期更新DSM，以確保QRadar能夠正確剖析來自外部裝置的各種安全事件資訊。雖然QRadar內含許多已定義好的各式DSM，但依據使用者的裝置組態設定不同，使用者可以調整DSM組態或是自訂DSM，以符合使用者環境的需求，完整剖析來自使用者裝置的日誌，收集安全資訊。

何謂DSM

裝置支援模組（DSM）是一種代碼模組，可剖析日誌來源中的事件，並將它們轉換為QRadar能夠使用及顯示的格式。現有許多日誌來源的DSM可供使用，但可能需要依照需求來開發，可參考開發DSM（https://developer.ibm.com/qradar/develop-dsm/）網頁說明。

QRadar能夠透過使用稱為DSM的外掛程式檔案，來蒐集安全產品的事件。此外，可以使用DSM編輯器建立DSM。DSM編輯器提供簡易的方式以建立自訂剖析器，將事件導入QRadar。從IBM QRadar主控台，即可存取DSM編輯器。

如何開啟DSM編輯器

可以從「日誌活動」標籤開啟DSM編輯器，或者如果本身是管理者，就能夠從「管理」標籤中開啟編輯器。例如，傳送到系統的事件未經適當處理，可從「日誌活動」標籤選取事件資料並傳送至DSM編輯器。對於尚未傳送到系統的事件，操作者必須是系統管理者，並從「管理」標籤存取DSM編輯器。

如果要從管理標籤開啟DSM編輯器，請遵循下列步驟：

STEP 1：在導覽功能表上，按一下管理。

STEP 2：在資料來源區間，按一下DSM編輯器。

如果要從日誌活動標籤開啟DSM編輯器，則遵循下列步驟：

STEP 1：按一下日誌活動標籤。

STEP 2：暫停送入的即時事件，然後醒目顯示一個或更多事件。

STEP 3：在導覽功能表上，選取動作→DSM編輯器

認識DSM編輯器

與其以手動方式建立日誌來源延伸以修正剖析問題，或增加新的日誌來源類型支援，建議用戶改用DSM編輯器，DSM編輯器將為你的資料提供不同的視角。可使用DSM編輯器來擷取欄位、定義自訂事件內容、分類事件，以及定義新的QID定義，詳細說明如下：

工作區

工作區會顯示未處理的事件資料。用戶可使用範例事件有效負載來測試日誌來源類型的行為，接著工作區區域會即時顯示所擷取的資料。

所有的範例事件會從工作區傳送到DSM模擬器，DSM將剖析事件內容並查閱QID對映，其結果會顯示於日誌活動預覽區間。可按一下編輯圖示，在編輯模式中開啟內容。

在編輯模式中，可以貼上多達100,000字元的事件資料到工作區中，或是直接編輯資料。當編輯內容標籤上的內容時，有效負載中的相符項在工作區會加上醒目標記，自訂內容以及置換的系統內容，也將會在工作區中被加上醒目標記。

日誌活動預覽

日誌活動預覽將模擬工作區中的負載會在日誌活動檢視器內如何呈現，也會顯示每一項受支援的標準內容。在其中標示為星號（*）的欄位，例如事件名稱、嚴重性、低層次種類及QID，會從QID對映中讀取。

從QID對映中讀取的欄位，無法從工作區中的未處理事件資料進行逐項剖析，因此無法被用戶定義或編輯，可藉由從事件對映標籤選取對應的事件ID和類別組合來調整它們的值。接著，可按一下編輯，以重新將事件對映到系統中存在的不同QID記錄或新建的QID。

按一下配置圖示，以選取在日誌活動預覽視窗中欲顯示或隱藏的欄位，以及重新排序欄位。

內容

內容標籤包含了組成DSM配置的系統及自訂內容的結合集。配置系統內容與配置自訂內容有所不同。可藉由選取置換系統行為勾選框並定義表示式，來置換內容。

有效負載中的相符項，會在工作區中的事件資料被醒目標記。取決於你所擷取的內容，醒目標記的色彩會有兩種色調，例如橘色的醒目標記代表捕捉群，而亮黃色醒目標記則代表所指定的其餘正規表示式。工作區的標記將顯示是否具有正確的正規表示式。如果一個內容有多個表示式，當表示式是焦點時，工作區中的醒目標記反映與該表示式相符的內容。當焦點是整體內容時，醒目標記會變為綠色，並依優先順序標示與聚集表示式集合相符的內容。

在格式字串欄位中，捕捉群使用$<數字>表示法來呈現。例如，$1代表正規表示式中的第一個捕捉群，$2是第二個捕捉群，以此類推。

可以新增多個表示式到同一個內容，而且能夠藉由拖放表示式到清單頂端來指派優先順序。此外，任何內容旁的警告圖示，則是表示用戶未新增表示式。

事件對映標籤

事件對映標籤，顯示系統中所選日誌來源類型的所有事件ID和種類組合。建立新的事件對映時，其會新增至事件對映標籤中顯示的事件ID和種類組合清單中。一般來說，事件對映標籤顯示所有事件ID和種類組合，以及它們所對映的QID記錄。

配置標籤

可以針對JSON格式的結構化資料，來配置「內容自動偵測」功能。依系統預設，此「內容自動偵測」功能是停用的。

當啟用配置標籤上的內容自動偵測功能，內容偵測引擎會自動產生新的內容，以擷取日誌來源類型所接收的事件中存在的所有欄位。可在自動偵測完成臨界值欄位中，配置要檢查新內容的連續事件數目。新偵測到的內容，將出現在內容標籤中，並且可用於規則及搜尋索引。

然而，如果在臨界值前未探索到新的內容，系統會視為完成偵測程序，並且將停用該日誌來源類型的內容自動偵測。可隨時在「配置」標籤上手動啟用「內容自動偵測」。

建立自訂DSM

DSM編輯器是QRadar 7.2.8導入的新功能，讓使用者建立自訂剖析器，以更便利且使用者友善的方式將事件導入QRadar中。這裡先概略瞭解如何使用編輯器，然後建立延伸以分享所創建的DSM。

將資料導入QRadar

首先，第一件事就是確保能夠將自己的資料導入QRadar，最簡單的方式是透過514埠上的Syslog將這些事件轉送到QRadar。有時會需要使用其他方式將資料導入QRadar，例如「日誌檔通訊協定」（Log File Protocol）（透過SFTP/SCP取得檔案的逐行讀取器）或是JDBC驅動程式。如果需要呼叫特定的REST API以取得事件，應該參閱相關手冊，例如使用「應用程式架構」建立你自己的「通訊協定」（https://developer.ibm.com/qradar/2017/02/28/app-framework-build-protocol/）。

使用DSM編輯器

一旦讓事件進入到QRadar，可以選取想要作為DSM基礎的事件，並直接將其傳送到編輯器（圖1）。

接著，會進入到DSM編輯器的預設操作畫面。如圖2所示，右上方將看到事件窗格，其中包含在編輯器中所使用的範例事件。左邊顯示的則是可從事件擷取的內容清單，在右下方則有可在日誌活動檢視器以及Ariel查詢中所觀察到的最終正規化事件預覽。

可以選取在現行日誌來源類型（SIM Generic Log DSM）旁的〔變更〕按鈕，並建立新的日誌來源類型，以符合自身希望在QRadar使用者介面中呼叫DSM的方式，如圖3所示。

現在，可以開始將正確的正規表示式填入正規化欄位，以剖析出事件中的相關資訊。在此必須留意的是，「事件種類」與「事件ID」為必填欄位，因為QRadar用它們來將意義對映到事件。「事件ID」應該是事件中定義事件的部分，且以種類作為進一步細分的方式。如果未有明顯的種類，那麼慣例是靜態地設定類別為「裝置類型」名稱（圖4）。一旦建立了qidmap項目，接著就可以將其對映到從事件剖析出的「事件ID/事件種類」組合（圖5）。在「事件對映」標籤中的新項目內輸入「ID/類別」組合（圖6），並且選擇與你事件相關的Qidmap項目類別。

在以所希望的方式剖析正規化事件欄位之後，現在可以針對所需的任何自訂內容建置剖析，以善用你的事件（圖7）。可以新增自訂內容的剖析，其方式是按一下內容窗格上的加號（新增）按鈕，然後選取要使用的內容。

如果可能的話，應該使用現有的內容進行剖析，因為客戶可能已經在其規則及搜尋中使用此內容。如果無法找到滿意的內容據以建置你的剖析，那麼應該新增自己的內容。一旦自訂內容被選取進行DSM剖析，可用建置正規化欄位的同樣方式建置正規表示式。

不過，自訂內容的處理方式有一些不同。首先，選擇為規則與報告而優化內容，這代表在事件進入時QRadar會計算內容，且對所有事件都會執行計算以達成優化。第二則是事件的選擇性，此項可設定內容只在某些事件中觸發（Fire）。

第三個不同之處則是自訂內容能夠設定為依預設停用，如此一來，客戶就能夠在需要時啟用此自訂內容。

必須注意的是，「身分欄位」是用來設定兩個欄位（例如使用者與IP）之間關聯或解除其關聯的特殊欄位。此項用於使用者資產追蹤。請參閱「身分入門」（Identity Primer）獲取相關資訊。

匯出你自訂的DSM

自訂DSM在匯出及打包的方式，與任何內容匯出的方式相同。然而，需要謹記幾個要點：DSM能夠獨立匯出，但是匯出時將不隨附任何自訂內容，或與用來搭配自訂DSM而建立的qidmap項目。當進行匯出時，應該考量下列類別作為一整個套件，以取得客戶使用的自訂DSM完整內容︰

‧sensordevicetype（DSM本身） ‧qidmap（自訂qidmap項目以及與你的事件之對映） ‧customproperty（用來搭配DSM而建立的自訂內容）

一旦已建立匯出，就能夠以如同應用程式的方式來打包匯出的DSM，並送到App Exchange。可參閱「打包你的延伸」頁面（https://developer.ibm.com/qradar/required-collateral-for-submitting-your-extension-for-validation/）以獲得相關處理流程的詳細資料。

透過DSM向UBA提供內容

現在QRadar已具備User Behaviour Analytics（UBA）應用程式，但應該熟記DSM如何提供資料至UBA。UBA是透過規則驅動的引擎，從送入的事件中獲取使用者資料，並針對使用者行為提供用戶更為深入的觀察。

用戶可透過記住幾個重點，來協助確保UBA所取用的資料皆為最高品質。在高層次中，UBA規則將用於查看事件分類，並將之歸納於以下三個儲存區：鑑別成功、鑑別失敗以及特權行動。這些分類的作用在於發現使用者，並根據使用者所採取的行動和那些行動所處情境，來追蹤與使用者名稱相關聯的風險評分。強化與UBA整合程度的關鍵，在於用戶可正確分類事件且所剖析的是正確的使用者名稱。

用戶必須確保其所剖析的是適當且有意義的使用者名稱，UBA一律假設所剖析的使用者名稱是採取行動的使用者，而非受該行動影響的使用者。對於用戶來說，最簡單的思考方式是，將使用者名稱視為類似資料庫主鍵（Primary Key）的重要資料，而主鍵的正確性對於UBA來說非常重要，可讓UBA不至於浪費時間在處理無用的使用者名稱上，並且能夠提供品質良好的分析。

舉例來說，如果一個使用者登入失敗事件有正確的使用者名稱，但是之後的另一個特權行動有錯誤的使用者名稱，這兩個事件看起來像是來自兩個不同的低威脅程度使用者，然而，事實上卻是UBA應該產生作用的高威脅程度使用者事件。

鑑別成功則是在使用者狀態變更為作用中時進行查看（非常類似於身分追蹤的做法）。因此，用戶開始提供資料到UBA最簡單的方式是確保：

1. 適當剖析使用者名稱。

2. 如果剖析的使用者名稱正在登入，則使用下列分類之一來對映事件：

鑑別。管理者登入成功

鑑別。鑑別伺服器登入成功

鑑別。已開啟鑑別伺服器階段作業

鑑別。FTP登入成功

鑑別。一般已開啟成功

鑑別。主機登入成功

鑑別。使用預設使用者名稱/密碼登入成功

鑑別。郵件服務登入成功

鑑別。細項登入成功

鑑別。密碼變更成功

鑑別。專用權提升成功

鑑別。遠端存取登入成功

鑑別。Samba登入成功

鑑別。SSH登入成功

鑑別。已授與系統安全存取權

鑑別。Telnet登入成功

鑑別。VoIP登入成功

鑑別。Web服務登入成功

鑑別。資料庫登入成功

鑑別。IKE鑑別成功

鑑別。RADIUS鑑別成功

鑑別。工作站鑑別成功

鑑別。TACACS鑑別成功

鑑別。使用者登入成功

以上這些事件，應該在身分事件中列入考量。

處理鑑別失敗的方式，非常類似於鑑別成功。然而，觸發UBA規則的情境不盡相同，其根據在於使用者是否為已知的活躍使用者或是不明使用者。UBA風險評分會隨著每次鑑別失敗而升高評分，因此能否獲取正確內容相形重要。其準則如下：

1. 使用者名稱經適當剖析。

2. 如果剖析的使用者名稱鑑別失敗，在事件對映中使用以下其中一個分類：

鑑別。管理者登入失敗

鑑別。鑑別伺服器登入失敗

鑑別。FTP登入失敗

鑑別。一般鑑別失敗

鑑別。主機登入失敗

鑑別。使用預設使用者名稱/密碼登入失敗

鑑別。郵件服務登入失敗

鑑別。細項登入失敗

鑑別。密碼變更失敗

鑑別。專用權提升失敗

鑑別。遠端存取登入失敗

鑑別。Samba登入失敗

鑑別。SSH登入失敗

鑑別。Telnet登入失敗

鑑別。VoIP登入失敗

鑑別。Web服務登入失敗

鑑別。資料庫登入失敗

鑑別。IKE鑑別失敗

鑑別。RADIUS鑑別失敗

鑑別。TACACS鑑別失敗

鑑別。使用者登入失敗

鑑別。工作站鑑別失敗

特權行動是關聯於使用者名稱的事件，其本身不見得是高風險事件，但是在鑑別失敗後或許多連續事件後，便會增加其風險程度。用戶在使用這些不常出現（且也不應常出現）的分類時應多加小心，因為稍有不慎可能會導致誤判狀況累積，原本不應該提高的使用者風險評分也可能隨之提高。以下是可遵循的通用規則：

1. 用戶應確認使用者名稱剖析正確！這需要再三確認，因為錯誤的使用者名稱比其他事件更容易使UBA的有效性下降。

2. 用戶應適當使用下列分類，確保這些分類未使用於模擬兩可的事件。用戶所剖析的使用者名稱應為採取行動的使用者（對於使用者新增∕修改的事件來說，此點尤其重要）：

鑑別。已新增群組

鑑別。已變更群組

鑑別。已新增群組成員

鑑別。已新增電腦帳戶

鑑別。已變更電腦帳戶

鑑別。已新增原則

鑑別。已變更原則

鑑別。已新增授信網域

鑑別。已新增使用者帳戶

鑑別。已變更使用者帳戶

鑑別。已指派使用者權限

鑑別。專用權提升成功

鑑別。已移除電腦帳戶

鑑別。已移除群組成員

鑑別。已移除群組

鑑別。已授予系統安全存取權

鑑別。已移除系統安全存取權

鑑別。已移除授信網域

鑑別。已移除使用者帳戶

鑑別。已指派使用者權限

鑑別。已移除使用者權限

系統。已解除安裝應用程式

系統。失敗的應用程式修改

系統。失敗的配置修改

系統。失敗的檔案修改

系統。失敗的主機原則修改

系統。失敗的登錄修改

系統。失敗的服務修改

系統。失敗的堆疊修改

系統。檔案已建立

系統。檔案已刪除

系統。已建立主機原則

系統。已刪除主機原則

系統。登錄刪除

系統。已解除安裝服務

系統。成功的配置修改

系統。成功的檔案修改

系統。成功的主機原則修改

系統。成功的登錄修改

系統。成功的服務修改

系統。成功的堆疊修改

系統。系統配置

系統。服務已停止

系統。系統中止

系統。已安裝服務

系統。登錄新增

系統。服務已啟動

系統。已安裝應用程式

IBM團隊也有建置與已鎖定及已停用使用者登入行為的相關規則，如果碰到此類事件，可與IBM Security Technology Alliances團隊聯繫，獲取處理相關事件的建議。

除了DSM外，也可以使用規則套件，透過感應事件直接向UBA提供內容。UBA會尋找24000到25000的分類，如果有自訂內容senseValue，UBA會使用該內容為事件的「風險」。

最簡單的UBA整合方式可能是建立規則，搭配尋找特定qid的測試。

舉例來說，如果友機(partner) X具有qid -「偵測到惡意執行檔在主機上執行」，則用戶可只為該qid建立規則，並在規則回應產生感應事件（Sense Event）時：

放置senseValue=10在事件說明中

高層次種類 = 感應

低層次 = 下列任何一項

事件名稱 - 可能為「*供應商名稱*：偵測到惡意執行檔在主機上執行」

在此的觸發事件也會需要使用者名稱（分派的新事件會繼承src/dest埠、IP、使用者名稱及其他內容）

感應事件的低層次分類：

感應。使用者行為

感應。使用者地理位置

感應。使用者時間

感應。使用者存取

感應。使用者專用權

感應。使用者風險

感應。感應攻擊

感應。資源風險 感應。UBA Machine Learning Anomaly（機器學習異常）

自訂DSM中的身分事件

用戶或許無法完全理解QRadar用以處理使用者及資產相關資訊的建置方式。資產與使用者資訊都與「身分」這個概念交錯在一起，用戶可能對於如何適當地處理這些事物感到困惑。此文旨在說明將此類資訊導入QRadar的最佳做法。

在最高層次，身分意指在以下內容之間建立關聯：

1. 使用者名稱與「資產識別資訊」（其中包括IPv4或IPv6位址、NetBIOS名稱、DNS名稱／主機名稱或MAC位址）

2. 兩項「資產識別資訊」（此概念主要用於連接實體機器與其網路身分）

因此，要讓事件與身分相關的最基本需求為至少包含兩項識別資訊。

然而，事件若僅包含IP及使用者名稱或是IP及MAC等識別資訊仍是不夠的，事件必須能夠清楚說明兩者之間的關聯。

因此，在建置自訂DSM的時候，必須考量兩個基本案例。在設定身分時，第一個考量的事件類型是登入。下列事件種類可算是登入：

主機登入成功

細項登入成功

鑑別伺服器登入成功

管理者登入成功

使用預設使用者名稱／密碼登入成功

SSH登入成功

遠端存取登入成功

使用者登入成功

請務必記得，在考慮事件情境時，應該運用自身最佳的判斷力。根據狀況不同，其他事件種類也可能算登入事件，而上面這些事件種類在某些情況下也許不算登入事件（應該在使用時評估為何該些種類不能算入）。

其他基本案例是資產識別案例。下列種類應該在使用該置換時加以考量：

1. DHCP成功

2. 指出查詢的主機名稱／DNS名稱所用IP的DNS查詢事件，以及建立IP位址與NetBIOS名稱間關聯的事件。

還有另一個案例，並未真正在DSM編輯器中涵蓋，此即登出案例。為了身分用途，QRadar可以追蹤登出以及登入。如果覺得此為必要（例如你的裝置重點在於身分管理，且登出追蹤至關重要），歡迎聯絡IBM Business Development團隊，獲得如何與QRadar開發團隊合作將此支援引進QRadar的相關資訊。

＜本文作者：IBM Security，位在台北南港的IBM 資安實驗室近年研發重點為打造智能資安中心（SOC）。從基礎防護如惡意郵件分析以及攔截、阻擋惡意DNS查詢（Quad9），到運用Watson進行智能事件分析，以及透過完整響應平台根除威脅，甚至打造情資分享平台讓企業能協同抵禦新型態攻擊。 ＞