STIX 自動抽取論文閱讀分析：當 Threat Report 真的想變成可交換情資，模型就不能只會抓幾個實體

論文基本資訊

• 論文標題：From Text to Actionable Intelligence: Automating STIX Entity and Relationship Extraction
• 作者：Ahmed Lekssays、Husrev Taha Sencar、Ting Yu
• 來源：arXiv
• 年份：2025
• arXiv：https://arxiv.org/abs/2507.16576
• 主題：CTI、STIX、entity extraction、relationship extraction、LLM fine-tuning、threat intelligence automation

如果說剛剛那篇 Transparent CTI 講的是「怎麼讓 LLM 抽出的資安知識更可驗證、更能被 ontology 與 SHACL 接住」，那這篇 From Text to Actionable Intelligence 值得接著讀的原因很直接：它把問題往 CTI 交換流程再推近一步，不再只問模型能不能抽出資訊，而是問它能不能把 threat report 直接整理成接近 STIX 的可交換結構。

這個差別其實很重要。很多 CTI 自動化研究最後停在「抽出一些 entities / relations 就算成功」，但真實世界的防守體系要接得住，通常還得再往下走一段：得能放進 STIX/TAXII、得能被 TIP 或 detection pipeline 使用、得能被 analyst 檢查，不然再漂亮的抽取結果也很難真正進到工作流裡。

本文由 AI 產生、整理與撰寫。

這篇論文在處理什麼問題？

作者要解的其實是 CTI 自動化裡一個很老、但一直沒真正解好的痛點：威脅分析報告大多仍是非結構化文字，但防守體系真正要用的卻是結構化、可交換、可機器處理的 threat data。

STIX 當然早就存在，也早就是威脅情報分享裡最常見的標準之一；問題不在「有沒有標準」，而在於 從 threat report 到 STIX 之間那段轉換，很多時候還是人工、緩慢、昂貴，而且很容易不一致。 論文引用的既有分析甚至指出，公開 STIX 生態裡大量資料都偏向 indicator 物件，真正能表達 threat behavior 的 relationship objects 與其他 domain objects 使用得並不充分，還有 timeliness 與品質問題。

換句話說，今天大家不是不知道 STIX 好用，而是還沒有足夠成熟的自動化管線，能把報告中的攻擊知識穩定轉成 STIX-compatible representation。這篇論文的野心，就是把這個轉換過程往前推。

作者怎麼做？不是一次叫模型吐完整 STIX，而是拆成四段

這篇 paper 很務實的一點，是它沒有天真地把整個問題當成「叫 LLM 直接輸出完整 JSON」就好。作者把 STIX 抽取拆成四個連續子任務：

• T1：Entity detection —— 先找出候選實體
• T2：Entity type identification —— 判斷它屬於哪種 STIX entity type
• T3：Related pair detection —— 找出哪些 entity pair 彼此有關
• T4：Relationship type identification —— 再判斷兩者之間是哪種 STIX relationship

這種拆法的價值不只是工程上比較好做，而是它把原本很模糊的一次性生成，拆成 analyst 較容易驗證的幾段。對高風險 CTI 工作流來說，能不能把錯誤定位清楚，常常比單次輸出看起來多完整更重要。

作者把整體框架命名為 AZERG。它的定位不是完全取代分析師，而是幫 analyst 先把 STIX entity 與 relationship 候選整理出來，最後再交由人做驗證與修正。這個姿態其實很對：在真實 CTI 環境裡，完全自動化往往不是最可靠的終點，半自動化但可審核，反而更接近能落地的答案。

資料集是這篇論文的一個重點

這篇研究不只是在 prompt 上做花樣，它真正有份量的地方之一，是自己建了一套相對扎實的資料基礎。作者標註了：

• 141 份完整的真實 threat analysis reports
• 4,011 個 STIX entities
• 2,075 個 STIX relationships

而且這些標註是直接對齊 STIX standard 做的。這件事看似平凡，其實很關鍵。因為 CTI 領域一直有個老問題：很多研究在抽取層看起來做得不錯，但抽取標的不是 operational standard，最後就很難直接接到情報共享或安全工具鏈。 這篇 paper 至少在資料層就很明確地把目標鎖在 STIX-compatible extraction，而不是做一個只在論文內部自洽的 schema。

成果如何？四個子任務的 F1 都不差，但難度差異很明顯

作者報告的 real-world scenario F1-score 分別是：

• T1 實體偵測：84.43%
• T2 實體類型辨識：88.49%
• T3 關聯 pair 偵測：95.47%
• T4 關係類型辨識：84.60%

這組數字有兩個值得記住的點。

第一，T3 高到 95.47%，代表在已知候選實體的前提下，模型對「哪些東西彼此有關」這件事其實抓得不錯。這說明 threat report 中很多關聯訊號並非完全不可學，尤其在 task decomposition 之後，模型對 pair detection 的掌握已經相當像樣。

第二，T1 與 T4 明顯比較難。這也很合理。實體偵測難，是因為 CTI 報告裡混著技術描述、命令列、配置片段、演算法名稱、樣本細節與一般敘事，很多詞看起來像 entity，實際卻不該被標。關係類型辨識難，則是因為它要求的不只是字面共現，而是要把語意關係對齊到 STIX 規格內可接受的關係種類。

也就是說，這篇 paper 的訊息不是「LLM 已經完美搞定 STIX 抽取」，而是更實際的那一句：把問題拆對、資料標對、模型調對之後，STIX-ready extraction 已經開始從 demo 走向 workflow component。

為什麼這篇比很多「CTI entity extraction」研究更值得注意？

因為它瞄準的不是泛泛的 entity / relation extraction，而是 STIX-compatible threat knowledge extraction。這讓它和許多只停在知識圖譜、triplet 或 ATT&CK mapping 的工作有一個明顯差別：它更直接面向「怎麼接進交換標準與現有情報基礎設施」。

很多 CTI 論文把重點放在從文字中抽出 subject-verb-object，或是把 TTP 抽成某種內部 schema；這些研究不是沒價值，但真正進現場時，常會卡在最後一公里。這篇則是在問：如果目標是讓情資真的能分享、流通、進平台，那 extraction target 就不能只是一個好看的研究格式，而要更貼近 STIX 這種 operational representation。

這也是為什麼它很適合接在今天剛發的 Transparent CTI 後面。前者強調 ontology 與 constraints 讓輸出更可驗證；這篇則把焦點拉到 threat report → STIX object / relationship 這條實務管線。兩篇一起看，會很清楚看到同一條主線：真正缺的不是再多一個「會讀報告的 LLM」，而是能把讀到的內容穩定轉成知識系統與交換系統都接得住的結構。

作者也沒有神化 LLM，反而把它擺回 assistive tool 的位置

我覺得這篇論文很成熟的一點，是它明白指出幾個很現實的限制：

• CTI 文本本身對通用 LLM 來說是明顯的 out-of-distribution input
• 內容混有 code、command、table、artifact、縮寫與非標準命名
• 有些 entity 的判斷高度依賴上下文，不是靠 pattern matching 就能搞定
• 真實世界 CTI 任務本來就有長文本、推理不穩、校準不佳等問題

所以作者沒有把 LLM 包裝成「從今天起 analyst 可以失業」，而是把它放回一個更可信的位置：協助 analyst 更快生成候選 STIX 結構，讓人把時間花在驗證與修正，而不是從零整理。 這種 framing 比很多喜歡把 automation 講滿的論文誠實得多。

這篇論文真正重要的地方，不只是抽得準，而是把 CTI automation 推向可交換格式

如果要濃縮這篇 paper 的核心價值，我會寫成一句話：

CTI 自動化真正缺的，常常不是再多抽一點 threat knowledge，而是把抽出的知識送進 STIX 這種可共享、可整合、可下游使用的格式時，還能維持足夠品質。

這句話乍看很工程，實際上很關鍵。因為在防守體系裡，沒有被結構化、沒有進入交換標準、沒有進入下游平台的情報，價值常常會在最後一公里蒸發掉。這篇 paper 雖然還沒有把 STIX 全屬性填充、外部知識補完、跨文件 coreference 等更難問題全部解掉，但它至少把方向定得很對：從 unstructured threat text 到 operational CTI object 的路，不該再只靠人工硬扛。

限制與我自己的看法

當然，這篇論文還是有幾個很明顯的限制。

• 它主要聚焦在 STIX domain objects 與 relationships，沒有完整處理大量 object attributes 的填充問題。
• 作者也承認，很多屬性若只靠單篇報告本身，資訊其實不夠，可能需要外部來源補全。
• STIX extraction 做得再好，離真正的 threat report operationalization 仍然還有 object normalization、deduplication、cross-report entity resolution 等後續工作。

但這不太像致命缺點，反而比較像這條研究路線下一步該去補的地方。畢竟，如果今天連 entity / relation → STIX core structure 這一步都還不穩，談完整自動化 threat sharing 還太早。這篇 paper 的價值，就是先把最該打穩的骨架打起來。

總結

From Text to Actionable Intelligence 值得看的地方，不在於它又證明一次 LLM 可以做 extraction，而在於它把 CTI 自動化從「抽點資訊出來」往前推成「讓這些資訊更接近可以直接被 STIX/TAXII 生態使用」。

它最重要的提醒是：在 CTI 裡，真正有價值的不是模型看懂多少，而是看懂之後，能不能用標準化、可驗證、可分享的方式把知識交出去。 如果這件事做不到，那很多自動化最後都只是在替 analyst 多生一層需要再手工整理的中間產物；如果做得到，LLM 才真的開始碰到可操作的 threat intelligence 基礎設施。

對 sectools.tw 最近這條主線來說，這篇剛好把 ontology / structured extraction / knowledge graph 那些較偏「知識表示」的討論，接到 STIX 交換標準 這個更偏 operationalization 的端點上。這比單純再多一篇抽取 paper，要有意思得多。