Day 1 曾經寫下這個系列最後想做的事：
最後希望可以使用 Brute Force、Port Scan、Web Attack 等不同案例來測試整個系統。
經過前面 28 天，系統已經具備從事件進入、搜尋、AI 分析到人工判斷的完整流程。今天不增加新功能，而是用三個攻擊情境把整個流程實際走一次，同時觀察 AI 分析的效果與限制。

測試流程

每個案例都使用相同的步驟：

1. 在 Dashboard 用搜尋找到事件
        ↓
2. 按下 Analyze with AI
        ↓
3. 閱讀事件摘要、風險與建議處置
        ↓
4. 到 MITRE ATT&CK 網站確認 AI 對應的 Technique 是否正確
        ↓
5. 在 Human Decision 寫下備註並決定狀態

第 4 步是這次測試的重點。Day 21 在 Prompt 中要求 AI 不可以自行編造 Technique，證據不足時必須回答 Unknown，今天要實際確認它有沒有做到。
在測試之前，我先寫下自己預期的對應，再和 AI 的回答比較：

案例一：Brute Force

搜尋 SSH，找到這筆事件：

Event Type : Brute Force
Source IP  : 203.0.113.45
Dest IP    : 192.168.3.141
Dest Port  : 22
Signature  : ET SCAN Potential SSH Scan / Brute Force Attempt
Severity   : High

按下 Analyze with AI

AI 的分析結果：

• 事件摘要：來源 IP 203.0.113.45 對內部主機 192.168.3.141 的 SSH 服務（連接埠 22）進行了潛在的掃描或暴力破解嘗試。
• 攻擊類型：Brute Force
• MITRE ATT&CK：T1110 Brute Force
• 建議處置：建議 SOC 分析人員檢查相關日誌以確認是否發生成功登入事件，並調查該來源 IP 的歷史活動與其他連線紀錄。
  MITRE ATT&CK 的對應和我預期的 T1110 相同。建議處置的重點是「確認有沒有登入成功」與「調查來源 IP 的其他活動」，兩項都是調查方向，沒有出現直接封鎖 IP 的內容，符合 Prompt 的規則。
  另外可以注意到，AI 在摘要中使用的是「潛在的掃描或暴力破解嘗試」。這條規則的名稱本身就同時包含 SSH Scan 與 Brute Force，AI 並沒有自己把它說成確定的暴力破解。
  Human Decision：來源是外部 IP，目標是 SSH，沒有理由是內部的正常行為，所以標記為 Confirmed，備註寫上「外部來源對 SSH 進行登入嘗試，需確認是否有登入成功的紀錄」。
  

案例二：Port Scan

搜尋 Nmap，這次選擇 Day 27 從 Suricata 匯入的告警：

Event Type : Web Application Attack
Source IP  : 192.168.3.100
Dest IP    : 192.168.3.141
Dest Port  : 80
Signature  : ET SCAN Possible Nmap User-Agent Observed
Severity   : High

這筆事件在 Day 27 已經分析過，所以按下 View Analysis 之後直接顯示保存的結果。

AI 的分析結果：

• 事件摘要：偵測到來自內部IP 192.168.3.100 的HTTP請求使用了可能與 Nmap 掃描器相關的 User-Agent，目標為 192.168.3.141 的 80 埠。
• 攻擊類型：Network Scanning
• MITRE ATT&CK：T1595 Active Scanning
• 建議處置：SOC分析人員應檢視該來源IP的歷史流量與存取日誌，確認是否有進一步的連接埠掃描或目錄列舉行為，並聯繫相關網管人員釐清是否為合法的資產盤點作業。
  這個案例有兩個值得注意的地方。
  第一，這筆事件 Suricata 給的分類是 Web Application Attack，但 AI 判斷的攻擊類型是 Network Scanning。也就是說 AI 是依照 Signature 的內容來判斷，而不是直接沿用 Event Type。以這條規則實際描述的行為來看，AI 的判斷比較貼近。
  第二，MITRE ATT&CK 的對應和我預期的不同。我預期的是 T1046 Network Service Discovery，AI 回答的是 T1595 Active Scanning。查了 MITRE ATT&CK 網站之後，這兩個 Technique 都和掃描有關，但屬於不同的階段：T1595 屬於 Reconnaissance，是攻擊者在入侵之前從外部對目標進行掃描；T1046 屬於 Discovery，是攻擊者已經進入環境之後，在內部尋找其他主機上的服務。
  有趣的是，Day 28 分析另一筆同樣來自 192.168.3.100 的 ET SCAN Nmap SYN Scan Multiple Ports 時，AI 回答的是 T1046。同一台主機、同樣是 Nmap 掃描，兩筆事件得到不同的 Technique。兩個答案都是真實存在而且相關的 Technique，不能說哪一個是錯的，但這也說明 AI 的對應並不是穩定一致的，Panel 上「AI 提供的技術對應仍需人工確認」這句提醒是必要的。
  這個案例另一個特別的地方在於來源是內部 IP。內部主機出現 Nmap 掃描，有可能是主機已經被入侵，也有可能是管理人員正在進行弱點檢測。這次測試以後者為情境：192.168.3.100 是被授權執行掃描的主機，所以這筆告警雖然 Severity 是 High，實際上是誤判。
  AI 沒有辦法知道這件事，它只看得到事件本身的欄位。不過 AI 在建議處置中有提到「聯繫相關網管人員釐清是否為合法的資產盤點作業」，等於是把這個問題交回給人來確認。這正是需要 Human Decision 的原因：標記為 False Positive，備註寫上「已授權的內部主機執行 Nmap 掃描」。
  

案例三：Web Attack

搜尋 Log4j：

Event Type : Web Attack
Source IP  : 198.51.100.88
Dest IP    : 192.168.3.141
Dest Port  : 8080
Signature  : ET EXPLOIT Apache Log4j RCE Attempt jndi:ldap in HTTP Header
Severity   : High

AI 的分析結果：

• 事件摘要：偵測到來自外部 IP 198.51.100.88 對內部伺服器 192.168.3.141 發起針對 Apache Log4j 漏洞的遠端程式碼執行 (RCE) 嘗試，攻擊載荷包含 jndi:ldap 請求字串於 HTTP 標頭中。
• 攻擊類型：Web Exploit / Remote Code Execution
• MITRE ATT&CK：T1190 Exploit Public-Facing Application
• 建議處置：建議 SOC 分析人員檢視目標伺服器的應用程式日誌與存取記錄，確認該 HTTP 請求是否成功觸發漏洞；同時檢查該網頁應用程式的 Log4j 版本與相依套件是否需要升級或套用修補程式。
  MITRE ATT&CK 的對應和預期的 T1190 相同。
  這個案例中 AI 的說明對我的幫助最大。在可能風險的部分，AI 說明了「若目標伺服器使用的 Log4j 版本存在漏洞且未修補，攻擊者可能透過 JNDI 注入成功載入惡意類別並在伺服器上執行任意程式碼」。光看 Signature 裡的 jndi:ldap，我並不知道它代表什麼，AI 的說明讓我知道這條規則在偵測的是什麼樣的攻擊手法。
  另外，AI 的用詞是「嘗試」，風險的描述也加上了「若…存在漏洞且未修補」的前提，沒有把這筆告警直接說成攻擊成功。建議處置中也提到要確認 Log4j 的版本。
  Human Decision：告警只代表有人「嘗試」攻擊，不代表攻擊成功。在確認目標主機是否使用 Log4j 之前無法下結論，所以先保持 Open，備註寫上「待確認 192.168.3.141:8080 的服務是否使用受影響的 Log4j 版本」。
  
  測試結果整理

三個案例最後得到三種不同的狀態，這也說明了為什麼不能讓 AI 直接決定處置方式。三筆事件的 Severity 都是 High，但實際上一筆需要處理、一筆是誤判、一筆還需要更多資訊。
回到 Dashboard 上方，加上 Day 28 處理的兩筆，目前 36 筆事件中有 2 筆 Confirmed、2 筆 False Positive，還有 32 筆等待處理。

觀察到的限制

實際測試之後，整理出目前系統的幾個限制：

1. AI 一次只看得到一筆事件
   Day 25 提過，搜尋 192.168.3.133 可以看到同一台主機陸續出現 C2 連線、DNS Tunneling 與橫向移動。把這些事件放在一起看，很明顯是一台主機被入侵之後的過程。但目前的 AI 分析是一筆一筆進行的，它不會知道這幾筆事件之間有關聯。
2. AI 只有 Signature 層級的資訊
   系統傳給 Gemini 的只有 IP、Port、Protocol 與 Signature，沒有實際的封包內容。所以 AI 的分析主要是在解釋「這條規則代表什麼」，而不是真的分析這一次的攻擊內容。案例三中 AI 提到的 jndi:ldap，其實也是來自 Signature 的文字。
3. AI 不了解環境
   案例二已經說明，AI 不知道哪些主機被授權進行掃描、哪些服務實際存在。這些資訊需要由分析人員補上。
4. MITRE ATT&CK 對應仍需要人工確認
   這次測試中 AI 回答的 Technique ID 都是 MITRE ATT&CK 中真實存在的項目，名稱也都正確，沒有出現編造的 ID，也沒有出現 Unknown。但案例二顯示，類似的行為可能被對應到不同的 Technique。AI 的對應適合當作查詢的起點，最後仍然需要回到 MITRE ATT&CK 網站確認。
5. 同一筆事件每次分析的文字不一定相同
   Day 25 第一次分析這筆 Log4j 事件時，AI 回答的攻擊類型是 Remote Code Execution (RCE)，今天重新分析則是 Web Exploit / Remote Code Execution。意思相同、MITRE ATT&CK 的對應也都是 T1190，但文字並不一樣。這也是 Day 26 要把分析結果保存下來的原因。