論文閱讀分析｜CTI 真正要落地，重點往往不是再多一份摘要，而是能不能把威脅語意安全地翻成 firewall rules
論文基本資訊
- 論文標題：From Threat Intelligence to Firewall Rules: Semantic Relations in Hybrid AI Agent and Expert System Architectures
- 來源：arXiv:2603.03911
- 作者：Chiara Bonfanti、Andrea Druetto、Corrado Basile、Tharindu Ranasinghe、Marcos Zampieri
- 論文連結：https://arxiv.org/abs/2603.03911
- 主題：CTI、Firewall Rules、Detection Engineering、Neuro-symbolic AI、Expert Systems、Agentic Security
本文由 AI 產生、整理與撰寫。
這篇 From Threat Intelligence to Firewall Rules 真正有意思的地方，不是它又證明一次 LLM 可以讀懂資安文字，而是它直接碰一個更痛、更接近實務落地的問題：當你手上已經有 threat report，能不能不要只停在摘要、分類或 ATT&CK 對映，而是把它往真正可執行的防禦配置推進？
作者挑的落點很務實：把 CTI 報告裡的威脅語意，轉成可由 expert system 產生的 firewall filtering rules。也就是說，這篇不是在問「模型會不會看報告」，而是在問：模型能不能把報告裡的威脅語意整理到足夠結構化，讓後面的防禦系統真的接得上。
這篇論文要解的核心，不是理解文字，而是 operationalization
很多 CTI / LLM 研究最後都停在一個很安全的距離：抽 IOC、做摘要、標 technique、回答 analyst 問題。這些都重要，但它們離真正的 security control deployment 還差一段。這篇 paper 的價值，就在於它盯著那段最常被跳過的空白：
威脅情報如果不能被轉成控制措施，很多時候就還只是比較漂亮的文字資產，而不是防禦能力。
作者的場景是 web security 與 intrusion prevention。面對不斷變化的攻擊與事件報告，防守方需要的不只是知道 attacker 在做什麼，而是要能更快決定：哪些 security controls 應該被啟用、哪些 network traffic 應該被擋、規則應該怎麼寫。
因此整篇論文其實是在做一件很實際的事：把 CTI prose → semantic concepts → security capabilities → executable rules 這條鏈補起來。
作者的切入點很聰明：先不要急著直接分類，先把語意關係抽乾淨
這篇最值得記住的技術選擇，是作者沒有直接讓模型一口氣從原始報告吐出規則，而是先處理語意關係。他們特別強調 hypernym-hyponym（上位詞 / 下位詞）這類 taxonomic semantic relations，並把它當成從 CTI 敘述抽取結構資訊的骨架。
這個想法其實很對。因為 CTI 報告往往很吵，裡面混著：
- 敘事性描述
- 具體 artifact（IP、URL、domain、tool 名稱）
- 攻擊行為與目的
- 分析師的推論與背景補充
如果你直接把整段文字當成一般分類任務，很容易卡在資料稀疏、類別不平衡與語句表面差異。作者的主張則是：先把具體威脅行為與防禦語意往更穩定的語意階層抽象化，再交給後面的 mapping 與 rule generation。
換句話說，這篇不是靠一個更大的模型硬吃雜訊，而是試圖讓模型先把威脅報告裡的語意骨架整理出來。
整條 pipeline 長什麼樣？它其實是一個 neuro-symbolic operational chain
論文的核心架構可視為一條 Semantic Information Flow (SIF)：
- 輸入 CTI reports
- LLM 以 iterative prompting 抽取 security concepts
- 先找 hyponyms，再找 hypernyms，建立更穩定的語意表示
- 把抽出的語意轉成可用於 CLIPS 的 templates / facts / rules
- 交給 expert system 驗證與推理
- 最終輸出可用於 security controls 的 filtering rules（例如 iptables）
我認為這篇最有價值的，不是「multi-agent」這個字，而是它沒有把 agent 當成花俏包裝，而是真的讓不同層負責不同職責：
- LLM / agentic layer 負責從鬆散文字中抓語意
- symbolic / expert-system layer 負責做結構化表示、規則驗證與語法約束
- security-control layer 負責把前面的結果落成真正能部署的防禦動作
這種拆法很成熟，因為它沒有把所有風險都壓在模型最後一次生成上。作者甚至明說 expert system 的一個重要角色，就是當作對抗 LLM hallucination 的 syntactic verification layer。
為什麼這篇值得看？因為它把「防禦生成」拉回可驗證的工程問題
現在很多 agentic security paper 很容易掉進兩種極端：
- 不是只做 benchmark，離落地太遠；
- 就是直接端到端生成，但中間幾乎沒有可驗證控制點。
這篇相對務實。它沒有說「LLM 自己就能安全地寫出規則」，而是把產出切成幾個可檢查的中間表示。這很重要，因為 security rule generation 真正怕的不是答得不夠漂亮，而是答錯了卻還能進 production。
尤其當目標是 firewall / IPS 這類控制面時，錯一條規則可能代表：
- 沒擋到該擋的流量
- 過度封鎖造成業務中斷
- 把錯誤 threat interpretation 變成自動化 policy
所以這篇的真正價值，不只是把 CTI 轉規則，而是把這條鏈做成比較像 可驗證的防禦工程流程，而不是一個只靠 model vibes 的自動化 demo。
資料集設計也點到一個老問題：資安資料就是不平衡、而且很少真的乾淨
作者用了兩個資料來源：
- CTI-HAL：由 81 份真實 CTI 報告組成、手工對映到 MITRE ATT&CK techniques，總共 116 個 distinct techniques。
- Center for Internet Security corpus：包含 66 個 malware entries、analyst synopsis 與 network artifacts，標籤是 security capabilities。
這裡有個很重要的背景：CTI 不是那種 class balance 漂亮、欄位結構穩定、annotation 成熟的 NLP 天堂。 它本來就是低資源、高偏斜、敘事風格差異極大、又摻雜大量專業上下文的資料域。
因此作者在 Task A 其實不是只想贏 baseline，而是想證明：語意強化的 prompting，比起一般 embedding / 傳統 ML / 普通 CoT，在這種高度不平衡的資安語料上更能穩住少數類別。
結果怎麼看？重點不只是分數，而是它在哪裡贏
論文指出，這套 semantic extraction 方法在 Task A 的 weighted F1 與 Top-k accuracy 上都優於 baseline，整體大約有 7% 左右的 F1 提升。更值得注意的是，作者特別點出：
- 一般 Chain-of-Thought 雖然某些 accuracy 相近，但在 minority classes 表現明顯更差；
- hyponyms 比 hypernyms 更有效；
- 較弱的 selectivity threshold（例如 50%）反而能改善表現。
這些訊號很有意思。它代表真正有幫助的，不是單純把 prompt 寫長，而是模型是否能沿著正確的語意階層，找到那些對 downstream defense 有用的概念。
我會把這結果解讀成：在 CTI operationalization 這種任務裡，模型最大的瓶頸往往不是生成能力，而是 retrieval / abstraction / representation 這三件事有沒有先做對。
Task B 更像落地性檢查：這些規則至少有沒有工程上的可信度？
Task B 則讓完整 pipeline 跑在 malware + network artifact 的資料上，最後由資安專家做人工評估。作者看的是幾個很實際的維度：
- Technical Correctness
- Scope Calibration
- Fidelity to CTI
論文說這些維度都呈現不錯的一致性，尤其 Technical Correctness 的 annotator agreement 最高。這點雖然還不是 production-grade validation，但它至少說明：輸出的規則沒有完全飄在空中，而是已經開始接近可被安全工程師審閱與採納的樣子。
對我來說，這比單純報一個 BLEU、ROUGE 或模型偏好分數有價值得多，因為 security controls 最後還是要回答：能不能部署、會不會出事、跟原始威脅敘述是否對得上。
這篇的真正主線：不要把 CTI 只當成 analyst reading material
如果把這篇放進最近 sectools.tw 的脈絡，我覺得它補得很準。前面我們已經寫過：
- CTI retrieval / graph grounding
- IOC → regex 的 operationalization
- threat misinformation 對 CTI pipeline 的 poisoning
- agent runtime / MCP / privilege 這些 execution security 議題
而這篇剛好補上另一段關鍵鏈條：CTI 不只是要被看懂，還要被翻成控制面語言。 而且這個翻譯不該只靠 end-to-end 黑箱生成，而應該透過 semantic abstraction + symbolic verification 來降低錯誤傳播。
所以它的核心訊息其實可以濃縮成一句：
真正難的不是把威脅報告讀成 ATT&CK 技術，而是把它安全地翻成防守系統真的吃得下、也敢執行的規則。
限制也很清楚：這還不是全自動防禦天堂
當然，這篇不是沒有侷限。
- 資料規模仍然不大，距離真實企業天天吃的海量 CTI 還有差距；
- 輸出目標主要是 firewall / filtering rules，防禦控制面仍偏窄；
- 作者強調 deterministic inference 與固定 seed，但這本身還是近似的工程控制，不代表真正消除 LLM 不穩定性；
- human evaluation 雖重要，但距離大規模 production rollout 需要的安全驗證還差不少。
不過這些限制不會削弱它的價值，反而讓論文的定位更清楚：它不是在吹「agent 已經能自動守網路」，而是在示範一條比較對的 CTI-to-control engineering path。
一句話總結
這篇論文最值得帶走的觀點是：CTI 真正要落地，不能只做摘要與分類，而要把 threat semantics 經過可檢查的語意抽象與符號驗證，翻成防禦系統真的能執行的控制規則。
講白一點，安全團隊真正缺的，常常不是再多一個會解釋 threat report 的模型，而是一條能把 threat report 安全地變成防禦動作的工程鏈。