前面幾天從 Log Source、Firewall、Network Traffic、EDR，一路講到昨天 SIEM 的架構規劃。

假設今天 Sensor、Collector、Analyzer 等相關功能都已經建置完成，客戶的 Log 也開始陸續進來，是不是就代表這套 SIEM 已經可以正式開始使用了？

其實沒有這麼快。

至少以我自己以前建置 SIEM 的經驗來說，當資料真的開始進來之後，才是另外一個挑戰的開始。

因為一開始看到的通常不是甚麼整理得很漂亮的資安事件，而是：

很多很多的資料，還有跟著資料一起出現的大量 Alert。

先放一個這天的大綱圖

Alert 進來的速度，比我看完的速度還快

我剛開始面對這種情況的時候，其實也有點不知道應該怎麼看。

最初使用的方法很笨，就是直接從 Alert 開始，一筆一筆點進去看。

看到一個 Alert，就看看 Source IP、Destination IP、Port，再找前後有沒有其他相關的 Log，想辦法弄清楚到底發生甚麼事情。

但是很快就會發現一個問題：

Alert 進來的速度，往往比我看完的速度還快。

可能前面的 Alert 都還沒有調查完，後面新的 Alert 又一直進來。

如果每一個 Alert 都從頭開始調查，基本上很難真的把全部 Alert 看完。

這時候我才開始去研究所謂的「關聯事件」到底是甚麼，以及為甚麼 SIEM 需要把不同的 Alert 關聯在一起。

單獨看一個 Alert 的時候，我可能只知道：

「這個 IP 有問題。」

「這裡發生很多次登入失敗。」

「這台主機產生了一個異常連線。」

但如果把時間拉在一起，可能就會發現原本分散的幾個 Alert，其實是在相近的時間、相同的 Host、IP 或 User 上發生。

這時候看到的就不再只是很多獨立的 Alert，而是開始能從它們之間的關係去理解：

這些行為是不是同一件事情的一部分？

📌 從大量 Alert 到關聯 Event

有 Alert，就代表真的有問題嗎？

開始看大量 Alert 之後，我覺得另外一個很重要的觀念就是：

系統產生 Alert，不代表真的已經發生資安事件。

SIEM 是根據 Detection Rule、關聯邏輯或其他偵測方式，發現某個行為符合條件，所以產生 Alert 提醒我們。

但是「符合偵測條件」跟「真的遭到攻擊」，其實還是兩件不同的事情。

這裡就可以用資安偵測很常見的四個象限來理解。

📌 Alert 判斷四象限

簡單來說：

True Positive（TP）
系統產生 Alert，而實際調查後確實有問題。

False Positive（FP）
系統產生 Alert，但實際調查後是正常行為。

False Negative（FN）
實際上有問題，但是系統沒有偵測出來。

True Negative（TN）
沒有問題，系統也沒有產生 Alert。

我剛開始看的時候，看到 High、Critical 或是 Malicious IP 這類型的 Alert，第一個反應很容易就是：

「這個是不是有問題？」

但後來看得越來越多，就會知道 Severity 或 Alert 名稱只是其中一個參考。

Alert 比較像是在告訴我「這裡值得調查」，而不是直接告訴我「這裡已經確定被攻擊」。

那我自己怎麼開始判斷一個 Alert？

做了一段時間之後，我自己也慢慢建立了一個比較習慣的查看方式。

第一個通常會先看：

時間。

這件事情是甚麼時間發生的？

上班時間？

半夜？

還是每天都在差不多的時間出現？

接著才會開始看：

Source IP、Destination IP、Port。

確認到底是哪一台設備連到哪裡，以及使用甚麼 Port、Service。

再來我通常還會注意：

• 連線持續多久
• 一段時間裡面出現幾次
• 如果是登入相關事件，登入嘗試的次數
• 傳送或接收的流量大小
• 使用的 Service
• 前後有沒有其他相關的 Event 或 Alert

所以如果簡單整理，我自己大概會像這樣看：

📌 我的 Alert 分析順序

當然這不是一套固定 SOP。

因為 Network Alert、Authentication Event、Endpoint Alert 本來就不可能全部用一樣的方式分析。

但這是我在看過大量事件之後，慢慢建立起來的一個分析方向。

尤其是：

我會把時間範圍拉長來看。

因為單獨一個時間點可能看不出甚麼，但是把時間從幾個小時拉到一天、七天甚至更久，有時候就會看到完全不一樣的 Pattern。

一個凌晨兩點出現的 Alert

我自己就碰過一個滿典型的例子。

當時有一個 Alert 出現在凌晨大約兩點多。

來源是客戶的內網設備，而且當時看到連線傳輸的流量有點大。

第一眼看到的時候，當然會覺得：

「為甚麼一台內網設備凌晨兩點還有這麼大的流量？」

但我沒有只看當下這一筆。

我把時間範圍拉長到七天之後，開始發現一件事情：

七天裡面其實出現過很多次類似的行為，而且發生的時間差異並不大。

也就是說，它不像是一個完全隨機出現的行為，反而有一種固定的 Pattern。

📌 Backup Server 案例

看到這種情況，我們還是不能自己直接認定：

「喔，這一定是備份，所以沒問題。」

而是會透過電話或 Email 跟客戶確認。

後來客戶確認這確實是一台 Backup Server，而且凌晨這個時間就是他們正常執行備份的排程。

這時候才會再進一步詢問：

既然這是已知的正常行為，是否可以針對這種情況加入白名單，或進行相對應的規則排除？

如果客戶同意，才會進行後續調整。

處理完 Alert，不代表事情就結束了

不過這個案例對我來說，真正有價值的其實不只是：

「找到 Backup Server → 加白名單。」

因為透過這次事件，我們又多知道了一些原本不知道的客戶環境資訊。

例如：

這個 Source IP 是甚麼設備？

Destination 又是哪些設備？

這台設備的用途是甚麼？

甚麼時間會執行備份？

這些資訊確認之後，我們也會把它記錄下來。

當時我們會把這次確認的情況放到週報裡面，同時把確認到的 IP 與設備資訊更新到提供給其他維運人員看的客戶 IP 設備清單。

這樣下一個維運人員再看到：

「這個 IP 怎麼每天凌晨兩點都有大量流量？」

就不用再重新從零開始查一次。

所以我後來會覺得：

Rule Tuning 的過程，其實也是在慢慢了解客戶環境的過程。

Day 6 有提到建置以前需要先調查客戶環境，但實際上第一次訪談不一定能把所有資訊都問出來。

有些東西甚至客戶自己一開始也不會想到需要告訴 SIEM 維運人員。

像是：

• NAS
• Backup Server
• 固定排程
• 管理用主機
• 特定 Server
• 只有特定時間才會執行的工作

反而是 Alert 出現之後，我們拿著 IP 去問：

「請問這台設備是做甚麼的？」

才慢慢把環境補完整。

另外一種情況：看起來真的很可疑，但也不能直接 Block

前面的 Backup Server 最後確認是正常行為。

但我也碰過完全不同的狀況。

有一次看到某個客戶出現一個跟外部 IP 有關的 Alert。

我去查這個 IP 的 Reputation，發現它的評分比較差，而且過去也曾經有被標記成惡意來源或攻擊站台的紀錄。

如果只看到這裡，很容易就會得到一個結論：

「惡意 IP，那就 Block 掉。」

但實際上沒有那麼簡單。

我一樣先把時間範圍拉長。

先看一個禮拜。

再拉到一個月。

後來甚至往前三個月去確認這個外部 IP 的連線情況。

結果發現它不是三個月裡面都持續大量出現，而是在其中某幾個時間區段特別活躍。

📌 External IP 分析

這裡還有一個很重要的客戶環境因素：

這個客戶本身有國外的客戶。

所以即使某個 External IP 的 Reputation 不好，也不能看到之後就直接封鎖。

因為你不知道它會不會影響客戶正常的海外業務。

當時這個客戶也沒有讓我們直接進行自動化 IP Blocking，所以我們能做的是先把分析到的情況通知客戶，讓客戶知道目前觀察到甚麼。

這也是我後來越來越在意 Context 的原因。

IP Reputation 可以幫助我們判斷，但它不能代替我們做最後的判斷。

Severity 高，也不代表只看 Severity 就夠了

同樣的道理也可以放到 Alert Severity。

High、Critical 當然值得注意。

但如果只照 Severity 排序，還是會少掉很多環境資訊。

例如同一種類型的 Alert：

發生在一般 User Endpoint，跟發生在客戶的重要 Server 上，我關注的程度可能就不一樣。

所以前面為甚麼要把客戶的重要設備、IP、用途慢慢記錄下來？

就是因為這些資訊最後都會變成事件分析的一部分。

我後來看的就不只是：

「這個 Alert 是 High 還是 Medium？」

而是：

「甚麼行為，在甚麼時間，發生在哪一台設備上？」

再把其他相關 Event、客戶環境與過去的行為一起放進來判斷。

開始做事件分類

當 Alert 越看越多之後，就不能永遠維持一筆一筆從頭分析。

這時候我也會開始整理：

哪些類型很常出現？

哪些是高風險？

哪些是高頻率？

哪些已經跟客戶確認過？

哪些是已知正常行為？

哪些目前還不確定？

哪些跟重要設備有關？

📌 事件分類概念

這裡我不會把它當成一套固定的事件分類標準。

比較像是面對大量 Alert 時，我開始需要知道：

哪些東西值得優先花時間？

而不是看到甚麼就查甚麼。

Rule Tuning 不是把 Alert 調得越少越好

當已經確認哪些行為是正常的之後，接下來才會真正進到 Rule Tuning。

如果今天某個正常行為每天都會觸發相同的 Alert：

今天出現 --> 人工確認 --> 正常 --> 明天又出現 --> 人工確認 --> 正常 --> 後天又出現 --> 人工確認
--> 正常

那 SOC 人員其實只是在重複做同樣的工作。

所以我們才會開始思考：

Rule 是否需要調整？

是不是要加入排除條件？

是否可以加入 Whitelist？

或者資料需要繼續保留，但不需要每次都讓相同的內容影響 Analyst？

不過我覺得這裡有一個很重要的觀念：

Rule Tuning 的目的不是單純把 Alert 數量變少。

假設今天有 10,000 筆 Alert，我直接把會產生這些 Alert 的 Rule 全部關掉，那 Dashboard 當然會瞬間變得非常乾淨。

但這不代表 SIEM 變得更好了。

因為真正有問題的行為，也可能一起被我們忽略掉。

所以比起：

「怎麼讓這個 Alert 不要再出現？」

我後來會更在意：

「為甚麼這個 Alert 會出現？」

確認原因之後，再決定是不是應該針對特定條件進行調整。

📌 Rule Tuning 的循環

所以 Rule Tuning 通常也不是做一次就結束。

客戶可能增加新的 Server。

可能新增新的排程。

可能更換設備。

甚至原本正常的行為，在不同時間、不同設備上發生，也可能有完全不同的意義。

這也是為甚麼我覺得 SIEM 的調校其實是一個持續的過程。

Alert 是調查的起點，不是事件的結論

回頭看自己剛開始接觸 SIEM 的時候，其實真的很單純。

看到 Alert，就點進去一筆一筆看。

但後來才慢慢發現：

Alert 本身不是答案。

時間、IP、Port、Service、連線次數、流量大小、其他關聯 Event，以及客戶自己的環境資訊，這些東西放在一起之後，才比較有機會理解一件事情到底是正常還是異常。

甚至一個原本看起來很可疑的凌晨大量傳輸，最後可能只是每天固定執行的 Backup。

反過來，一個 Reputation 不好的 External IP，也不能因為「它被標記為惡意」就直接不管客戶環境進行封鎖。

所以我自己後來對 Rule Tuning 的理解，不只是：

把 Alert 調少。

而是：

讓真正需要注意的行為，更容易從大量資料裡面被看到。

但這裡還有一個問題。

即使我們已經知道某些 Alert 是 False Positive，如果它每天還是不斷出現，SOC 人員一樣會被大量雜訊淹沒。

所以 Day 8，我想接著來談一個我實際維運 SIEM 時一定會碰到的問題：

每天幾百、幾千甚至更多的 Alert，到底要怎麼降低 False Positive？

以及更重要的：

我們怎麼在降低雜訊的同時，不把真正應該看到的事件也一起過濾掉？