Convertir des règles Sigma vers Elastic (ECS, Lucene, ES|QL) : le guide pratique

Sigma s'est imposé comme le format pivot des règles de détection : un YAML lisible, indépendant du SIEM, que l'on peut partager sur GitHub et versionner comme du code. Mais une règle Sigma ne s'exécute nulle part telle quelle. Elastic ne « lit » pas du Sigma : il interroge des documents indexés via Lucene, EQL ou ES|QL, et ces documents suivent un schéma bien précis, l'Elastic Common Schema (ECS). Entre le YAML générique et une requête qui matche réellement vos logs, il y a une étape de conversion. Cet article détaille comment la faire proprement, et surtout où ça casse.

Pourquoi une conversion est nécessaire

Une règle Sigma décrit une logique de détection avec des noms de champs « logiques » : Image, CommandLine, ParentImage, TargetFilename… Ces noms viennent historiquement de Sysmon et des journaux d'événements Windows. Elastic, lui, ne stocke pas les événements sous ces noms. Que vous ingériez via Winlogbeat, via Elastic Agent (intégration Windows) ou via Beats, les documents sont normalisés en ECS : process.executable, process.command_line, process.parent.name, file.path, etc.

Résultat : si vous poussez une règle Sigma brute dans Kibana sans traduire ni les champs ni la syntaxe, rien ne matche. Les champs Image ou CommandLine n'existent tout simplement pas dans vos index. La conversion doit donc faire deux choses : traduire la syntaxe (Sigma → Lucene/DSL) et traduire le schéma (champs Sigma → champs ECS).

pySigma, le backend Elasticsearch et le pipeline ECS

L'outillage moderne s'appuie sur pySigma (le successeur du vieux sigmac) et sa CLI sigma. Deux briques entrent en jeu :

• Le backend pysigma-backend-elasticsearch, qui expose notamment le LuceneBackend. Il sait produire du Lucene (Kibana Query Language / requête DSL), la lingua franca de recherche d'Elastic. Le même écosystème permet aussi des sorties EQL ou des règles au format natif Elastic Security.
• Le pipeline de traitement ecs_windows, qui applique le mapping des champs Sigma vers ECS. C'est lui qui transforme Image en process.executable et CommandLine en process.command_line.

L'installation et la conversion tiennent en quelques commandes :

pip install pysigma pysigma-backend-elasticsearch pysigma-pipeline-sysmon
 
sigma convert -t lucene -p ecs_windows regle.yml

Le drapeau -t lucene choisit la cible (le backend), et -p ecs_windows applique le pipeline ECS. Sans -p, vous obtenez bien une requête syntaxiquement valide… mais avec les champs Sigma d'origine, donc inutilisable sur des index ECS. ECS est le schéma pivot d'Elastic : tout tourne autour de lui, et c'est le pipeline qui vous y amène.

Un exemple concret : AVANT / APRÈS

Prenons une règle Sigma classique qui détecte un PowerShell lancé avec une commande encodée (-EncodedCommand), technique très courante d'obfuscation.

La règle Sigma, côté source :

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

Après sigma convert -t lucene -p ecs_windows, on obtient une requête Lucene exprimée en champs ECS, prête pour Kibana :

process.executable:*\\powershell.exe AND (process.command_line:*-enc* OR process.command_line:*-EncodedCommand*)

Notez le passage de Image à process.executable et de CommandLine à process.command_line. C'est exactement le travail du pipeline ecs_windows. Sans lui, la requête aurait conservé Image: et CommandLine:, et n'aurait jamais rien remonté.

Les pièges qui vous attendent

La conversion « heureuse » ci-dessus cache plusieurs chausse-trapes bien réelles en production.

Winlogbeat vs Elastic Agent. Les deux collecteurs ne produisent pas toujours les mêmes champs. L'intégration Windows d'Elastic Agent et Winlogbeat divergent sur certains chemins ECS et sur la normalisation de certains événements. Une règle testée sous Winlogbeat peut silencieusement rater sous Elastic Agent, et inversement. Vérifiez toujours contre le collecteur réellement déployé.

Wildcards Lucene coûteux. Une requête avec un wildcard en tête (*-enc*) impose un leading wildcard, notoirement lourd pour le moteur : Elastic doit parcourir un large espace de termes. Multiplié par des milliers de règles et un gros volume, l'impact sur les performances est réel. Certaines organisations désactivent même les leading wildcards.

keyword vs text. Un champ mappé en text est analysé (tokenisé, mis en minuscules) ; un champ keyword ne l'est pas. Une recherche par sous-chaîne ou sensible à la casse se comporte différemment selon le mapping. Beaucoup de « faux négatifs » viennent d'une règle écrite pour du keyword exécutée contre un champ text (ou l'inverse). C'est l'une des causes les plus insidieuses d'échec silencieux.

Tags Sigma non standard. pySigma valide le YAML. Une règle communautaire avec des tags exotiques, une logsource bancale ou des modificateurs non supportés fera planter la conversion. À l'échelle d'un dépôt de plusieurs milliers de règles, ces cas cassants sont fréquents et doivent être filtrés ou corrigés.

Règles de corrélation. Sigma a introduit un format de corrélation (compteurs, temporal, seuils). Tous les backends ne le traduisent pas de la même façon vers Elastic, et une partie exige EQL ou des règles de seuil natives plutôt qu'un simple Lucene. Ne présumez pas qu'une règle de corrélation se convertit aussi proprement qu'une règle de détection simple.

Lucene brut ou règles natives Elastic Security ?

Deux stratégies coexistent. La première : importer du Lucene brut dans une règle de requête Kibana. Simple, mais vous perdez une partie du contexte (métadonnées, sévérité, mapping MITRE ATT&CK propre, gestion du cycle de vie de la règle).

La seconde : produire des Elastic Security Detection Rules, le format natif d'Elastic. C'est plus riche (la règle embarque son type de requête (Lucene, EQL, ES|QL, seuil), sa planification, sa sévérité et ses tags) mais cela demande un pipeline d'export/import plus élaboré. Pour un déploiement sérieux, le format natif est presque toujours le bon choix.

Le vrai mur : l'échelle

Convertir une règle, c'est cinq minutes. Convertir et maintenir un dépôt de plus de 3 000 règles Sigma, c'en est une autre. Chaque mise à jour du référentiel Sigma amont (nouvelles règles, champs renommés, corrections) impose de reconvertir, revalider et retester l'ensemble contre votre schéma ECS et votre collecteur. Filtrer les règles qui plantent, arbitrer keyword/text, surveiller les wildcards coûteux, gérer les divergences Winlogbeat/Elastic Agent : fait à la main, c'est intenable sur la durée. C'est précisément là que la plupart des équipes décrochent, et où les règles « converties une fois » pourrissent en silence.

Comment ThreatClaw simplifie ça

Le flux de détection ThreatClaw livre le corpus Sigma déjà converti pour Elastic, aligné sur ECS et retesté à chaque mise à jour amont. Vous récupérez des règles exploitables sans monter et maintenir votre propre chaîne pySigma. Le flux gère le filtrage des règles cassantes et le suivi des évolutions du référentiel Sigma, pour que votre couverture reste à jour sans effort manuel. Découvrir le flux de règles →

FAQ

Lucene, EQL ou ES|QL : lequel choisir ?

Lucene (via KQL/DSL) est le plus universel et le plus simple à générer : idéal pour la majorité des règles de détection simples. EQL (Event Query Language) brille pour les séquences d'événements et la corrélation temporelle (ex. processus parent → enfant). ES|QL, le langage plus récent orienté requêtes et transformations, est puissant pour l'analyse et l'agrégation. En pratique : Lucene pour le gros du volume, EQL pour la corrélation, ES|QL pour l'exploration analytique.

Faut-il une licence Elastic Security payante ?

Pas obligatoirement. Vous pouvez exécuter des requêtes Lucene et créer des règles de détection dans les niveaux ouverts d'Elastic. Certaines fonctionnalités avancées (machine learning natif, RBAC fin, certaines intégrations) relèvent des abonnements payants, mais la conversion Sigma → Lucene/ECS et l'exécution des règles de base ne l'exigent pas.

Peut-on convertir sans pipeline ECS ?

Techniquement oui, mais la requête produite portera les champs Sigma d'origine (Image, CommandLine) qui n'existent pas dans des index ECS : elle ne matchera rien. Le pipeline (-p ecs_windows ou équivalent) est ce qui rend la règle réellement fonctionnelle sur des documents Elastic Agent, Beats ou Winlogbeat.