Retrieval-Augmented LLMs for Security Incident Analysis 論文閱讀分析：當 SOC 想讓模型真的看懂事件，不是先變大，而是先把證據找對

論文基本資訊

• 論文標題：Retrieval-Augmented LLMs for Security Incident Analysis
• 年份：2026
• 來源：arXiv:2603.18196
• 論文連結：https://arxiv.org/abs/2603.18196
• DOI：10.48550/arXiv.2603.18196
• 主題：RAG、LLM、Security Incident Analysis、Digital Forensics、SOC、MITRE ATT&CK、Log Analysis、Attack Reconstruction

如果前幾篇 sectools.tw 的主線，已經一路從 CTI benchmark、SOC triage、agentic incident response 走到「模型到底能不能幫分析師做真實工作」，那這篇 Retrieval-Augmented LLMs for Security Incident Analysis 值得看的地方，在於它把焦點收得更實務：當你真的把大量安全日誌丟進來，LLM 要怎麼在 context window 限制下，找出關鍵證據、回答 forensic 問題，甚至把攻擊序列重建回來？

這篇論文的貢獻不是再做一個泛泛的「SOC Copilot」demo，而是提出一套比較務實的設計：先用 query library 依 MITRE ATT&CK 技術做定向過濾，再用 RAG 把最 relevant 的 log context 找回來，最後才讓 LLM 在受控脈絡下做語意推理與事件重建。 換句話說，它要解決的不是「模型懂不懂資安」，而是「模型在真實 log volume 面前，怎麼不被雜訊淹死」。

這篇論文想解決什麼問題？

Security incident analysis 有一個很典型、但也最難被簡化的痛點：證據來源很多、格式很多、噪音很多，而且真正重要的線索通常只佔很小一部分。 分析師要同時看 intrusion detection alerts、network traffic records、authentication events、DNS / proxy / endpoint logs，最後還得把這些碎片拼成一條合理的攻擊時間線。

這件事之所以難，不只是因為資料量大，更是因為 analysis 本身包含幾個不同層次的工作：

• 先把 relevant evidence 挖出來
• 再把證據和 ATT&CK / 攻擊步驟對上
• 最後才能回答 forensic questions，例如受害主機是誰、惡意網域是什麼、command-and-control 在哪裡、攻擊是怎麼一步步發生的

而純 LLM 方法的問題也很明顯：如果不先做檢索與過濾，模型很難在有限 context 中看到對的 log；但如果只做關鍵字檢索，又常常抓不到真正語意相關的證據。 因此作者要回答的核心問題可以濃縮成一句話：

能不能把 query-based filtering 與 RAG 結合，讓 LLM 在 context limit 內仍能做準確、可重建的 security incident analysis？

方法核心：不是直接把所有 log 丟給模型，而是先做「有方向的縮減」

這篇研究最值得注意的地方，是它沒有假設 LLM 可以直接吞下完整事件資料。作者很清楚地把整體流程拆成三個階段：

1. targeted query-based filtering
2. RAG-based context retrieval
3. LLM semantic reasoning 與 attack reconstruction

整體 pipeline 可以整理成：

Raw security logs
   ↓
Query library filtering
   ↓
Indicators / candidate evidence extraction
   ↓
RAG retrieval of relevant context
   ↓
LLM-based forensic Q&A and attack-sequence reconstruction
   ↓
Structured incident analysis

這個設計的核心價值，在於它沒有把 RAG 當作一個空泛口號，而是真的把它嵌進 incident analysis workflow：先縮資料，再補上下文，最後才推理。

Query Library 為什麼重要？

很多談 LLM for security 的系統，會直接從「把資料向量化」開始。但這篇論文前面多放了一層 query library，而且明確把 query 和 MITRE ATT&CK techniques 綁在一起。這個做法很聰明，因為它其實把 analyst 的先驗知識顯式化了。

也就是說，系統不是憑空問「哪些 log 重要」，而是先利用與攻擊技術相關的定向查詢，把可能對應某個 ATT&CK step 的原始 evidence 先抓出來。這麼做的好處至少有三個：

• 降低資料量：先把明顯無關的 log 篩掉
• 保留調查方向：retrieval 不只是找相似文字，而是沿著攻擊技術去找
• 讓後續 RAG 更穩：因為 vector retrieval 的候選集合本來就更乾淨

從研究定位來看，這篇論文其實很像在說：真正可用的 AI-assisted incident analysis，不會是「什麼都交給模型」，而是把 analyst workflow 裡的 query discipline 保留下來。

RAG 在這篇裡扮演的是「上下文保真器」

第二層是 RAG retrieval。作者的重點不只是讓模型「有外部知識」，而是讓模型在回答 forensic 問題時，能回到和當前 incident 最相關的 log context。這一層的價值很實際，因為在安全調查裡，很多錯誤不是推理能力不足，而是模型根本沒看到關鍵證據。

如果用標準形式表示，系統大致可抽象為：

q = forensic question
D = filtered evidence set
C_top-k = Retrieve(q, D)
a = LLM(q, C_top-k)

也就是對 forensic question q，先從過濾後的 evidence set D 中取回 top-k relevant contexts，再交給 LLM 生成分析答案 a。而如果寫成常見的 embedding retrieval 形式，則是：

z_q = Emb(q)
z_i = Emb(d_i)
sim(q, d_i) = (z_q · z_i) / (||z_q|| ||z_i||)

這種設計的重要性在於：模型不再只靠參數記憶做 security reasoning，而是被迫基於當前 incident 的具體證據回答。

任務不只問答，還包括 attack sequence reconstruction

如果這篇論文只做到「根據 log 回答問題」，那其實還只是 security QA。但作者更進一步要求系統做 attack sequence reconstruction。這點很關鍵，因為真正的 incident analysis 很少只問單點問題，而是要把分散事件拼回一條時間序列：

• 哪個階段先發生？
• 哪台主機先中？
• 哪個憑證先被濫用？
• 惡意網域與 C2 基礎設施何時出現？
• 從初始入侵到 lateral movement 中間經過哪些步驟？

也就是說，這篇論文的目標比一般 log summarization 更高，它實際上在測的是：LLM 是否能在 evidence-grounded 的前提下，重建一個 analyst 可用的攻擊敘事。

實驗設計：為什麼作者選 malware traffic 與 Active Directory attacks？

作者用兩類場景驗證系統：

• malware traffic incidents
• multi-stage Active Directory attacks

這兩類選得很合理。前者比較像是 network-centric investigation，重點在惡意流量、網域、C2 與 victim identification；後者則更接近 enterprise IR 裡最麻煩的場景之一，因為 AD 攻擊往往跨多步驟、多帳號、多主機，而且 lateral movement 與 privilege escalation 的關聯很難只看單一 log 就搞懂。

換句話說，作者不是只挑一種 toy scenario，而是故意挑兩類對分析方式要求不同的 incident，來看系統的泛化能力。

主要結果一：不同模型的表現與成本差異很大

這篇論文一個很有意思的地方，是它不只比對 correctness，也把成本拉進來看。這比很多只報 accuracy 的安全 AI 論文更實際，因為 production SOC 不會只問「最準的是誰」，還會問「一輪 analysis 成本多少」。

根據摘要，作者觀察到：

• Claude Sonnet 4 與 DeepSeek V3 在四個 malware scenarios 上都達到 100% recall
• 但 DeepSeek V3 的成本大幅更低，約為 $0.008 vs. $0.12 per analysis

這個結果很值得注意，因為它暗示：security analysis 這類任務未必永遠是 frontier closed model 壟斷，成本更低的模型只要搭配夠好的 retrieval 與 workflow，也可能達到非常接近甚至相同的 recall。

主要結果二：Active Directory attack step detection 的 precision 很高，但 recall 還沒滿分

在 Active Directory scenarios 上，論文報告的 attack step detection 成績是：

• Precision：100%
• Recall：82%

這組數字很有意思。它代表系統一旦說某個 attack step 存在，通常是對的；但它還是會漏掉部分步驟。從安全實務來看，這是一種相對可以接受、但仍需要 analyst 補位的行為模式。因為在 incident analysis 中：

• 高 precision 代表不太會亂報，減少 analyst 被誤導
• recall 未滿 則代表系統還不能完全獨立完成事件重建

也就是說，這篇論文支持的不是「AI 已可取代分析師」，而是比較合理的命題：AI 已經能在證據過濾與重建上顯著加速 analyst，但仍需要人類補齊漏網步驟。

Ablation study 為什麼是這篇最有說服力的部分？

我認為這篇論文最關鍵的證據，不是 headline 數字，而是 ablation 結果。作者指出：沒有 RAG-enhanced context 的 LLM baseline，雖然能找出 victim hosts，卻會漏掉所有 attack infrastructure，包括 malicious domains 與 C2 servers。

這個發現非常重要，因為它直接指出純 LLM 方法在安全場景中的典型盲點：模型可以做出表面上合理的高層摘要，但一碰到需要跨 log 拼接、要指出具體基礎設施與 artefact 的 forensic 問題，就會明顯失真。

從這點看，RAG 在這篇裡不是小修小補，而是整個系統能不能成立的分水嶺。

這篇論文真正補上的缺口是什麼？

如果把它放進最近一批 agentic security / SOC copilot 論文的脈絡中，可以這樣看：

• 有些研究偏向benchmark：模型會不會做資安題目
• 有些研究偏向agent orchestration：多代理人怎麼合作
• 有些研究偏向incident response action：模型敢不敢、會不會動手
• 而這篇更聚焦在analysis substrate：在真正推理之前，系統怎麼把 relevant evidence 留下來

這使它的價值很特別。它不是直接往更大更複雜的 agent system 走，而是回頭處理一個最根本的問題：沒有好的 evidence filtering 與 context retrieval，再聰明的 LLM 也只是在 log 海裡迷路。

方法上的優點

• 把 MITRE ATT&CK 與 query library 綁在一起，讓過濾不是盲目的關鍵字搜尋
• 把 RAG 放在 incident analysis workflow 中心，不是事後附會
• 同時看 correctness 與成本，更接近 SOC adoption 現實
• 用 attack-sequence reconstruction 當任務，比一般 QA 更貼近分析師工作
• ablation 清楚證明 RAG 必要性，而非僅僅帶來小幅加分

這篇論文的限制

當然，這篇研究也有幾個值得保留的地方：

• query library 的品質高度影響整體效果，若 query coverage 不夠，前面就會先漏證據
• 實驗場景雖然有代表性，但仍有限，未必涵蓋更複雜的 cloud / SaaS / endpoint 多源調查
• 82% recall 說明 multi-stage attack reconstruction 仍會漏步驟
• 依賴特定 log 結構與檢索流程，移植到不同 SOC stack 可能需要不少工程調整

此外，從長期角度看，這套方法也提出一個新問題：當 ATT&CK 技術與攻擊樣式持續演化時，query library 要怎麼維護、更新與校準？ 這件事可能決定它在 production 環境的可持續性。

對後續研究的啟發

這篇論文很自然地指向幾個下一步：

• 把 query library 維護半自動化，隨 ATT&CK 與新攻擊樣式更新
• 加入 reranking 與 evidence citation，讓每個答案都更可驗證
• 從事件分析擴展到完整 incident report generation
• 加入 human-in-the-loop correction，把 analyst 回饋反哺 retrieval policy
• 測更多 enterprise-scale 場景，例如混合雲、身份攻擊、EDR + SIEM 聯合調查

重點整理

• 這篇論文提出一套 query-based filtering + RAG + LLM reasoning 的 security incident analysis 系統。
• 系統先用與 MITRE ATT&CK 綁定的 query library 從原始 logs 抽取候選 evidence，再以 RAG 補上下文。
• 任務不只回答 forensic questions，還包括 attack sequence reconstruction。
• 在四個 malware scenarios 上，Claude Sonnet 4 與 DeepSeek V3 都達到 100% recall。
• DeepSeek V3 成本顯著更低，約為 $0.008 vs. $0.12 per analysis。
• 在 Active Directory scenarios 上，attack step detection 達到 100% precision 與 82% recall。
• ablation 顯示：沒有 RAG-enhanced context 的純 LLM baseline 會漏掉所有 attack infrastructure，包含惡意網域與 C2 伺服器。

Takeaway

這篇論文最值得記住的地方，不是它再次證明 LLM 可以看懂安全日誌，而是它更精準地指出：真正可用的 incident analysis，不是把所有 log 丟給模型，而是先用 analyst-style query discipline 把證據縮到模型能處理的範圍，再用 RAG 把上下文補齊，最後才做推理與重建。

對今天的 SOC / DFIR 工作流來說，這其實比「更大模型」更重要。因為安全分析的瓶頸，很多時候不是模型不夠聰明，而是證據進不去、上下文留不住、推理沒有 grounding。而這篇 paper 的價值，就是把這三件事串成了一條比較像真正 analyst workflow 的路。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文、摘要與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。