Advancing Autonomous Incident Response 論文閱讀分析：很多 IR 自動化真正缺的不是更大的模型，而是先把 CTI 餵進可行動的上下文
論文基本資訊
- 論文標題：Advancing Autonomous Incident Response: Leveraging LLMs and Cyber Threat Intelligence
- 作者：Amine Tellache、Abdelaziz Amara Korba、Amdjed Mokhtari、Horea Moldovan、Yacine Ghamri-Doudane
- 來源：arXiv
- 年份：2025
- 論文連結：https://arxiv.org/abs/2508.10677
- 主題：Incident Response、Cyber Threat Intelligence、RAG、SOC、Alert Enrichment、LLM
如果前幾篇 incident response 文章比較偏 agent 規劃、協作結構 跟 investigation depth，那這篇 Advancing Autonomous Incident Response 補的其實是另一個更貼近 SOC 現場、也更常被低估的問題：很多 IR automation 卡住，不是因為模型不會想，而是因為它根本沒被餵到夠像樣的 threat context。
作者的核心主張很直白：當 alert 只有幾行 SIEM 訊息、IOC 又是碎的、CTI 報告散在各平台與 PDF 裡時，單靠模型裸答 incident response，結果通常不是太空泛，就是太像 checklist。真正缺的不是再換一個更大的 LLM，而是先把 incident 與 CTI 之間那層 enrichment 做成可用的 retrieval pipeline。
這篇 paper 真正想推動的，不是讓 LLM 直接取代 responder，而是讓它先學會把 alert 接回 threat intelligence 脈絡，再產生比較像樣的 mitigation 建議。
這篇在解什麼問題？
論文開頭抓得很準：SOC 團隊每天面對大量告警、誤報、跨雲環境與碎片化 threat intelligence，分析師先被 alert fatigue 壓垮，後面才談得上 response quality。
而且 CTI 明明很重要，卻常常在流程裡變成昂貴又慢的一段：
- 要先找 IOC
- 再去 VirusTotal 之類平台查
- 再翻歷史 CTI 報告
- 最後才把這些資訊串回當前 incident
這整段如果還要人工完成，就很難真的跟得上 response tempo。也因此作者想做的不是另一個單純的 summarizer，而是一條把 SIEM alert、IOC lookup、CTI retrieval 與 response generation 串起來的 RAG-based IR workflow。
核心方法：不是單一檢索，而是 hybrid CTI retrieval
我覺得這篇最值得注意的地方，不是它用了 RAG——現在很多 paper 都會說自己用了 RAG。真正重要的是，它把 retrieval 拆成兩種不同性質的情報來源，再把兩者接起來。
- Standard search：先從 alert 抽 IOC，去查 VirusTotal 這類 CTI 平台 API，拿到 reputation、歷史惡意活動、地理資訊、關聯線索。
- NLP-based search：把 alert 與前一步 enrichment 後的內容轉成更有語意的查詢，再到 CTI report vector database 找相似歷史案例與文件片段。
這個設計的重點在於：它承認 IOC lookup 跟語意式 threat correlation 其實是兩件不同的事。 前者比較像查表、查 reputation；後者比較像把這次 alert 放回過往 campaign、TTP、案例脈絡裡理解。
很多所謂的 IR copilot 系統會把這兩者混成一句「我們做了 retrieval」，但實際上它們在 operational value 上差很多。作者這裡至少有把這個差異講清楚，也把它做成顯式架構。
它怎麼把 alert 變得更適合檢索？
論文有一個我蠻喜歡的小設計：不是直接拿 raw alert 去做向量檢索，而是先讓 LLM 依照 prompt 把 alert 重新改寫成更有上下文的 augmented alert。
原因很合理。很多 SIEM alert 原始內容非常乾，只有事件片段、少量欄位和 IOC；如果你直接拿這種東西去做 similarity search，常常只會撈到表面相近的片段，撈不到真正 relevant 的 CTI 報告。
作者的做法比較像先把 alert 語意補齊，再去找歷史 intelligence。這一步的價值，不在於讓模型多說幾句話，而在於把檢索 query 從 log fragment 提升成 incident hypothesis。
知識庫怎麼建？
這篇的 CTI knowledge base 目前主要來自公開的 APT / cybercriminal campaign reports，先做 PDF 轉文字、chunking、embedding，最後丟進向量資料庫。作者也提到未來希望直接整合 OpenCTI，讓資料同步更順。
這件事看起來很普通，但它其實剛好點出一個 production reality：IR automation 要落地，真正費工的通常不是 prompt，而是資料底座。
如果你的 CTI corpus 沒整理、沒 chunk 好、沒持續更新，那再聰明的生成模型也只是在更優雅地猜。
生成端做的事其實很務實
做完 hybrid retrieval 之後，系統才把：
- 原始 SIEM alert
- IOC / threat platform 查詢結果
- 從 CTI 報告撈到的相關片段
一起塞進最終 prompt，讓 LLM 生成 incident response strategy。
這裡的亮點不是生成技巧本身有多花，而是它把回答建立在被檢索過、被接地過的 CTI context 上。從藍隊實務角度看，這很重要，因為 analyst 真正痛恨的不是模型答得慢，而是它看起來很有道理，但跟現場 threat context 沒半點關係。
評估設計：它不是只拿單一 dataset 自嗨
評估上，作者用了兩種資料：
- 100 筆真實世界 SIEM alerts
- 10 筆在隔離測試環境中用 Caldera 模擬攻擊產生的 alerts
其中模擬環境還刻意橫跨 Linux / Windows，並包含不同 MITRE ATT&CK 技術，像是 process injection、credential dumping、exfiltration、active scanning 等。這雖然不算超大規模 benchmark，但至少不是只拿幾條 toy prompt 在那邊自我感覺良好。
評估維度也抓在 RAG 系統比較該看的地方：
- Answer Relevance：回應有沒有真的在回答 incident
- Context Relevance：撈回來的 context 對不對題
- Groundedness：生成內容有沒有建立在 retrieved context 上
更有意思的是，它不是只用 LLM 當 judge，而是再讓資安專家去 cross-validate。這一點我覺得比很多 agent paper 誠實，因為在安全場景裡，光靠 model-based judge 很容易把 fluent bullshit 也打高分。
這篇最值得記住的一句話：IR 自動化真正缺的不是更多回答，而是更好的 context fusion
如果要我挑這篇 paper 最值得 sectools.tw 讀者記住的一個洞見，我會選這個：
incident response 的 LLM 系統如果沒有把 CTI fusion 做好，最後多半只會變成一個會把 alert 重述得比較漂亮的文字機器。
這篇的價值就在於，它把 CTI 從「補充閱讀材料」拉回 incident response pipeline 的核心。也就是說，CTI 不是 analyst 額外參考的附件，而是 response quality 的主要燃料之一。
放回最近 sectools.tw 主線裡，它補的是哪一塊？
如果把最近這幾篇串起來看，位置其實很清楚：
- SIR-Bench 在問：agent 有沒有真的往 alert 外面挖證據？
- Multi-Agent Incident Response 在問：多角色編排能不能讓決策比較穩？
- In-Context Autonomous Network Incident Response 在問：單一 agent 怎麼做規劃與重規劃？
- 這篇 在補：如果你連 CTI enrichment 都沒接好，那前面那些規劃與協作其實很可能都只是空轉。
換句話說，這篇談的不是最 flashy 的 autonomous agent，而是IR agent 前面那條 intelligence ingestion / retrieval substrate。而這層基礎，反而常常決定後面的建議到底像 production，還是像 demo。
這篇的限制也很明顯
當然，這篇也不是沒有弱點。
- 平台依賴偏高：standard search 目前很仰賴 VirusTotal 這類資料源，能拿到多少 context，會受外部 CTI 平台覆蓋率影響。
- 評估規模還不算大：110 筆 alert 對概念驗證夠用，但離真正多樣化 enterprise IR reality 還有距離。
- response generation 仍偏 advisory：這篇重點是生成 mitigation strategy，不是直接進到自動化執行與閉環驗證。
所以我會把它看成一篇把 alert enrichment 與 CTI retrieval 做對方向的 paper，而不是已經完成 end-to-end autonomous IR 的終局答案。
我的看法
我自己蠻喜歡這篇，因為它沒有把焦點放在那種很容易吸睛、但也很容易灌水的「agent 全自動接管 SOC」敘事上，而是回頭處理一個比較土、卻真的很要命的問題：模型要先看到什麼，才有資格回答下一步該做什麼。
很多 security AI 系統現在最大的錯覺，是以為只要把 response prompt 寫長一點、模型換大一點，就能自動長出可靠的 IR 能力。但現實往往是相反的：如果 threat context 本身沒有被整合進來，模型越能講，反而越容易講得像真的。
如果要我用一句話總結這篇 paper，我會這樣講：
真正讓 incident response automation 比較像系統的，未必是 agent 會不會自己規劃，而是它能不能先把 alert、IOC 與 CTI 融成同一個可行動的上下文。
而從這個角度看，這篇雖然不炫，但補得很實際。
本文由 AI 產生、整理與撰寫；內容僅供研究與技術分析參考。