Cutting the cost of SIEM rule conversion
You inherit two thousand detection rules from an acquisition. They are written for a platform your company does not use. Your senior detection engineer estimates six months to port them. That estimate assumes nothing else breaks in the meantime.
Mergers happen. Platforms get swapped. Some organizations run two analytics tools in parallel and maintain rules for both. Every time, someone spends weeks reading vendor manuals and rewriting queries that already worked somewhere else. The researchers behind a new system called ARuleCon, describe the manual approach plainly as “slow and imposes a heavy workload”, which is the kind of understatement detection engineers will recognize.
Overview pipeline of ARuleCon (Source: Research paper)
Why this is harder than it sounds
If you have ever wondered why nobody has fixed this already, the short answer is that detection rule conversion looks like SQL translation and is nothing like it. SQL has a standard. Detection query languages do not. Each vendor invented its own operators, its own field names, its own way of handling time windows and aggregations. A keyword in one platform can decompose into three separate steps in another. Two operators that read as equivalent can produce different results on the same data.
The authors note that reliable conversion requires “deeper reasoning about execution semantics and domain-specific understandings”, which is a polite way of saying the model needs to know things it does not know.
Throwing a general-purpose language model at the problem produces rules that look right and quietly fail. The model drops a grouping clause and your per-host count becomes a global count. It puts a threshold in the wrong part of the query and the rule stops alerting entirely. The query parses. The platform accepts it. Nothing fires. Detection engineers know this is the worst possible outcome, because it looks like success.
What ARuleCon does differently
The system, called ARuleCon, takes the source rule and breaks it down into a vendor-neutral description of what the rule is trying to do. Filter these events. Group by this field. Apply this threshold over this time window. Once that description exists, building a draft rule for the target platform becomes a more constrained problem.
A second component reads the target vendor’s documentation the way an analyst would. It asks specific questions about specific operators, checks whether the answers resolve the question at hand, and refines its search if they do not. This matters because most translation errors come from missing knowledge about how the target platform handles a particular construct, and the model alone does not have that knowledge reliably.
The third piece is the one that earns its keep. The system compiles the original rule and the converted rule into runnable Python, generates synthetic logs, and compares outputs. If the source rule produces a list of suspicious IPs and the target rule produces a single global count, the mismatch surfaces before anyone deploys the rule. Errors that textual comparison would never catch get caught here.
What the testing showed
Across roughly 1,500 conversion pairs spanning five major platforms, ARuleCon improved similarity to reference rules by about 15 percent over direct language model translation. Execution validity on target platforms generally cleared 90 percent. The gains held across three different underlying models, which suggests the architecture is doing real work.
A few honest caveats. The primary scoring measures similarity to a reference rule, which is a proxy for correctness and not the same thing. The execution test uses logs the system generates from its own representation of the source rule, which is convenient and a little circular. Two of the five platforms had fewer than 50 rules in the test set. No part of the evaluation involved replaying real attack traffic against converted rules on production deployments. Human review before anything goes live is still required.
Why you should care
Rule portability is a quiet form of vendor lock-in, and the cost of that lock-in shows up in your team’s calendar every time someone changes platforms. A working translator changes the math.
Migration projects shrink. Running parallel platforms becomes less punishing. Detection engineers spend more time deciding what to detect and less time figuring out how to express it in a different dialect. The system costs more in compute than naive translation, and it is not ready to be turned loose without supervision. The direction is the point.
Download: Secure Foundations for AI Workloads on AWS