Convertir des règles Sigma vers Splunk (SPL) : le guide pratique

Vous avez une belle bibliothèque de règles Sigma, un SIEM Splunk en production, et pourtant rien ne se déclenche. Le problème n'est presque jamais la règle : c'est la conversion. Splunk ne lit pas le Sigma nativement, et une conversion bâclée produit des requêtes SPL qui cherchent des champs qui n'existent pas dans votre index. Voici comment faire ça proprement.

Sigma, c'est quoi et pourquoi Splunk 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, Lucene/EQL pour Elastic, 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 Splunk ne sait pas quoi en faire : son moteur attend du SPL. Il faut donc compiler la règle Sigma en une requête SPL exécutable. C'est le rôle de pySigma.

Convertir avec pySigma et le backend Splunk

pySigma est la bibliothèque de référence (elle remplace l'ancien sigmac). La conversion vers Splunk repose sur deux composants :

• pysigma-backend-splunk, le SplunkBackend, qui génère la syntaxe SPL.
• Un pipeline de traitement, ici splunk_windows, qui mappe les champs Sigma vers le schéma CIM (Common Information Model) de Splunk.

Installation et conversion en ligne de commande :

pip install sigma-cli pysigma-backend-splunk
 
sigma convert -t splunk -p splunk_windows regle.yml

Le flag -t splunk sélectionne le backend, -p splunk_windows applique le pipeline. Sans le pipeline, vous obtenez une requête syntaxiquement valide mais sémantiquement fausse, on y revient tout de suite, car c'est le piège numéro un.

Le vrai problème : le field mapping

C'est ici que 90 % des conversions échouent silencieusement. Une règle Sigma parle en champs Sigma abstraits : Image, CommandLine, ParentImage. Ces noms n'existent pas tels quels dans Splunk. Vos données sont indexées selon un schéma (souvent le CIM, le modèle de données Endpoint.Processes) où les champs s'appellent Processes.process_path, Processes.process, Processes.parent_process.

Sans pipeline, sigma convert produit une requête qui cherche littéralement un champ Image :

Image="*\\powershell.exe" CommandLine IN ("*-enc*", "*-EncodedCommand*")

Si vos données Sysmon sont normalisées CIM, il n'y a aucun champ nommé Image dans l'index. La requête s'exécute, ne lève aucune erreur, et retourne zéro résultat. Vous croyez être couvert ; vous ne l'êtes pas. C'est le piège des règles converties « brutes » : elles sont vertes dans votre catalogue et aveugles en production.

Le pipeline splunk_windows résout ce mapping. Il traduit Image vers le champ réel, ajoute la contrainte de logsource (le bon sourcetype / data model), et gère les particularités du CIM. La requête devient exploitable contre vos données réelles.

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

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

Image="*\\powershell.exe" CommandLine IN ("*-enc*", "*-EncodedCommand*")

Notez la mécanique : endswith devient un wildcard *\powershell.exe, la liste contains devient un IN (...) avec des wildcards des deux côtés. Avec le pipeline CIM, Image et CommandLine sont remplacés par leurs équivalents indexés (Processes.process_path, Processes.process) et la requête est préfixée par le tstats / datamodel approprié. Sans pipeline, vous gardez Image et CommandLine bruts, syntaxe correcte, résultat nul.

Pièges courants qui cassent la conversion

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

• Tags Sigma non standard, un champ hors spécification (une extension maison, un custom.field) que le pipeline ne connaît pas ne sera pas mappé, ou fera échouer le parsing. Alignez-vous sur la taxonomie Sigma officielle.
• Règles correlation, les règles de corrélation Sigma (agrégation, temporelle) ne sont pas supportées par tous les backends. Vérifiez la couverture avant de compter dessus, sinon la conversion échoue ou produit du SPL partiel.
• Backticks et caractères spéciaux, un backtick dans une valeur peut casser la requête SPL générée. Attention aussi aux caractères qui ont un sens dans SPL.
• Escaping des backslashes Windows, les chemins Windows (\Device\, C:\Windows\) exigent un double échappement. Une seule contre-oblique mal échappée et le wildcard ne matche plus rien. C'est une source classique de règles « vertes mais mortes ».

Le point commun de tous ces pièges : ils ne lèvent pas forcément d'erreur. Ils produisent une règle qui semble fonctionner. Il faut donc tester chaque règle convertie contre des données réelles ou des logs de test, 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, les backends pySigma changent, et votre schéma d'indexation aussi.

À l'échelle, il faut traiter la conversion comme du code :

• Un pipeline versionné : la source Sigma, le pipeline de mapping et le SPL généré sont tous dans Git.
• Une re-conversion automatisée à chaque mise à jour amont, pas un export manuel ponctuel.
• Une suite de tests qui rejoue chaque règle contre des logs connus pour attraper les régressions de field mapping avant la production.

Sans ça, votre catalogue diverge silencieusement de la réalité : des règles restent au format Sigma jamais compilées, d'autres pointent vers un champ CIM renommé il y a six mois.

Si vous ne voulez pas maintenir ce pipeline vous-même, le flux de règles ThreatClaw publie des règles Sigma et YARA signées, livrées déjà converties pour Splunk (SPL/CIM), Sentinel, Elastic et QRadar. Vous récupérez le SPL prêt à charger, re-testé à chaque mise à jour, au lieu de rejouer pySigma sur des milliers de fichiers.

FAQ

pySigma supporte-t-il tous les champs Splunk ?

Non, et c'est la nuance clé. pySigma génère du SPL correct, mais le mapping des champs dépend entièrement du pipeline choisi. Le pipeline splunk_windows couvre le CIM pour les logs Windows courants (process creation, réseau, authentification). Un champ Sigma sans équivalent dans le pipeline ne sera pas mappé, il faut alors étendre le pipeline ou ajouter un mapping personnalisé. Aucun backend ne « devine » votre schéma d'indexation à votre place.

Faut-il Splunk Enterprise Security (ES) ?

Pas pour exécuter une requête SPL convertie, un Splunk de base suffit à lancer la recherche. En revanche, le pipeline CIM suppose que vos données sont normalisées selon les data models CIM, ce qui est justement le terrain d'ES et de l'app Common Information Model. Sans normalisation CIM, adaptez le pipeline à vos propres noms de champs, ou vos règles chercheront des champs absents.

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 SPL (Splunk), KQL (Sentinel), Lucene/EQL (Elastic) ou AQL (QRadar) en changeant simplement de backend et de pipeline pySigma. Le field mapping reste toutefois spécifique à chaque cible : une règle validée pour Splunk CIM doit être re-testée contre le schéma de chaque autre SIEM.