Dans les SOC que j’accompagne en Afrique de l’Ouest, je rencontre souvent la même limite : Wazuh détecte des comportements anormaux, mais ne sait pas si l’IP, le hash ou le domaine impliqué est connu pour être malveillant. L’analyste investigue dans le brouillard, perd du temps sur des faux positifs, et passe parfois à côté de menaces avérées que la communauté CTI mondiale a déjà identifiées depuis plusieurs heures.
C’est précisément là que MISP (Malware Information Sharing Platform) change la donne. En l’intégrant à Wazuh, on transforme un SIEM réactif en plateforme de détection contextualisée, capable de relier chaque événement local au renseignement collectif sur les menaces. Dans cet article, je détaille la valeur ajoutée de MISP, les types d’indicateurs exploitables, l’intégration technique avec Wazuh, et cinq cas d’usage que j’ai déployés sur le terrain.
Pourquoi MISP est la pièce manquante de votre SIEM
MISP n’est pas qu’une « base d’IoC ». C’est une plateforme de threat intelligence collaborative, maintenue par le CIRCL (Luxembourg) et utilisée par plus de 6 000 organisations dans le monde — dont des CSIRT nationales, des banques, des opérateurs télécoms et de nombreuses agences gouvernementales.
Sa valeur ajoutée tient à quatre piliers que peu de plateformes commerciales offrent simultanément.
Le partage structuré et standardisé. MISP utilise les standards ouverts (STIX 2, MISP format, OpenIOC) pour échanger des indicateurs avec d’autres instances. Une organisation peut consommer des feeds publics, recevoir des alertes de partenaires sectoriels, et contribuer à son tour ses propres observations. Cette circulation bidirectionnelle du renseignement est l’un des leviers les plus puissants face à des attaquants qui mutualisent eux aussi leurs outils.
Le contexte autour de chaque indicateur. Un IoC seul (une IP, un hash) a une valeur limitée. MISP attache à chaque indicateur un événement qui décrit le contexte : campagne d’attaque, acteur de menace, secteur ciblé, TTPs (techniques, tactiques, procédures) référencées dans MITRE ATT&CK. C’est ce contexte qui permet à un analyste de qualifier rapidement la sévérité d’une alerte.
Les galaxies et taxonomies. MISP intègre plus de 70 galaxies (catalogues de groupes APT, familles de malwares, kits d’exploitation) et des dizaines de taxonomies (classifications TLP, kill chain, niveau de confiance). Ces métadonnées permettent une corrélation fine, par exemple « alerter si un IoC est associé à un groupe ransomware actif et noté en confiance haute ».
L’API REST mature. MISP expose une API REST complète et documentée. C’est ce qui rend l’intégration avec Wazuh — ou tout autre SIEM, EDR, firewall — non seulement possible, mais industrialisable.
Les types d’IoC que MISP rend exploitables dans Wazuh
L’intégration MISP-Wazuh ne se limite pas aux adresses IP malveillantes. C’est l’une des raisons pour lesquelles elle est si puissante : elle permet d’enrichir une grande variété d’événements détectés par Wazuh.
Voici les principales catégories d’indicateurs que j’exploite chez mes clients.
Indicateurs réseau. Adresses IP source/destination, plages CIDR, noms de domaine, URL complètes, hostnames. Ces IoC sont matchés contre les logs de connexion remontés par les agents Wazuh, les firewalls et les proxies. Cas typique : détecter une connexion sortante vers un serveur de command and control connu.
Indicateurs de fichiers. Hashes MD5, SHA1, SHA256, SHA512, ssdeep, imphash. Wazuh dispose d’un module FIM (File Integrity Monitoring) qui calcule automatiquement les hashes des fichiers créés ou modifiés sur les endpoints. Le matching contre MISP permet d’identifier en temps réel un binaire malveillant dès qu’il touche le disque.
Indicateurs email. Adresses expéditrices, sujets, hashes de pièces jointes, adresses de retour. Couplés à un connecteur sur la passerelle email, ils permettent de détecter des campagnes de phishing ciblées en cours.
Indicateurs système. Noms de mutex, clés de registre Windows, chemins de fichiers, noms de processus, services Windows. Particulièrement utiles pour détecter la persistance d’un malware sur un endpoint via les règles Sysmon intégrées à Wazuh.
Indicateurs cryptographiques. Empreintes de certificats SSL/TLS, signatures de code, clés PGP. Permettent de détecter un trafic chiffré vers une infrastructure malveillante, ou un binaire signé avec un certificat compromis.
Indicateurs comportementaux et TTPs. Au-delà des IoC atomiques, MISP référence des patterns d’attaque liés à MITRE ATT&CK. Couplés aux règles de corrélation Wazuh, ils permettent une détection comportementale, plus résistante au changement d’infrastructure des attaquants.
Cette diversité est la véritable plus-value : peu importe à quel niveau de la chaîne d’attaque la menace se manifeste — réseau, fichier, email, système — MISP fournit la grille de lecture.
Architecture de l’intégration Wazuh-MISP
L’architecture que je déploie repose sur un principe simple : Wazuh interroge MISP en temps réel lorsqu’une alerte contient un indicateur potentiellement malveillant.
Le flux fonctionne ainsi :
- Les agents Wazuh déployés sur endpoints et serveurs remontent leurs événements (logs système, FIM, télémétrie) vers le Wazuh Manager.
- Les équipements réseau (firewalls, proxies, IDS) envoient leurs logs au Manager via Syslog ou décodeurs dédiés.
- Lorsque le Manager détecte un événement contenant un IoC exploitable, le module integrator déclenche une requête vers l’API REST de MISP.
- MISP répond en quelques millisecondes : l’indicateur est-il connu ? À quel événement, à quel acteur, à quelle famille de malware est-il rattaché ?
- Si le match est positif, Wazuh enrichit l’alerte avec le contexte CTI et la relève en sévérité.
- L’alerte enrichie est indexée dans le Wazuh Indexer, visualisée dans le dashboard, et peut déclencher une réponse automatisée via un SOAR (Shuffle, par exemple).
Côté MISP, la plateforme se synchronise en continu avec des communautés CTI externes : feeds CIRCL, ANSSI, abuse.ch, partenaires sectoriels, instances MISP privées de partage entre organisations. Cela garantit que la base d’indicateurs reste fraîche — un point critique, car la valeur d’un IoC se dégrade rapidement.
L’Active Response de Wazuh : du contexte à l’action automatisée
C’est ici que l’intégration MISP-Wazuh prend toute sa dimension opérationnelle. Détecter une menace, c’est bien. Y répondre automatiquement en quelques secondes, c’est ce qui fait la différence entre un incident contenu et une crise majeure.
Wazuh dispose nativement d’un mécanisme appelé Active Response : un système qui exécute des scripts ou des commandes sur les agents ou le manager dès qu’une alerte dépasse un certain seuil de sévérité ou correspond à une règle précise. Bloquer une IP au niveau du firewall, désactiver un compte utilisateur, isoler un endpoint du réseau, tuer un processus malveillant — tout cela est possible nativement.
Le problème, sans MISP, c’est que l’Active Response repose sur la confiance que vous accordez à vos propres règles de détection. Bloquer automatiquement une IP parce qu’elle a généré 10 connexions en 5 minutes, c’est risqué : ça peut être un comportement légitime. Beaucoup d’équipes laissent donc l’Active Response désactivé ou en mode très conservateur, par peur des faux positifs.
MISP change radicalement cette équation. Quand l’enrichissement CTI confirme qu’un IoC est associé à un acteur de menace connu, à une famille de ransomware active, ou à une infrastructure C2 documentée par la communauté mondiale, on n’est plus dans le doute. On peut déclencher une réponse automatisée avec un haut niveau de confiance, et c’est ce qui rend l’Active Response réellement percutant.
Concrètement, voici ce que cette combinaison permet sur le terrain.
Blocage d’IP au niveau périmétrique. Lorsqu’un agent Wazuh détecte une connexion sortante vers une IP, l’integrator interroge MISP. Si l’IP est référencée dans un événement actif et noté en confiance haute, l’Active Response pousse automatiquement une règle de blocage sur le firewall (via l’API du firewall ou via iptables/firewalld sur l’agent local). La connexion est coupée en moins de 5 secondes, et toutes les autres machines tentant la même connexion sont protégées immédiatement.
Isolation d’un endpoint compromis. Lorsque le module FIM détecte un nouveau fichier dont le hash correspond à une famille de malware référencée dans MISP, l’Active Response peut déconnecter le poste du réseau (en désactivant l’interface réseau de l’agent) tout en gardant l’agent Wazuh actif pour permettre l’investigation. Le malware est neutralisé avant même que l’analyste ne reçoive sa notification.
Quarantaine de fichier malveillant. Plutôt qu’isoler tout le poste, on peut cibler le fichier : déplacer le binaire dans un répertoire de quarantaine, supprimer les droits d’exécution, et enregistrer son hash et son chemin pour investigation. Particulièrement utile sur les serveurs où l’on ne peut pas se permettre une coupure réseau.
Désactivation d’un compte utilisateur. Si une alerte enrichie par MISP indique qu’un compte est utilisé depuis une IP compromise (par exemple, un VPN authentifié depuis un nœud Tor référencé), l’Active Response peut révoquer la session active et désactiver temporairement le compte dans l’Active Directory.
Blocage d’un domaine au niveau DNS. Lorsqu’un domaine malveillant est détecté dans les logs DNS et confirmé par MISP, l’Active Response peut pousser une règle de sinkhole sur le résolveur DNS interne, ce qui protège instantanément l’ensemble du parc.
Le principe à retenir est simple : MISP fournit la confiance, Wazuh fournit l’action. Sans MISP, l’Active Response reste timide pour éviter les faux positifs. Avec MISP, on peut configurer des réponses agressives et automatiques sur les IoC à confiance haute, tout en gardant des réponses plus prudentes (notification simple) sur les IoC à confiance moyenne.
Pour calibrer correctement, je recommande systématiquement à mes clients d’introduire un mode progressif : on commence par activer l’Active Response uniquement en notification (pas d’action réelle), on observe pendant 2 à 4 semaines la pertinence des déclenchements basés sur les enrichissements MISP, puis on bascule progressivement vers des actions de blocage. Cette approche élimine quasiment tout risque de faux positif bloquant.
Bénéfices opérationnels et stratégiques
Au-delà des cas d’usage, l’intégration produit des effets mesurables.
Pour les équipes opérationnelles, le ratio signal/bruit s’améliore significativement. Sur les déploiements que j’ai accompagnés, les équipes rapportent une réduction notable du temps passé à investiguer des faux positifs, et une montée en compétence rapide des analystes juniors qui disposent d’un contexte explicite à chaque alerte. Le temps moyen de détection (MTTD) chute mécaniquement.
Pour la direction, l’intégration matérialise un investissement cybersécurité tangible. Elle transforme un SIEM « boîte noire » en plateforme de défense active, alignée sur les menaces réelles ciblant l’organisation. Elle facilite également la conformité : pouvoir démontrer qu’on consomme et qu’on partage de la threat intelligence est un argument fort lors d’audits ou d’évaluations de maturité (NIST CSF, ISO 27001, ITU-T X.1500).
Pour la communauté, MISP n’est pas seulement un consommateur de threat intelligence — c’est aussi une plateforme de partage. Une organisation suffisamment mature peut contribuer ses propres observations à des communautés sectorielles ou nationales. Dans le contexte ouest-africain où je travaille, ce point est particulièrement structurant : la mutualisation du renseignement est l’un des leviers les plus efficaces pour rattraper l’écart de capacité face à des attaquants souvent transnationaux.
Limites et points d’attention
L’efficacité du couple Wazuh-MISP dépend directement de la qualité des feeds CTI consommés. Un MISP mal alimenté générera du bruit ou pire des faux négatifs. La sélection et le scoring des sources sont un travail continu, pas un paramétrage initial.
L’intégration nécessite par ailleurs une gouvernance claire : qui maintient les règles d’enrichissement ? Qui révise les playbooks ? Qui supervise la santé de l’instance MISP ? Sans cette gouvernance, l’outil dérive et perd sa valeur en quelques mois.
Enfin, Wazuh et MISP sont des projets open source actifs : il faut prévoir un effort de mise à jour et de veille pour suivre les évolutions des deux plateformes, notamment les changements d’API.
Intégrer MISP à Wazuh, ce n’est pas simplement ajouter une brique technique à un SIEM. C’est faire passer un SOC d’une posture défensive réagir aux alertes à une posture proactive, où chaque événement est lu à la lumière du renseignement collectif sur les menaces. La diversité des IoC exploitables, la richesse du contexte CTI fourni par MISP et la maturité de son API en font, à mes yeux, l’une des intégrations les plus rentables que peut faire un SOC aujourd’hui.
Pour les organisations qui veulent bâtir une capacité de cybersécurité moderne sans s’enfermer dans des solutions propriétaires, c’est un choix structurant. Une entreprise comme IDIAWARE, accompagne cette transformation de bout en bout : architecture, déploiement, règles de corrélation personnalisées, formation des analystes et gouvernance CTI.
Si vous envisagez un projet de cette nature, ou si vous souhaitez auditer un déploiement existant, contactez-moi : je serai heureux d’échanger sur votre contexte.
