Réduire les faux positifs YARA à l'échelle : tuning et performance en entreprise

Une règle YARA qui matche un vrai malware mais aussi trois applications légitimes n'est pas une demi-victoire : c'est un problème. À l'échelle d'un parc de milliers de machines, chaque faux positif se multiplie, noie l'analyste sous des alertes vides, et finit par éroder la confiance dans toutes vos détections. Le jour où l'équipe commence à ignorer les alertes YARA par réflexe, la règle la mieux écrite ne sert plus à rien.

Cet article traite les deux faces du même problème opérationnel : rendre vos règles précises (peu de faux positifs) et rapides (un scan de parc qui se termine). Les deux se travaillent, et se mesurent.

D'où viennent les faux positifs

Presque toujours de la même cause : une chaîne trop générique. Une règle qui cherche Microsoft, GetProcAddress, une URL de bibliothèque connue ou un fragment de code présent dans des milliers de binaires sains va se déclencher partout. Trois sources récurrentes :

• Les chaînes de bibliothèque et de compilateur : elles apparaissent dans tout ce qui est compilé avec la même toolchain.
• Les conditions trop lâches : 1 of ($s*) sur des motifs peu discriminants suffit à matcher du bénin.
• Les chaînes courtes : plus une chaîne est courte, plus elle a de chances d'apparaître par hasard dans un fichier légitime.

On ne corrige que ce qu'on mesure : le corpus bénin

Impossible de tuner à l'aveugle. La première brique est un corpus bénin (goodware) : vos binaires système, vos applications métier, les runtimes courants. Passer une règle sur ce corpus donne le seul chiffre qui compte vraiment : combien de fois elle se déclenche sur du sain. Un seul déclenchement est un faux positif à corriger avant tout déploiement.

# taux de faux positifs d'une règle sur le corpus bénin
yara -r mes_regles.yar /chemin/corpus-benin/ | wc -l

Ce corpus se maintient dans le temps : on y ajoute les logiciels qui ont généré des faux positifs en production, pour qu'une régression soit rattrapée avant la prochaine mise en production. C'est exactement le test que la plupart des règles publiques n'ont jamais subi, et c'est ce qui sépare un jeu de règles fiable d'un dépôt brut.

Corriger : rendre la règle plus précise

Une fois les faux positifs identifiés, quelques leviers :

• Remplacer le générique par le distinctif. À la place d'une chaîne de bibliothèque, cherchez ce qui est propre à la famille : un marqueur interne, un chemin PDB de compilation, un mutex, un message d'erreur inhabituel.
• Ancrer par la structure. filesize < 500KB, uint16(0) == 0x5A4D (en-tête PE), ou l'imphash réduisent le champ avant même de tester les chaînes. Un ancrage structurel fort rend la règle à la fois précise et résistante aux variantes.
• Relever le quorum. Passer de 1 of à 2 of ($s*) exige la présence conjointe de plusieurs marqueurs distinctifs, ce qui coupe la plupart des faux positifs sans perdre la famille.
• Exclure explicitement. Une condition négative (and not $chaine_legitime_connue) retire un logiciel sain récurrent qui matcherait malgré tout.
• Cadrer les chaînes. fullword évite de matcher un fragment au milieu d'un mot ; ascii/wide doivent correspondre à l'encodage réel de la cible, sinon la règle ne matche rien (faux négatif silencieux) ou matche mal.

Accélérer : la performance sur un grand parc

Une règle correcte mais lente peut faire dérailler un scan de parc entier. YARA construit des atomes (courtes séquences d'octets) pour présélectionner les fichiers à examiner en détail. Des atomes de mauvaise qualité forcent le moteur à ouvrir bien plus de fichiers que nécessaire.

• Préférez les chaînes littérales longues aux expressions régulières : elles produisent de meilleurs atomes. Une chaîne de 8 octets uniques filtre bien mieux qu'une regex ouverte.
• Évitez les regex non ancrées et les atomes trop courts : /.*payload.*/ ou une chaîne de 2-3 octets forcent un examen quasi systématique.
• Attention au nocase sur de longues chaînes et aux jokers en début de motif, coûteux à l'exécution.
• Bornez le scan : plafond de taille de fichier, chemins ciblés plutôt que le disque entier.

Un linter comme yaraQA (F. Roth) automatise une partie de ce contrôle : il repère les règles qui ne peuvent jamais matcher et les motifs ruineux en performance. À intégrer dans votre chaîne, au même titre que la compilation.

Gouverner : un cycle de vie des règles

Le tuning n'est pas un acte unique. À l'échelle, il faut une gouvernance :

• Un score de confiance par règle (testée sur corpus bénin et malveillant, ou non testée) attaché au jeu de règles.
• Retirer les règles qui produisent des faux positifs à répétition en production plutôt que de les rafistoler indéfiniment.
• Versionner les règles comme du code, pour tracer chaque modification et revenir en arrière si une correction dégrade la couverture.

En résumé

Réduire les faux positifs YARA, c'est une discipline mesurable, pas une intuition : mesurer sur un corpus bénin, corriger en remplaçant le générique par le distinctif et en ancrant par la structure, accélérer avec de bons atomes et un linter, puis gouverner le cycle de vie. Une règle qui a passé ces étapes vaut infiniment plus qu'une règle qui « compile ».

C'est précisément la promesse difficile que porte le feed YARA de ThreatClaw : des règles validées sur le moteur réel, rétro-matchées sur leurs échantillons et testées contre un corpus bénin pour tenir un engagement que peu de feeds osent afficher, peu de faux positifs, prouvés. C'est ce qu'un simple dépôt de règles ne peut pas garantir.