YARA vs Sigma : quelle règle de détection choisir ?

Les rapports de menace se terminent souvent par « déployez une règle YARA » ou « ajoutez une détection Sigma ». Ces formats sont complémentaires. YARA demande si un contenu correspond à un motif. Sigma demande si des événements enregistrés décrivent un comportement.

Le choix part des données disponibles et de la décision attendue.

YARA en une phrase

YARA examine chaînes, octets, structure de fichier, métadonnées et conditions. La documentation officielle YARA décrit cette syntaxe.

Utilisez YARA pour :

• trier des échantillons ;
• scanner fichiers et mémoire ;
• identifier code ou configuration d’une famille ;
• chasser dans des dépôts forensiques ;
• repérer du contenu packé ou embarqué.

YARA retrouve une famille après un changement de hash, mais des chaînes larges ou expressions coûteuses créent bruit et surcharge.

Sigma en une phrase

Sigma décrit en YAML des événements suspects avec source de logs, sélections et conditions. La documentation des règles Sigma montre la conversion vers différents SIEM.

Utilisez Sigma pour :

• processus, authentification et audit cloud ;
• PowerShell et lignes de commande ;
• persistance et privilèges ;
• journaux réseau et DNS ;
• corrélation identité-endpoint.

La portabilité dépend du mapping et de la collecte. Une règle parfaite ne détecte pas un événement jamais journalisé.

Décider en pratique

Choisissez YARA si la preuve primaire est un fichier, une zone mémoire ou un objet binaire. Choisissez Sigma pour une séquence, une valeur de champ ou un comportement dans les logs. Utilisez les deux lorsque contenu et exécution se confirment.

Exemple : un loader contient un marqueur stable de configuration chiffrée. YARA trouve le fichier. Après exécution, il lance un interpréteur, crée une persistance et contacte un domaine récent. Sigma détecte cette chaîne. La réputation du fichier, du domaine et de l’IP relie les alertes à une campagne.

Transformer la CTI en règles

Commencez par une hypothèse :

• quel contenu ou comportement est distinctif ?
• quel logiciel bénin peut le partager ?
• quelle télémétrie porte la preuve ?
• combien de temps restera-t-elle utile ?

Pour YARA, préférez plusieurs attributs modérément stables à une chaîne courante. Pour Sigma, identifiez la source et les champs avant la sélection. Joignez références, auteur, date, statut et faux positifs.

Ne copiez pas simplement des IOC dans une règle. Domaines et hashes expirent ; gérez-les comme listes gouvernées sauf si la règle exprime un motif durable.

Tests et mise en production

Testez YARA sur des échantillons confirmés et un vaste corpus sain représentatif. Mesurez temps et mémoire. Testez Sigma sur des événements positifs sauvegardés et les logs normaux de chaque backend.

Appliquez un cycle :

1. règle expérimentale en périmètre limité ;
2. revue analyste ;
3. tuning et exceptions ;
4. diffusion ;
5. validation et retrait périodiques.

Versionnez, imposez la revue par pair et reliez chaque changement à une enquête.

Échecs fréquents

• chaînes YARA publiques sans vérification des bibliothèques communes ;
• champs Sigma absents ou normalisés autrement ;
• sévérité critique sans preuve de précision ;
• absence de propriétaire, expiration ou corpus de test ;
• règles maintenues après la campagne ;
• conversion backend jamais relue.

Exploiter les deux comme un produit

Reliez les matches YARA aux processus, connexions et comptes. Reliez les alertes Sigma aux fichiers et à la mémoire collectés. Enrichissez les IOC par recherche de réputation en masse, puis injectez les confirmations dans le tuning.

Mesurez précision, délai de déploiement, couverture, coût et incidents où un format confirme l’autre.

Conclusion

YARA reconnaît le contenu ; Sigma reconnaît le comportement journalisé. Le bon choix suit la preuve. Utilisez-les dans un workflow de detection engineering revu, où la threat intelligence apporte le contexte et les incidents le contrôle qualité.