論文閱讀分析：OntoLogX 如何把雜亂資安日誌轉成可映射 ATT&CK 的 CTI 知識圖譜

如果最近這波 sectools.tw 的 CTI / AI 論文，已經一路從 threat report extraction、ontology-grounded CTI、STIX entity / relationship extraction、ATT&CK technique mapping 寫到「怎麼把非結構化威脅文字變成可用知識」，那這篇 OntoLogX 值得補進來的原因很直接：它不再從 threat report 開始，而是把起點往更原始、也更混亂的一層拉回去——system logs 本身。

這件事的重要性其實很高。因為真實世界裡，很多攻擊脈絡根本還來不及被整理成報告；它們最早是以 SSH 嘗試、process 行為、service message、honeypot interaction、系統事件這些碎片形式出現。問題從來不是 SOC 沒有資料，而是資料太早、太碎、太吵，還沒長成能拿來做 CTI 的樣子。

OntoLogX: Ontology-Guided Knowledge Graph Extraction from Cybersecurity Logs with Large Language Models 想解的，就是這個上游問題：能不能讓 LLM agent 直接吃原始 logs，把它們轉成 ontology-grounded knowledge graphs，再往上連到 MITRE ATT&CK tactics，讓 log 不只是留存，而是真的能長出可行動的 threat intelligence。

論文基本資訊

• 論文標題：OntoLogX: Ontology-Guided Knowledge Graph Extraction from Cybersecurity Logs with Large Language Models
• 作者：Idilio Drago、Anisa Rula、Devis Bianchini、Federico Cerutti
• 年份：2025
• 論文連結：https://arxiv.org/abs/2510.01409
• 關鍵字：CTI、System Logs、Knowledge Graph、Ontology、RAG、MITRE ATT&CK、LLM Agent

這篇論文在問什麼？

作者的問題意識其實非常務實：system logs 明明是高價值 CTI 來源，但它們往往缺乏結構、語意不一致，而且關鍵攻擊脈絡還會分散在不同設備、不同 session、不同格式的訊息裡。 這使得 logs 很難直接變成 analyst 真正能查、能串、能解釋的 threat knowledge。

所以這篇不是單純在做 log parsing，也不是只想把 log 摘要成自然語言。它更進一步想做的是：

• 把原始 log event 轉成結構化知識圖譜
• 讓這些圖譜遵守明確 ontology，而不是每次都自由生成
• 透過 retrieval 與 correction 機制降低 LLM 胡亂生 graph 的風險
• 最後再從多個事件層級往上，推斷對應的 MITRE ATT&CK tactics

換句話說，作者不是把 LLM 當 summarizer，而是把它塞進一條更完整的 log → KG → session-level tactics intelligence pipeline 裡。

為什麼這題值得寫？

最近很多 CTI 自動化論文都在處理 threat reports，因為 report 本身已經是人類整理過的結果：句子比較完整、敘事比較線性、實體和關係相對容易抓。但如果真正想把 CTI 往前推到偵測、追蹤、主動觀測那一層，遲早得面對更原始的 log 世界。

這裡的困難在於，logs 跟 report 完全不是同一種素材：

• 語法異質：不同系統、不同版本、不同服務的 log 長得完全不一樣
• 語意不完整：很多 log 只留下極短片段，需要靠背景知識補全
• 跨事件碎裂：攻擊脈絡常分布在多個 session、主機與事件中
• 噪音極高：若沒有好結構，模型很容易抓錯重點

因此，OntoLogX 真正要測的不是 LLM 會不會看 log，而是能不能在不先做大量人工規則前處理的前提下，直接把 log 變成一個可以被查詢、驗證、追溯與再利用的知識層。

OntoLogX 的核心設計：不是只抽資訊，而是先逼模型活在 ontology 裡

這篇最值得注意的地方，是它沒有走「讓 LLM 自由輸出 JSON」那條最直覺、也最容易失控的路。作者反而先做了幾個限制：

• 自訂一個 lightweight log ontology
• 搭配 SHACL 規則做結構與語意驗證
• 在生成前先從圖資料庫中 retrieve 類似 log 的 KG 範例
• 生成後若違反 schema，再進入 iterative correction loop

也就是說，OntoLogX 的邏輯不是「相信 LLM 會自己長對」，而是讓模型被 ontology、few-shot examples 與 validator 三面夾擊。這個設計很資安，也很實際。

整條 pipeline 怎麼跑？

作者把流程拆成幾個步驟：

1. 輸入原始 log event，可附帶裝置、process、OS、honeypot 版本等 context
2. 從圖資料庫找相似範例，同時做 vector search 與 full-text search，再用 MMR 重新排序
3. LLM 依照 ontology 與結構化 schema 產生 candidate KG
4. 用 SHACL 與額外語意檢查驗證，例如是否缺少 Event node、是否有重複節點、是否指到未定義 entity
5. 若出錯則回饋模型修正，反覆最多幾輪直到產出合法 graph
6. 把單一 event KGs 存起來，再按 session 聚合
7. 由 LLM 對 session-level KGs 預測 MITRE ATT&CK tactics

這整條線最大的價值，在於它不是只抽單一欄位，而是把 raw log 慢慢抬升成可連接到 CTI framework 的知識層。對藍隊來說，這比單純做 alert summarization 更接近真正可 operationalize 的方向。

為什麼作者不用現成的大 ontology？

這篇一個很有意思的判斷，是作者刻意沒有直接拿 UCO 這種較大型、較通用的 ontology 來硬套。他們的理由很合理：

• 太小的 ontology 不夠用，抓不到 CTI 分析需要的概念
• 太大的 ontology 又會讓 LLM 自動生成時錯誤率飆高
• 很多既有模型其實預設輸入已經半結構化，但 raw logs 常常不是這樣

所以 OntoLogX 走的是中間路線：做一個夠輕、但又足以表示 event、source、timestamp、user credential、application argument 等常見 log 概念的 custom ontology。

這個選擇背後反映一個很重要的工程現實：在 LLM pipeline 裡，ontology 不是越完整越好，而是要剛好完整到模型還能穩定生成。

Retrieval 不是配角，而是讓 graph 長得比較像樣的關鍵

作者在 retrieval 設計上也不是隨便補一個 RAG 就收工。OntoLogX 同時用了：

• vector search：找語意相近的 log / KG
• full-text search：找詞面幾乎相同的訊息
• MMR：避免找回一堆彼此重複的例子

這段很關鍵，因為 log 世界常有兩種需求同時存在：

• 你要找非常像的訊息，幫助模型對齊欄位與結構
• 你也要找語意相關的訊息，補上隱含脈絡與類似攻擊模式

只靠全文檢索太死，只靠向量檢索又可能漏掉最有用的近重複樣本。作者把兩者結合，對 log 這種高重複、但又充滿變體的資料型態來說，是很合理的設計。

Correction loop：這篇真正成熟的地方，是它不假設第一版輸出就能用

很多 LLM security paper 會在 demo 階段直接把第一次輸出當結果，但 OntoLogX 比較誠實：它明確承認 LLM 很可能產生不完整、格式錯誤、型別不一致或 schema 不合法的 graph，所以特別設了一條 correction pipeline。

它檢查的內容包括：

• 輸出格式是否正確
• 是否符合 ontology 與 SHACL 約束
• 是否存在多個 Event node 或缺少 Event node
• relationship 是否指向未定義實體
• 是否有重複 entity 定義

一旦違規，就把錯誤訊息回饋給模型修。修不好就再修；若最後還是不合法，乾脆輸出 empty graph，也不把壞資料寫進知識庫。

這個策略很值得記住，因為它代表作者優先追求可稽核性與知識庫潔淨度，而不是為了好看數字把所有半殘輸出都吞進去。對真正要落地的 CTI system 來說，這比「偶爾答對」重要得多。

實驗怎麼做？

作者把評估拆成兩塊：

1. KG generation quality：比較不同 pipeline 元件和不同 LLM 組合，看看 graph 產生得多好
2. ATT&CK tactics prediction：看 session-level graph 能不能幫助高階戰術推斷

在 KG generation 這邊，作者做的是 ablation study，比了五種配置：

• 沒有 retrieval、沒有 structured output、沒有 correction 的 baseline
• 只有 retrieval
• 只有 structured output
• structured output + correction
• 完整 OntoLogX pipeline

模型方面則拉了一整排不同風格的 LLM：Llama 3.x、Claude Sonnet 4、Claude 3.5 Haiku、Mistral Large、gpt-oss、Qwen3 Coder 等。這讓結果不只是「某一個模型特別會」，而是能看出哪類模型更適合這種 task。

結果一：只靠 structured output 不夠，retrieval 反而更重要

這篇最有意思的實驗結論之一，是單靠 structured output 並沒有想像中有用。作者發現，只有 schema 約束時，很多模型其實還是會 tool call 失敗、輸出 malformed graph，或結構正確但內容很空。

反而是 retrieval-based 配置，不管是完整 retrieval 還是 starter examples，都在 precision、recall、F1、entity linking、relationship linking 上表現最好，而且兩者差距不大。

這代表什麼？代表在 log → KG 這種任務裡，給模型看幾個像樣的先例，往往比只塞一份格式規格更重要。 模型不是不知道要吐什麼欄位，而是需要知道「這類 log 在這個 ontology 裡通常怎麼被表述」。

結果二：correction 確實讓 ontology compliance 變得穩很多

論文指出，完整配置的 SHACL violation ratio 比最簡 baseline 低一個數量級。這表示 correction loop 不是裝飾，而是真的有把 graph 拉回合法範圍。

對資安應用來說，這件事特別重要。因為一旦你的 KG 要拿去做：

• 查詢
• 關聯分析
• 證據追溯
• 後續 ATT&CK mapping

那麼一張半歪不歪的 graph，會比空 graph 更危險。OntoLogX 在這裡做出的取捨很合理：寧可有些事件最後輸出為空，也不要把錯的圖硬塞進知識底座。

結果三：code-oriented 模型在這種結構化任務上特別吃香

作者特別提到，像 Qwen3 Coder 這類 code-oriented model，在結構化 log analysis 與 KG generation 這類任務上表現很好。這其實不難理解，因為這些模型本來就更擅長：

• 守格式
• 維持型別一致
• 生成語法正確的結構化輸出
• 處理比較像「半文字、半程式」的輸入

這也提醒我們，做 CTI pipeline 時未必該無腦追求最會聊天或最會寫摘要的模型；如果任務核心是 schema-constrained extraction，code / reasoning-oriented model 可能更對味。

結果四：高 G-Eval 不代表 graph 真比較好

這篇還有一個很值得記的觀察：某些較簡陋的方法，在 G-Eval 這類語意評分上看起來很高，甚至高到 0.9 左右，但實際 F1 卻不佳。作者的解讀是，這些 graph 雖然抓到不少資訊，卻混入太多噪音或多餘內容，所以看起來「語意很豐富」，但作為知識抽取結果其實不夠精準。

這點很像很多 LLM-for-security 任務的通病：模型看起來懂很多，但一旦要進入可驗證、可比對、可當下游輸入的任務，噪音就會開始反噬。

作者甚至認為理想的 G-Eval 並不是越高越好，而是大概落在 0.7–0.8，代表保留足夠資訊、但沒有把太多雜訊也一起當成知識。這個判斷我覺得很成熟。

這篇對 sectools.tw 主線的意義在哪裡？

如果把 OntoLogX 放回最近 sectools.tw 這串文章脈絡，它的位置很清楚：

• 透明 ontology / STIX extraction 類論文，在處理 threat report 如何變結構
• ATT&CK extraction 類論文，在處理文字如何連到 technique / tactic
• security logs to ATT&CK insights 那類工作，則試著從遙測往高階理解靠近
• OntoLogX 則是更底層地回答：在 log 還沒先被人整理過之前，能不能先長出一個可用知識底座？

所以它補的是一個很上游、但很關鍵的缺口：CTI 不一定要從報告開始；如果 log 本身就能先被結構化、驗證化與 ontology-grounded 化，那麼後面的 ATT&CK mapping、session reasoning、threat hunting、cross-source fusion 才會更穩。

這篇論文的限制也很明顯

當然，OntoLogX 不是沒代價。

• 成本與延遲高：retrieval、generation、validation、correction 都要花算力
• 目前重點是單 event KG + session tactics，還沒真的把跨圖整合做到很深
• 對 ontology 設計品質很敏感：ontology 太窄會漏資訊，太大又會拖垮生成穩定度
• 真實企業環境日誌量更大、更雜，部署時資料治理與索引維護也會是問題

但這些限制比較像工程帳單，不是方向錯誤。相反地，正因為作者把這些約束攤開來講，才讓這篇看起來更接近可落地研究，而不是一個只在乾淨 benchmark 上漂亮示範的 prototype。

總結

OntoLogX 最值得記住的，不是它又做了一個會看 log 的 LLM agent，而是它把問題定義得更對：在 CTI pipeline 裡，真正稀缺的不是再多一個會摘要的模型，而是能把 noisy raw logs 穩定抬升成可驗證、可查詢、可映射到 ATT&CK 的知識結構。

作者給出的答案也很務實：別只靠 prompt；要加 ontology、加 retrieval、加 SHACL、加 correction，讓 LLM 不只是會生成，而是被放進一條能被治理的知識生產線。

如果你關心的是「AI 能不能讓 SOC 更早把資料變成 intelligence」，那這篇很值得看。因為它提醒我們，真正有價值的 CTI 自動化，不一定從報告摘要開始，而可能得先從一條把 log 變知識圖譜的艱苦工程線開始。

免責聲明

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