FALCON 論文閱讀分析：把 CTI 自動變成可部署的 Snort / YARA 規則，真的可行嗎？

論文基本資訊

• 論文標題：FALCON: Autonomous Cyber Threat Intelligence Mining with LLMs for IDS Rule Generation
• 作者：Shaswata Mitra, Azim Bazarov, Martin Duclos, Sudip Mittal, Aritran Piplai, Md Rayhanur Rahman, Edward Zieglar, Shahram Rahimi
• 來源：arXiv 2508.18684
• 主題：CTI、Agentic AI、IDS Rule Generation、Snort、YARA、Threat Detection
• 論文連結：https://arxiv.org/abs/2508.18684

這篇 FALCON 很值得接在最近幾篇 CTI benchmark／reasoning 論文後面看，因為它不再只是問「LLM 懂不懂 CTI」，而是更進一步問：如果模型真的看懂了，那它能不能把 CTI 直接轉成可以部署的 IDS 規則？

作者想解的問題非常務實。SOC 團隊每天都在面對新的攻擊樣態、IoC、行為特徵與威脅報告，但從這些 CTI 資訊一路走到可上線的 Snort 或 YARA 規則，中間通常還要經過人工抽取、比對既有規則、撰寫、驗證、調校。這整段流程又慢、又吃人力、還容易因為規則爆量而拖垮維運效率。

FALCON 的核心主張是：用 agentic LLM workflow，把 CTI 自動翻成可部署的 IDS 規則，並在內部完成語法、語意、效能三層驗證，讓整條管線不只是「生成」，而是接近「可交付」。

這篇論文想解決什麼？

傳統的 IDS rule engineering 有三個老問題：

• 速度不夠快：新威脅冒出來時，規則更新往往跟不上。
• 高度仰賴專家：要把 CTI 轉成 Snort / YARA，需要很熟語法、平台特性與偵測邏輯的人。
• 規則庫會持續膨脹：每來一個變體就新增一條，很快就 rule bloat，拖累執行效率。

作者的觀察很準：今天的難點不只是「寫出一條規則」，而是寫出一條和原始 CTI 對得上、語法正確、效能合理、而且最好還能判斷該更新舊規則還是新增新規則的規則。

也因此，FALCON 不是把 LLM 當成單次 code generator，而是把它放進一個有檢索、生成、驗證、回饋迭代、人類審核的 agentic pipeline 裡。

FALCON 的整體架構在做什麼？

整個流程可以簡化成下面這樣：

CTI 輸入
  ↓
檢索相近的既有 IDS 規則
  ↓
LLM 產生候選 Snort / YARA 規則
  ↓
語法驗證
  ↓
語意驗證
  ↓
效能驗證
  ↓
若未過關則回饋重新生成
  ↓
最後交給分析師審核後部署

這個設計最重要的地方，是它承認單靠一次生成不夠可靠。真正有價值的是把生成包進驗證閉環，讓模型不是亂吐一條 rule 就結束，而是必須一路通過多層檢查。

Generation phase：先生成，但不是盲生

FALCON 的第一階段是 generation。輸入是一份 CTI，裡面可能包含：

• IP、domain、hash 等 signature
• 通訊協定、惡意行為、payload pattern 等 behavior
• 其他從 threat report 或 sandboxing 萃取出的指標

接著系統不會直接丟給 LLM，而是先找出語意上相近的既有 IDS 規則。這一步的目的有兩個：

• 提供更好的上下文，幫助模型生成更貼近實務的規則
• 判斷這次到底該「新增規則」還是「更新舊規則」

這個觀念很重要。很多論文都在談自動生成，但比較少真的處理規則維運的現實：不是每個新 CTI 都值得長出一條全新的規則。有時候更好的做法是重用或微調既有規則，避免規則庫無限制膨脹。

Validation phase：這篇論文真正有料的地方

如果只看摘要，你會以為 FALCON 的亮點是 agentic AI。但我覺得更有價值的是它把驗證拆成三層，而且每一層都真的對應到部署現場會踩到的坑。

1. Syntax validation：先確定規則至少能被吃下去

第一層是語法檢查，確認產出的 Snort / YARA 規則至少結構正確、能被 parser 接受。這一步聽起來很基本，但很必要，因為小模型或第一次生成很容易在格式上就出錯。

作者在討論中也提到，較小的模型常常需要 2 到 3 輪回饋後，才會收斂到有效規則。這其實很符合實務直覺：小模型不是不能用，而是更依賴結構化 feedback loop。

2. Semantic validation：不是長得像 rule，就真的對應到 CTI

這篇論文最值得注意的技術點，是作者知道「語法正確」遠遠不等於「邏輯正確」。一條看起來像樣的規則，可能還是抓錯協定、漏掉關鍵 indicator、或用錯偵測重點。

為了解這個問題，他們設計了自己的 CTI-Rule Semantic Scorer。概念上，它是一個 bi-encoder 模型，把：

• 自然語言的 CTI 描述
• 形式化的 IDS 規則

一起投影到同一個 embedding space，再用 cosine similarity 去判斷兩者在功能上是否對得起來。

作者明確指出，這件事不能只靠 BLEU、ROUGE、BERT-F1，甚至也不能完全信任 LLM 自己說「我覺得這條規則合理」。因為 CTI 和 IDS rule 本來就不是同一種表示形式：前者是自然語言威脅敘述，後者是高度壓縮、結構化的檢測語言。兩者之間存在很大的 representation gap。

所以他們才做了一個專門衡量 functional alignment 的語意分數器，拿來支撐 semantic validation 與 rule retrieval。這個想法其實比單純「再加一個 LLM judge」更紮實，因為它至少試圖把「像不像」和「有沒有真的抓到威脅邏輯」分開。

3. Performance validation：生成出來還要能跑

第三層是效能驗證，這點很務實，也讓 FALCON 比很多 demo 型研究更像真實產品設計。

作者關注的不只是 rule 能不能 match，還包括：

• 有沒有冗餘邏輯
• 有沒有不必要的額外規則
• 執行時會不會造成效能負擔
• 是否可以透過更新既有規則，避免新規則無限擴張

這一層的存在很關鍵，因為真實世界的 IDS 維運不是比誰 rule 多，而是比誰的規則庫有效、可維護、可持續演進。如果沒有 performance validation，自動化最後很可能只是把人工撰寫的瓶頸，換成自動生成的 rule bloat。

資料集與實驗設計：不是小玩具

FALCON 的實驗規模不算小。作者蒐集了：

• 4017 條 Snort 規則
• 4587 條 YARA 規則

並為每條規則建立對應的 CTI，最後形成：

• 8034 組 Snort CTI-rule pairs
• 9174 組 YARA CTI-rule pairs

此外，作者還另外建立了大量「相關但已過時」的舊規則，用來測 retriever 是否能找到可重用的 existing rules。這個設計很不錯，因為它不是只驗證生成品質，而是把「規則重用／更新」這個實務議題一併拉進來。

整體來看，這篇的資料與實驗設計至少有做到兩件事：

• 不是只在少數手工案例上 demo
• 有試著把 rule retrieval、semantic scoring、end-to-end pipeline 串成一套完整驗證

結果怎麼看？

論文最吸睛的數字，是摘要提到的：

• 平均 95% accuracy
• 多位資安分析師 qualitative evaluation 的 84% inter-rater agreement

如果只看這兩個數字，會很容易覺得「這已經可以全自動上線了」。但我認為比較合理的解讀是：FALCON 證明了這條路可行，但還不代表可以把 analyst 從流程裡拿掉。

原因有三個：

• 論文自己就把 Cybersecurity Analyst 放在最後一關，表示作者也不主張 fully hands-off deployment。
• 所謂 accuracy 與相似度分數，仍是建立在作者定義的 scoring 與評估框架上，不等於真實 SOC 環境裡的長期偵測效益。
• 即便 rule 在語法、語意、效能上都通過，仍可能和組織本身的 policy、誤報容忍度、現場流量型態不一致。

換句話說，這篇最有價值的地方，不是「從今天起分析師失業」，而是：分析師可以把時間從手工 rule drafting，轉移到高價值的審核、修正與策略判斷。

多模型比較透露了什麼？

作者還比較了多種不同大小的模型，包括 GPT-4o、Llama-3.3-70B、Qwen3-32B、Mistral-Small、Granite、Phi-4-mini。結果很有意思：

• 大模型與中型模型在 first-shot generation 上通常比較穩
• 小模型初稿比較容易出錯，但在 feedback loop 裡仍然能逐步修正
• 這表示真正重要的，可能不只是 base model 大小，而是整個 agentic pipeline 的糾錯能力

這點其實和很多最近的安全 AI 系統很像：工作流設計開始比單次 prompting 更重要。如果你有良好的 validator、retriever、回饋機制，小模型也未必不能做出接近可用的結果；反過來說，如果沒有驗證閉環，再強的模型也可能穩定地產生看似合理、其實不能部署的垃圾。

我怎麼看這篇論文？

我覺得 FALCON 有三個很實際的價值。

第一，它把 CTI → Detection Engineering 這條鏈真正接起來了

很多 CTI + LLM 論文停在摘要、問答、分類、benchmark 或 reasoning assessment。FALCON 則更往前一步，把輸出直接對準 Snort / YARA rule。這讓研究成果離 SOC 現場更近，也更容易被真正採用。

第二，它知道「生成」本身不是重點，重點是 validation

如果今天一篇論文只說「我們用 LLM 生成 IDS rule」，那老實說沒有太大說服力。FALCON 比較成熟的地方，是它很清楚：可用性來自驗證閉環，不來自生成本身。

第三，它碰到了 rule lifecycle management，而不只是單次產出

這篇有認真處理規則重用、舊規則更新、rule bloat 這些維運議題。這表示作者不是只把論文做成一個 flashy prototype，而是有意識到部署後的管理成本。

這篇論文的限制在哪？

當然，FALCON 也不是沒有弱點。

• 第一，資料仍高度依賴既有規則與對應 CTI 的品質。 作者自己假設 CTI 已經正確包含足夠的 signature 與 behavior。現實裡如果 CTI 本身殘缺、噪音很多、甚至帶有錯誤，後面整條管線都會跟著歪。
• 第二，評估仍偏向離線實驗。 它證明了 rule generation 可行，但沒有真正展示在 live traffic、實際告警負載、誤報／漏報成本下的長期效果。
• 第三，semantic scorer 很有想法，但仍是作者自建框架。 它目前看起來優於 RAGAS 與 BERT-F1，但未來還需要更多跨資料集、跨環境驗證，才能確定這個分數真的穩。
• 第四，人類仍是最後保險絲。 這不是缺點，而是現階段非常合理的現實。任何聲稱可以完全自動部署偵測規則的系統，我反而會先提高警覺。

對 CTI / SOC 團隊的啟示

如果你在做 CTI、Detection Engineering 或 SOC Automation，FALCON 帶來的啟示不是「讓 AI 自己去寫規則就好」，而是下面這幾點：

• 可以開始把 CTI 到 detection content 的轉譯 視為可自動化問題
• 不要只追求生成，一定要把 syntax / semantic / performance validation 一起設計進去
• 規則生成系統不該只會新增，還要能考慮 rule reuse 與 lifecycle management
• 未來真正可落地的方向，很可能是 agentic pipeline + analyst-in-the-loop，而不是純 autonomous replacement

總結

FALCON 是一篇很有「工程落地感」的論文。它的價值不在於再一次證明 LLM 可以看懂資安文字，而在於把問題推進到更接近實務的一步：能不能從 CTI 自動產出真正可部署的 IDS 規則？

作者給出的答案是：可以，但前提不是單次生成，而是要有檢索、語意對齊、效能驗證、回饋迭代，以及人類最後把關。

如果說 AttackSeqBench 這類 benchmark 論文是在測模型到底看不看得懂攻擊序列，那 FALCON 代表的就是下一步：當模型開始看懂之後，我們能不能把理解轉成可行動、可部署、可維護的防禦產物。

這條路還沒走完，但至少這篇論文證明了一件事：CTI 自動化的下一個關鍵戰場，不只是問答與摘要，而是直接進入 detection engineering。