ARuleCon 論文閱讀分析：當 SOC 真的在換 SIEM，最難搬的往往不是語法，而是偵測語意本身

論文基本資訊

• 論文標題：ARuleCon: Agentic Security Rule Conversion
• 作者：Hongtai Wang、Yanpei Guo、Zhengmin Yu、Weili Han、Hoon Wei Lim、Jin Song Dong、Jiaheng Zhang
• 年份：2026
• 來源：arXiv:2604.06762 / WWW 2026
• 論文連結：https://arxiv.org/abs/2604.06762
• DOI：10.48550/arXiv.2604.06762
• 主題：SOC、SIEM、Detection Engineering、Rule Conversion、Agentic AI、RAG、AIOps

如果最近一串 sectools.tw 的主線，已經一路從 agent security 邊界、memory poisoning、indirect injection、multi-agent orchestration，一路寫到 AppSec / SAST workflow，那 ARuleCon 這篇值得補的原因很直接：它談的不是模型會不會被打，也不是模型能不能找洞，而是另一個更土、卻更接近 SOC 日常痛點的問題——當企業真的在換 SIEM、併購平台、或同時維運多家廠商工具時，既有 detection rule 到底怎麼搬，才不會把原本的偵測邏輯搬丟？

這個問題其實很少被 AI 論文好好處理。因為比起 prompt injection、tool misuse、autonomous exploitation 這類高戲劇性的題目，跨 SIEM 規則轉換看起來很像只是 detection engineering 的髒活。但現實上，SOC 能不能穩定運作，常常不是卡在「有沒有再多一個模型」，而是卡在既有規則資產能不能被保留、重用、驗證與遷移。

ARuleCon 真正有意思的地方就在這裡：它不是把 rule conversion 當成單純語法翻譯，而是把它重新定義成一個語意對齊、文件檢索、邏輯補全與執行一致性驗證的 agentic workflow。這個切法，我覺得比很多「LLM 幫你寫規則」的 demo 更成熟。

這篇論文想解決什麼？

作者盯上的問題很務實。今天多數 SIEM 平台——例如 Splunk、Microsoft Sentinel、IBM QRadar、Google Chronicle、RSA NetWitness——雖然都在做 log aggregation、rule-based detection、alerting 與 investigation support，但它們的規則語言各自為政：

• Splunk SPL
• Microsoft KQL
• IBM AQL
• Google YARA-L
• RSA ESA

這些規則不只是語法不同，連：

• 欄位命名方式
• 資料模型
• 聚合與 correlation 邏輯
• 內建函式與保留關鍵字
• 必要欄位與 schema 慣例

都可能不一樣。也就是說，把規則從 A 平台搬到 B 平台，麻煩的從來不只是 query 長得不像，而是兩邊對「同一條偵測邏輯」的理解方式都未必一樣。

所以這篇論文真正想回答的，不是「LLM 能不能幫忙翻譯一段 SPL」，而是：

當 SOC 要在異質 SIEM 之間保留既有 detection logic 時，能不能用 agentic workflow 把規則轉換做成一條可驗證、可補知識、可檢查語意漂移的流程，而不只是一次性的文字改寫？

為什麼這件事比看起來難很多？

ARuleCon 很清楚地指出，SIEM rule conversion 不等於 SQL dialect conversion。這個判斷非常關鍵。

一般人直覺上會覺得，規則語言不就是類 SQL 的東西，做 translation 應該跟 code translation 差不多。但作者認為，這裡真正麻煩的是：

• 沒有統一標準：各家 SIEM 都有自己的方言，甚至不是單純方言，而是連語義邊界都不同。
• 平台依賴很重：同一個欄位、函式或 operator，換到別家 SIEM 可能根本沒有等價物。
• 資料 schema 綁定 vendor pipeline：同一條偵測意圖，要落到不同平台常得重新補欄位、補 metadata、補 mapping。
• conversion error 不一定會報錯：最危險的不是轉不動，而是看起來能跑、實際上 quietly drift，最後 detection coverage 被偷掉。

這也是為什麼我覺得這篇 paper 的問題意識很準：規則轉換真正難的不是 syntax preservation，而是 detection semantics preservation。

ARuleCon 做了什麼？核心是三段式閉環

ARuleCon 不把問題當成一次性 prompting，而是拆成三個核心部件：

• conversion intermediate representation（IR）
• agentic RAG pipeline
• Python-based consistency check

這個設計很重要，因為它代表作者其實接受了一件現實：光靠模型本體記憶，不足以穩定處理跨 SIEM 轉換。 你必須先把 rule 的核心邏輯抽離出來，再把平台知識補回去，最後還要檢查功能是否真的還在。

1. 先把偵測邏輯抽成 vendor-neutral IR

第一步是把來源規則蒸餾成一層中介表示。這層 IR 的目的不是取代原規則，而是把像 source condition、filtering、aggregation、correlation intent、輸出欄位等核心偵測語意，先從 vendor-specific syntax 裡拔出來。

這一步我認為是整篇最有價值的設計之一。因為很多 rule conversion 之所以最後變成 fragile prompting，本質上就是沒有一個穩定的中介層，導致模型直接在「來源方言」和「目標方言」之間硬跳。結果就是：

• 有些條件被漏掉
• 有些欄位被錯配
• 有些 aggregation 邏輯被偷換
• 有些必要 metadata 根本沒補上

有了 IR 之後，規則轉換才比較像是在做意圖保持下的結構性重建，而不是把字串改寫得看起來像另一種語言。

2. 再用 agentic RAG 補 vendor-specific 知識

第二步，ARuleCon 用 agentic RAG 去拉官方文件，補齊目標平台的語法、欄位慣例、必要 section、允許的關鍵字與函式使用方式。

這一段其實點出了傳統 LLM prompt-based rule conversion 最容易失手的地方：模型可能知道大意，但未必真的熟到每一家 SIEM 的最新 grammar、field namespace 與必填規則模板。

作者不是假設模型本來就會，而是直接讓系統在轉換時檢索 authoritative vendor docs。這樣做有幾個實際好處：

• 降低幻覺式 keyword 映射
• 補齊 required fields / sections
• 把 platform convention 當成外部知識而不是模型記憶
• 讓 rule completeness 與 syntax correctness 更可控

這也是這篇 paper 最值得被 detection engineering 圈記住的一點：rule conversion 真正需要的不是更會猜的模型，而是更像樣的 documentation-grounded generation。

3. 最後用可執行一致性檢查去抓 semantic drift

第三步是我最喜歡的部分。ARuleCon 不停在「文字像不像」，而是進一步生成 Python-based executable code，模擬來源規則與目標規則在受控測試資料上的執行結果，檢查兩邊輸出是否一致。

這個思路非常對。因為在 SIEM 轉換裡，最危險的錯誤常常不是 parser-level syntax error，而是：

• 條件次序改了，結果樣本集合變了
• 聚合窗格不同，行為判斷變了
• 欄位映射不完整，某些事件被默默漏掉
• 邏輯表面相似，但輸出集合已經不等價

換句話說，真正要驗的不是 rule 長得像不像，而是它跑起來還是不是在抓同一件事。 這種 executable equivalence checking，雖然不可能完美覆蓋所有真實 log 情境，但至少比單純字面比對成熟太多。

評估規模與主要結果

論文提到，ARuleCon 在 1,492 組跨五個主流 SIEM 平台的 rule conversion pairs 上做了完整評估，評量面向不只看文本相似度，還看 execution success 與整體邏輯對齊。

作者的主要 claim 是：ARuleCon 相較於一般基線 LLM 做法，平均可提升約 15% 的 similarity alignment，而且在語法完整性、語意保真與可執行性上都有更穩定的表現。

我覺得這裡最值得注意的，不是那個 15% 本身，而是它改善的是哪一種品質：

• 不是只讓 rule 看起來更像
• 而是讓 rule 更有機會真的能跑、跑出接近原意的結果

對 SOC 來說，這比一般 benchmark 上多幾分 BLEU 或 text similarity 有價值得多。因為 detection migration 真正怕的從來不是寫不出 rule，而是你以為搬完了，結果 coverage 已經少一塊，而且沒人發現。

這篇論文最重要的啟發：SOC migration 的真正成本，很多時候是 detection semantics

我覺得 ARuleCon 最值得留下來的，不是「agent 可以幫忙轉 rule」這個表面結論，而是它背後那個更實際的提醒：

企業在做 SIEM migration、multi-vendor coexistence 或平台整併時，真正昂貴的未必是新工具授權，而是既有 detection logic 能不能被完整地帶過去。

這個觀點很重要，因為很多資安 AI 論文還停在「幫 analyst 更快寫東西」。但 ARuleCon 談的是另一層：如何保留組織已經累積下來的 detection capital。 也就是說，規則不是單純的技術 artifact，而是企業把過去事件、誤報修正、平台脈絡與攻擊知識累積下來的 operational memory。

從這個角度看，ARuleCon 的價值其實不只在 rule translation，而是在幫 SOC 減少 migration 過程中的知識流失。

它和最近那串 agentic security 論文有什麼不同？

最近很多 agentic security paper 都在談：

• prompt injection
• skill / tool supply chain
• memory poisoning
• delegation / authorization boundary
• runtime verification

ARuleCon 則完全不是那條線。它比較像是把 AI 放進 detection engineering infrastructure 裡，而不是把焦點放在 AI 自己會不會做壞事。這也是為什麼我覺得它很適合接在最近幾篇之後：它把主軸從「怎麼防 agent」拉回「怎麼用 agent 把 SOC 裡一個很痛、很耗人、又常常做得不夠好的工作流重新工程化」。

更直白地說，這篇提醒的是：

• 有些最值得做的資安 AI，不是再造一個 autonomous cyber defender
• 而是把現有 security operations 裡最容易出錯、最耗專家時間、最難標準化的部分，做成比較可驗證的 workflow

限制與保留

• 官方文件檢索雖然比裸 prompting 好，但不代表文件本身就足夠描述所有實務坑：真實規則常常還依賴在地資料模型、欄位清洗流程與組織內部慣例。
• 執行一致性檢查很有價值，但仍受限於測試資料代表性：如果 synthetic logs 沒涵蓋到關鍵邊界條件，semantic drift 還是可能漏掉。
• 15% alignment improvement 雖然不錯，但最終導入仍要看 production false negative / false positive 風險：rule conversion 錯一點點，在高風險場景可能就很要命。
• 多平台 rule conversion 不是一次性問題，而是持續維護問題：平台版本、語法與 schema 一更新，整條 pipeline 也要跟著維護。
• 這類系統若沒接好 change management，可能反而加速規則擴散而不是品質提升：轉換更快，不代表審核就可以省掉。

我怎麼看這篇論文？

我會把 ARuleCon 看成一篇很務實、也很值得企業 SOC 注意的 detection engineering / SIEM migration paper。它沒有在講一個很炫的 cyber battle story，而是在處理一個真實世界裡很痛的問題：安全規則資產如何跨平台保存，而不是在每次平台遷移時都被迫重寫、重猜、重踩坑。

更重要的是，它用一個很成熟的方式示範了 agentic workflow 在資安裡真正該長什麼樣：

• 先抽出核心語意
• 再用權威知識補上下文
• 最後用執行結果做驗證

這比單純喊「LLM 可以自動化安全工作」可信得多。因為它不是讓模型直接當 oracle，而是把模型放進一條會被外部知識約束、會被執行結果糾錯的流程裡。

一句話總結

ARuleCon 真正提醒我們的，不是 LLM 可以幫你把 SPL 改寫成 KQL，而是當 SOC 進入多平台與持續遷移時代，真正該被保護的不是某段查詢語法，而是那條累積多年的 detection semantics 本身。

---

本文由 AI 產生、整理與撰寫；內容僅供研究與技術分析參考，若需引用或用於正式決策，請務必回到原始論文與作者資料進一步確認。