Après l'article sur Strix, plusieurs personnes nous ont demandé ce qu'on avait mis en place côté surveillance continue. Strix attaque en actif sur la preprod pour trouver des vulnérabilités avant qu'elles n'atteignent la production. Wazuh fait le travail inverse : il surveille en permanence ce qui se passe sur l'infrastructure de production, détecte les comportements anormaux, et remonte les alertes. Les deux outils sont complémentaires et couvrent des phases très différentes du cycle de sécurité.

Wazuh est un projet open-source (GPLv2, dépôt wazuh/wazuh, environ 15 700 étoiles GitHub) issu du projet OSSEC. Il se positionne aujourd'hui comme une plateforme unifiée XDR et SIEM : détection sur les endpoints, corrélation de logs, évaluation de la posture de sécurité, et modules de conformité.

Ce que couvre Wazuh

La distinction entre EDR, XDR et SIEM est souvent floue dans les communications marketing. Wazuh les regroupe dans une architecture cohérente.

Le SIEM collecte, normalise et corrèle les logs de toutes les sources : serveurs, services AWS, accès réseau. Des règles de détection identifient les patterns suspects et génèrent des alertes. Tout cela est indexé dans un moteur OpenSearch et accessible via un dashboard Wazuh.

La couche XDR va plus loin : des agents légers déployés sur chaque workload surveillent en temps réel ce qui se passe sur la machine. Modifications de fichiers, processus lancés, connexions réseau établies, changements de configuration : chaque événement est transmis au manager central pour analyse.

Les capacités principales qu'on utilise :

  • File Integrity Monitoring (FIM) : détection en temps réel de toute modification de fichier sur les chemins surveillés. Sur un serveur applicatif, un fichier PHP modifié en dehors d'un déploiement est un signal d'alerte immédiat.
  • Détection de vulnérabilités : l'agent inventorie les paquets installés et les corrèle contre les bases NVD et les bulletins des éditeurs. On sait en permanence quelles CVE actives touchent nos workloads.
  • Security Configuration Assessment (SCA) : vérification automatique de la configuration des systèmes contre les benchmarks CIS. Un port ouvert inutilement, un service actif par défaut qui devrait être désactivé : ce sont des écarts que le scan remonte.

Architecture : manager, agents, indexeur

Wazuh repose sur trois composants. Le Wazuh Manager reçoit et traite les événements de tous les agents. Le Wazuh Indexer (basé sur OpenSearch) stocke et indexe les données pour la recherche et les dashboards. Le Wazuh Dashboard est l'interface de visualisation.

Les agents s'installent sur chaque machine à surveiller : serveurs Linux, instances EC2, conteneurs. Leur empreinte est légère. Ils collectent les événements localement et les transmettent au manager, ce qui permet de centraliser la corrélation sans surcharger les workloads applicatifs.

La configuration minimum recommandée pour le manager est 4 cœurs, 8 Go de RAM et 100 Go de stockage SSD. En production avec un volume de logs significatif, on monte à 8 cœurs et 16 à 32 Go selon la charge. AWS propose des templates CloudFormation pour déployer une architecture Wazuh en cluster directement depuis le Marketplace.

Chez nous, Wazuh tourne sur un serveur dédié. Chaque environnement client embarque son agent, et les correctifs système sont appliqués chaque semaine : la détection de vulnérabilités indique quoi corriger, le cycle hebdomadaire s'assure que c'est fait.

Les modules de conformité

Pour une plateforme qui traite des données personnelles et des transactions financières, la conformité réglementaire n'est pas un sujet secondaire. Wazuh embarque des règles de détection pré-mappées sur plusieurs référentiels : RGPD, PCI DSS, HIPAA, NIST 800-53.

Concrètement, cela signifie que chaque alerte est taggée avec les contrôles réglementaires correspondants. Un accès non autorisé à des données est immédiatement associé aux articles RGPD pertinents. C'est utile non seulement pour la détection, mais aussi pour la documentation des incidents, qui fait partie des obligations de notification à la CNIL en cas de violation.

Côté AWS, la posture de sécurité du compte est évaluée en continu par AWS Security Hub (standards AWS Foundational Security Best Practices et CIS), complété par GuardDuty, CloudTrail et IAM Access Analyzer. Wazuh se concentre sur les serveurs, Security Hub sur la configuration des services AWS.

Ce qu'il faut être honnête sur

Wazuh n'est pas une solution clés en main. C'est un outil puissant qui demande un investissement initial réel : configuration des règles, tuning pour réduire le bruit, définition des seuils d'alerte adaptés à son contexte. Les règles par défaut génèrent des faux positifs qu'il faut filtrer pour que les alertes restent actionnables.

Il n'a pas non plus les capacités de profilage comportemental (UEBA) des solutions commerciales comme CrowdStrike ou Microsoft Defender. Sur ce point, les EDR propriétaires ont une longueur d'avance, notamment pour détecter des attaques sophistiquées basées sur des comportements subtils plutôt que des signatures connues.

Enfin, les agents tournent en espace utilisateur. Un attaquant ayant obtenu des privilèges suffisants sur une machine compromise peut théoriquement supprimer des logs avant qu'ils ne soient transmis. C'est une limite réelle, commune à beaucoup d'outils open-source dans cet espace.

Pour une équipe dont la sécurité n'est pas la spécialité principale, Wazuh représente un niveau de visibilité inaccessible à coût nul avec des outils propriétaires. L'alternative commerciale équivalente en fonctionnalités représente un budget annuel à cinq ou six chiffres. Le vrai coût de Wazuh, c'est le temps d'ingénierie pour le configurer et le maintenir.

En résumé

Wazuh couvre un spectre large : surveillance des serveurs, intégrité des fichiers, détection de vulnérabilités, corrélation de logs, conformité réglementaire. Pour une équipe SaaS qui veut une visibilité sérieuse sur son infrastructure sans passer par un SIEM commercial, c'est le point de départ le plus cohérent aujourd'hui. Couplé à Strix pour la détection offensive en preprod, on a une couverture des deux phases critiques du cycle de sécurité.