Cross-SIEM Query Generation

• Cross-SIEM query generation is the automated synthesis of platform-specific queries from a unified threat detection specification.
• It addresses challenges posed by diverse log schemas, query languages, and analytic workflows across multiple SIEM platforms.
• Frameworks like SynRAG leverage retrieval-augmented generation and strict syntax constraints to improve query accuracy and execution rates.

Cross-SIEM query generation designates the automated synthesis of platform-specific queries for threat detection and incident investigation tasks across heterogeneous Security Information and Event Management (SIEM) systems, using a unified, platform-agnostic threat or investigation specification. The inherent diversity among SIEM platforms—including differences in log schema, query languages, architectural models, and exposed analytic primitives—presents considerable obstacles to cross-platform security analytics. Frameworks such as SynRAG formalize this translation challenge, enabling analysts to express high-level threat detection logic in a standardized specification language that can subsequently be programmatically rendered as executable queries for multiple disparate SIEMs (Saju et al., 31 Dec 2025).

1. Motivation and Challenges

Enterprises operate SIEM systems such as Palo Alto Networks QRadar, Google SecOps, Splunk, Microsoft Sentinel, and the Elastic Stack to ingest and analyze large-scale infrastructure logs. These systems differ significantly in their supported query languages and analytic workflows. Manual crafting of equivalent queries for each SIEM platform requires extensive specialist knowledge and training, exacerbating workforce requirements and risking inconsistency in threat coverage. Automated cross-SIEM query generation addresses this gap by facilitating seamless and reliable query translation, reducing operational overhead and the need for SIEM-specific expertise (Saju et al., 31 Dec 2025).

2. Platform-Agnostic Specification Language

Central to cross-SIEM query translation is a high-level, platform-independent specification for detection or investigation tasks. SynRAG employs a YAML-based “threat specification” formalizable as extended BNF:

$\begin{array}{rcl} \langle\mathit{Spec}\rangle &::=& \texttt{description:}\;\langle\mathit{String}\rangle\;\langle\mathit{Fields}\rangle\;\langle\mathit{Source}\rangle\;\langle\mathit{Logic}\rangle\;[\langle\mathit{Window}\rangle] \[6pt] \langle\mathit{Fields}\rangle &::=& \texttt{fields:}\;\texttt{-}\;\langle\mathit{Field}\rangle\;(\texttt{-}\;\langle\mathit{Field}\rangle)^* \[3pt] \langle\mathit{Source}\rangle &::=& \texttt{source:}\;\langle\mathit{Identifier}\rangle \[3pt] \langle\mathit{Logic}\rangle &::=& \texttt{conditions:}\;\langle\mathit{CondList}\rangle \[3pt] \langle\mathit{CondList}\rangle &::=& \langle\mathit{Cond}\rangle\;(\langle\mathit{LogicalOp}\rangle\;\langle\mathit{Cond}\rangle)^* \[3pt] \langle\mathit{Cond}\rangle &::=& \langle\mathit{Field}\rangle\;\langle\mathit{CompOp}\rangle\;\langle\mathit{Value}\rangle \[3pt] \langle\mathit{Window}\rangle &::=& \texttt{window:}\;\langle\mathit{Duration}\rangle \[3pt] \langle\mathit{LogicalOp}\rangle &::=& \texttt{AND}\mid\texttt{OR}\ \langle\mathit{CompOp}\rangle &::=& =\mid \neq\mid >\mid <\mid \ge\mid \le \end{array}$

Key elements include a free-form textual description, explicit lists of fields to select or group, a source identifier (typically a log table), Boolean conditions over fields, and, optionally, a time window. Each atomic logical condition $$\langle\mathit{Field}\rangle\,\langle\mathit{CompOp}\rangle\,\langle\mathit{Value}\rangle$$ is ultimately mapped to a platform-specific predicate within a WHERE clause; the window element corresponds to a platform-aware mechanism for time-scoping (e.g., “LAST 5 MINUTES”) (Saju et al., 31 Dec 2025).

3. System Architecture for Query Generation

The SynRAG framework typifies state-of-the-art architectural approaches for cross-SIEM query generation. Its principal architectural elements are:

• YAML Parser: Parses the platform-agnostic specification into an abstract syntax tree representing core components (fields, logic, time window, and so on).
• Knowledge Extraction & Vector Store: Offline crawlers amass documentation for SIEM query languages (e.g., QRadar AQL, YARA-L). These are split into overlapping 500-character chunks, embedded via all-MiniLM-L6-v2, and indexed in a Chroma vector database to facilitate retrieval-augmented prompting.
• Syntax Service: Maintains precomputed, explicit vocabularies for each SIEM platform, encompassing allowable keywords, fields, functions, and clause names. This enforces strict constraints on generated queries, ensuring conformance to expected syntax and semantics.
• RAG-Based Translator (using GPT-4o): At inference, it embeds the threat specification, retrieves SIEM-specific documentation, prompts the LLM with both detection logic and syntax constraints, and enforces syntactic validity via post-processing.

Processing flow proceeds from spec parsing through knowledge retrieval, prompt construction (with institution of vocabulary/field constraints), generation of a candidate query, and post-generation well-formedness validation (Saju et al., 31 Dec 2025).

4. Formal Translation and Example Generated Queries

Formal translation from the specification to an executable query proceeds by systematically mapping YAML AST nodes and logical operators to target SIEM query constructs. The following transformation rules are applied:

$$\begin{array}{rcl} \langle\mathit{FieldList}\rangle &\to& \text{SELECT } \langle\mathit{fields}\rangle \ \langle\mathit{Source}\rangle &\to& \text{FROM } \langle\mathit{source}\rangle \ \langle\mathit{CondList}\rangle &\to& \text{WHERE } \langle\mathit{conds}\rangle \ \langle\mathit{Window}\rangle &\to& \text{LAST } \langle\mathit{duration}\rangle \end{array}$$

A concrete example, detecting brute-force logins (>20 authentication successes in 5 minutes over the last 5 hours), results in the following output:

Platform-agnostic YAML:

fields: - sourceIP - username source: events conditions: eventName = "Authentication Success" window: 5m lookback: 5h

Translated to QRadar AQL:

SELECT sourceIP AS src, username AS user, COUNT(*) AS attempts FROM events WHERE eventName = 'Authentication Success' AND startTime >= current_timestamp - 5 hours GROUP BY src, user HAVING attempts > 20 LAST 5 MINUTES

Translated to Google SecOps YARA-L:

meta: description = "Brute‐force login detection" events: $e = events | where eventName == "Authentication Success" | summarize count() by sourceIP, username | where count_ > 20 | window(duration = "5m") | lookback(duration = "5h") condition: $e

This illustrates direct, rule-based mapping of high-level threat intent into diverse SIEM query dialects (Saju et al., 31 Dec 2025).

5. Model Adaptation Paradigm

Contrary to full-model fine-tuning, SynRAG employs retrieval-augmented generation (RAG) exclusively, without gradient-based updates to the base LLM (GPT-4o). All SIEM language adaptation is achieved by constraining generation with (a) explicit, precomputed vocabulary/field lists and (b) retrieval-injected documentation. The generation process is thus entirely prompt- and retrieval-driven, with no auxiliary loss functions or cross-entropy minimization (Saju et al., 31 Dec 2025).

This paradigm relies on the capacity of the pre-trained model, given accurate context and strict constraints, to generate syntactically and semantically valid queries. The knowledge of SIEM-specific syntax is enforced through the Syntax Service’s curated token sets.

6. Evaluation Methodology and Empirical Findings

Evaluation utilized 40 manually crafted YAML threat specifications, targeting both QRadar (AQL) and SecOps (YARA-L). SynRAG was compared to GPT-4o, LLaMA-3.3, DeepSeek-V3, Gemma, and Claude Sonnet 4. Metrics were:

• BLEU (n-gram precision, brevity penalty):

$$\mathrm{BLEU} = \mathrm{BP}\,\exp\Bigl(\sum_{n=1}^N w_n\log p_n\Bigr)$$

• ROUGE-L (longest common subsequence F-score):

$$\mathrm{ROUGE\text{-}L} = \frac{(1+\beta^2)\,\mathrm{LCS}(R,C)}{|R| + \beta^2\,|C|}$$

• Execution Success Rate: Percentage of generated queries that executed without syntax error.
• Optional paired t-test for score significance:

$t = \frac{\overline{d}}{s_d/\sqrt{n}}$

with $d_i$ the difference for spec $i$, $\overline{d}$ its mean, $s_d$ sample standard deviation.

Performance on QRadar (AQL):

Model	BLEU	ROUGE-L	Execution Success Rate
SynRAG	0.1287	0.6039	85%
GPT-4o	0.0467	0.4283	0%
Claude	0.0304	0.3063	0%
LLaMA	0.0702	0.4839	0%
DeepSeek	0.0461	0.3793	0%
Gemma	0.0560	0.3591	0%

Error analysis shows baseline models frequently generate queries with incorrect field names, missing window/“LAST” clauses, or misordered AQL clauses. SynRAG’s rigorous syntax constraint and documentation retrieval substantially improve correctness and execution rates (Saju et al., 31 Dec 2025).

7. Limitations and Prospects

Current limitations of SynRAG and analogous frameworks include support for only two SIEM dialects (QRadar AQL, SecOps YARA-L) and a restricted evaluation set (40 threat scenarios). The approach’s scalability to additional SIEMs and more complex detection logic remains an open research question. Nonetheless, domain-aware RAG augmented by strict syntax enforcement is positioned as a robust, generalizable methodology for future research in cross-SIEM analytics (Saju et al., 31 Dec 2025).