Converting Sigma Rules to IBM QRadar (AQL): A Practical Guide

You have a library of Sigma rules, an IBM QRadar deployment in production, and you'd like to wire one into the other. The catch: QRadar doesn't read Sigma. It queries its events through AQL (Ariel Query Language) so every Sigma rule has to be compiled into AQL. Done properly, you get performant queries; done carelessly, you get queries that scan the raw payload and drag the console to its knees. Here's how to do it right.

What Sigma is, and why QRadar can't read it

Sigma is a generic detection-rule format written in YAML. The idea: describe a detection once, independent of any SIEM, then compile it to the target query language, SPL for Splunk, KQL for Sentinel, AQL for QRadar.

A Sigma rule looks like this:

title: PowerShell EncodedCommand
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - '-enc'
            - '-EncodedCommand'
    condition: selection

It's readable, portable, versionable in Git. But QRadar doesn't know what to do with it: its Ariel engine expects AQL, a SQL-like language that queries the events table (or flows). So the Sigma rule has to be compiled into an executable AQL query. That's the job of pySigma.

Converting with pySigma and the QRadar backend

pySigma is the reference library (it replaces the old sigmac). Conversion to QRadar relies on the pysigma-backend-qradar-aql backend (the QRadarAQLBackend) paired with two processing pipelines, and this is the part that really matters:

• QRadarAQL_fields, maps Sigma fields to QRadar's normalized properties (the console properties). The query hits indexed columns: fast and precise, but it only covers the properties that are actually mapped and extracted by your DSM.
• QRadarAQL_payload, the fallback. When a field isn't normalized, it searches the raw payload (the event's UTF8 text). It covers everything, but it scans unindexed text: slower and more expensive at scale.

Install and convert on the command line:

pip install sigma-cli pysigma-backend-qradar-aql
 
sigma convert -t qradar-aql -p QRadarAQL_fields rule.yml

The -t qradar-aql flag selects the backend, -p QRadarAQL_fields applies the "fields" pipeline. The pipeline choice is not cosmetic: it decides whether your rule queries clean properties or rakes through the whole payload.

An honest note on compatibility

To be upfront: the QRadar backend has a history of compatibility issues with recent pySigma releases, broken imports, pipeline APIs that shifted. In practice you isolate it in a dedicated Python environment with pinned versions (a frozen pip freeze, or a reproducible venv) rather than letting it track the latest pySigma. It's not a deal-breaker, but it's an operational constraint to know before you build a pipeline on top of it.

The real problem: QRadar properties vs. raw payload

This is where conversion quality is won or lost. A Sigma rule speaks in abstract fields: Image, CommandLine, ParentImage. In QRadar those concepts exist as properties (for example Process Path, Process CommandLine, Parent Process Path) provided your DSM (Device Support Module) and your custom properties actually extract them from the event.

With QRadarAQL_fields, pySigma tries to map Image to the Process Path property. If the mapping exists, the query hits a clean column. If the property is not extracted by your log source, there's nothing to query, and that's where QRadarAQL_payload steps in, falling back to ILIKE '%...%' in the raw payload. The rule still matches, but at the cost of an unindexed text scan.

So the trade-off is explicit: fields = performant but partial, payload = exhaustive but heavy. The right reflex is to prefer fields and only fall back to payload for the fields your DSM doesn't extract.

A full example: before / after

Take the PowerShell -EncodedCommand rule above.

Sigma (source, portable):

detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - '-enc'
            - '-EncodedCommand'
    condition: selection

Generated AQL (target, executable):

SELECT * FROM events WHERE "Process Path" ILIKE '%\powershell.exe' AND ("Process CommandLine" ILIKE '%-enc%' OR "Process CommandLine" ILIKE '%-EncodedCommand%')

Notice the mechanics: endswith becomes ILIKE '%\powershell.exe', the contains list becomes an OR group of ILIKE '%...%'. The double-quoted names ("Process Path", "Process CommandLine") are QRadar properties, that's the output of the fields pipeline. If those properties don't exist in your deployment, the payload fallback would instead produce a payload ILIKE '%...%' that hunts the same string in the event's raw text.

Common pitfalls that break the conversion

Even with the right backend and pipeline, several things derail a QRadar conversion:

• DSM that doesn't extract the property, if your log source never parsed Process CommandLine, the fields pipeline has nothing to target and you fall back to payload. Confirm your custom properties are defined and active.
• Cost of ILIKE on payload, an ILIKE '%...%' over unindexed payload, multiplied by thousands of rules and millions of events, is expensive on Ariel CPU. At scale it's the leading cause of a sluggish console.
• Mandatory time range, AQL requires a time window. A query without LAST X MINUTES (or START ... STOP ...) will scan all history or fail. Add LAST 15 MINUTES for a test search.
• Non-standard Sigma fields, an off-spec field, an in-house extension the pipeline doesn't know, won't be mapped and can break pySigma parsing. Stick to the official Sigma taxonomy.
• correlation rules, Sigma correlation rules (aggregation, temporal) aren't covered the same way across all backends. Check support before you rely on them.

The common thread: these pitfalls don't always raise an error. They produce a rule that looks like it works but either matches nothing or scans too much. Test every converted rule against real data, not just that it compiles.

Maintaining this at scale

Converting one rule by hand is doable. Converting 3,000 (and re-converting them every time the Sigma repository updates) is not. The public Sigma corpus changes constantly, the QRadar backend has to be re-pinned on every pySigma bump, and your set of QRadar properties evolves too.

At scale you treat conversion as code: a versioned Sigma source, a pinned and reproducible pySigma/QRadar environment, automated re-conversion on every upstream update, and a test suite that replays each AQL query against known logs. Doing the double work by hand (conversion and backend pinning on every update) is simply unsustainable.

If you'd rather not maintain that pipeline yourself, the ThreatClaw detection feed publishes signed Sigma rules, delivered already converted for QRadar (AQL, mapped properties with a payload fallback). You get ready-to-load AQL, re-tested on every update, instead of re-running a fragile backend over thousands of files.

FAQ

QRadar properties or payload search: which should I use?

Prefer properties (QRadarAQL_fields): queries hit normalized columns, so they're fast and precise. Reserve payload (QRadarAQL_payload) for fields your DSM doesn't extract, keeping in mind that ILIKE on raw payload is more expensive. In practice you combine both: fields by default, payload as a safety net for whatever isn't normalized.

Which QRadar and pySigma versions do I need?

On the QRadar side, any version with AQL and the events table can run the generated queries; what matters is that your DSMs extract the properties the rules target. On the pySigma side, the pysigma-backend-qradar-aql backend is version-sensitive: pin pySigma and the backend in a dedicated environment rather than tracking the latest release, otherwise a broken import can block the whole conversion.

Can I convert to multiple SIEMs from the same Sigma source?

Yes, that's the whole point of Sigma. The same YAML rule compiles to AQL (QRadar), SPL (Splunk), KQL (Sentinel), or Lucene/EQL (Elastic) by swapping the pySigma backend and pipeline. Field mapping stays target-specific, though: a rule validated for QRadar properties must be re-tested against each other SIEM's schema.