isMalicious vs Spamhaus : les listes DNSBL et l'enrichissement de menaces servent des couches différentes

Spamhaus est le nom de référence des listes de blocage basées sur DNS depuis plus longtemps que la plupart des produits de sécurité n'existent. DROP, EDROP, SBL et la liste composite Zen sont câblées dans les agents de transfert mail, les résolveurs DNS et les pipelines de filtrage BGP dans le monde entier. Lorsqu'une organisation doit bloquer des espaces IP connus malveillants en périphérie réseau avec une liste que l'industrie fait confiance, Spamhaus figure souvent en tête de la shortlist.

La comparaison avec isMalicious surgit pour une autre raison. Les équipes qui cherchent une « alternative Spamhaus » veulent parfois remplacer entièrement une DNSBL — ce qui est généralement une mauvaise idée — et parfois des capacités que Spamhaus n'a jamais été conçu pour fournir : enrichissement REST, analyse de malware URL, contexte CVE, suivi ransomware et flux STIX vers un SIEM. Ce sont des exigences différentes, et les confondre crée des manques dans un sens comme dans l'autre.

Ce que Spamhaus fait bien

• Des listes DNSBL de référence industrielle (SBL, XBL, PBL, DROP, EDROP) avec une confiance établie depuis longtemps dans le filtrage email et réseau.
• Conçu pour l'intégration MTA et résolveur, où une requête DNS contre une zone renvoie une décision de blocage avec une surcharge de latence minimale.
• Un signalement d'abus faisant autorité et des critères de listage maintenus par une équipe de recherche dédiée.
• Des produits de flux de données (DNS Blocklists, Threat Intel feeds) pour les organisations qui consomment des listes par programmation plutôt qu'en interrogeant des résolveurs publics.
• Une faible complexité opérationnelle au point d'application — s'abonner à la zone, l'interroger, bloquer en cas de correspondance.

Pour la sécurité mail et le blocage IP au niveau réseau, c'est une infrastructure fondamentale.

Où le manque apparaît

Le périmètre Spamhaus est délibérément étroit, et les manques apparaissent quand les workflows dépassent la DNSBL :

• Aucune API REST d'enrichissement renvoyant WHOIS, contexte DNS, données CVE et réputation multi-sources en un appel.
• Aucune analyse de malware URL ni analyse de chaîne de redirection pour le triage de phishing.
• Aucun suivi de groupes de ransomware associant un indicateur à une campagne d'extorsion.
• Aucune surveillance du dark web pour des signaux d'exposition de données ou d'identifiants.
• Aucun renseignement CVE avec statuts CVSS, EPSS ou KEV aux côtés d'un indicateur.
• Un contexte domaine limité au-delà des décisions de listage — pas d'analyse d'ancienneté d'enregistrement, de visibilité sous-domaines ou de données de pivot hébergement dans une réponse d'enrichissement.
• Pas une source d'enrichissement SIEM au sens de JSON structuré par indicateur pour des playbooks SOAR ; l'interface principale est la liste de blocage, pas une API d'investigation.

Rien de cela n'est un défaut. Une DNSBL doit être rapide, faisant autorité et étroite. Le problème survient quand une équipe la traite comme l'ensemble de sa stack de threat intelligence et découvre ensuite que le triage d'alertes, l'investigation URL et la corrélation de vulnérabilités exigent tous des outils séparés.

Ce que fournit isMalicious

isMalicious opère à la couche enrichissement et évaluation :

• Des verdicts de réputation multi-sources pour les IP, domaines et URL via une API REST.
• Une analyse d'URL avec suivi de chaîne de redirection pour le triage de liens phishing et malware.
• Un renseignement CVE avec les statuts CVSS, EPSS et KEV reliant les indicateurs à une exploitation active.
• Le suivi des groupes de ransomware et des signaux d'exposition sur le dark web.
• Des exports de listes de blocage et des collections STIX/TAXII pour l'ingestion pare-feu, filtrage DNS et SIEM.
• Des contrôles en masse pour traiter de longues listes d'indicateurs en réponse à incident ou en chasse aux menaces.
• Une offre gratuite en libre-service et une tarification transparente pour l'évaluation.

Ce qu'isMalicious ne fournit pas, c'est les décennies de confiance DNSBL que Spamhaus porte à la couche MTA. Remplacer SBL ou DROP sur une passerelle mail de production par une liste non éprouvée sans test de délivrabilité est une migration que la plupart des équipes email évitent à juste titre. Les listes de blocage isMalicious conviennent bien aux pare-feux, aux résolveurs DNS hors contexte MTA et à la corrélation SIEM — pas nécessairement en remplacement direct de Spamhaus Zen sur un serveur mail chargé.

Comparaison des fonctionnalités

| Capacité | Spamhaus | isMalicious | | :--- | :--- | :--- | | DNSBL (SBL, DROP, EDROP) | Oui, référence industrielle | Partiel (export blocklist) | | Intégration MTA / passerelle mail | Oui, cas d'usage principal | Non principal | | Blocage IP en périphérie réseau | Oui | Oui (via blocklist) | | API REST d'enrichissement | Non | Oui | | Analyse de malware URL | Non | Oui | | Scoring de réputation multi-sources | Non | Oui | | Contexte WHOIS / DNS en API | Non | Oui | | Renseignement CVE (CVSS, EPSS, KEV) | Non | Oui | | Suivi groupes ransomware | Non | Oui | | Surveillance dark web | Non | Oui | | Export STIX/TAXII | Partiel | Oui | | Enrichissement API en masse | Non | Oui | | Offre gratuite en libre-service | Partiel (DNSBL public) | Oui |

La stack qui fonctionne en pratique

Plutôt que de choisir l'un ou l'autre, la plupart des déploiements matures superposent les deux :

1. Spamhaus en périphérie mail et réseau. Les MTA interrogent SBL et Zen ; les filtres BGP consomment DROP et EDROP. C'est un blocage éprouvé à faible latence pour les espaces IP connus malveillants.
2. isMalicious dans la couche investigation et enrichissement. Quand une alerte se déclenche, analystes et playbooks SOAR appellent l'API pour le contexte de verdict, l'analyse URL et la corrélation CVE — des données qu'une requête DNSBL ne peut pas renvoyer.
3. isMalicious alimente SIEM et TIP. Les collections STIX/TAXII et exports de listes de blocage fournissent du renseignement structuré à OpenCTI et aux politiques pare-feu au-delà de ce que les zones DNSBL offrent.
4. Traitement en masse pour la réponse à incident. Les listes d'indicateurs d'un dossier passent par des contrôles en masse plutôt que des requêtes DNSBL séquentielles qui ne renvoient qu'une décision binaire de blocage.

Le mode d'échec consiste à attendre d'une DNSBL qu'elle réponde à des questions d'investigation. « Cette IP est-elle listée ? » est une question valide pour Spamhaus. « Quel est l'historique d'enregistrement, le contexte d'hébergement, l'exploitation CVE associée et le lien de campagne ransomware pour ce domaine ? » est une question d'enrichissement — et c'est là qu'isMalicious a sa place.

Pour les workflows email, consultez aussi les solutions sécurité email et les données de listes de blocage pour voir comment les listes isMalicious complètent plutôt qu'elles ne remplacent les politiques DNSBL MTA.

Pour commencer

Si votre besoin est le blocage DNSBL de passerelle mail avec des listes de confiance industrielle, Spamhaus reste la référence et isMalicious ne prétend pas remplacer SBL sur votre MTA. Si votre besoin est l'enrichissement API, le triage URL, le contexte CVE et les flux STIX pour votre stack SOC, consultez le face-à-face sur la page de comparaison Spamhaus.

L'étape pratique consiste à cartographier vos workflows par couche : quelles décisions se prennent à la bordure DNSBL versus lesquelles exigent un appel d'enrichissement. Faites passer un indicateur d'alerte récent par l'API et comparez la profondeur de réponse à une simple requête DNSBL. Ce test clarifie plus vite où chaque outil a sa place qu'un tableau de fonctionnalités.