論文閱讀分析：用 LLM 自動化 SOC 裡的 Threat Intelligence 分析工作流
論文基本資訊
- 論文標題：Using LLMs to Automate Threat Intelligence Analysis Workflows in Security Operation Centers
- 作者：PeiYu Tseng、ZihDwo Yeh、Xushu Dai、Peng Liu
- 年份：2024
- 來源：arXiv
- 論文連結：https://arxiv.org/abs/2407.13093
- 主題：CTI、SOC、SIEM、LLM Agent、IOC Extraction、Regex Generation、Relationship Graph
如果前面幾篇 sectools.tw 的主線，已經一路追到 CTI benchmark、agentic investigation、SOC 協作、incident response 與偵測規則生成，那這篇 Using LLMs to Automate Threat Intelligence Analysis Workflows in Security Operation Centers 值得補進來的理由很直接：它不是在問模型懂不懂 CTI 題目，也不是單純展示一個 chat assistant，而是把焦點放回 SOC 分析師每天真的在做、但又最耗時間的那一段重複勞動——把自然語言 CTI 報告轉成可落地的 SIEM correlation rule 元件。
作者要解決的問題非常實務：分析師明明已經有 threat report，但還是得手動讀段落、抽 IOC、判斷相依關係、再把內容轉成能搜尋的 Regex 與規則條件。這件事既耗時，又容易因疲勞或上下文遺漏出錯。論文的核心主張是：如果把 LLM 放進一個設計良好的 agent workflow，再補上 voting、retrieval-based purification、Regex testing 與 relationship verification，就有機會把這條流程大幅自動化，而不是只做出一個會回答問題的 demo。
研究問題
這篇論文的研究問題可以濃縮成三個層次：
- 能不能讓 LLM 自動從 CTI 報告中抽出 SOC 真正需要的 IOC 與行為脈絡？
- 能不能把這些自然語言中的 IOC 進一步轉成適合 SIEM 使用的 Regex，而不是停在抽取文字片段？
- 能不能在不依賴人工逐步校正的前提下，把 IOC 之間的依賴關係整理成 relationship graph，支撐分析師快速理解攻擊流程？
這裡最值得注意的一點，是作者從一開始就沒有把目標設定成「幫分析師摘要 CTI」而已，而是更往下游推：要讓輸出直接有助於規則建立與威脅模式理解。這也是它和一般 CTI 問答系統最大的差別。
問題背景：為什麼 SIEM 還是卡在自然語言 CTI 前面？
論文指出，現代 SIEM 雖然已經很成熟，也能做 event correlation、alerting 與各種偵測工作，但它仍然很難處理來自自然語言 CTI 報告的內容。因為報告裡的關鍵知識，往往散落在段落敘述中，例如：
- 某惡意程式會建立哪個 registry key
- 某 process 在什麼條件下被啟動
- 某檔案、命令列與程序之間的先後依賴關係
這些資訊對分析師而言都很重要，但如果要把它們轉成 SIEM 可用的 correlation rule，通常還是得靠人工消化。論文裡給的 motivating example 就很典型：分析師需要從公開 CTI 報告中，手動抽出惡意 registry key 與對應程式名稱，然後寫進規則欄位。這不是高創造性工作，卻非常吃時間，而且對 SOC 反應速度有直接影響。
方法總覽：一個把 CTI 轉成規則素材的 LLM Agent
作者提出的 AI agent 可以分成八個步驟，核心概念是：
CTI report
→ paragraph-level IOC extraction
→ voting + retrieval purification
→ capture / non-capture group finding
→ Regex generation + Regex testing
→ dependency extraction
→ relationship mapping
→ relationship verification
→ relationship graph construction這套流程的關鍵不在「用 GPT-4 做抽取」本身，而在於作者很清楚知道：LLM 直接輸出的內容不夠可靠，因此必須在前後加上一整套 purification 與 verification 機制。這個設計思路和很多只展示 prompt engineering 效果的論文不太一樣，它更接近真正會進入 SOC pipeline 的 system paper。
Step 1：先做 paragraph-level IOC extraction，而不是整篇亂丟給模型
作者沒有直接把整份 CTI 報告一次丟給 LLM，而是先把報告切成一段段、每段約 3 到 4 句，再要求模型從每段中找出 IOC 相關名詞，例如：
- 檔名（filenames）
- 命令列（command lines）
- registry keys
- domain、IP、hash 等 IOC
這種 paragraph-level 設計很合理，因為 CTI 報告裡很多 IOC 其實高度依賴局部上下文。若把整篇丟進模型，不只容易增加 token 成本，也會讓模型在長上下文中漏掉本來就很細碎的 technical artifact。
Step 2：Purification，用多次投票加 RAG 過濾 LLM 的胡扯
這篇論文最值得看的地方之一，就是它沒有假設 LLM 抽出的 IOC 天生可信。作者明講了 challenge C1：LLM 可能會抽出完全不相關的東西，這些 factual errors 對安全分析流程是不能接受的。
因此作者設計了兩層 purification：
- Majority voting：同一段文字重跑多次 LLM，只有達到投票門檻的結果才保留
- Retrieval-augmented filtering：再把保留下來的 IOC 跟向量資料庫中的 domain knowledge 比對
這裡的 domain knowledge 不是一般百科內容，而是 SOC 環境會用到的作業系統文件與結構知識，例如 Windows / Linux 的 command format、預設路徑、系統目錄等。論文裡的想法是：如果模型說某段是檔名、命令列或 path，那它至少要和真實系統知識對得上，否則就很可疑。
從系統工程角度看，這一步其實很關鍵。因為在資安場景裡，抽到一個不存在的 IOC，往往比少抽一個 IOC 更麻煩：前者會污染規則與調查流程，後者至少還是漏報而不是假脈絡。
Step 3：找出 capture groups 與 non-capture groups，為 Regex 生成做準備
很多論文做到 IOC extraction 就停了，但這篇論文更進一步問：如何把自然語言中的 IOC 轉成可用於 SIEM 規則的 Regex？
作者提出的做法，是先把 IOC 字串切成多個 substring，再用 retrieval-augmented matching 判斷哪些部分屬於 capture groups、哪些屬於 non-capture groups。概念上：
- capture groups：攻擊者不容易改變、較穩定的部分，例如系統程式名、固定參數、預設目錄
- non-capture groups：攻擊者可變動的部分，例如檔名、GUID、變數名稱
例如論文提到某些 command line 中，像 cmd.exe、WMIC、shadowcopy、delete 會被視為較穩定的 capture groups；而具體 GUID 則應視為可變部分。這種拆分很重要，因為如果 Regex 把所有字串寫死，規則就太脆；但如果全部模糊化，又會導致誤報大增。
Step 4：讓 LLM 生成 Regex，但一定要接上 Regex tester
在 capture / non-capture groups 標好之後，agent 再要求 LLM 生成 SIEM 規則可用的 Regex。不過作者很清楚，Regex generation 這件事就算對人類都不總是容易，對 LLM 更不能直接盲信，所以他們再加上一個 Regex tester，做 step-by-step testing 與 feedback loop。
也就是說，這裡不是：
LLM 生成 Regex → 直接採信而是：
LLM 生成 Regex → tester 驗證格式與可行性 → 若失敗就回饋模型修正這一步非常務實，因為它把 LLM 放在「候選生成器」的位置，而不是唯一權威。對任何要進 SOC / detection engineering 的 AI 系統來說，這種設計通常比單純提升 prompt 複雜度更可靠。
Step 5–8：從 IOC pair 到 relationship graph
除了抽 IOC 與寫 Regex，這篇論文還想補上一塊更高層的分析價值：把 IOC 之間的依賴關係做成 relationship graph。
做法大致如下：
- 讓 LLM 回頭分析原始段落中的 nouns 與 verbs
- 找出 noun pairs，並比對哪些 pair 的兩端其實是前面抽出的 IOC
- 處理代名詞或中介詞彙，例如把某個 “dropper” 重新對應到具體惡意程式
- 再依據 verbs 判斷兩個 IOC 的關係，例如 create、write 等
- 最後用 mapping table 將語意接近但用詞不同的動詞標準化
作者也額外做了 relationship verification。例如如果某個 registry key 被推成會「create」一個 file 或 process，這在語義上通常不合理，那 agent 就要回去定位原始段落，重新讓 LLM 判別。這種基於型別與語義約束的驗證，對 relationship graph 的可信度非常重要。
評估結果
論文在 50 多篇 CTI reports 上做實驗，結果包含幾個值得記下來的數字：
- LLM 共辨識出 2,900+ 個 potential IOCs
- 經 purification 後保留約 2,300 個 valid IOCs
- 產生約 2,200 個 Regex
- 和人工 ground truth 比較時，只漏掉約 3% 的 IOCs
此外，hash、IP、domain 等 IOC 類型約佔 valid IOCs 的 70%。這代表系統不只是處理極少數高結構化案例，而是已經碰到相當大量、且形式不一的 CTI artifact。
當然，這篇論文沒有像近年的 benchmark papers 一樣給出一整套細緻的 task-by-task 指標分解，因此如果你期待看到非常完整的 precision / recall / F1、relationship extraction 分類表、Regex correctness breakdown，這篇資料還是不夠細。但就它作為一篇 workflow automation 論文的定位來看，至少已經說明了：這不是只有 prompt demo，而是真正做過一輪 end-to-end pipeline evaluation 的系統。
這篇論文的真正價值
對 sectools.tw 近期這條 CTI / AI / SOC 主線來說，這篇的價值其實不在「模型更強」，而在它明確指出：真正卡住 SOC 的，不只是 detection model 準不準，而是 threat report 到 operational rule 之間，還有一整段又碎又煩的轉譯流程。
而作者做的事，就是把這段流程拆成可自動化的模組：
- IOC extraction
- IOC purification
- Regex generation
- dependency extraction
- relationship graph construction
如果你把它和最近站上幾篇放在一起看，脈絡會很清楚：
- CTI-REALM / FALCON 在看 threat intel 如何轉成 detection rules
- CyberRAG / IRCopilot / AutoBnB-RAG 在看 agent 如何進入 SOC / IR workflow
- LLMs in the SOC 在看真實分析師怎麼與模型協作
- 這篇 則更像是補上中間那個最瑣碎但最必要的 translation layer：把 CTI 文本變成 SIEM 真能吃的結構化素材
限制與保留
雖然方向很對，但這篇論文也有幾個明顯限制：
- 評估細節仍偏粗：沒有把每種 IOC、每種 relationship、每類 Regex 的錯誤型態拆得很細
- 依賴 GPT-4 類模型：成本、延遲與長期維運問題，在真實 SOC 中不能忽略
- relationship graph 的可用性：論文展示了概念與 workflow，但對 analyst 實際使用方式與介面評估還不夠多
- no human intervention 的主張很大膽：實務上高風險規則是否真能完全不經人工審核，還是要保留懷疑
也就是說，這篇比較像是把方向與架構立起來，而不是已經把 production-grade SOC agent 完全做完。但它依然有價值，因為它處理的是 真實工作流中的摩擦點，而不是只追求一個看起來漂亮的 benchmark 分數。
重點整理
- 這篇論文聚焦在 自動化 SOC 中的 CTI 分析工作流，而不是一般性的 CTI 問答。
- 核心目標是把自然語言 CTI 報告中的 IOC、關係與規則素材自動抽出，減少分析師的重複勞動。
- 方法不是只靠單次 LLM prompt，而是加入 majority voting、RAG-based purification、capture-group finding、Regex tester、relationship verification 等機制。
- 在 50+ CTI reports 上，系統辨識 2,900+ potential IOCs，保留約 2,300 valid IOCs，並產生約 2,200 個 Regex。
- 和人工 ground truth 比較時，IOC 漏失率約 3%，顯示這條 pipeline 已具備一定實用價值。
- 這篇的關鍵意義，在於它把 CTI report → SIEM rule material 這條常被忽略的轉譯鏈條，變成可被 AI 自動化處理的對象。
Takeaway
這篇論文最值得記住的一點，是它提醒我們：在 SOC 裡，真正耗掉分析師時間的，不一定是最複雜的推理，而往往是那些反覆把 threat report 翻譯成 operational artifact 的工作。
而這篇 Using LLMs to Automate Threat Intelligence Analysis Workflows in Security Operation Centers 的貢獻，就在於它沒有只停在「LLM 會抽 IOC」這種展示層級，而是進一步把 purification、Regex generation、relationship verification 與 graph construction 接起來，試圖把一整條 CTI-to-SIEM workflow 自動化。對最近這波 CTI / AI 論文來說，它不是最 flashy 的一篇，但很可能是最接近真正 analyst 日常痛點的一篇。
免責聲明
本文由 AI 產生、整理與撰寫。內容主要根據公開論文與可取得資料進行整理、解讀與摘要；儘管已盡力校對與保持技術脈絡完整，仍可能因模型理解、資料版本或語意轉譯而存在疏漏。若需引用研究結論、方法細節或實驗設計，請以原始論文與作者公開資料為準。