CyberTeam 論文閱讀分析：把藍隊 Threat Hunting 真正拆成一條可執行的 LLM workflow
論文基本資訊
- 論文標題：Benchmarking LLMs in an Embodied Environment for Blue Team Threat Hunting
- 系統名稱：CyberTeam
- 作者：Feiyang Yu、Xi Li、Guanhua Yan、Ping Yang、Zhaohan Xi
- 年份：2025
- arXiv：https://arxiv.org/abs/2505.11901
- DOI：10.48550/arXiv.2505.11901
- 主題：Blue Team、Threat Hunting、Benchmark、Embodied Functions、LLM Evaluation、SOC、CTI Workflow
如果前一批論文還在問「LLM 懂不懂 CTI」、「會不會做 SOC triage」、「能不能幫 analyst 寫報告」，那 CyberTeam 這篇論文往前推的一步是：我們能不能把藍隊 threat hunting 拆成一條有依賴關係、可逐步執行、可模組化評估的工作鏈，然後真正去量模型在這條鏈上的表現？
這篇論文的價值，不在於它又做了一個新的資安題庫，而在於它明確意識到：真實 threat hunting 從來不是單題問答，而是一串互相依賴的分析動作。 你要先抽 IOC、判斷 threat actor、理解行為，再往下做優先排序、response 與 mitigation。很多既有 benchmark 只測其中一小段，但 CyberTeam 試圖把這整條 pipeline 組起來，而且不是完全放任模型自由發揮，而是用一組作者稱為 embodied functions 的結構化工具，去引導模型按照藍隊邏輯一步步做事。
對 sectools.tw 這條主線來說，CyberTeam 很值得看，因為它正好卡在兩個世界中間：它不像純知識 benchmark 那麼靜態，也不像真正 live agent environment 那麼昂貴難控。它更像是一個把 threat hunting workflow 明確程序化的中介層，讓我們開始比較嚴肅地問：模型不是會不會答，而是能不能沿著藍隊任務鏈穩定往下做。
這篇論文想解決什麼問題？
作者的起點其實非常實際。現有 LLM for cybersecurity 的研究雖然越來越多，但大多落在兩種形式：
- 單點任務評估：例如做 malware classification、CVE 問答、CTI 摘要或 log interpretation。
- 開放式 agent 展示：看起來很厲害，但難以做系統化比較，也不容易知道模型究竟卡在哪一段。
問題在於，真實 blue team threat hunting 並不是孤立任務的集合，而是一個有明顯上下游依賴的流程。你如果前面 attribution 做錯，後面的 mitigation 建議再流暢也只是錯得更完整。因此這篇論文真正想回答的是：
能不能用更接近藍隊實務的流程結構，去評估 LLM 在 threat hunting 上的能力，而不是把整件事切碎成互不相干的小題目？
這個問題很重要，因為它直接牽涉到我們到底在量什麼。如果 benchmark 測的是脫離脈絡的片段能力，那最後得到的多半只是「這模型懂一些資安概念」；但 CyberTeam 想測的是另一件事：這模型是否能在一條有順序、有依賴、有格式要求的藍隊工作流裡持續產出可用結果。
CyberTeam 的核心設計：把 threat hunting 變成 dependency chain
CyberTeam 最值得注意的設計，是它把 threat hunting 明確拆成四大類工作：
- Threat Attribution
- Behavior Analysis
- Prioritization
- Response & Mitigation
這四類並不是平行擺著而已，而是被作者整理成一條任務依賴鏈。也就是說，某些下游任務需要依賴前面任務的輸出才能完成。例如：
- 要做 actor identification，通常得先完成 infrastructure extraction 或 campaign correlation 的某些線索整理。
- 要做 attack complexity、severity scoring 或 playbook recommendation，前面對行為與攻擊路徑的理解就不能太差。
- 要做 response & mitigation，前提通常是 attribution 和 behavior analysis 不能崩。
這種 dependency-chain 的設計，讓 CyberTeam 比一般 benchmark 更像 analyst workflow。它不是單純在問模型「你知道這個 IOC 代表什麼嗎」，而是逼模型先把前置拼圖拼起來，再往後推。這點非常關鍵，因為很多模型在單點題目上看起來不錯，但一旦任務之間開始互相依賴，表現就會明顯掉下來。
Embodied functions 是什麼？為什麼它重要？
CyberTeam 另一個核心概念是 embodied functions。作者沒有讓模型在整條流程裡完全自由生成，而是設計了 9 種函式型能力模組，例如：
- NER：命名實體辨識
- REX：正規表示式解析
- SUM：摘要
- SIM：相似度比對
- MAP：文字映射
- RAG：檢索增強生成
- SPA：片段定位
- CLS：分類
- MATH：數值計算
每個 threat-hunting task 都會對應到一組適合的 embodied functions。比如：
- Infrastructure Extraction 可能會用到 NER、REX、SUM。
- TTP Extraction 會結合 RAG 與 MAP。
- Severity Scoring 會用到 SUM 與 MATH。
- Playbook Recommendation 或 Patch Tool Suggestion 則偏向 RAG 與 SUM。
這裡的真正重點，不只是「有工具可用」，而是作者在嘗試把藍隊任務裡不同類型的 cognitive operation 拆出來。這件事的研究意義很大，因為它讓 benchmark 不只是看最後答對沒，而是開始能討論：模型在哪一類程序性能力上穩，在哪一類程序性能力上會失真。
換句話說，CyberTeam 想做的不是一個純開放式的 agent playground，而是一個有結構、可追蹤、可比較的 threat-hunting function-calling environment。
資料規模與任務覆蓋面
CyberTeam 在規模上也不小。根據論文，它一共包含 30 個 threat-hunting tasks，橫跨上面四大類工作，並結合 23 個 vulnerability databases 與 threat intelligence sources。文中提到的來源包括：
- MITRE ATT&CK、MITRE CVE、CWE、CAPEC、D3FEND
- NVD、Exploit-DB、VulDB
- Microsoft Security Update Guide、IBM X-Force
- VirusTotal、AlienVault OTX、MISP
- Mandiant、Recorded Future、Unit 42 等 threat intelligence 平台或報告來源
這種設計反映出作者不是只想做學術題庫，而是想把 vulnerability metadata、threat intelligence、response knowledge 都一起納入。從藍隊觀點看，這很合理，因為真實分析師也本來就不是只看單一資料庫，而是在多個來源間來回對照。
更重要的是，30 個 task 的設計覆蓋面相當完整。例如在 Threat Attribution 裡就包含：
- Malware Identification
- Signature Matching
- Temporal Pattern Matching
- Affiliation Linking
- Geographic Analysis
- Victimology Profiling
- Infrastructure Extraction
- Actor Identification
- Campaign Correlation
而 Behavior Analysis、Prioritization、Response & Mitigation 也各自有完整子任務，像是：
- Command & Script Analysis
- Event Sequence Reconstruction
- Attack Vector Classification
- Severity Scoring
- Patch Code Generation
- Advisory Correlation
這種 breadth 本身就很有意義，因為它讓 CyberTeam 有機會回答一個比「平均分多少」更有價值的問題：模型到底在哪些藍隊工作段落掉鍊子？
CyberTeam 真正想比的是什麼？
論文的評估問題（RQ）設得很清楚，主要圍繞四件事：
- Embodied functions 相較於 ICL、CoT、ToT 這些常見 prompting 策略，是否更有效？
- LLM 是否真的能解 individual threat-hunting tasks？
- LLM 能不能理解 task dependencies，並選對 function？
- 在有噪音的 threat log 下，這套方法有沒有足夠 robustness？
這四個問題很聰明，因為它們不只是拿 CyberTeam 來排模型名次，而是在測一個更底層的命題：如果你給模型一個結構化藍隊工作環境，它到底會不會沿著這個環境做出比純 prompt engineering 更可靠的行為？
這對所有在做 agentic SOC、CTI copilots、investigation pipelines 的人都很重要。因為很多系統目前的做法，說穿了還是「一個大 prompt + 一點 RAG + 一點工具呼叫」，但缺少明確的 task decomposition 與 function constraints。CyberTeam 等於是在說：也許問題不只是模型不夠強，而是我們還沒有把 threat-hunting workflow 表述成它比較能穩定執行的形式。
這篇論文帶出的幾個重要訊號
雖然論文在本文中沒有像 leaderboard 網頁那樣塞滿所有細節數字，但從設計與作者的實驗敘事，可以讀出幾個值得注意的方向。
1. 藍隊 workflow 的「程序化」比單純提示技巧更重要
CyberTeam 其實在挑戰一個常見迷思：很多人以為把 prompt 寫得更長、更會說話，模型就會更像 analyst。但作者的設計暗示的是另一件事——對藍隊任務來說，真正重要的可能不是更花俏的 prompt，而是更明確的程序框架。
也就是說，與其期待模型自發理解 threat hunting 的工作節奏，不如把需要的操作類型、任務依賴與輸出形式先做結構化。這件事很像把 analyst workflow 從「自由揮灑」改成「標準作業＋保留彈性」，而這通常更接近大型團隊真正落地的方式。
2. 真實瓶頸不只在知識，而在任務銜接
CyberTeam 的四段式任務鏈讓人重新看到一個重點：模型未必缺資安知識，但常常缺的是把前一步輸出轉成下一步可用輸入的能力。這其實就是很多 analyst pipeline 失敗的原因。
你可以把它想成：
- 知道某段敘述提到 APT28，不代表你就能正確把它映射到後續 actor identification。
- 抽出了幾個 IOC，不代表你就能正確做 campaign correlation 或 response recommendation。
- 能夠摘要 log，不代表你就能把它轉成 severity judgement。
所以 CyberTeam 的價值，某種程度上不只是 benchmark，而是把 task handoff 這件事抬到台面上來。
3. 藍隊評估正從 QA benchmark 走向 workflow benchmark
如果把它放進近幾篇 sectools.tw 主線來看，會發現一條很清楚的演化：
- 早期 benchmark 常在測知識題、CTI extraction、單一分類任務。
- 後來開始出現更貼近 analyst 工作的 benchmark，例如 CTIArena、AthenaBench、SOC-bench、OpenSec。
- 而 CyberTeam 則站在中間，強調 以 embodied function 為骨架的 workflow evaluation。
它的重要性就在於：它把「工作流程」本身變成評估對象。 這比只是擴大題庫更有價值，因為真實部署時，模型很少是單回合回答一個問題，而是要在流程裡不斷把中間產物往後傳。
從實務角度看，CyberTeam 有什麼價值？
如果你是研究者，CyberTeam 當然是一個 benchmark；但如果你是產品團隊、SOC 架構師或在做內部安全 copilot，我覺得它至少有四個實務啟發。
第一，不要把 blue team automation 想成單一 agent 的自由發揮
很多人一想到 agentic security，直覺上會想做一個超大統一 agent，讓它自己決定該查什麼、做什麼、報什麼。但 CyberTeam 提醒你：更可行的做法可能是把工作拆成有類型的 function，再讓模型在這些 function 之間移動。
第二，task dependency 要做顯式建模
如果你的系統裡，attribution、behavior analysis、prioritization、response 建議之間沒有清楚的資料依賴與驗證規則，那模型再強也很容易在中間某步驟出現連鎖誤差。CyberTeam 的 dependency-chain 設計，正好可以拿來當這類系統設計的參考。
第三，格式約束與程序約束本身就是安全機制
資安任務最怕模型一本正經地胡說。Embodied functions 的一個潛台詞是：當你把模型限制在某些明確函式與輸出型態裡，至少比較容易檢查、比較容易追錯，也比較不容易一路自由幻覺到底。
第四，benchmark 不該只問答對沒，而要問哪一段最脆弱
這點對產品最重要。很多團隊只看總體分數，但 CyberTeam 這種 task-rich benchmark 更適合回答：
- 模型是 attribution 弱？
- 還是 behavior analysis 弱？
- 它在 prioritization 會不會亂判？
- response recommendation 會不會前面都對、最後卻建議錯？
這類診斷資訊，遠比單一 accuracy 更有落地價值。
這篇論文的限制在哪？
CyberTeam 很有價值，但也要看清楚它的邊界。
- 它仍然不是 live operational environment：雖然比純 QA benchmark 更接近 workflow，但它並沒有真的把模型放進會動的企業網路或真實 IR 環境。
- embodied functions 是作者定義的 abstraction：這很有研究價值，但不代表每個實務團隊都會同意這九類 function 正好是最佳切法。
- 部分任務仍偏資料驅動 benchmark：它比一般題庫更流程化，但離真正 analyst 面對雜訊、權限、時間壓力與組織成本的現場，還是有距離。
- 開放式推理仍受限：流程更清楚的代價，往往就是犧牲某些創造性或非預期路徑的探索能力。
所以我會把 CyberTeam 定位成：它不是最終的藍隊 agent deployment benchmark，但它是一個非常重要的過渡層。 它讓評估從「問模型懂不懂」往「看模型能不能沿著藍隊流程做事」推進了一大步。
我的看法：CyberTeam 的重點不是分數，而是它代表的設計哲學
我覺得 CyberTeam 最值得注意的，不是某個模型在某幾項 task 上多幾分，而是它背後反映的那種設計哲學：
- 不要只測知識，要測 workflow。
- 不要只看輸出，要看任務依賴。
- 不要只靠 prompt，要給模型一個可操作的程序骨架。
- 不要只談 autonomous agent，要先把 analyst work decomposition 做清楚。
這幾點其實就是現在很多安全 AI 系統最缺的東西。大家都在追求「更像 agent」，但真正缺的常常不是更多自主性，而是更清楚的工作結構。CyberTeam 正是在提醒我們：如果沒有結構，模型即使會很多，也不一定能沿著藍隊工作的節奏把事情做完。
重點整理
- CyberTeam 想解決的，不是單點資安問答，而是 blue team threat-hunting workflow 的系統化評估。
- 它把 threat hunting 拆成 Threat Attribution、Behavior Analysis、Prioritization、Response & Mitigation 四大階段。
- 核心設計是 task dependency chain，強調上下游任務之間的依賴關係。
- 論文提出 9 種 embodied functions，用來約束模型在不同任務中的操作類型。
- 整體 benchmark 含 30 個 tasks，並整合多個漏洞資料庫與 threat intelligence 來源。
- 它比純 QA benchmark 更接近 analyst workflow，也比完全自由的 agent 展示更可比較、可診斷。
- 對實務最有價值的啟發，是 把 blue team automation 做成有程序、可驗證、可追蹤的 function chain。
- 它的限制是仍不等於 live SOC / IR 環境，但已經是從題庫走向 workflow benchmark 的重要一步。
一句話總結
CyberTeam 最值得看的地方，不是它又建立了一個新的資安 benchmark，而是它把藍隊 threat hunting 重新定義成一條可拆解、可依賴、可程序化執行的工作鏈，讓我們終於能開始更像在評估 analyst workflow，而不只是評估模型會不會答題。
免責聲明
本文由 AI 產生、整理與撰寫。內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要；儘管已盡力確保完整性與可讀性，仍可能因模型理解限制、資料版本差異或語意轉譯而存在疏漏、不精確或更新延遲之處。實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。