前三天講了背景、網段跟整體架構。今天想拿一個實際發生過、我有記錄下來的事件,把它從頭到尾走一遍——比起再畫一次架構圖,我覺得跟著一筆真實事件走,比較看得出東西是怎麼動的。

這筆事件是什麼
情境很單純:在一台受監控的主機上,用系統管理員權限新增一個測試帳號,然後把這個帳號加進本機 Administrators 群組。

理論上這串動作走完,應該要在 Wazuh 上留下兩筆有意義的告警:一筆是「新增帳號」,一筆是「加入特權群組」——而且如果規則設計得好,第二筆告警應該要能表達「這兩件事是同一個人、短時間內接連做的」,而不是兩筆各自獨立、看不出關聯的告警。

以下照時間順序走一遍,順便說我原本以為會發生什麼、實際發生了什麼。

① 事件產生:Windows 自己先寫了一筆記錄
新增帳號的動作一執行,Windows 的安全性日誌就會產生一筆事件(Event ID 4720)。這一步不需要 Wazuh 介入,單純是作業系統自己的稽核機制在做事——前提是稽核政策有開,這點我在 Day 6 會回頭講,因為我自己就在這裡卡過。

② 採集:Wazuh Agent 把它撿起來
裝在這台主機上的 Wazuh Agent 透過 Windows 的 Event Channel 讀到這筆事件,轉送給 Manager。這一步平常是無感的,能不能順利發生,取決於 Agent 的採集設定有沒有涵蓋 Security 這個 channel。

③ 規則比對:第一筆告警出現
Manager 收到事件後,先過 decoder 解析欄位,再拿去跟規則庫比對。這裡我自己寫了一條規則去接這類「帳號建立」事件,比對成功後產生了第一筆告警,等級是中等(不是最高,因為單獨一次帳號建立,還不足以斷定有問題)。

④ 關聯:第二個動作接上,等級跳高
大約一分半之後,我把剛才那個帳號加進本機 Administrators。這個動作對應到另一筆 Windows 事件(Event ID 4732)。

寫這條規則的時候,我原本以為只要照抄一般教學的寫法接上內建的通用規則就好,結果測的時候發現沒那麼簡單...

⑤ 呈現:這一步老實說還沒接上
原本設計裡,這裡應該要接一層 AI,把這兩筆告警串成一句話,例如「某操作者在短時間內新增帳號並提升為系統管理員,建議立即檢查」。

但目前這筆事件我還沒有實際跑過 AI 摘要——這一步還沒做。我手上有的,是我針對另一個時間窗、用人工方式整理出來的一份摘要範例,格式跟我想要 AI 產出的東西很接近,但那份是我自己寫的,不是 AI 產生的,兩者不能混為一談。我打算把這份人工範例當作「目標長什麼樣子」的參考,實際把 AI 接上、看它能不能做到同樣品質。

這一輪走下來,我的理解是
四個步驟裡,前四步(產生、採集、比對、關聯)我目前是有實測證據的——不是設計上「應該會這樣」,是我真的做了這個操作、真的在 Wazuh 上看到對應的告警與等級變化。

比較讓我意外的一點是:單一事件的等級不見得能反映真正的風險,「這兩件事是同一個人做的、而且時間很接近」這個資訊本身,才是判斷風險的關鍵。這也是我後面想在 AI 那幾天強調的:如果分析這一層只看單筆告警的等級,不去看事件之間的關聯,很多真正該注意的情況會被漏掉。

明天
接下來想往回補一塊今天跳過的細節:Wazuh 本身的四個元件是怎麼分工的,以及我在裝起來之後,第一個踩到的設定坑是什麼。

明天見。