前八天陸續講了環境、架構、規則。今天想講一件手量化過的事：在我環境裡等級偏高的告警裡,絕大多數根本不是攻擊。

為什麼想量化這件事？
在寫 Day 8 那批規則的過程中,我陸續注意到幾條內建規則好像特別常出現。一開始只是抽樣印象,沒有數字支撐。剛好那陣子我這邊的網路環境暫時斷線,沒有新事件進來與其乾等,不如回頭把歷史資料撈出來,老老實實算一次：到底噪音佔多少比例、集中在哪幾條規則。

先講清楚這次量化的性質：這是用歷史歸檔資料做的離線分析,不是即時監看。 環境斷線期間沒有新事件,我分析的是斷線之前、已經寫進歸檔檔案裡的資料。這一點會影響後面「降噪規則有沒有效」這個問題的答案——先說結論:規則寫好了、語法測過了,但實際會不會在真事件上生效,我還沒能力驗證。

兩個一開始沒想到的技術陷阱
在算數字之前,我先踩了兩個坑,如果不是這次認真去查歷史資料,不會發現。

陷阱一：當天的告警檔只有當天,歷史資料在別的地方。 Wazuh 即時查詢用的那個檔案,只保留當天資料,前幾天的都已經輪替壓縮到別的路徑去了。如果不知道這件事,直接查「當天」的檔案,只會查到一堆空結果(因為那幾天環境剛好斷線),然後可能誤以為告警系統整個壞了。

陷阱二：壓縮檔的日期跟檔案內部的時間戳記,對應的時區不一樣。 檔案輪替是按 UTC 日切的,但檔案裡面每筆事件記的時間戳記卻是本地時區。如果我直接用事件裡的時間戳記字串去分組統計「這是哪一天的資料」,四個完整的 UTC 日會被切成五個殘缺不全的本地日期,頭尾兩天都不完整,算出來的日均值會被拉低,整組數字失真。

正確做法是用檔名本身認定日期,不要用事件內部的時間戳記去反推。 檔名就是 UTC 日的定義,不需要再做時區換算。這件事聽起來瑣碎,但如果沒發現後面所有數字都會是錯的。

量化結果：三條規則佔了 99.3%
選定四個完整的 UTC 日作為基準窗口之後,算出來的數字大概是這樣：

也就是說,等級 > 8 的告警裡,99.3% 集中在三條規則。這三條分別是：

• 一條跟雲端同步軟體存取檔案總管有關的規則,等級 12,平均每天 96 次
• 一條是 Wazuh 自己內建的安全組態評估模組執行 PowerShell 時觸發的規則,等級 9,平均每天 38 次
• 一條是系統磁碟清理工具的父子程序行為,等級 15——這是 Wazuh 分級裡數一數二高的等級,平均每天 3 次

這三條規則四天下來,每天的觸發次數幾乎一模一樣,連續四天幾乎零變異。這種穩定度不太可能是巧合,比較合理的解釋是：它們背後都是固定排程的良性背景行為,不是攻擊行為的隨機性。

那條等級 15 的規則特別值得說一下——這也是我在 Day 7 埋的那個伏筆。Wazuh 把它定義成僅次於最高等級的嚴重性,但實際觸發原因只是系統磁碟清理的正常父子程序關係。如果只看等級數字排優先順序,這條規則每天都會被排在最前面,但它其實一次都不是真正該關注的事件。等級高不代表危險,只代表這條規則的設計者覺得「如果這是真的,後果會很嚴重」——但觸發原因是不是真的攻擊,還是要看實際內容。

主機之間的差異,也告訴我一些事
四天的資料裡,兩台工作站型態的受監控主機,噪音量非常接近(平均每天都在 68 上下)；但網域控制站那台,同樣期間的等級 >7 告警平均每天只有 1 筆左右,而且前面提到的雲端同步規則跟 SCA 規則,在這台上完全沒出現過。

我一開始有點緊張,以為是不是這台主機的資料管線斷了、沒在收集。查了一下歷史記錄才確認,管線是活的——這台主機光是登入相關的安全事件,歷史累積就有兩萬多筆,遙測沒有問題。
真正的原因是：這台主機的用途跟工作站不一樣,本來就沒有裝雲端同步軟體,套用的組態評估政策也跟工作站不同,所以那兩個噪音來源天生就不會出現在這裡。

這裡也順便發現一個還沒補齊的缺口：目前這台主機的事件採集設定,還沒有涵蓋目錄服務與複寫相關的通道,而歷史資料裡也確實找不到這方面的正面證據。 這台之後會是我重點測試 AD 相關情境的主機,這個採集缺口不補上,之後如果跑 AD 專屬的攻擊模擬,結果可能會是假的「什麼都沒發生」,而不是真的什麼都沒發生。

修規則的時候,順手抓到一個寫死路徑的 bug
在驗證那條 SCA 規則的降噪 pattern 能不能對上真實資料的時候,152 筆裡有 8 筆對不上。仔細比對才發現,差異只在一個資料夾名稱：32 位元跟 64 位元版本的 PowerShell,呼叫路徑其中一段資料夾名稱不一樣,但我原本的規則只寫死了其中一種。

修法很單純,把那一段路徑改成可以接受兩種寫法的選擇性條件,其餘完全不動。改完之後重新比對,152 筆全數命中。這件事讓我更謹慎看待「規則寫完、語法測試通過」跟「規則真的能吃下所有真實樣本」之間的落差——不跑過真實資料,不會發現這種藏在路徑細節裡的坑。

一個意外發現：確實有訊號被漏掉過
在整理這四天資料的過程中,我意外發現一組真正該關注的告警——不是那三條噪音規則,是少數幾筆跟系統元件當機有關的真實錯誤事件,等級也達到門檻。但這幾筆事件,是我在六天之後、為了做這次基準分析回頭翻歷史資料時才發現的。規則有正確觸發、等級也夠高,但這段期間沒有被人工處理過。

老實說,這個發現比噪音數字本身更讓我在意。它具體證明了一件事：告警產生跟人工介入處置之間,是有可能斷掉的,而且不是理論上的風險,是在我自己的環境裡真實發生過、有時間戳記可以佐證的斷點。降噪能提高訊噪比,但降噪本身不會自動修好這個斷點。

這篇證明了什麼、還沒證明什麼？
證明了的：在我這四天的歷史歸檔資料裡,99.3% 的高等級告警確實可以定位到三個具體、可解釋的良性來源,不是一句「規則太敏感,需要全面調校」可以打發的模糊結論。

還沒證明的：我已經把降噪規則寫好、部署上去,而且用歷史資料做了條件比對,確認規則邏輯在真實樣本上大致吃得住(除了上面修掉的那個路徑 bug)。但降噪規則有沒有辦法在真實事件流上正常運作,我目前還沒辦法驗證,我對降噪後的效果有一組具體預測(高噪音規則的觸發次數應該會大幅降到接近零)。

我原本以為這次分析的結論會是「預設規則整體太敏感,需要大範圍調校」。實際做完之後,結論完全不是這樣——問題集中、可定位,處置方式也完全不同。這算是這次量化過程裡,對我自己判斷修正最大的一次。

明天
明天想先停下來,回顧一下這九天寫下來的東西:哪些地方是真的做過、哪些只是設計,中間有沒有哪個判斷後來被推翻過。

明天見。