Détection prouvée, pas des règles ramassées : ce qui distingue le feed ThreatClaw

La règle est devenue une commodité

Il n'a jamais été aussi facile de récupérer des règles de détection. Les dépôts publics en comptent des dizaines de milliers, et une poignée d'acteurs se contentent de les reconditionner et de les revendre. Le résultat est prévisible : des catalogues qui se ressemblent tous, gonflés au nombre de règles, dont personne ne peut vous dire si elles se déclenchent réellement, si elles noient vos analystes sous les faux positifs, ni quoi faire quand l'une d'elles sonne à trois heures du matin.

Chez ThreatClaw, nous partons du principe inverse : la règle n'est pas le produit, la détection prouvée l'est. Une règle n'a de valeur que si elle est vérifiée, propre, et accompagnée de ce qu'il faut pour agir. Voici, concrètement, ce que traverse chaque règle avant d'atterrir dans votre feed.

1. Testées sur un vrai moteur, pas sur un vérificateur de syntaxe

La plupart des catalogues valident leurs règles avec un simple linter : la syntaxe est correcte, donc « ça passe ». Cela ne prouve rien. Une règle syntaxiquement valide peut très bien ne jamais compiler dans le moteur qui l'exécutera.

Chaque règle de notre chaîne passe le moteur réel correspondant à son format, en conditions de rejet : compilation YARA, suricata -T pour le réseau, falco --validate pour le runtime, validation nuclei pour les templates, moteur OPA pour la conformité. Une règle qui ne s'exécute pas ne part pas. C'est une barrière bloquante, pas un avertissement que l'on ignore.

Ce point paraît évident. Il ne l'est pas : une règle qui échoue silencieusement à se charger est pire qu'une absence de règle, parce qu'elle vous donne un faux sentiment de couverture.

2. Faux positifs prouvés à zéro, pas « faibles »

Une règle bruyante finit désactivée, et une règle désactivée ne protège personne. Le vrai coût d'une détection, ce n'est pas de la manquer, c'est de crier au loup jusqu'à ce que l'équipe cesse d'écouter.

Nos règles sont donc confrontées à un corpus de 5 694 binaires légitimes et signés, exécutables Windows, ELF Linux, applications macOS, pilotes, avant publication. Le seuil n'est pas « peu de faux positifs » : c'est zéro faux positif sur ce corpus, sinon la règle est retravaillée ou écartée. Ce corpus inclut délibérément macOS et les pilotes, les angles morts classiques qui laissent filer les fausses alertes.

3. Dédupliquées, licences vérifiées, pack signé

Le nombre de règles ne veut rien dire s'il est gonflé par des doublons. Notre chaîne déduplique avant publication : ce que vous chargez, c'est de la couverture nette, pas du remplissage.

Chaque source est passée au crible de sa licence, nous savons ce que nous avons le droit de redistribuer, et ce qui relève de notre travail maison sous notre propre licence. Enfin, chaque livraison est signée cryptographiquement (Ed25519) : votre agent vérifie la signature du manifeste avant d'appliquer quoi que ce soit. Une chaîne d'approvisionnement de détection doit être aussi sérieuse que celle de vos logiciels.

4. Le point qu'aucun agrégateur n'offre : un playbook d'investigation par règle

Une alerte brute pose plus de questions qu'elle n'en résout. Est-ce un vrai incident ? D'où vient-il ? Jusqu'où s'étend-il ? Comment l'écarter s'il est bénin ?

Chaque règle de nos packs Sigma et YARA est livrée avec un playbook d'investigation au standard CACAO 2.0 (OASIS) : confirmer l'alerte, pivoter vers l'origine et le contexte, cadrer la portée sur le parc, écarter les faux positifs connus, orienter la réponse. Ces étapes ne sont pas rédigées par une IA, elles sont générées de façon déterministe à partir des faits que porte la règle elle-même (technique ATT&CK, source de log, champs de détection, référentiel MITRE D3FEND). C'est un choix : la recherche a montré que les modèles de langage inventent des actions de remédiation plausibles et dangereuses. Un playbook qui dit à un analyste d'isoler un hôte doit être exact.

Et surtout, ces playbooks sont reliés entre nos moteurs. C'est là notre vraie différence.

Le moat : une détection qui en corrobore d'autres, sur tous nos moteurs

Une menace ne se manifeste jamais sur un seul plan. Un même comportement laisse une trace dans le SIEM, une signature dans un fichier, un motif sur le réseau, un état sur l'hôte. Un agrégateur qui ne vend qu'un seul type de règle ne peut pas relier ces traces. Nous, si, parce que nous possédons tous les moteurs, mappés sur une taxonomie commune (MITRE ATT&CK).

Concrètement : quand une règle Sigma se déclenche, son playbook vous indique nos autres détections qui couvrent la même technique, la règle YARA sur le fichier associé, la signature réseau Suricata, la requête osquery, l'artefact Velociraptor. Vous ne partez pas d'une alerte isolée : vous partez d'un faisceau, et vous savez immédiatement quoi lancer d'autre pour confirmer et élargir. Plus de huit règles Sigma sur dix de nos packs, feed SIEM comme règles embarquées dans l'agent, pointent ainsi vers au moins un autre de nos moteurs.

Aucun catalogue de règles ne peut faire cela, pour une raison simple : il faut d'abord posséder les huit moteurs (Sigma, YARA, Suricata, nuclei, Falco, OPA, osquery, Velociraptor) et les avoir tous alignés sur la même carte des techniques adverses. C'est le travail de fond de ThreatClaw.

Ce que cela veut dire pour vous

Nous ne vous vendons pas un tas de règles. Nous vous livrons de la détection sur laquelle vous pouvez vous appuyer : vérifiée sur moteur réel, prouvée sans faux positif, dédupliquée, sous licence claire, signée, et accompagnée du plan d'action qui transforme une alerte en investigation menée.

C'est la différence entre acheter une liste et acheter une capacité. Le feed de règles ThreatClaw est pensé pour la seconde.