寫到第十天,先暫停一天,回頭看看前面九天：哪些東西是我真的驗證過的、哪些其實還只是設計;有沒有哪個判斷後來被自己推翻;接下來要驗證什麼。

哪些是實測,哪些是設計
對照 Day 1 定的規矩,先盤點一次。

有實機證據的：兩個網段確實分開、流量確實會經過防火牆(Day 2 踩坑之後才確認);Day 4 那條新增帳號→加入 Administrators 的事件鏈,從 Windows 產生到 Wazuh 產生關聯告警;Day 5 那次佇列塞爆是真實發生過的插曲,事後也真的查過恢復狀態;Day 9 的噪音量化,用的是四天的真實歷史資料,不是假設出來的數字。

還在設計階段,或只驗證了一部分的：Day 3 提過,分析層(AI 摘要、RAG)跟呈現層(儀表板、問答)目前偏規格,實作還在補;Day 8 那 32 條規則裡,目前只有 1 條鏈是真的用實機事件驗證過,其餘大多還停在「語法正確、邏輯上該接得上」;Day 9 的降噪規則,只做過歷史資料的條件比對,還沒在真實事件流上驗證過。

這樣列出來,結論大概是：蒐集層跟偵測邏輯的骨架有實測支撐,分析呈現這一側大部分目前還是紙上談兵。這跟 Day 3 一開始講的狀態一致,沒有太大意外——比較意外的是下面這件事。

有一個判斷,被自己的資料打臉了
Day 8 寫規則的時候,我原本的假設很單純：如果 Wazuh 上有告警跑出來,就代表這條規則在正常運作。 這個假設聽起來理所當然,我一開始也是這樣看待告警畫面的。

後來認真測那條攻擊鏈規則,才發現完全不是這麼回事。因為我把自訂規則掛在一個太籠統的內建父規則上,實際事件進來的時候,會先被更具體的內建手足規則接住——告警照樣有產生,畫面上看起來一切正常,但我真正在意的關聯鏈,因為訊號來源不對,根本沒有被觸發過。「有告警」跟「規則按照我設計的邏輯在運作」是兩件事。

第二個被修正的判斷,發生在 Day 9。我原本以為噪音問題的結論會是「預設規則整體太敏感,需要大範圍調校」——這是我開始統計之前腦中的預設答案。實際算完四天資料才發現,99.3% 的高等級噪音集中在三條可以具體定位的規則,不是規則整體都有問題。這兩種結論會導向完全不同的處置方式,而我一開始猜的方向是錯的。

這兩次修正給我的共同心得是：我對「系統正常運作」的直覺判斷,常常來自畫面表面看起來沒問題,而不是真的去驗證邏輯有沒有走完。 這也是我打算在後面幾天繼續保持的習慣——能實測就不用猜的。

這九天裡,有兩件事讓我印象比較深
一是 Day 6 的兩層缺口。 稽核政策開了,不代表 Wazuh 就看得到——這兩層要分開查證,不然會在「到底是哪一層沒開」這個問題上瞎猜。這件事我現在還沒完全解決,PowerShell 那個通道目前仍然還沒加進 Wazuh 的採集設定,算是一個知道存在、但還沒處理完的缺口...

二是 Day 9 那個六天後才發現的告警。 規則有正確觸發、等級也夠高,但那段期間沒有被人工處理過,直到我為了做基準分析回頭翻歷史資料才注意到。這件事讓我意識到,降噪能提高訊噪比,但不會自動修好「告警產生」跟「人工介入」之間可能斷掉的這一段。這個斷點目前也還沒有處理方案,先記下來...

接下來要驗證什麼
往後幾天(Day 11–19)要進到具體的攻擊情境跟偵測邏輯,這幾件事是我特別想盯著看的：

Day 8 那 32 條規則裡,還有 29 條沒有實機驗證過,接下來寫攻擊情境的時候,能驗證幾條算幾條,不會為了湊篇幅硬說已經測完。
Day 6 留下的 PowerShell 通道缺口,如果剛好碰到 PowerShell 相關情境,會回頭處理。
Day 3 提到的儀表板跟問答系統完成度,到了 Day 19 前要面對——實作有沒有跟得上設計，到時候再向各位報告。
明天開始回到正題,先講 Windows Security 日誌本身的地圖。

明天見。