Recherche en masse d'IP et de domaines : concevoir un enrichissement qui tient au volume réel

Les recherches unitaires conviennent quand c'est un humain qui pose la question. Le problème commence quand la liste provient d'une machine : une extraction de journaux proxy, un export de pare-feu, l'ensemble d'indicateurs d'un rapport d'incident, ou un flux que vous voulez valider avant de lui faire confiance. À ce stade, vous ne faites plus des recherches, vous exécutez un traitement — et les décisions de conception qui font qu'un traitement fonctionne diffèrent de celles qui font qu'une recherche unitaire fonctionne.

Ce guide explique comment structurer un enrichissement par lots pour qu'il reste rapide, reste dans les quotas, et ne perde pas silencieusement la moitié de vos indicateurs lorsqu'un incident technique survient.

D'où vient le volume

L'enrichissement par lots apparaît dans un ensemble prévisible de situations :

• La recherche rétrospective. Une nouvelle campagne est publiée avec ses indicateurs, et vous interrogez des semaines de journaux à la recherche de correspondances. L'extraction produit des milliers d'adresses et de domaines candidats, presque tous hors sujet.
• L'établissement du périmètre d'un incident. Une intrusion confirmée génère la liste de toutes les destinations contactées par l'hôte compromis. Distinguer l'infrastructure d'attaquant du trafic ordinaire constitue toute la tâche.
• La revue des journaux de pare-feu et de proxy. L'examen périodique de ce avec quoi votre réseau a réellement communiqué, seul moyen fiable de trouver la connexion sur laquelle personne n'a alerté.
• La validation de flux. Avant d'intégrer un flux tiers dans des contrôles de blocage, le confronter à une source indépendante révèle son taux de faux positifs.
• L'évaluation de la surface d'attaque. Énumérer les domaines et adresses propres d'une organisation — lors d'un démarrage, d'une acquisition ou d'un audit — et vérifier l'exposition de chacun.
• L'hygiène des listes de blocage. Les entrées de blocage vieillissent mal. Les revérifier périodiquement permet de trouver les adresses depuis réattribuées à quelque chose de légitime.

La forme commune : une liste produite automatiquement, majoritairement du bruit, dont la valeur réside dans le petit sous-ensemble qui s'avère important.

Réduire avant d'envoyer

Le plus grand gain d'efficacité d'un pipeline par lots se produit avant la première requête.

Dédupliquez. Les extractions brutes de journaux sont extraordinairement répétitives — une seule adresse très active peut représenter des milliers de lignes. Réduire à un ensemble unique divise couramment le volume par un ordre de grandeur sans rien coûter en couverture.

Filtrez ce que vous savez déjà. Plusieurs catégories peuvent être retirées sans recherche :

• les plages d'adresses privées et réservées, qui n'ont aucune réputation externe à vérifier ;
• vos propres ASN et blocs d'adresses ;
• les adresses et domaines appartenant à une infrastructure que vous avez déjà examinée et autorisée ;
• les entrées enrichies assez récemment pour que la réponse n'ait pas plausiblement changé.

Mettez en cache généreusement, avec une durée de vie sensée. La réputation évolue, mais pas de minute en minute. Conserver les résultats quelques heures permet de traiter localement les indicateurs qui réapparaissent dans le lot du lendemain. Les données d'enregistrement évoluent encore plus lentement — les enregistrements WHOIS sont généralement mis en cache environ 24 heures pour cette raison précise.

Normalisez. Retirez les ports, mettez les domaines en minuscules, traitez le punycode de manière cohérente, et décidez d'emblée si example.com et www.example.com constituent un ou deux indicateurs. Une normalisation incohérente ruine la déduplication et gonfle le nombre de requêtes sans ajouter d'information.

Ce n'est qu'après ces quatre étapes que la taille réelle de votre traitement devient claire, et elle représente généralement une fraction de l'extraction brute.

Concevoir autour de deux limites distinctes

Les API par lots imposent des limites sur deux dimensions, et les confondre est la cause de la plupart des problèmes d'intégration.

La taille de lot par requête correspond au nombre d'indicateurs tenant dans un appel. L'API en masse d'isMalicious accepte jusqu'à 100 entités par requête sur le plan Pro, avec de plus petits lots d'évaluation sur le plan gratuit. Les traitements plus volumineux sont découpés en plusieurs requêtes.

Le volume total dans le temps correspond à votre quota mensuel et à votre débit de pointe — sur Pro, une allocation mensuelle de vérifications de réputation et un plafond de requêtes par minute. Un traitement peut être parfaitement découpé et échouer malgré tout parce qu'il a tenté 400 requêtes en 30 secondes, ou réussir toute la semaine puis épuiser l'allocation mensuelle le 28.

Conséquences pratiques :

• Découpez à la limite de lot, et non à un nombre choisi arbitrairement. Des requêtes de 100 là où 100 sont autorisées représentent un dixième des appels de requêtes de 10.
• Limitez votre propre débit délibérément au lieu de découvrir le plafond par des requêtes en échec. Un léger délai entre les lots coûte moins cher qu'une logique de réessai.
• Suivez la consommation de quota comme une métrique, et alertez avant l'épuisement. Un pipeline qui cesse silencieusement d'enrichir est pire qu'un pipeline qui échoue bruyamment, parce que personne ne s'en aperçoit avant un incident.
• Priorisez au sein du traitement. Si un lot dépasse ce que vous pouvez traiter, enrichissez d'abord les indicateurs apparus dans des alertes avant ceux qui n'apparaissent que dans les journaux.

Traiter explicitement les échecs partiels

Un lot de 100 ne réussit ni n'échoue comme un bloc, en pratique. Des entrées individuelles peuvent être mal formées, non résolvables, ou d'un type que le point de terminaison ne traite pas, et un pipeline qui considère tout problème unitaire comme un échec du lot entier réessaiera indéfiniment un travail coûteux.

• Associez explicitement les résultats aux entrées. Ne comptez pas sur l'ordre de la réponse pour faire correspondre résultats et indicateurs soumis.
• Distinguez « aucune donnée » de « erreur ». Une adresse sans historique de réputation est une réponse valide et ne doit pas être réessayée. Un dépassement de délai, si.
• Réessayez avec temporisation croissante, et uniquement les échecs. Resoumettre un lot entier parce que deux entrées ont échoué gaspille du quota sur 98 recherches réussies.
• Consignez ce que vous n'avez pas enrichi. L'indicateur qui n'a silencieusement jamais été vérifié est celui qui ressort lors de la revue post-incident.

Interpréter les résultats en masse sans provoquer de panne

La tentation, avec l'enrichissement par lots, est de brancher la sortie directement sur le blocage. Résistez-y, au moins au début.

Un verdict de réputation est un élément de preuve, pas une instruction. Un blocage automatique fondé sur le seul score finira par neutraliser une adresse de périphérie de CDN, un fournisseur de messagerie ou un point de terminaison SaaS dont l'activité dépend — et il le fera à grande échelle, puisque c'est le propre de l'automatisation. Le schéma plus sûr sépare les deux décisions :

• Enrichir et prioriser automatiquement, pour tout. Attacher du contexte à chaque indicateur ne coûte rien et améliore chaque décision en aval.
• Bloquer automatiquement seulement dans des catégories examinées, derrière un seuil de confiance, et toujours derrière une liste d'autorisation de l'infrastructure que l'activité ne peut pas perdre.
• Orienter la zone grise vers un humain, avec l'enrichissement déjà attaché pour que l'analyste porte un jugement au lieu de collecter des données.

Il est également utile que les résultats en masse renvoient le contexte de menace complet pour chaque entrée plutôt qu'un simple verdict : c'est la raison du score qui permet à un analyste de le contredire à bon escient.

Un pipeline qui fonctionne

1. Extraire les indicateurs de la source, en conservant le contexte d'origine — quel journal, quel hôte, quelle alerte.
2. Normaliser vers des types d'indicateurs cohérents.
3. Dédupliquer vers un ensemble unique.
4. Filtrer les plages privées, votre propre infrastructure, les entrées autorisées et tout ce qui est déjà en cache.
5. Découper à la limite de lot par requête.
6. Soumettre avec un rythme délibéré sous le plafond de pointe.
7. Fusionner les résultats sur le contexte d'origine, afin qu'un verdict soit rattaché à l'hôte ayant établi la connexion plutôt que de flotter isolément.
8. Mettre en cache l'ensemble avec une durée de vie appropriée.
9. Orienter selon la confiance : malveillant à forte confiance vers les contrôles, ambigu vers les analystes, propre vers l'archive.
10. Mesurer la consommation de quota, le taux de succès du cache et la proportion d'indicateurs qui se sont avérés importants — ce dernier chiffre vous dit si votre filtrage est trop laxiste ou trop strict.

Le mettre en route

L'API en masse d'isMalicious accepte les tableaux JSON, le texte délimité par retours à la ligne et le CSV, et détecte le type de chaque entrée pour que domaines, IP et URL puissent être mélangés dans une seule requête au lieu d'être séparés par type. Chaque entrée renvoie le contexte de menace complet plutôt qu'un verdict seul, ce qui rend possibles les décisions d'orientation décrites plus haut.

Pour les détails d'implémentation — forme des requêtes, comportement du découpage et limites exactes de votre plan — consultez la documentation du point de terminaison en masse et la référence des limites de débit. Les équipes qui branchent cela sur leur outillage de détection partent généralement du parcours d'intégration SIEM, et la documentation développeurs couvre la voie du SDK si vous préférez ne pas écrire la couche HTTP à la main.

Le fond du sujet est peu spectaculaire : le goulot d'étranglement de l'enrichissement d'indicateurs n'est presque jamais la recherche elle-même. C'est la centaine de lignes dupliquées, le cache absent, le quota non suivi et la tempête de réessais provoquée par deux entrées mal formées. Corrigez cela et l'enrichissement cesse d'être l'étape lente du triage.