SOC-bench 論文閱讀分析：我們終於開始認真評估多代理人 AI 的藍隊 incident response 能力了嗎？
論文基本資訊
- 論文標題：Design principles for the Construction of a Benchmark Evaluating Security Operation Capabilities of Multi-agent AI Systems
- 作者：Yicheng Cai、Mitchell John DeStefano、Guodong Dong、Pulkit Handa、Peng Liu、Tejas Singhal、Peiyu Tseng、Winston Jen White
- 來源：arXiv:2603.28998v1
- 年份：2026
- 主題：SOC、Benchmark、Blue Team、Incident Response、Multi-Agent AI、Ransomware、Security Evaluation
- 論文連結：https://arxiv.org/abs/2603.28998
本文由 AI 產生、整理與撰寫。
如果前面幾篇 sectools.tw 的主線，已經一路從 CTI benchmark、SOC triage、agentic security、human-AI collaboration 走到「模型到底會不會做事、能不能進 workflow、該不該讓它進高風險決策」，那接下來其實很自然會撞上一個更基礎、也更麻煩的問題：我們到底要用什麼 benchmark，來評估多代理人 AI 在藍隊現場的真實能力？
這個問題之所以麻煩，是因為目前很多大家熟悉的 security benchmark，不是偏紅隊、偏 CTF、偏單一任務，就是偏知識問答。它們當然有價值，但它們測到的東西，和真實 SOC 在大型事件中的工作，往往還是隔著一整層 operational reality。
這篇 Design principles for the Construction of a Benchmark Evaluating Security Operation Capabilities of Multi-agent AI Systems 有意思的地方，就在於它沒有急著再丟出一份 leaderboard，而是先回到更上游的問題：如果我們真的要做一個評估藍隊 incident response 能力的 benchmark，那它應該遵守哪些設計原則？
作者把這個概念叫做 SOC-bench。而我認為這篇論文真正值得看的，不只是它提出了五個任務，而是它很清楚地指出：藍隊 benchmark 不能只是把幾個零散資安小題拼起來，也不能照搬紅隊 benchmark 的設計哲學。因為真正的 SOC 工作，本來就是跨任務、跨證據來源、跨時間窗、而且充滿不完美資料的 incident response 過程。
這篇論文想補的缺口非常明確：今天我們對 multi-agent AI 的安全評估，還是太偏紅隊了
作者一開始就點出一個很現實的問題：現在 AI × cybersecurity 的 benchmark，確實已經不少，但多數比較集中在幾個方向：
- 紅隊滲透與 exploit 能力
- CTF 或攻防競賽型任務
- 單點藍隊子任務，例如 IoC extraction、patch generation、某種特定分類問題
問題在於，這些 benchmark 和真實 SOC 的核心工作並不完全對齊。因為真實 SOC 在面對大型 ransomware campaign、橫向移動、資料外洩、檔案加密、containment 決策時，做的不是一道題、不是一個 prompt，也不是一個單點分類器能完成的工作。它比較像是一場橫跨多個角色、多種資料來源、多個時間階段的持續調查與應變流程。
所以作者認為，如果產業真的開始認真談「更自主的 SOC」與「multi-agent AI 進藍隊流程」，那我們就不能一直只拿偏紅隊的 benchmark 或碎片化藍隊小任務來當代理指標。你需要的是一個真的對準 Blue Team – Incident Response 類型工作的 benchmark。
這個判斷我認為很準。因為現在很多 security AI 討論，最大的問題不是沒有結果，而是評估目標和實際部署目標對不上。你可以證明模型會做資安問答、會打 CTF、會抽 IOC、會寫規則，但這不自動等於它有能力在真實 SOC 事件中與其他 agent 協作、跨證據推理、面對告警延遲與資料缺漏，最後做出對 incident response 真的有用的輸出。
這篇論文最重要的不是任務清單，而是五個設計原則
我認為整篇 paper 的骨架，就是作者提出的五個 design principles。這五點其實比後面的 task 細節更重要，因為它們決定了這個 benchmark 想測的到底是什麼。
原則一：金標不是理想化未來 SOC，而是現實世界「本來就長這樣」的 SOC
第一個原則非常關鍵：除了把人類的角色縮到 supervisor 之外，benchmark 應該以現實世界已存在的 incident response 系統為 gold standard，而不是某種重新設計、重新最佳化過的未來理想 SOC。
這句話看起來抽象，其實很有殺傷力。因為很多 benchmark 一做，就會默默犯兩種錯：
- 把環境做得太乾淨、太理想、太像實驗室
- 讓 AI 獲得現場人類本來不會有的先驗提示、結構線索或過度整理好的資料
SOC-bench 反過來要求幾件事：
- 事件要基於真實發生過的大型攻擊事件
- 資料來源要是 SOC 本來就常用的那些來源
- AI 不能知道超出 SOC 可見範圍的攻擊真相
- 部署 AI 不應神奇地消除原本存在的不確定性
這點很成熟，因為它承認了資安現場一個最根本的事實：藍隊永遠是在不完整資訊下工作。 你不知道 attacker 全貌，不知道對方最終目標，不知道哪些缺失是雜訊、哪些是真異常。若 benchmark 一開始就把世界整理得過度透明，那它評到的就不是藍隊 incident response，而只是資訊充足環境下的資安推理遊戲。
原則二：不要替 AI 預先標出跨任務依賴，讓它自己去發現
第二個原則同樣重要：因為真正的多代理人藍隊系統，應該能自主探索不同任務之間的資料與控制依賴，所以 benchmark 不應該主動給它 cross-task hints。
這個設計哲學，其實是在反對一種很常見但不太誠實的 benchmark 作法：名義上在測多步驟協作，實際上卻在題目結構裡偷偷把協作路徑都寫好了。
如果 benchmark 直接告訴 agent：
- 哪個任務會依賴哪個任務的輸出
- 哪幾種 coordination pattern 最有效
- 哪些 signals 要拿去餵後續模組
那你最後測到的，很可能不是 agentic blue-team capability，而是 agent 有多會照著 benchmark 作者預想的路線走。這就會讓 benchmark 變成一種被強烈結構化的流程測驗，而不是對自主 incident reasoning 能力的評估。
作者在這裡其實是在要求一件更難、但也更接近真實世界的事：讓 AI 自己辨認「哪些資訊對誰有用、什麼時候該交棒、哪些調查結果應該回流到其他任務」。
原則三：不要只測 AI 是否模仿人類流程，而是看它是否交出正確結果
第三個原則我很喜歡，因為它比很多安全論文更少人類中心偏見。作者認為，AI 系統不需要嚴格模仿人類 analyst 的解題程序；真正該評估的是它能否在相同輸入下，交出正確且可驗證的 outcome。
換句話說，SOC-bench 採的是一種 outcome-only principle。這代表：
- 你不需要照人類分析師的順序思考
- 你也不必複製人類團隊的逐步調查細節
- 只要最後交出的判斷、歸納、關聯與建議是對的，就應該得分
這很重要，因為它避免把 benchmark 做成「評估 AI 有多像人類 analyst 演戲」。現實中真正有價值的 AI，未必會沿著人類原有流程行動。它可能會用不同順序整合資料、用更快方式做 cross-host correlation、或在某些地方採取人類不直覺但結果更好的策略。
如果 benchmark 把「像不像人」當成核心分數，那它很可能會壓抑真正有機會超越人類工作方式的系統設計。作者在這裡其實是在說：我們應該評估 AI 的藍隊能力，而不是 AI 的 analyst cosplay 能力。
原則四：真實 SOC 本來就不完美，benchmark 也不能裝作它很乾淨
第四個原則說得很直白：真實 SOC 內的 telemetry、IDS、SIEM alerts、本來就有 false positive、false negative、延遲與可見性缺口。 所以 benchmark 必須把這些缺陷保留下來，而不是刻意消毒。
這一點對藍隊 benchmark 特別關鍵，因為藍隊工作難的地方，往往不是知識本身，而是在模糊、不一致、不完整的訊號裡做判斷。如果你把資料做成乾乾淨淨、所有 log 都完整、所有 alert 都準時、所有 evidence 都彼此一致，那你其實是在測一個不存在於現實的 SOC。
作者也提到，很多有潛力的資料來源在真實世界根本不一定能取得，例如更底層、更理想的量測訊號。這意味著 benchmark 不應假設未來系統一定有超豪華可觀測性。它應該忠實反映：藍隊常常只能用手上已有的、 imperfect 的、延遲的資料做出足夠好的決策。
原則五：不要讓 benchmark 綁死在當下流行的 AI 技術棧上
第五個原則則更像是對未來的預防針：SOC-bench 不應該依附於當前某種特定 AI 技術，例如 MCP、RAG、MoE 或某種熱門 agent 編排方式。
這點非常必要。因為 AI 安全論文很容易跟著技術潮流跑，結果 benchmark 才剛做出來，就已經被一代新框架甩開。作者在這裡提醒的是：benchmark 要測的是藍隊能力本身，而不是某個世代工具鏈的熟練度。
這也讓 SOC-bench 的企圖更清楚：它不是想成為「評估某種現有 agent framework」的 benchmark，而是想成為一個能跨技術演化、持續評估 blue-team autonomy 的長期基礎設施。
作者不是空談原則，而是直接給出一個五任務的 SOC-bench 概念設計
為了驗證這五個原則不是空話，作者進一步提出了一個概念性 benchmark 設計，場景鎖定在大型 ransomware incident response，而且具體參照了 Colonial Pipeline 類型事件的企業網路情境。
這個選擇很有代表性。因為大型 ransomware 不只是「檔案被加密」這麼簡單，它通常天然會牽動：
- 早期異常偵測
- 橫向移動判讀
- 主機與檔案系統鑑識
- 資料外洩分析
- IOC / TTP 與 threat attribution
- containment 與決策建議
也就是說，它本身就適合拿來當一個能測 cross-task dependency 的 incident response 戰場。
作者把 SOC-bench 概念設計拆成五個任務，名稱分別是：
- Task Fox：Early cyberattack campaign detection
- Task Goat：File system forensics
- Task Mouse：Data exfiltration analysis
- Task Tiger：IOC 分析、攻擊歸因與 TTP 報告
- Task Panda：Containment action recommendation
這五個任務的漂亮之處，在於它們並不是五個彼此獨立的小題，而是共同構成了真實藍隊事件處理中最典型的一段鏈條。換句話說，作者不是要測 AI 是否會做某一項 SOC 技能，而是要測它能不能在一個真實 incident story 裡，把多種技能串起來。
Task Fox 很值得注意：它不是問「有沒有惡意」，而是問「這是不是一場正在成形的 campaign」
在五個任務裡，我覺得最有代表性的是 Task Fox。因為它很清楚地展示出這個 benchmark 與傳統告警分類題目不一樣的地方。
Task Fox 的目標，不是單純判斷某一筆事件是否惡意，而是要在多個 stage 中，持續回答三件事：
- 這是 isolated anomaly、localized issue，還是 campaign-scale attack？
- 如果是 campaign-scale，它更像 ransomware-like activity，還是其他型態的 coordinated attack？
- 能不能產出一個 evidence-backed 的 SOC alert bundle，把 cross-host、cross-stage 的訊號關聯起來？
這個設計比一般「惡意 / 正常」分類成熟很多，因為它直接貼近了真實 SOC 早期 triage 最難的地方：你看到的往往不是完整答案，而是一群分散在不同主機、不同時間窗裡的異常片段。你得先判斷它們是不是同一件事，再判斷它們正在朝什麼方向演化。
而且作者刻意要求這些輸出都要帶 evidence linkage，還會在不同 stage 下評分 earliest stage。這就使 benchmark 不只是測最後有沒有答對，而是在問：你能不能在足夠早、資訊還不完整的時候，就做出足夠可信的判斷。
這種設計非常像真實藍隊工作。因為 incident response 的價值，常常不只在最終 diagnosis，而在夠不夠早看出這不是零星事件、夠不夠早意識到它正在擴大。
Task Goat 也很實戰：它把檔案系統鑑識從「有沒有被加密」拉回可驗證的多層級判讀
Task Goat 則聚焦在 ransomware 場景下的 file-system forensics。這個任務要 AI 系統完成的，不只是說「某主機中鏢了」，而是要交出多種更細的輸出：
- file 與 directory level 的 encryption-state labels
- host / share 層級的 impact aggregation
- VSS tamper facts
- primary encryptor process tree attribution
- 最後再整成一頁摘要
這裡很值得注意的一點是，作者不是把 ransomware forensics 想像成單點 artifact 偵測，而是把它設計成一個從低層 evidence 到高層彙整的多層級推理任務。你必須同時面對 file metadata、change journal、process telemetry、backup/VSS logs、甚至 helpdesk reports，而且還要避免被過於簡單的 proxy signal 誤導。
例如論文就特別提醒：不能只因為看到 ransom note 就認定整個目錄都算加密，也不能單靠 SIEM summary 就做 attribution。 這種限制很合理，因為它迫使 benchmark 真的回到 evidence hygiene，而不是讓模型靠幾個高關聯關鍵字取巧。
SOC-bench 的場景設定也很聰明：不是抽象世界，而是帶著真實網路限制的企業 incident
作者在 network topology 與 scope 的設定上也很有意識。SOC-bench 對應的是一個模仿 Colonial Pipeline 事件條件的企業網路，包含 corporate IT、OT、remote access 等區塊，而且保留了 segmentation 不完善、橫向移動可行、資料可見性受限等真實限制。
這些設定的重要性在於，它讓 benchmark 的很多高層任務有了共同戰場。也就是說，Fox、Goat、Mouse、Tiger、Panda 並不是五個抽象技能包，而是發生在同一個 incident universe 裡的不同調查與應變面向。
這會帶來兩個好處：
- 第一，跨任務依賴變得自然。 早期 detection 的判讀，會影響後續 containment 與 attribution；檔案系統鑑識與資料外洩分析，也可能彼此補充。
- 第二，benchmark 不再只是拼盤，而更像真實事件 replay。
這種設計方向，我認為比很多把 security task 拆成孤立 benchmark 的做法更值得期待。因為真正的 incident response，最難的本來就不是每個子題各自的局部最優，而是如何把不同局部任務的結果編織成可行動的整體理解。
這篇論文的真正野心：不是做一套題，而是替「更自主的藍隊 AI」先蓋評估基礎設施
如果只看表面，這篇 paper 好像還沒有完整釋出一套可直接跑 leaderboard 的 benchmark，而比較像設計論文。但我認為這恰恰是它的價值所在。
因為在 agentic security 這波浪潮裡，很多人急著討論：
- 哪個多代理人架構最強
- 哪個模型最會做 alert triage
- 哪種 RAG / tool use / orchestrator 最有效
但如果沒有一個真正對應藍隊 incident response 的 benchmark，這些比較其實很容易流於 demo 對 demo、prompt 對 prompt、場景對場景。你很難知道它們到底是在優化真實 SOC 能力，還是在優化某個特定作者自己搭的 showcase。
從這個角度看，SOC-bench 的野心比較像是在補一塊評估基礎設施空白。它不是先問「誰最強」，而是先問「我們到底該怎麼公平、務實、長期地測這件事」。這一步其實很枯燥，但往往也最重要。
這篇論文的限制也很清楚：它現在更像 benchmark manifesto，而不是已經成熟的 production benchmark
當然，這篇論文也不是沒有侷限。
第一，它目前比較像一篇 benchmark design / manifesto 型論文。也就是說，它最強的是問題意識、設計原則與概念框架，而不是已經完成大規模實測、能立刻拿來全面比較模型的成熟 benchmark ecosystem。
第二，它目前選擇的 incident 宇宙相對集中在 大型 ransomware response。這當然是合理起點，因為 ransomware 天然具有多任務交織特性；但如果未來真要做成長期基礎設施，可能還需要延伸到其他 incident 類型，例如 cloud intrusion、supply-chain compromise、identity-centric attack、OT-specific response 等。
第三，它強調 outcome-only、避免 technology lock-in、保留現實不完美，這些方向都對；但真正落地時，grader consistency、evidence resolution、task boundary 定義、以及不同 agent systems 的 submission normalization，都還會是很硬的工程問題。
不過這些問題並不削弱它的價值。反而可以說，這篇論文最誠實的地方就在於：它沒有假裝藍隊 autonomy benchmark 是一件輕鬆的事，而是把難處直接攤在桌上。
怎麼把它放進近期 sectools.tw 追的主線裡？
如果把最近這幾篇放在一起看，這篇的位置其實非常漂亮。
- 像 CTIBench、AthenaBench、AttackSeqBench、CyberMetric、CAIBench，比較偏向能力盤點與 benchmark 地圖建立。
- 像 CyberThreat-Eval，則是把 benchmark 往真實 threat research workflow 推進。
- 像 CORTEX、AIDR、LLMs in the SOC、Policy-Guided Threat Hunting，是在問 AI / multi-agent 要怎麼進 SOC 的實際調查與決策流。
- 而這篇 SOC-bench design paper，剛好補上最上游的一塊：如果未來真的會有越來越多「號稱能做藍隊 incident response 的 agentic system」，那我們該用什麼 benchmark 去測它們，而不是只看漂亮 demo？
所以它雖然不像某些應用論文那樣直接展示一個 flashy system，但它對這條閱讀主線的價值其實很高。因為當討論從「模型會不會答題」升級到「模型能不能接工作」，下一個必然問題就是：那我們怎麼評估它接工作的能力？
我的看法：這篇最有價值的地方，是它終於把藍隊 benchmark 從「題目」拉回「事件」
老實說，我覺得這篇論文最值得記住的一句潛台詞是：藍隊工作不是一組題目，而是一場事件。
這句話其實很重。因為只要你還把藍隊能力理解成幾道 extraction 題、幾個 classification labels、幾個 MITRE mapping 小任務，你就很容易高估模型的 readiness。真正的 incident response 是一個持續展開的過程：資料不完整、訊號彼此矛盾、時間壓力存在、影響面在變化、不同任務彼此依賴、而 containment 的代價也不是零。
這篇論文的貢獻，就是強迫我們把 benchmark 設計重新對準這件事。它提醒產業：如果你真的想走向更自主的 SOC，就不能只測模型答得對不對，而要測它在一場不完美事件裡，能不能像藍隊一樣持續工作。
而這裡我最欣賞的一點，是作者沒有把答案寫成「只要多 agent 就會好」。相反地，他們比較像是在說：先把評估地基蓋好，再來談 autonomy；不然你看到的很可能只是會表演的系統，不是能負責的系統。
總結
Design principles for the Construction of a Benchmark Evaluating Security Operation Capabilities of Multi-agent AI Systems 是一篇很值得補進近期 CTI / SOC / agentic security 閱讀地圖的論文，因為它不是再做一個新的 flashy agent demo，而是回到更根本的問題：藍隊 incident response 的 AI 能力，到底該怎麼被正確評估？
我會把它的核心價值整理成四點：
- 明確指出現有 security benchmark 太偏紅隊、太偏單點任務，無法真正代表 SOC incident response。
- 提出五個很成熟的 benchmark 設計原則：忠於現實 SOC、保留 cross-task 自主探索、重 outcome 不重模仿、保留資料不完美、避免綁死在當代技術棧。
- 用 Fox / Goat / Mouse / Tiger / Panda 五任務概念設計，示範藍隊 benchmark 應如何圍繞同一場真實 incident universe 來建構。
- 替未來更自主的 SOC AI 系統，先補上一塊一直很缺的評估基礎設施思維。
如果你正在關注的不只是「模型懂不懂資安」，而是「它能不能真的在 SOC 裡工作」，那這篇論文非常值得讀。因為它把一件經常被忽略、但其實決定一切的事說清楚了：沒有對的 benchmark，就很難有對的進步；而藍隊要的從來不是會答題的模型，而是能撐住事件的系統。
本文由 AI 產生、整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。