SIGIL — générateur de règles de détection

Le problème

Écrire une détection demande deux compétences distinctes : savoir ce qu’il faut chercher, et connaître la syntaxe de l’outil qui cherchera. La première s’acquiert sur le terrain. La seconde change à chaque outil — et un SOC en a rarement un seul.

Résultat courant : des équipes qui savent exactement quel comportement les inquiète, et qui perdent une demi-journée à le formuler en SPL, en KQL, en langage EDR, puis à retrouver où l’on crée une règle personnalisée dans chaque console.

Ce que fait l’outil

Vous écrivez : « un utilisateur non administrateur exécute PowerShell pour télécharger un exécutable depuis Internet ».

SIGIL renvoie, pour l’outil choisi :

1. La requête de recherche — à lancer tout de suite, pour savoir si c’est déjà arrivé.
2. La règle personnalisée — et la marche à suivre pour l’installer dans la console, afin que le comportement remonte désormais en alerte à chaque occurrence.
3. La règle Sigma de référence — format indépendant de l’éditeur, lisible et versionnable.
4. Les faux positifs attendus et la conduite à tenir. Une règle sans ça n’est pas une détection, c’est une notification.

Outils visés

SentinelOne, CrowdStrike, Splunk, Elastic (ELK), Microsoft Sentinel et Defender — et tout outil disposant d’un convertisseur pySigma.

Pourquoi Sigma au centre

Parce que la logique de détection survit à l’outil qui l’exécute. Quand le SIEM change — et il change — c’est le seul actif qu’on ne réécrit pas. La requête et la règle propres à chaque outil en sont dérivées.

État

En construction.