Convertir des règles Sigma vers IBM QRadar (AQL) : le guide pratique

Vous avez une bibliothèque de règles Sigma, un IBM QRadar en production, et vous voudriez brancher l'un sur l'autre. Le problème : QRadar ne lit pas le Sigma. Il interroge ses événements via AQL (Ariel Query Language) et il faut donc compiler chaque règle Sigma en AQL. Fait proprement, on obtient des requêtes performantes ; fait à la va-vite, on obtient des requêtes qui scannent tout le payload brut et écroulent la console. Voici comment s'y prendre.

Sigma, c'est quoi et pourquoi QRadar ne le lit pas

Sigma est un format générique de règle de détection, écrit en YAML. L'idée : décrire une détection une seule fois, indépendamment du SIEM, puis la compiler vers le langage de requête cible, SPL pour Splunk, KQL pour Sentinel, AQL pour QRadar.

Une règle Sigma ressemble à ça :

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

C'est lisible, portable, versionnable dans Git. Mais QRadar ne sait pas quoi en faire : son moteur Ariel attend de l'AQL, du SQL-like qui interroge la table events (ou flows). Il faut donc compiler la règle Sigma en une requête AQL exécutable. C'est le rôle de pySigma.

Convertir avec pySigma et le backend QRadar

pySigma est la bibliothèque de référence (elle remplace l'ancien sigmac). La conversion vers QRadar repose sur le backend pysigma-backend-qradar-aql (le QRadarAQLBackend) accompagné de deux pipelines de traitement, et c'est le point vraiment important :

• QRadarAQL_fields, mappe les champs Sigma vers les propriétés normalisées de QRadar (les properties de la console). La requête interroge des colonnes indexées : c'est rapide et précis, mais ça ne couvre que les propriétés effectivement mappées et extraites par votre DSM.
• QRadarAQL_payload, le fallback. Quand un champ n'est pas normalisé, il recherche dans le payload brut (le texte UTF8 de l'événement). Ça couvre tout, mais ça scanne du texte non indexé : plus lent, plus coûteux à grande échelle.

Installation et conversion en ligne de commande :

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

Le flag -t qradar-aql sélectionne le backend, -p QRadarAQL_fields applique le pipeline « champs ». Le choix du pipeline n'est pas un détail cosmétique : il détermine si votre règle interroge des propriétés propres ou ratisse le payload entier.

Un mot honnête sur la compatibilité

À signaler franchement : le backend QRadar traîne des soucis de compatibilité avec les versions récentes de pySigma, imports cassés, API de pipeline qui a bougé. En pratique, on l'isole dans un environnement Python dédié avec des versions épinglées (pip freeze figé, ou un venv reproductible) plutôt que de le laisser suivre la dernière version de pySigma. Ce n'est pas un défaut rédhibitoire, c'est une contrainte d'exploitation à connaître avant de bâtir un pipeline dessus.

Le vrai problème : propriétés QRadar ou payload brut

C'est ici que se joue la qualité de la conversion. Une règle Sigma parle en champs abstraits : Image, CommandLine, ParentImage. Dans QRadar, ces concepts existent sous forme de propriétés (par exemple Process Path, Process CommandLine, Parent Process Path) à condition que votre DSM (Device Support Module) et vos custom properties les extraient réellement de l'événement.

Avec QRadarAQL_fields, pySigma tente de mapper Image vers la propriété Process Path. Si le mapping existe, la requête interroge une colonne propre. Si la propriété n'est pas extraite par votre log source, il n'y a rien à interroger, et c'est là qu'intervient QRadarAQL_payload, qui retombe sur un ILIKE '%...%' dans le payload brut. La règle matche quand même, mais au prix d'un scan texte non indexé.

Le compromis est donc explicite : fields = performant mais partiel, payload = exhaustif mais lourd. Le bon réflexe est de privilégier fields et de ne basculer sur payload que pour les champs que votre DSM n'extrait pas.

Exemple complet : avant / après

Reprenons la règle PowerShell -EncodedCommand ci-dessus.

Sigma (source, portable) :

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

AQL généré (cible, exécutable) :

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

Notez la mécanique : endswith devient un ILIKE '%\powershell.exe', la liste contains devient un groupe OR de ILIKE '%...%'. Les noms entre guillemets doubles ("Process Path", "Process CommandLine") sont des propriétés QRadar, c'est le rendu du pipeline fields. Si ces propriétés n'existent pas dans votre déploiement, le fallback payload produirait à la place un payload ILIKE '%...%' qui cherche la même chaîne dans le texte brut de l'événement.

Pièges courants qui cassent la conversion

Même avec le bon backend et le bon pipeline, plusieurs choses font dérailler la conversion QRadar :

• DSM qui n'extrait pas la propriété, si votre log source n'a jamais parsé Process CommandLine, le pipeline fields n'a rien à cibler et vous retombez sur le payload. Vérifiez que vos custom properties sont bien définies et actives.
• Coût des ILIKE sur le payload, un ILIKE '%...%' sur du payload non indexé, multiplié par des milliers de règles et des millions d'événements, coûte cher en CPU Ariel. À grande échelle, c'est le premier facteur de lenteur de la console.
• Time range obligatoire, AQL exige une fenêtre temporelle. Une requête sans LAST X MINUTES (ou START ... STOP ...) part scanner tout l'historique, ou échoue. Pensez à ajouter LAST 15 MINUTES pour une recherche de test.
• Tags Sigma non standard, un champ hors spécification, une extension maison que le pipeline ne connaît pas, ne sera pas mappé et peut faire échouer le parsing pySigma. Alignez-vous sur la taxonomie Sigma officielle.
• Règles correlation, les règles de corrélation Sigma (agrégation, temporelle) ne sont pas couvertes de la même manière par tous les backends. Vérifiez la prise en charge avant de compter dessus.

Le point commun de ces pièges : ils ne lèvent pas toujours d'erreur. Ils produisent une règle qui semble fonctionner mais qui, soit ne matche rien, soit scanne trop. Il faut donc tester chaque règle convertie contre des données réelles, pas seulement vérifier qu'elle compile.

Maintenir ça à l'échelle

Convertir une règle à la main, c'est faisable. En convertir 3 000 (et les re-convertir à chaque mise à jour du référentiel Sigma) ne l'est pas. Le corpus Sigma public évolue en permanence, le backend QRadar doit être ré-épinglé à chaque changement de pySigma, et votre jeu de propriétés QRadar évolue aussi.

À l'échelle, il faut traiter la conversion comme du code : une source Sigma versionnée, un environnement pySigma/QRadar épinglé et reproductible, une re-conversion automatisée à chaque mise à jour amont, et une suite de tests qui rejoue chaque règle AQL contre des logs connus. Maintenir manuellement le double travail (conversion et pinning du backend à chaque MAJ) est tout simplement intenable.

Si vous ne voulez pas maintenir ce pipeline vous-même, le flux de règles ThreatClaw publie des règles Sigma signées, livrées déjà converties pour QRadar (AQL, propriétés mappées avec fallback payload). Vous récupérez l'AQL prêt à charger, re-testé à chaque mise à jour, au lieu de rejouer un backend fragile sur des milliers de fichiers.

FAQ

Propriétés QRadar ou recherche payload : que choisir ?

Privilégiez les propriétés (QRadarAQL_fields) : les requêtes interrogent des colonnes normalisées, donc rapides et précises. Réservez le payload (QRadarAQL_payload) aux champs que votre DSM n'extrait pas, en gardant en tête que le ILIKE sur payload brut est plus coûteux. En pratique, on combine les deux : fields par défaut, payload en filet de sécurité pour ce qui n'est pas normalisé.

Quelle version de QRadar et de pySigma faut-il ?

Côté QRadar, toute version disposant d'AQL et de la table events convient pour exécuter les requêtes générées ; l'important est que vos DSM extraient les propriétés que les règles ciblent. Côté pySigma, le backend pysigma-backend-qradar-aql est sensible aux versions : épinglez pySigma et le backend dans un environnement dédié plutôt que de suivre la dernière release, faute de quoi un import cassé peut bloquer toute la conversion.

Peut-on convertir vers plusieurs SIEM depuis la même source Sigma ?

Oui, c'est tout l'intérêt de Sigma. La même règle YAML se compile vers AQL (QRadar), SPL (Splunk), KQL (Sentinel) ou Lucene/EQL (Elastic) en changeant de backend et de pipeline pySigma. Le field mapping reste spécifique à chaque cible : une règle validée pour les propriétés QRadar doit être re-testée contre le schéma de chaque autre SIEM.