Choisir et exploiter un feed d'IOC : au-delà de la liste d'adresses qui bloque vos propres clients

Tout le monde propose un « threat feed ». Récupérer une liste brute d'adresses IP, de domaines et de hashs malveillants est trivial, et presque sans valeur. Le volume n'est pas de la sécurité : un feed de dix millions d'indicateurs périmés, non corrélés et truffés de faux positifs vous fera plus de mal que de bien le jour où vous le brancherez sur un pare-feu. Les deux vraies questions ne sont pas « où trouver un feed » mais « lequel choisir » et « comment l'exploiter sans me tirer une balle dans le pied ».

Cet article traite ces deux questions : les critères pour évaluer un feed, et la discipline pour l'opérer, parce qu'un feed d'IOC mal exploité est un incident en attente.

Pourquoi une liste brute est un piège

Trois manières dont un feed brut se retourne contre vous :

• Les indicateurs périmés. Une IP malveillante l'an dernier est peut-être aujourd'hui un routeur domestique réattribué, ou pire, un service légitime. Sans vieillissement, vous bloquez du trafic sain.
• Les faux positifs qui coupent. Une IP partagée de CDN ou de cloud se retrouve régulièrement dans les feeds. La bloquer au pare-feu, c'est couper l'accès à une partie de vos propres utilisateurs.
• Les pièges de licence. Beaucoup de feeds « gratuits » sont en réalité non commerciaux, ou interdisent la redistribution. Les intégrer à un produit ou un service revendu est un risque juridique, pas une bonne affaire.

Choisir un feed : les critères qui comptent

• La licence, d'abord. Pouvez-vous seulement l'utiliser dans votre contexte ? Un feed en usage non commercial est inutilisable dans un service payant. Le badge « open source » ne suffit pas : lisez les conditions réelles.
• Original ou ré-agrégé ? Un feed qui agrège trente autres listes hérite du bruit et des licences de toutes. Un feed au contenu original (issu de sa propre télémétrie) vaut mieux qu'un agrégat que vous pourriez reconstituer vous-même.
• La corroboration. Un indicateur confirmé par plusieurs sources indépendantes est bien plus fiable qu'un signalement unique. C'est le premier facteur de confiance.
• La fraîcheur. Un bon feed date ses indicateurs et les fait expirer. Un indicateur sans date de vue est un indicateur en lequel on ne peut pas avoir confiance.
• Le contexte. « Cette IP est mauvaise » vaut peu ; « cette IP est un C2 de telle famille, vue tel jour » vaut une décision. Le contexte transforme un indicateur en action.

Exploiter le feed : la discipline

Choisir n'est que la moitié du travail. Voici ce qui sépare un feed utile d'un feed dangereux.

Normaliser et dédupliquer. Les sources arrivent en formats hétérogènes (CSV, STIX, MISP, RPZ). Il faut les ramener à un modèle commun et fusionner les doublons, sinon le même indicateur, vu dix fois, pèse dix fois dans votre scoring.

L'hygiène du « ne jamais bloquer ». C'est la règle qui évite l'incident. Maintenez des listes d'exclusion : les plages privées (RFC 1918), vos propres préfixes, les IP partagées de CDN et de cloud, les domaines les plus populaires. Un indicateur qui tombe dans une exclusion ne doit jamais déclencher un blocage automatique, quelle que soit la source. Bloquer une IP de CDN parce qu'un feed l'a signalée, c'est provoquer soi-même la panne.

Le vieillissement. Un indicateur n'est pas malveillant pour l'éternité. Faites expirer les IP après un délai, réévaluez les domaines. Un feed sans décroissance ne fait que grossir et se tromper de plus en plus.

Le scoring par corroboration. Attribuez une confiance à chaque indicateur selon le nombre de sources indépendantes qui le confirment. C'est ce qui vous permet de décider : alerter sur un signal faible, bloquer sur un signal fort.

Le bon type d'indicateur au bon endroit

Un IOC ne s'applique pas n'importe où. La cohérence entre le type d'indicateur et le point d'application fait la différence :

• IP → pare-feu, ou résolution DNS. Avec exclusions, toujours.
• Domaine → filtrage DNS (une zone RPZ est le format naturel).
• Hash → EDR, ou règle YARA sur les fichiers.
• URL → proxy web.

Brancher un feed de hashs sur un pare-feu ne sert à rien ; brancher un feed d'IP sur un pare-feu sans exclusion sert à provoquer une panne.

Valider : mesurer avant de bloquer

Avant de mettre un feed en application automatique, mesurez deux choses :

1. Le taux de faux positifs contre votre propre trafic connu-bon : combien de vos flux légitimes seraient touchés ? Si le chiffre n'est pas quasi nul, restez en mode alerte, pas en mode blocage.
2. Le taux de couverture : le feed voit-il des menaces que vos autres sources ratent ? Un feed qui n'apporte rien de neuf ne mérite pas sa place.

Les pièges qui coûtent cher

• Le blocage d'IP sans exclusion. La première cause d'auto-panne. La liste « ne jamais bloquer » n'est pas optionnelle.
• Les hashs périmés. Un hash reste valide, mais un feed de hashs jamais nettoyé enfle sans fin et ralentit vos corrélations.
• La licence oubliée. Un feed non commercial ou interdit à la revente n'a rien à faire dans un service facturé. Vérifiez avant d'intégrer.
• La source unique sur-crue. Un indicateur d'une seule source, sans corroboration, mérite une alerte, pas un blocage aveugle.

En résumé

Exploiter un feed d'IOC, c'est une discipline, pas un branchement : choisir sur la licence, l'originalité et la corroboration ; puis normaliser, exclure ce qu'on ne bloque jamais, faire vieillir, scorer, et appliquer le bon type d'indicateur au bon point. Le reste (les formats, les compteurs) est de la plomberie.

C'est exactement ce que fournit le feed IOC de ThreatClaw : des indicateurs normalisés multi-format, scorés par corroboration croisée, avec l'hygiène « ne jamais bloquer » intégrée pour que la valeur (la détection) ne se paie jamais d'une panne. C'est ce qu'une simple liste brute ne peut pas garantir.