30 天前，我在 Day 1 寫下：
對於這些工具和技術實際上如何串在一起，以及資安人員收到一筆告警後到底要如何分析，我其實沒有完整的概念。
今天是最後一天。這篇文章會整理這 30 天完成了什麼、最後的系統長什麼樣子，並且試著想如果要把這個學習實作當成一個產品來介紹，它是什麼？還差什麼？

30 天回顧

最終的系統架構

        Suricata
           ↓
        EVE JSON
           ↓
   ingest_suricata.py ──────────┐
   （只匯入 Alert、避免重複）     │
                                ↓
                        ┌──────────────┐
                        │    SQLite    │
                        │  events      │ ← 原始事件 + 人工判斷
                        │  ai_analyses │ ← AI 分析結果
                        └──────────────┘
                                ↑↓
                        ┌──────────────┐        ┌──────────┐
                        │   FastAPI    │ ←────→ │  Gemini  │
                        │ Severity 規則 │        │摘要、風險│
                        │ 搜尋、統計    │        │建議、MITRE│
                        └──────────────┘        └──────────┘
                                ↑↓
                        ┌──────────────┐
                        │ React        │
                        │ SOC Dashboard│ ←────→ SOC 分析人員
                        └──────────────┘         （最終判斷）

和 Day 1 相比，最大的差別有兩個：

• 多了資料庫作為中心。原本以為資料是一路往下傳，實際上所有元件都是圍繞著資料庫在運作。
• 多了「人」這個角色。Day 1 的架構圖終點是 Dashboard，但實作到後面才發現，Dashboard 不是終點，分析人員的判斷才是。

功能總覽

對照 Day 1 的目標

Day 1 希望系統可以「讀取資安事件，並利用 AI 協助產生事件摘要、風險等級、可能的攻擊行為、MITRE ATT&CK 對應，以及初步的處置建議」。

其中「風險等級」是和原本規劃不同的地方。Day 19 因為讀者的建議，把 Severity 的判斷從 LLM 移回 Backend。這個改變後來影響了整個系統的設計方向：確定的事情用規則處理，需要解釋的事情才交給 AI。

如果把它當成一個產品

AI SOC Dashboard 是一個協助資安新手看懂 IDS 告警的分析平台。它把 Suricata 產生的告警整理成可以搜尋的事件列表，由 AI 用中文說明每一筆告警代表什麼、可能有什麼風險、接下來應該調查什麼，最後由分析人員記錄自己的判斷。
它想解決的問題
Suricata 這類開源 IDS 是免費的，但它產生的告警對初學者來說很難閱讀。一條像 ET EXPLOIT Apache Log4j RCE Attempt 的告警，需要具備相當的背景知識才知道它代表什麼、嚴不嚴重、下一步該做什麼。
大型企業可以購買商用的 SIEM 與 XDR，也有專職的 SOC 團隊。但沒有資安專職人員的小型團隊、正在學習資安的學生，往往是架好了 IDS，卻看不懂它在說什麼。

適合的使用對象

• 資安課程與學習者：搭配 Suricata 實驗環境，一邊產生告警、一邊透過 AI 的說明學習攻擊手法與 MITRE ATT&CK。
• 沒有專職資安人員的小型團隊：由兼任的 IT 人員每天花少量時間查看高風險且尚未處理的事件。
• 想了解 AI 如何應用在資安的開發者：整套系統的程式碼都記錄在這個系列中，可以作為起點繼續擴充。
  和直接把告警貼給 AI 聊天機器人有什麼不同
  這是我在開發過程中一直在想的問題。把告警複製貼到聊天機器人，一樣可以得到解釋，那為什麼還需要這套系統？
• 回答的格式是固定的。透過 Structured Output，每一筆分析都有相同的欄位，可以存進資料庫、可以統計。
• 有明確的限制。Prompt 規定不可以自行編造 MITRE Technique、不可以直接做出封鎖或隔離的決定。
• 事件內容被當成資料而不是指令。攻擊者有可能在封包中放入給 AI 的指令，Prompt 中已經要求把事件內容視為資料。
• 分析結果與人工判斷都有紀錄。誰在什麼時候看過這筆事件、結論是什麼，都留在系統中。

這套系統目前是一個可以展示完整流程的雛型，如果要讓其他人實際使用，至少還需要補上的部分：

未來方向

如果繼續發展，我會依照這個順序進行：

1. 即時匯入：持續監看 EVE JSON，讓告警自動出現在 Dashboard。
2. 事件關聯：把同一個來源 IP 或同一台主機在一段時間內的事件一起交給 AI 分析，讓它可以描述完整的攻擊過程。
3. 登入與操作紀錄：讓多人可以共同使用，並記錄每一次的判斷。
4. 讓誤判的紀錄發揮作用：當一筆事件被標記為 False Positive，之後出現相同來源與相同規則的告警時，可以提醒分析人員過去的判斷。
5. 支援其他來源：除了 Suricata，也接收防火牆或主機的 Log。

30 天的心得

這 30 天對我來說最大的收穫，是把原本只是「聽過」的名詞變成自己實際串接過的東西。現在看到 SOC、IDS、EVE JSON、MITRE ATT&CK，我想到的不再只是定義，而是它們在系統中各自負責哪一段。
第二個收穫是對「AI 應該放在哪裡」的想法改變了。一開始我以為做一個 AI 資安平台，重點是讓 AI 做越多事情越好。但實際開發之後，我反而花了很多時間在限制 AI：Severity 不給它判斷、不讓它編造 Technique、不讓它直接決定處置、最後還加上人工判斷。系統裡真正交給 AI 的，只有「把難懂的告警解釋成人看得懂的內容」這一件事，而這剛好也是它做得最好的事。
第三個是關於持續。30 天裡有很多天是在很晚的時候才完成當天的進度，也有寫到一半發現前面的設計需要修改的時候。但每天只往前推進一小步，30 天之後回頭看，確實完成了一套從資料來源到使用者介面都有的系統。
最後，謝謝這段時間閱讀與留言的讀者，特別是 Day 18 提出 Severity 問題的讀者，那個建議改變了整個系統後半段的設計。
這個系列到這裡結束，但這套系統還有很多可以繼續做的地方。謝謝大家。