Qu'est-ce que Sigma, et comment transformeriez-vous un résultat de hunt en règle de détection portable ?

Sigma est aux détections ce que YARA est aux fichiers : une manière portable et lisible par l'humain d'exprimer à quoi ressemble une activité malveillante dans les logs, indépendamment de tout SIEM particulier. Vous écrivez la logique une fois et la convertissez dans le langage de requête que parle votre stack.

Anatomie d'une règle

Une règle Sigma est du YAML avec quelques sections clés :

• Métadonnées — title, id, status, level (informational → critical), description, author, tags (souvent des identifiants de technique ATT&CK comme attack.t1059).
• logsource — où chercher : category (par exemple process_creation), product (par exemple windows), éventuellement service.
• detection — une ou plusieurs sélections nommées de correspondances champ/valeur, plus une condition qui les combine logiquement.
• falsepositives et fields — des indications pour l'analyste qui trie un déclenchement.

Du hunt à la règle

Lorsqu'un hunt fait remonter une technique réelle, codifiez-la. Disons que vous avez trouvé un usage malveillant de rundll32.exe chargé depuis un chemin temporaire : écrivez une sélection correspondant à Image se terminant par rundll32.exe et CommandLine contenant le motif de chemin temporaire, puis une condition. Étiquetez-la avec la technique ATT&CK pour que la couverture soit traçable.

La garder précise

Une règle qui correspond trop largement enterre le SOC sous les faux positifs et finit désactivée. Ancrez-vous sur des champs spécifiques à l'attaquant, excluez les parents connus comme légitimes, fixez un level sensé et documentez les faux positifs attendus pour que les analystes sachent ce qui est normal.

Pourquoi c'est important

Les recruteurs veulent une logique de detection-as-code : des règles portables, versionnées et mappées sur ATT&CK — pas des recherches en pointer-cliquer qui ne vivent que dans une seule console et dans la tête d'une seule personne.