昨天講完 MITRE 對應目前只是設計參考地圖。今天想面對同一個問題：我規劃的 SOC 儀表板有 18 個 widget,實際做出來的有4 個。

為什麼是 4 個,不是 18 個？
18 個全做,不是一天能做完的事,硬要湊只會變成品質很差的展示... 我挑了 soc-home.md 設計裡最核心的一組——高風險事件卡片、等級分布、Top 來源 IP、Top 受影響帳號——組成著陸頁最上面那塊。 其餘 14 個目前還是設計文件,還沒有做。

做法是延伸我已經有的 soc_query.py(Day 24 會細講這支腳本的其他部分),重用它已經驗證過的連線方式,不重造一次認證邏輯。

一個技術上的小發現：唯讀政策 vs 聚合查詢
寫的時候先卡了一個設計問題:soc_query.py 明確聲明「Indexer 只用 GET」,但 OpenSearch 做聚合統計(算 Top IP、算等級分布這種)標準做法要帶一段 JSON 查詢內容,多數工具庫因此都用 POST 送出。

後來確認 OpenSearch 的 _search 端點其實接受「GET 方法 + 帶 JSON 內容」這種不算標準、但被廣泛支援的用法——這樣就能在不違反「唯讀、只用 GET」這條自訂政策的前提下,還是做得到聚合查詢。這個做法我覺得值得記一筆,因為它同時滿足了兩件事:技術上要用到的聚合能力,跟自己訂下的安全邊界。

我原本的預測是錯的
寫完腳本的時候,我有個預測：ipAddress、targetUserName 這類欄位在 OpenSearch 裡有可能被存成 text 而不是 keyword,做聚合查詢很可能會直接報錯,得改成 .keyword 版本才行。

實際跑起來,完全沒有這個問題。 腳本第一次執行就 exit 0,沒有任何欄位聚合警告,也不需要改成 .keyword。我原本準備了容錯機制去接住這個預期中的錯誤,結果錯誤沒發生——這算是這 19 天以來少數幾次「猜測比實際情況悲觀」的例子,跟 Day 9 那次「猜錯噪音是全面性問題」的方向相反,但同樣的教訓適用：猜測要拿真實結果驗證,不管猜對還是猜錯。

結果本身：沒預期到的事
4 個 widget 都成功產生了畫面,但內容比我預期的更有意思。

高風險事件卡片只抓到 2 筆,等級都是 10,描述是「連續三次 sudo 驗證失敗」,對映 MITRE T1548.003(濫用 sudo 提權)。這裡有個地方要停下來講清楚：這兩筆事件的來源主機,不是我規劃裡要保護的 Windows 靶機,是 Wazuh Manager 自己這台 Linux 主機。

換句話說,過去 24 小時內,我這套系統唯一浮出來的高風險訊號,是監控系統自己被人連續打錯三次 sudo 密碼,發生了兩次。這就是我自己手滑打錯密碼(o′┏▽┓｀o)...
這讓我意識到：我一直在講「保護 Windows 靶機」,但 Wazuh Manager 本身也是一個資產,它被入侵的後果可能比任何一台靶機都嚴重,而這台主機的提權嘗試,我目前完全沒有另外設計過偵測邏輯去特別關注它。這算是這次做 dashboard 之前完全沒想到、做完才浮現的一個缺口。

等級分布顯示過去 24 小時內,Level 7 有 39 筆、Level 9 有 2 筆、Level 10 有 2 筆,加起來 43 筆。Top 來源 IP 跟 Top 受影響帳號兩個查詢都成功執行,但沒有資料。

這個「沒有資料」我不想輕描淡寫地說成「代表系統很乾淨」。比較合理的解釋是：這個時間窗內僅有的告警(那些 sudo 失敗事件)本身不帶 Windows 的 eventdata 欄位,所以兩個查詢自然撈不到東西——這不代表 Windows 靶機那邊真的沒有任何事件,也可能代表那幾台 agent 這段時間根本沒有產生事件。 這正好呼應 Day 17 那套四態架構裡的 None：「沒看到訊號」跟「真的沒發生」中間,永遠要先排除感測器本身有沒有問題,才能下結論。

心得
做 4 個 widget,比繼續描述 18 個 widget「應該長怎樣」有價值得多——真正跑出真實資料之後,冒出來的問題(Manager 自己的 sudo 失敗、資料量的落差)是我光看設計文件永遠不會想到的。這也再次印證 Day 15 那次的判斷:先做出一小塊真的能跑的東西,比堆更多篇幅的設計文件更值得優先做。

剩下 14 個 widget,老實說目前還是設計,沒有做。這篇附上的程式碼已經照專案慣例補了 README、manifest 跟一支離線驗證腳本,如果之後要擴充其他 widget,骨架已經在了。

明天
明天是第二次小結,回顧 Day 11 到 Day 19——這九天從具體的登入事件講到今天這個意外發現,要停下來看看哪些判斷需要修正。

明天見。