上一篇有提到，我剛開始接觸 SIEM 的時候，面對 Alert 其實也是一筆一筆慢慢看。

從時間、IP、Port、Service、連線次數、傳輸量，再去看有沒有其他相關的事件，慢慢去判斷這個 Alert 到底是真的有問題，還是其實只是客戶環境裡面的正常行為。

但做了一段時間之後，又會碰到另外一個問題。

有些 Alert 明明昨天才看過，也已經跟客戶確認是正常的，結果今天又出現。

今天處理完，明天可能又再來一次。

如果每一次都重新調查，SOC 的時間很快就會被這些東西吃掉。

這也是這篇想講的東西：

當 SIEM 裡面開始出現大量 False Positive 跟噪音的時候，我以前是怎麼慢慢把它降下來的。

不到一天，就出現一萬多筆 Alert

我印象比較深的一次，是客戶的 SIEM 剛建置完成，資料開始進來之後，不到一天就已經產生一萬多筆 Alert。

這種狀況其實在系統剛建置完成的時候比較容易碰到。

因為這時候 SIEM 雖然已經開始收到客戶的資料，但很多客戶環境裡面原本就存在的正常行為，我們其實還不清楚。

哪些 Server 平常會互相連線？

哪些設備有固定排程？

哪些 Service 本來就在大量使用？

哪些流量對這個客戶來說其實很正常？

這些東西一開始都還要慢慢了解。

所以系統剛上線的階段，很多原本在客戶環境裡很正常的行為，也可能一直產生 Alert。

我自己印象中，當時數量很多的其中一種，就是內網 SMB 相關的連線。

企業內部本來就可能有很多 SMB 的使用情境，所以當大量內網設備開始產生這些行為時，Alert 很快就會累積起來。

而且這時候如果只是一直照著 Alert 一筆一筆看，其實很難處理得完。

【SIEM 剛建置後，Alert 是怎麼快速累積的】

一萬多筆 Alert，不代表真的有一萬種問題

碰到這種情況之後，我後來不會想著：

「我要怎麼把這一萬多筆全部看完？」

因為真的看不完。

反而會先去找，到底是哪些 Alert 一直重複出現。

例如某幾個 Source IP 是不是特別多？

是不是都在使用相同的 Service？

Destination 是不是集中在某幾台設備？

是不是某個 Network Segment 特別容易出現？

或者某一種類型的 Alert，出現的次數遠高於其他 Alert？

因為一萬多筆 Alert，不一定代表真的有一萬種不同的問題。

很多時候是少數幾種行為一直重複出現，最後才把 Alert 的總數堆得很高。

所以我會先從這些高頻的 Alert 開始處理，再去確認它為甚麼一直出現。

如果確認是客戶正常的行為，接下來才會開始想要怎麼調整。

確認是正常的，也不是直接把 IP 白名單

這邊是我自己後來比較在意的地方。

假設今天有一台內網設備一直產生 Alert，查完也跟客戶確認過，確定它是正常設備，而且目前看到的行為也是正常的。

最簡單的做法可能就是直接把這個 IP 加進 Whitelist。

Alert 的確可能馬上少很多。

但我通常不太會直接這樣做。

因為現在確認正常的，是這台設備目前看到的這個行為，不代表這台設備之後做甚麼事情都沒有問題。

假設今天確認的是：

Source IP
    +
SMB
    +
固定的 Destination IP

這個連線是客戶正常的使用方式。

那我比較希望排除的是這個已經確認過的行為，而不是把整個 Source IP 都排除掉。

所以我以前在處理這些 Alert 的時候，會依照客戶環境慢慢增加條件。

可能是：

Source IP
+
Service
+
Destination IP

如果這樣還不夠，有些情況可能還會再加：

Connection Frequency 或者 Traffic Volume

最後實際用哪些條件，還是要看客戶環境跟 Alert 的類型。

【直接 Whitelist IP vs 複合條件排除】

每個客戶的噪音其實都不太一樣

這也是為甚麼我覺得 SIEM 的 Tuning 很難直接複製。

有些客戶可能是某個 Network Segment 產生很多 Alert。

有些是某個 Service。

有些可能是特定 Source IP 一直連線到內網某一台設備。

有些則是設備本身的傳輸量就比較大。

所以以前實際調整時，我可能會從：

特定網段、特定 Service、Source IP、Destination IP、連線次數、傳輸量，或是多個條件組成的 Query 去處理。

有些情況也會依照產品能做到的功能，讓符合特定條件的行為不要再一直產生相同的 Alert。

但我不太會覺得：

「這套條件在 A 客戶有效，所以直接複製到 B 客戶就好。」

因為兩邊的環境可能完全不一樣。

同樣一個 SMB 行為，在某個環境可能很正常，換到另外一個環境就不一定。

所以很多時候還是得先了解客戶到底在做甚麼。

有些 Alert 不一定要直接排除，也可以調 Threshold

另外一種我以前會碰到的情況，是跟 Threshold（閾值）有關。

有些設備本來就會有比較大的傳輸量，或者連線次數本來就比一般設備高。

像 Backup Server 就是一個很好理解的例子。

如果它每天固定時間都需要進行備份，本來就可能出現大量的資料傳輸。

如果這個行為每次都會觸發 Alert，那就可以再去看目前的判斷條件是不是適合這台設備。

有些情況下，如果 Detection 本身支援調整 Threshold，就可能依照這台設備平常的使用狀況做調整。

但這也不是看到 Backup Server 就直接把 Threshold 拉高。

因為假設它平常都是固定時間、固定 Destination、固定 Service 在做備份，結果某一天突然在不同時間，對不同的 Destination 產生大量傳輸，那我還是會想知道發生甚麼事情。

所以 Threshold 有時候只是其中一個判斷條件，不一定是單獨使用。

【正常 Baseline 與異常行為的差別】

但不是每個客戶都願意把 Alert 排除

實際維運的時候還會碰到另外一種情況。

我們已經確認某些 Alert 是正常的，也問過客戶能不能針對這些情況做調整。

結果客戶可能會說：

「這些我還是希望全部保留。」

那就不能因為 SOC 覺得很吵，直接把這些 Alert 關掉。

這時候我以前在 Stellar Cyber 上會改成從 Dashboard 顯示的部分去處理。

例如使用 Filter，把已經確認過的正常行為，先從 SOC 平常看的 Dashboard 裡面排除。

這樣 Alert 或相關資料還是保留著。

只是 SOC 人員在平常監控的時候，不需要一直看到相同的雜訊。

後面如果真的需要調查，資料還是可以再查回來。

所以我自己後來會把這兩件事情分開看：

客戶要不要保留資料是一件事情，SOC 平常監控要不要一直看到它，是另外一件事情。

不同 SIEM 的實作方式當然不一定一樣。我當時是在 Stellar Cyber 上使用 Dashboard Filter，其他產品可能會透過 Query、View 或其他篩選功能來處理。

【保留資料 vs SOC Dashboard 顯示】

做一段時間之後，才開始比較有辦法看 High Risk

前面的事情持續處理一段時間之後，Alert 的噪音真的會少很多。

一開始可能打開 Dashboard 就是一大堆 Alert，甚至像我前面碰過的情況，不到一天就已經一萬多筆。

但慢慢把高頻的 Alert 找出來、確認、再根據客戶環境去做調整之後，那些每天一直重複出現的正常行為就會減少。

這時候才比較有辦法先去處理 High Risk 的事件。

或者某一天突然出現以前沒看過的行為，也比較容易注意到。

不然如果 Dashboard 一直被相同的 Alert 洗掉，就算裡面真的出現一筆值得注意的事件，也很容易被其他雜訊蓋過去。

所以我覺得 False Positive 的處理，並不只是為了讓 Alert 數量看起來比較少。

對 SOC 來說，更實際的是：

讓分析人員有時間先處理比較重要的事情。

雜訊處理一段時間之後，還是要繼續做

不過 Alert 降下來之後，也不是代表這個客戶就調整完成，以後都不用再碰了。

因為客戶的環境還是會改變。

可能增加新的 Server、新的 Service，或是 IT 人員增加新的排程。

原本設備的用途也可能改變。

這些變化都有可能再次產生以前沒有看過的 Alert。

所以我以前實際維運的方式，通常還是會持續看。

如果發現某一種類型的 Alert 突然變多，就再去分析看看。

確認之後再問客戶。

如果是正常的，再決定要不要調整 Rule、Threshold、Query，或者只是在 Dashboard 上面做 Filter。

做完之後再繼續觀察。

過一段時間可能又有新的雜訊，再重新處理一次。

【False Positive / 雜訊調校循環】

Alert 變少只是結果，不是目的

做 SIEM Tuning 久了之後，我自己不太會把 Alert 數量變少當成唯一的目標。

因為如果真的只想讓 Alert 變少，其實有很多很快的方法。

把 Rule 關掉、把 IP 全部 Whitelist，或者把 Threshold 一直往上調，Alert 當然可以很快降下來。

但這樣做，也有可能連原本應該看到的事件一起排掉。

所以我自己比較習慣的是，先確認客戶的環境，再針對已經知道是正常的行為去做調整。

如果可以用 Source IP + Service + Destination IP 來判斷，就不一定要直接把整個 IP 排除。

如果還需要更細，就再看連線次數或傳輸量。

如果客戶要求全部保留，那就換成從 Dashboard Filter 去降低平常監控看到的雜訊。

處理一段時間之後，Alert 的數量自然會慢慢降下來，也比較能優先去看真正需要注意的高風險事件。

但雜訊的部分還是要繼續處理。

因為環境會一直改變，新的 Alert 也還是會一直出現。

這大概也是我自己做 SIEM 維運這幾年，對 False Positive 比較直接的感受：

不是想辦法把 Alert 全部消掉，而是不要讓那些已經確認過的正常行為，一直佔掉分析人員的時間。

下一篇就來聊另外一個在事件分析跟 Detection 上很常看到的東西：

MITRE ATT&CK。

以前剛接觸的時候，我其實只知道它就是一張很大的表格，後來真的開始做事件分析之後，才慢慢知道這些 Tactic、Technique 跟我們每天看到的 Alert 到底有甚麼關係。