SIR-Bench 論文閱讀分析：真正值得信的 IR Agent，不是會把 alert 說得更像人話，而是會自己挖出 alert 沒講的新證據
論文基本資訊
- 論文標題：Evaluating Investigation Depth in Security Incident Response Agents
- 作者：Daniel Begimher、Cristian Leo、Jack Huang、Pat Gaw、Bonan Zheng
- 來源：arXiv
- 年份：2026
- 論文連結：https://arxiv.org/abs/2604.12040
- 主題：SOC、Incident Response、LLM Agents、Benchmark、Digital Forensics、Cloud Security
如果最近這波 sectools.tw 的主線，已經一路從 SOC triage、IR agent、human-AI collaboration、guardrail 寫到各種 benchmark，那 SIR-Bench 這篇最值得補上的位置很清楚：它不是再問 agent 最後判對了沒，而是問它到底有沒有真的做過像樣的調查。
這個差別很重要。因為在 incident response 裡，「猜對」跟「查對」根本不是同一件事。一個 agent 可能看 alert 標題、看幾個關鍵字、照歷史機率去猜這多半是真警報；另一個 agent 則真的去翻 CloudTrail、列 IAM policy、追 cross-account role assumption、找出資料碰過哪些 S3 bucket。兩者都可能得到同樣的 triage 結論，但只有後者比較接近你真的敢放進 SOC pipeline 的東西。
這篇論文真正有價值的地方，就是它把這個長期被混在一起的問題拆開：security investigation agent 的能力，不該只看最後答對率，還要看它有沒有挖出 alert 原本沒直接告訴你的新證據。
這篇論文在解什麼問題？
作者的核心不滿其實很合理：現有很多資安 benchmark，要嘛是在測知識問答，要嘛是在測 CTF / offensive task，要嘛只是看 classification accuracy。但真實 incident response 比較像這樣：
- 先接到一個可能真、也可能假的告警
- 再去不同資料源追證據
- 找出 alert 沒直接寫出來、但能改變判斷的重要發現
- 最後才做 triage 與後續處置
也就是說，IR agent 真正該被測的，不只是會不會回答，而是會不會查。
作者把這種能力命名得很直白：investigation depth。這個概念背後其實是在反擊一個現在很常見、但很危險的評測偏誤：alert parroting。也就是 agent 只是把原始 alert 換句話說、整理成比較像分析報告的口氣，卻沒有真的發現任何新的 forensic evidence。
SIR-Bench 的核心想法：不要只獎勵正確答案，要獎勵真的挖出新東西
SIR-Bench 是一個用來評估 autonomous security incident response agents 的 benchmark，總共有 794 個 test cases，來自 129 個匿名化 incident pattern。這些 pattern 不是憑空捏的，而是從真實安全事件經驗抽象出來，再放進受控雲端環境裡重播。
作者特別想解的，是 benchmark 常見的兩個問題：
- 資料不夠真：如果沒有真實攻擊留下的 telemetry，agent 其實很容易靠表面 pattern 過關。
- 評分太扁平：只看最後 true positive / false positive，無法知道它是靠查證還是靠猜。
所以這篇 paper 的方法論重點，不只是做一個新資料集，而是把「怎樣才算真的調查過」這件事變成可量化的 benchmark 設計。
OUAT：用受控模擬把真實 incident pattern 重新長回可評測環境
為了做這件事，作者先建了一個叫 Once Upon A Threat (OUAT) 的框架。它的工作流程大致是：
- 從匿名化 incident pattern 出發
- 在受控 AWS 環境裡重建接近真實客戶部署的架構
- 執行對應的攻擊行為，例如 credential compromise、cross-account role assumption、S3 object enumeration、data exfiltration
- 保留真實產生的 CloudTrail 與相關 artifacts
- 再由 security engineer 補上與審核 ground truth findings
這一段很關鍵，因為它讓 benchmark 不再只是人工寫一個題目，然後假設哪個答案算對。相反地，它試圖保留 investigation 最重要的那條證據鏈：攻擊真的發生過、log 真的被產生、你真的得沿著 telemetry 去追。
作者也不是只做 true positive case。他們還特別處理 false positive：那些看起來可疑、足以觸發告警，但最後調查應該證明是 benign 的事件。這點非常重要，因為 production SOC 最痛的從來不只是漏報，還有你每天被大量 benign alert 拖死。
這篇論文最好的地方：它把評估拆成三個層次
SIR-Bench 的評估不是只有一個總分，而是拆成三個互補指標：
- M1：Triage Accuracy —— 最後判斷 TP / FP 對不對
- M2：Novel Finding Discovery / Investigation Depth —— 有沒有找到 alert 之外的新證據
- M3：Tool Usage Appropriateness —— 工具用得對不對
真正有新意的是 M2。作者把 findings 分成兩種：
- 一般 findings：你在調查報告裡提到的安全相關事實
- novel findings：這些事實不是 alert 文字本身已經講出來的，而是你靠查工具、翻 telemetry、串證據才挖到的
換句話說，這篇 paper 真正想量的不是「agent 會不會整理」，而是它能不能從原本模糊的告警，真的長出更深一層的 incident understanding。
為什麼這個設計比只看 accuracy 更接近現場？
因為在真實 IR 裡，一個看起來很漂亮的結論，如果沒有新的、可驗的證據支撐，很多時候其實沒那麼有用。
例如同樣判定某事件是 true positive：
- 弱的 agent 可能只會說：「這符合 credential exfiltration pattern，應視為惡意活動。」
- 強的 agent 則會指出：「access key 在外部 Kali host 被使用、後續有 cross-account role assumption、列舉過哪些 bucket、資料往哪個外部 IP 流動。」
這兩者的 operational value 完全不同。前者比較像是把告警合理化；後者才是你可以拿去支援 escalation、containment、scoping 與 post-incident review 的東西。
所以我會說，SIR-Bench 真正補上的，不只是另一個 benchmark，而是一個更像 analyst 工作方式的評測哲學。
資料集長什麼樣？
作者把案例分成幾個常見 incident pattern 類別，包括：
- Brute Force
- Malicious File Execution
- Misconfiguration
- Unauthorized Access
這種分類很實際，因為它不是抽象能力類別，而是比較像 SOC / cloud IR 現場真的會遇到的 case family。論文也強調，整體 false positive rate 約 40.2%，刻意去逼近 production alert 現實，而不是把 benchmark 做成一個乾淨漂亮、很容易被模型猜中的世界。
評分機制也有意思：不是盲信 LLM-as-a-Judge，而是刻意做 adversarial judge
這篇還有一個我覺得相當成熟的地方：作者知道 LLM-as-a-Judge 很容易出現一個問題——只要 agent 報告寫得像樣，judge 就很可能被話術說服。
所以他們刻意把 judge 設計成偏 adversarial 的模式，也就是預設沒有 security activity，除非 agent 真的拿出具體證據，否則不輕易給分。這其實就是把 incident response 裡一個很重要的工作原則搬進評測：burden of proof 應該在主張有事的那一方，而不是在評審那一方自行腦補你可能有查過。
另外，在 finding matching 上，他們沒有完全把判定交給另一個 LLM，而是用經過人工校準的 ROUGE-L threshold 去做對應。這不一定完美，但它有個現實優勢：便宜、可重現、而且不會每次 judge 心情不同就改分。
結果怎麼看？
作者用自己的 SIR agent 跑完整個 benchmark，得到幾個很醒目的數字：
- 97.1% true positive detection
- 73.4% false positive rejection
- 平均每個 case 找到 5.67 個 novel key findings
- 在 true positive case 上，novel finding coverage 為 41.9%
如果只看 M1，這成績已經不差；但我覺得更值得看的其實是 M2。因為這個 benchmark 的重點不在於證明「agent 很強」，而是在於把能力分層：你不只要分得對，還要查得深。
從論文數字看，這套 agent 在 unauthorized access 類別表現最好，因為 CloudTrail 對這類事件本來就比較有豐富證據鏈；但在 malicious file execution 上就明顯比較弱。這不是太意外，因為如果只靠 CloudTrail，本來就看不到太多 instance-level activity。這也點出一件很實在的事：IR agent 的上限，不只受模型能力限制，也受 telemetry 邊界限制。
這篇論文真正戳到哪個痛點？
我覺得它精準戳到現在很多 SOC / IR agent 討論裡最容易被糊掉的地方：我們太常把「判得像」誤認成「查得對」。
而這在 security 場景特別危險，因為：
- 表面上看起來合理的報告，很可能只是把 alert 重述一遍
- 高 recall 不代表高 investigation quality
- 如果沒有新的 evidence，很多 containment / escalation decision 其實站不穩
- 一個會說故事的 agent，不等於一個真的會做 DFIR 的 agent
所以這篇 paper 在我看來，不是在炫耀某個 SIR agent 已經多成熟；它比較像是在替整個領域補一句很該早點說的話：
對 incident response agent 來說，最該被獎勵的不是把判決說得漂亮，而是把 alert 以外的證據真的挖出來。
放回近期 sectools.tw 主線裡，SIR-Bench 補的是哪一塊？
如果把它放回最近這串文章脈絡，SIR-Bench 的位置其實很漂亮。
前面像 SIABench、SOC-bench、IRCopilot、LLMs in the SOC、Like a Hammer, It Can Build, It Can Break 這些文章，分別在談 incident analysis、blue-team benchmark、IR agent 架構、真實採用情況與人機協作邊界。但 SIR-Bench 往前補了一個很細、卻很關鍵的問題：就算 agent 最後判對了，我們怎麼知道它不是只會背 alert？
也就是說，它補的是 investigation epistemology 這一層：你到底怎麼定義「真的調查過」？
這層如果沒補起來，很多 agent demo 其實都會有一點危險，因為你很容易被高階 summary 與漂亮敘事騙到，以為系統已經具備 analyst-grade capability。
這篇的限制也很清楚
當然，論文不是沒有邊界。
- 目前主要聚焦 AWS / CloudTrail 世界，雲外或主機內部 evidence 還沒真正涵蓋
- Malicious File Execution 類別已經明顯暴露 telemetry boundary 問題
- 作者評的是自家 SIR agent，雖然 benchmark 本身有價值，但跨架構比較仍待後續公開驗證
- ROUGE-L 做 finding match 很務實，但也不可能完美等同 human semantic judgment
不過這些限制反而讓它顯得比較誠實。作者沒有假裝自己已經解完 autonomous IR 評測，而是很明白地指出：如果未來要做得更完整，還得把 VPC Flow Logs、runtime telemetry、host-level logging，甚至 multi-cloud evidence 一起拉進來。
我的看法
我自己很喜歡這篇，因為它處理的不是最 flashy 的問題，卻是最該先搞清楚的問題。
現在資安圈談 agent，很容易一路衝去問：
- 它能不能自動 triage？
- 能不能自動調查？
- 能不能自動 response？
但 SIR-Bench 逼我們先退一步問：你所謂的「調查」，到底是指它最後給對答案，還是指它有能力沿著證據鍊走出 alert 本身看不到的部分？
這個差別，決定了你是在評一個會講 security 報告的模型，還是在評一個真的可能進入 production IR workflow 的 agent。
如果要我用一句話總結這篇 paper，我會這樣講：
在 incident response 裡，真正有價值的 agent 不是最會下結論的那個，而是最會把 alert 外面的證據慢慢挖出來的那個。
而 SIR-Bench 的價值，就在於它終於開始認真量這件事。