Convertir des règles Sigma vers Microsoft Sentinel (KQL) : le guide pratique

Sigma est devenu le format universel d'écriture de règles de détection. Le problème : Microsoft Sentinel et Defender XDR ne comprennent pas le YAML Sigma. Ils parlent KQL, Kusto Query Language. Entre les deux, il faut convertir. Et cette conversion est bien plus subtile qu'un simple sigma convert.

Ce guide explique comment faire proprement, quelles sont les deux cibles possibles, et pourquoi le choix du pipeline change radicalement le taux de règles réellement exploitables.

Sigma est générique, KQL ne l'est pas

Une règle Sigma décrit une logique de détection de façon abstraite : un champ Image qui se termine par powershell.exe, un CommandLine qui contient -enc. Sigma ne sait pas dans quelle table ces champs vivent, c'est justement son intérêt, être portable entre SIEM.

KQL, lui, interroge des tables concrètes avec des colonnes concrètes. Image n'existe pas dans Sentinel : selon le contexte, la donnée s'appelle FolderPath, ProcessCommandLine, InitiatingProcessCommandLine… Convertir Sigma vers KQL, ce n'est donc pas traduire une syntaxe, c'est remapper un modèle de données.

pySigma et le backend Kusto

L'outil de référence est pySigma, la réécriture moderne de l'ancien sigmac. La conversion vers KQL passe par le backend pysigma-backend-kusto (KustoBackend).

pip install pysigma pysigma-backend-kusto
sigma convert -t kusto -p microsoft_xdr regle.yml

Le point crucial, souvent mal compris, c'est le -p : le pipeline de traitement. C'est lui qui applique le field mapping et cible la bonne table. Sans pipeline, la KQL générée cherche des colonnes qui n'existent pas, et la règle ne remonte jamais rien.

Deux cibles : microsoft_xdr vs sentinel_asim

Le backend Kusto expose deux pipelines qui ne visent pas le même schéma :

• microsoft_xdr, cible les tables Advanced Hunting de Defender XDR : DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents…
• sentinel_asim, cible le schéma ASIM (Advanced Security Information Model), la couche normalisée de Sentinel : imProcessCreate, imNetworkSession, etc.

Le compromis est concret et il faut le connaître. Le pipeline Defender XDR couvre bien mieux les champs des logs endpoint : pour les règles de type process creation, la couverture de champs tourne autour de ~98 %, contre ~52 % pour l'ASIM. Autrement dit, pour de la détection endpoint (création de processus, ligne de commande, hash, arbre parent/enfant), on cible presque toujours microsoft_xdr. L'ASIM brille davantage sur les schémas réseau, authentification et DNS normalisés, multi-sources, mais laisse tomber une bonne partie des champs endpoint fins que Sigma exploite.

Règle simple : détection endpoint → microsoft_xdr. Corrélation multi-source normalisée → sentinel_asim.

Le field mapping, concrètement

Prenons une règle Sigma classique. Ses champs Image et CommandLine doivent devenir, dans DeviceProcessEvents :

• Image → FolderPath
• CommandLine → ProcessCommandLine
• ParentImage → InitiatingProcessFolderPath
• User → AccountName

C'est exactement ce que fait le pipeline microsoft_xdr. Sans lui, sigma convert produirait une requête sur des colonnes Image/CommandLine absentes du schéma Defender, techniquement valide, fonctionnellement morte.

Avant / après

Une règle Sigma détectant PowerShell lancé avec une commande encodée (-EncodedCommand / -enc), une fois passée par sigma convert -t kusto -p microsoft_xdr, donne une KQL de la forme :

DeviceProcessEvents
| where FolderPath endswith "\\powershell.exe"
| where ProcessCommandLine has_any ("-enc","-EncodedCommand")

On retrouve bien la table Advanced Hunting, les colonnes remappées, et les opérateurs KQL (endswith, has_any). C'est ça, une règle prête à coller dans une requête de chasse ou une analytics rule.

Les pièges qui font perdre des heures

Advanced Hunting n'est pas Sentinel Analytics. Les tables DeviceProcessEvents & co. vivent dans Defender XDR (Advanced Hunting). Une instance Sentinel « classique » qui ingère du Sysmon via l'agent AMA travaille, elle, sur SecurityEvent, Event, Sysmon… Ce ne sont pas les mêmes colonnes. Choisir le mauvais pipeline pour la mauvaise plateforme est l'erreur numéro un. Si vos tables Device* sont exportées vers un workspace Sentinel connecté à Defender, microsoft_xdr reste le bon choix ; sinon, adaptez.

Les opérateurs KQL ont un coût. has s'appuie sur l'indexation par termes et reste rapide ; contains fait une recherche de sous-chaîne bien plus coûteuse ; matches regex est le plus lourd. pySigma choisit l'opérateur selon la sémantique Sigma, mais une règle truffée de wildcards en milieu de chaîne génère du contains/matches regex qui peut plomber une requête à l'échelle de milliers d'endpoints.

Les tags Sigma non standard cassent le parsing. Un champ modificateur exotique, un condition alambiqué ou un backend feature non supporté fait échouer pySigma avec un SigmaFeatureNotSupportedByBackendError. Il faut alors nettoyer ou adapter la règle.

Les règles de corrélation. Les correlation Sigma (compte d'événements, chaînes temporelles) ne se traduisent pas toutes proprement en KQL ; certaines demandent une réécriture manuelle en summarize / join.

À l'échelle, la conversion manuelle ne tient pas

Convertir trois règles à la main, c'est une après-midi. Maintenir un socle de 3 000+ règles Sigma en est une autre : chaque mise à jour du dépôt de règles upstream implique de reconvertir, revérifier le pipeline, retester les colonnes, contrôler le coût des opérateurs et repérer les règles cassées par un modificateur non supporté. Fait à la main, à chaque cycle, c'est intenable, et c'est là que la couverture de détection se dégrade silencieusement.

C'est précisément le problème que résout le flux de règles ThreatClaw : les règles Sigma sont livrées déjà converties en KQL ciblant le schéma Defender XDR Advanced Hunting, reconverties et revalidées à chaque mise à jour du corpus. Vous récupérez du KQL prêt à l'emploi plutôt qu'un pipeline pySigma à maintenir vous-même. Détails sur le flux de règles de détection.

FAQ

microsoft_xdr ou sentinel_asim, lequel choisir ? Pour de la détection endpoint (processus, ligne de commande, fichiers, registre), microsoft_xdr : sa couverture de champs endpoint (~98 % des règles process) écrase celle de l'ASIM (~52 %). Réservez sentinel_asim aux détections réseau/authentification normalisées et multi-sources.

Ça marche avec Sentinel « classique » ou seulement Defender XDR ? Le pipeline microsoft_xdr vise les tables Advanced Hunting (Device*). Elles sont natives dans Defender XDR et disponibles dans un workspace Sentinel connecté à Defender. Un Sentinel qui n'ingère que du Sysmon via AMA travaille sur SecurityEvent/Event : il faut alors un pipeline adapté à ces tables, pas microsoft_xdr.

Pourquoi ma règle convertie ne remonte-t-elle rien ? Presque toujours parce qu'aucun pipeline -p n'a été passé : la KQL interroge des colonnes Sigma (Image, CommandLine) inexistantes dans le schéma cible. Ajoutez le bon pipeline et vérifiez le field mapping.