Wazuh : Plateforme XDR/SIEM Open Source 2026 - Guide Complet

Wazuh est une plateforme de securite unifiee XDR (Extended Detection and Response) et SIEM (Security Information and Event Management) open source, distribuee sous licence GPLv2, qui agrege la collecte de logs, la detection de menaces, le monitoring d'integrite des fichiers (FIM), l'evaluation des vulnerabilites, l'evaluation de la configuration de securite (SCA) et l'audit de conformite reglementaire dans une stack unique. Maintenue par Wazuh Inc. (Sunnyvale, Californie) depuis 2015 apres son fork de OSSEC, la plateforme atteint la version 4.12 en mai 2026 et compte plus de 20 000 deploiements actifs dans 150 pays. Wazuh repose sur quatre composants : un Wazuh Manager (correlation et analyse), un Wazuh Indexer (fork OpenSearch 2.x pour stockage et recherche), un Wazuh Dashboard (interface OpenSearch Dashboards customisee) et des agents legers deployes sur les endpoints Linux, Windows, macOS, AIX, Solaris ou HP-UX. La solution rivalise avec Splunk Enterprise Security, Elastic Security et Microsoft Sentinel sur le perimetre fonctionnel mais conserve un avantage decisif : aucun cout de licence par GB ingere, contrainte qui plombe les budgets SOC dans les architectures proprietaires.

Definition technique de Wazuh

Wazuh est defini officiellement comme une plateforme de securite unifiee XDR et SIEM open source. Le projet est ne en juin 2015 d'un fork de OSSEC HIDS par Santiago Bassett, fondateur et CEO de Wazuh Inc. La version stable courante est Wazuh 4.12.0 (mai 2026), distribuee sous licence GNU GPLv2 avec code source heberge sur github.com/wazuh/wazuh. La plateforme couvre techniquement trois piliers : endpoint security (HIDS, FIM, rootcheck, SCA), threat intelligence (correlation logs, MITRE mapping, integration CTI) et security operations (alerting, automation, conformite). Le moteur de regles utilise un format XML declaratif avec plus de 3 800 regles preconfigurees et 600 decoders couvrant Apache, Nginx, sshd, Windows Event Log, AWS CloudTrail, Office 365, Azure AD, GCP, kube-apiserver, Docker daemon. Wazuh n'est pas un EDR commercial proprietaire : c'est une suite XDR/SIEM modulaire dont le cycle de release suit un rythme trimestriel.

Architecture technique de la plateforme Wazuh

L'architecture Wazuh decoupe quatre composants distincts communiquant via des canaux chiffres TLS 1.3. Le schema ci-dessous illustre les flux de donnees entre endpoints, manager, indexer et dashboard dans une topologie de production typique.

+--------------------+        +--------------------+        +--------------------+
|   Wazuh Agent      |  TLS   |   Wazuh Manager    |  HTTPS |   Wazuh Indexer    |
|   (endpoint)       |─────►|   (analysis engine)|─────►|   (OpenSearch)     |
|   port 1514        |        |   port 1514/55000  |        |   port 9200        |
+--------------------+        +--------------------+        +--------------------+
                                       |                              |
                                       | filebeat                     | API REST
                                       |                              |
                                       v                              v
                              +-----------------------------------------+
                              |        Wazuh Dashboard (Kibana fork)    |
                              |              port 443                   |
                              +-----------------------------------------+

Le Wazuh Agent est un binaire C compile statiquement, empreinte memoire moyenne 35 MB RSS, qui collecte logs, evenements FIM, inventaire systeme, donnees rootcheck et resultats SCA. Il transmet via le protocole proprietaire OSSEC remoted (port 1514 UDP/TCP) avec authentification par cle pre-partagee.

Le Wazuh Manager est le moteur central de correlation. Il execute analysisd (parsing logs), remoted (gestion agents), authd (enrolment), wazuh-modulesd (vuln detector, AWS, Azure, Office 365, Docker, GitHub, Microsoft Graph) et api (REST sur port 55000). Il publie les alertes en JSON via Filebeat vers l'Indexer.

Le Wazuh Indexer est un fork OpenSearch 2.13 (en 4.12) optimise pour le pattern d'ingestion Wazuh. Il stocke les indices wazuh-alerts-*, wazuh-archives-*, wazuh-statistics-*, wazuh-monitoring-*. Le sharding par defaut est 1 shard primaire et 1 replica, configurable via les templates ISM.

Le Wazuh Dashboard est un fork OpenSearch Dashboards integrant les plugins Wazuh-app, Wazuh-monitoring et Wazuh-vulnerability-detector. Il expose la cartographie MITRE ATT&CK, les rapports PCI DSS, NIST, ISO 27001 et la console d'investigation forensique.

Fonctionnalites principales de Wazuh

Wazuh embarque douze modules de securite activables via la configuration ossec.conf. Chaque module produit des evenements normalises consommes par le moteur de regles.

File Integrity Monitoring (FIM)

Le module syscheck surveille la creation, modification, suppression de fichiers via inotify (Linux), ReadDirectoryChangesW (Windows) ou FSEvents (macOS). Il calcule les hashes SHA1, SHA256, MD5 et detecte les modifications d'attributs (permissions, ownership, ACL, timestamps). Frequence configurable de 60 secondes (whodata temps reel) a 24 heures (scan baseline).

Rootcheck et detection d'anomalies

Rootcheck identifie les rootkits Linux/Windows via signatures connues, processus caches, ports en ecoute non declares, fichiers suid suspects, modules kernel illegitimes. La base embarque les signatures de 87 rootkits documentes (Beastkit, ZKrootkit, Suckit, Diamorphine, Reptile, Drovorub).

Vulnerability Detection

Le module Vulnerability Detector inventorie les paquets installes (rpm, dpkg, msi, brew) et croise avec les feeds CVE NVD, Canonical OVAL, Red Hat OVAL, Debian OVAL, Microsoft MSRC, ALAS Amazon Linux. Wazuh 4.8+ utilise un moteur unifie en C++ avec cache LRU pour reduire la latence de scan a moins de 5 secondes par endpoint.

Security Configuration Assessment (SCA)

SCA execute des policies au format YAML evaluant la conformite par rapport aux CIS Benchmarks (Linux, Windows, Docker, Kubernetes), NIST 800-53, PCI DSS et HIPAA. La bibliotheque officielle compte 47 policies pre-redigees couvrant 95 % du parc Linux/Windows entreprise.

MITRE ATT&CK mapping

Chaque regle Wazuh peut referencer une ou plusieurs techniques MITRE ATT&CK v15. Le dashboard affiche une matrice navigable et calcule la couverture de detection par tactique (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact).

Log analysis et correlation

Le moteur analysisd parse les logs via 600+ decoders. Le langage de regles XML supporte les conditions sur fields (srcip, user, action, status_code), les seuils (frequency, timeframe), les correlations multi-evenements (if_matched_sid, if_matched_group), les regex PCRE2 et les listes (CDB lists).

Active Response

Active Response declenche des scripts sur l'agent en reponse a une alerte (firewall-drop, host-deny, ip-block, account-disable). Les scripts sont executes en sandbox avec timeout configurable et logs centralises.

Regulatory Compliance reporting

Le dashboard genere des rapports automatiques PCI DSS 4.0, GDPR, HIPAA, NIST 800-53, TSC, GPG13, NIS2. Chaque alerte est taggee avec les controles applicables, permettant l'export PDF/CSV pour les audits.

Stack technique et dependances

Wazuh est ecrit en C, C++ et Python. Le manager utilise C/C++ pour les daemons critiques (analysisd, remoted, syscheckd) et Python 3.10+ pour l'API REST (framework connexion + aiohttp). Les modules cloud (AWS, Azure, GCP, Office 365) sont en Python pur. Le dashboard hereditaire le stack Node.js d'OpenSearch Dashboards (Node 18 LTS en 4.12).

Le Wazuh Indexer est un fork OpenSearch 2.13. Historiquement, Wazuh utilisait Elasticsearch OSS jusqu'en version 4.3 (mai 2022), puis a migre vers OpenSearch suite au changement de licence Elastic vers SSPL. Le fork conserve la compatibilite API avec Elasticsearch 7.10 mais s'aligne progressivement sur les fonctionnalites OpenSearch (anomaly detection, alerting, ML commons).

Les OS supportes pour les agents : Linux (RHEL/CentOS/Rocky/AlmaLinux 7+, Ubuntu 18.04+, Debian 10+, SLES 12+, Amazon Linux 2/2023), Windows 7/8/10/11 et Server 2008 R2 a 2025, macOS 10.13+, AIX 6.1+, Solaris 10+, HP-UX 11i v3. Les binaires sont signes GPG et distribues via les packages officiels deb/rpm/pkg/msi.

Cas d'usage entreprise typiques

Wazuh adresse quatre profils d'organisations distincts.

PME et ETI sans budget SIEM commercial

Pour une organisation de 50 a 500 endpoints, Wazuh remplace Splunk Enterprise Security ou IBM QRadar a cout zero licence. Le ROI typique est atteint en 3 mois sur le poste licensing, avec un cout total de possession (TCO) sur 3 ans entre 35 000 et 80 000 EUR (infrastructure + integration + run interne) versus 250 000 a 600 000 EUR pour une suite proprietaire.

Grands comptes et architectures multi-clusters

Les grands comptes deploient Wazuh en architecture distribuee multi-clusters avec un Wazuh Manager master et des workers en mode cluster (jusqu'a 50 nodes), un Wazuh Indexer en cluster OpenSearch (3 a 30 nodes), et plusieurs Dashboard pour la repartition de charge. La capacite typique est de 50 000 a 200 000 agents par cluster.

Managed Security Service Providers (MSP)

Les MSP exploitent l'architecture multi-tenant de Wazuh via les groupes d'agents et les comptes RBAC. Chaque tenant dispose de son groupe, de ses regles custom et de ses index isoles via les ISM templates. La plateforme supporte le SAML 2.0 et OpenID Connect pour l'integration aux IDP clients (Azure AD, Okta, Keycloak).

Conformite reglementaire

Wazuh est deploye comme outil pivot pour les audits PCI DSS 4.0 (controles 10.x sur logging), NIS2 (article 21 mesures techniques), ISO 27001 Annex A.8.16 et A.5.30, HIPAA Security Rule 164.312(b). La traceabilite end-to-end et l'archivage long terme (jusqu'a 7 ans selon la politique ISM) couvrent les exigences de retention reglementaire.

Limites et pieges connus de Wazuh

Wazuh n'est pas une plateforme magique. Six pieges recurrents emergent en production.

Scaling de l'Indexer : OpenSearch reste le composant le plus delicat. Au-dela de 5 000 EPS (events per second), il faut tuner le sharding, ajuster refresh_interval a 30 secondes minimum, dedier des nodes hot/warm/cold via ISM et provisionner du SSD NVMe pour les nodes hot. Un sous-dimensionnement provoque des cluster yellow/red et des alertes silencieusement perdues.

Multi-tenancy : la separation par groupes d'agents est fonctionnelle mais incomplete. Les regles globales et les decoders sont partages entre tenants. Les MSP avec exigences strictes d'isolation deploient generalement un cluster par client.

Vulnerability Detector et endpoints air-gap : les feeds CVE necessitent une connexion sortante vers les sources NVD, OVAL et MSRC. En environnement air-gap, il faut mettre en place un proxy de feeds avec synchronisation manuelle.

Performance des decoders complexes : un decoder mal ecrit avec regex catastrophiques (backtracking exponentiel) peut faire saturer analysisd. La verification via wazuh-logtest est obligatoire avant deploiement.

Manque de detection comportementale UEBA native : Wazuh repose sur des regles deterministes. Les capacites UEBA (User and Entity Behavior Analytics) avec ML restent limitees comparees a Microsoft Sentinel ou Splunk UBA. Des integrations externes (Anomali, Elastic ML) sont necessaires.

Courbe d'apprentissage : la maitrise du langage de regles XML, la modelisation des decoders custom et le tuning de l'Indexer requierent un ingenieur SOC senior. Le delai d'autonomie pour une equipe SOC est de 4 a 6 mois.

Comparaison Wazuh vs Splunk vs Elastic Security vs Microsoft Sentinel

Le tableau ci-dessous compare Wazuh aux trois principaux concurrents sur les criteres techniques et economiques pertinents pour le choix d'une plateforme SIEM/XDR en 2026.

Historique et versions de Wazuh

Wazuh suit un cycle de release aligne sur les versions majeures Elastic/OpenSearch. Les jalons cles depuis le fork OSSEC en 2015 :

• Wazuh 1.x (2015-2016) : fork initial de OSSEC HIDS 2.8.3, ajout du module Wazuh API et de l'integration Kibana 4.
• Wazuh 2.x (2017-2018) : refonte de l'agent, support Windows ameliore, premieres regles MITRE.
• Wazuh 3.x (2018-2020) : modules cloud (AWS, Azure, GCP), Vulnerability Detector, SCA, support Elastic Stack 6.x puis 7.x.
• Wazuh 4.0 (octobre 2020) : refonte de l'API en Python aiohttp, nouveau dashboard, integration TheHive et Cortex.
• Wazuh 4.3 (mai 2022) : derniere version supportant Elasticsearch OSS, prelude a la migration OpenSearch.
• Wazuh 4.4 (janvier 2023) : migration vers OpenSearch 2.x, fork du dashboard.
• Wazuh 4.7 (decembre 2023) : support FIPS 140-2, ameliorations RBAC.
• Wazuh 4.8 (juin 2024) : nouveau Vulnerability Detector unifie en C++.
• Wazuh 4.10 (decembre 2024) : refonte Active Response, support agent ARM64.
• Wazuh 4.12 (mai 2026) : version courante, OpenSearch 2.13, ameliorations cluster manager.
• Wazuh 5.0 (Q3 2026 prevu) : refonte majeure, OpenSearch 3.x, nouvelle UI, EDR module integre.

Compatibilite avec les referentiels de conformite

Wazuh est officiellement compatible avec dix referentiels reglementaires majeurs. Pour chaque referentiel, le produit fournit des rapports preconfigures et des regles taggees.

NIS2 (Directive UE 2022/2555) : Wazuh couvre l'article 21 (mesures techniques de gestion des risques) via la collecte de logs, la detection d'incidents, le monitoring d'integrite et la gestion des vulnerabilites. Le mapping NIS2 est documente officiellement depuis Wazuh 4.9.

ISO/IEC 27001:2022 : couverture native des Annex A.5.7 (renseignement sur les menaces), A.8.15 (logging), A.8.16 (monitoring), A.8.30 (services externalises), A.5.30 (continuite IT).

MITRE ATT&CK v15 : matrice complete avec 14 tactiques et 220+ techniques mappees. Le dashboard genere une heatmap de couverture exploitable pour les exercices threat hunting et red team.

GDPR (Reglement UE 2016/679) : detection des acces non autorises a des donnees personnelles, traitement des incidents (article 33), pseudonymisation et suivi des transferts.

PCI DSS 4.0 : couverture de 70 % des controles techniques, notamment les exigences 10 (logging), 11.5 (FIM), 6.3 (vulnerability management), 1.2 (network monitoring).

HIPAA Security Rule : couverture des controles 164.308(a)(1) (security management process), 164.312(b) (audit controls), 164.312(c) (integrity), 164.312(e) (transmission security).

Autres referentiels supportes : NIST SP 800-53 Rev 5, NIST CSF 2.0, TSC (Trust Services Criteria), GPG13 (UK), CIS Controls v8.

Communaute et modele de support

Wazuh est porte par Wazuh, Inc., societe californienne fondee en 2018 apres essaimage du projet open source. La societe a leve 105 millions USD en 2024 (serie B menee par Kleiner Perkins). L'effectif depasse 250 collaborateurs en 2026, repartis entre Sunnyvale, Madrid et Bangalore.

La communaute open source compte plus de 12 000 stars GitHub, 350 contributeurs actifs et 4 500 issues fermees. Le Slack communautaire (wazuh.com/community/join-us-on-slack) reunit 14 000 membres. Les ressources officielles incluent la documentation Wazuh (1 200 pages), les Wazuh Webinars mensuels et les Wazuh Days regionaux.

Le support commercial est propose en trois tiers : Standard (8x5, SLA 24h), Premium (24x7, SLA 4h, ingenieur dedie) et Enterprise (24x7, SLA 1h, architect dedie, professional services). Les prix de support ne sont pas publics et negocies par devis selon le nombre d'agents.

Integrations natives et ecosysteme

Wazuh expose une API REST documentee OpenAPI 3.0 et des integrations preconfigurees avec les briques courantes du SOC.

Threat Intelligence : integration native MISP via le module integration-tool, alimentation de listes IOC depuis MISP events, enrichissement des alertes avec score de confiance et tags TLP.

Incident Response : integration TheHive 5 et Cortex 3 pour la creation automatique de cases et l'execution d'analyzers (VirusTotal, AbuseIPDB, MISP, Shodan, MaxMind).

Network Detection : integration Suricata IDS via lecture des eve.json, Zeek (anciennement Bro) via les logs conn/dns/ssl/http, pfSense et OPNsense via syslog.

Notification et alerting : Slack, Microsoft Teams, PagerDuty, Telegram, Email SMTP/SMTPS, webhooks generiques HTTPS.

Configuration management : roles Ansible officiels (wazuh-ansible) pour le deploiement automatise du manager, indexer, dashboard et agents. Modules Puppet et Chef communautaires.

Cloud providers : AWS (CloudTrail, GuardDuty, VPC Flow, S3, Macie), Azure (Activity Log, Sign-in, Audit, Monitor), GCP (Audit Logs, Pub/Sub), Office 365 (Management Activity API).

Container et orchestration : Docker (events daemon), Kubernetes (audit logs, kube-apiserver), CRI-O, containerd. Helm chart officiel pour deploiement Wazuh sur Kubernetes.

Coute total de possession (TCO) Wazuh

Le modele economique de Wazuh distingue deux scenarios.

Self-hosted (open source) : licence GPLv2 sans cout. Le TCO est compose de l'infrastructure (compute, stockage, reseau), du temps homme d'integration et d'exploitation, et eventuellement du support commercial.

Pour 1 000 endpoints en self-hosted on-premise, le TCO 3 ans est typiquement de :

• Infrastructure : 24 000 EUR (3 serveurs Dell PowerEdge R650, 64 GB RAM, 4 TB NVMe)
• Integration initiale : 25 000 EUR (5 jours x 5 000 EUR JH)
• Run interne : 60 000 EUR/an (0,3 ETP ingenieur SOC)
• Support Wazuh Standard (optionnel) : 18 000 EUR/an
• TCO 3 ans (sans support) : 229 000 EUR
• TCO 3 ans (avec support Standard) : 283 000 EUR

Wazuh Cloud (SaaS) : offre managee operee par Wazuh Inc. depuis AWS, eu-west-1 (Irlande) et us-east-1 (Virginie). Pricing public au tarif de 0,16 USD/agent/jour en tier Standard, soit environ 4,80 USD/agent/mois. Pour 1 000 endpoints : 58 000 USD/an, soit ~165 000 USD sur 3 ans hors integration.

Implementation pratique : prerequis et duree

Un deploiement Wazuh production-ready pour une organisation de 500 a 5 000 endpoints suit un planning standardise.

Prerequis infrastructure : trois VMs minimum (Manager, Indexer, Dashboard), 8 vCPU et 16 GB RAM par VM en demarrage, 500 GB NVMe par VM avec extension prevue. Reseau : flux 1514/UDP, 1515/TCP, 55000/TCP, 9200/TCP, 9300/TCP, 443/TCP. Latence reseau agent-manager < 100 ms.

Prerequis equipe : 1 ingenieur SOC senior (5+ ans), 1 sysadmin Linux, 1 owner produit/CISO. Pour les organisations sans equipe SOC, prevoir l'accompagnement d'un integrateur certifie Wazuh Partner.

Phasage type 90 jours :

1. Semaine 1-2 : architecture, sizing, achats, provisioning infrastructure.
2. Semaine 3-4 : installation manager + indexer + dashboard, configuration cluster.
3. Semaine 5-7 : deploiement agents par vagues (pilote 50 agents, puis 500, puis 5 000).
4. Semaine 8-9 : tuning des regles, suppression des faux positifs, customisation decoders.
5. Semaine 10-11 : integrations TheHive, MISP, Slack, Active Response.
6. Semaine 12-13 : transfert de competences, documentation, runbooks, mise en exploitation.

Pour un guide detaille, consultez notre guide de deploiement Wazuh SIEM/XDR et notre architecture SIEM hybride Wazuh + Graylog + Suricata.

Wazuh dans une architecture SOC moderne

Wazuh occupe la position centrale de SIEM/XDR dans les architectures SOC niveau 2 a niveau 3. Il est generalement couple a un NDR (Network Detection and Response) tel que Suricata ou Zeek, a une plateforme TI (MISP), a un SOAR (Shuffle ou Tines) et a un case management (TheHive). Le pipeline type collecte les logs des endpoints (Wazuh Agent), des firewalls (syslog), des cloud workloads (CloudTrail, Activity Log) et des applications metier (HTTPS, syslog, beats).

Pour aller plus loin sur les concepts SIEM, consultez notre glossaire SIEM et notre analyse approfondie du deploiement Wazuh open source.

FAQ entity-first sur Wazuh

Wazuh est-il vraiment 100 % gratuit pour un usage entreprise ?

Oui. Wazuh est distribue sous licence GPLv2, qui autorise l'usage commercial, la modification et la redistribution sans cout de licence ni redevance. Aucune fonctionnalite n'est enfermee derriere une edition payante : le code source complet est disponible sur GitHub. Les couts entreprise concernent l'infrastructure d'hebergement, le temps d'integration et, optionnellement, le support commercial Wazuh Inc.

Quelle est la difference entre Wazuh et OSSEC ?

Wazuh est un fork d'OSSEC HIDS realise en juin 2015. OSSEC reste un HIDS pur (host-based intrusion detection system) avec interface CLI minimaliste, alors que Wazuh est devenu une plateforme XDR/SIEM complete avec dashboard web, modules cloud, vuln detector, SCA, integrations TI et SOAR. OSSEC est pratiquement abandonne (derniere release majeure en 2020) tandis que Wazuh publie 4 versions majeures par an.

Wazuh peut-il remplacer un EDR commercial comme CrowdStrike ou SentinelOne ?

Partiellement. Wazuh couvre la detection comportementale via regles, le FIM, le SCA, la collecte de logs et l'Active Response. Cependant, il n'embarque pas de moteur ML/IA avance, pas de protection memoire kernel runtime (sans driver kernel-mode dedie), pas de threat hunting natif avance comme CrowdStrike Falcon Identity ou SentinelOne Singularity. Pour les organisations a faible risque ou contraintes budgetaires, Wazuh est suffisant. Pour les cibles APT sophistiquees, un EDR commercial reste recommande en complement.

Quelle taille d'infrastructure pour 10 000 agents Wazuh ?

Pour 10 000 agents avec une charge moyenne de 50 EPS par agent (500 000 EPS total), la configuration recommandee est : 3 Wazuh Managers en cluster (16 vCPU, 32 GB RAM chacun), 6 nodes Wazuh Indexer (16 vCPU, 64 GB RAM, 4 TB NVMe chacun en hot tier, 8 TB SSD warm tier), 2 Wazuh Dashboard derriere un load balancer. Stockage total environ 30 TB sur 90 jours de retention.

Wazuh est-il certifie ANSSI ou FIPS 140-2 ?

Wazuh n'est pas certifie ANSSI Common Criteria. Le mode FIPS 140-2 est supporte depuis Wazuh 4.7 via le build des composants OpenSSL en mode FIPS-compliant, requis pour les deploiements US Federal et certaines administrations europeennes. La conformite NIS2 est documentee mais ne constitue pas une certification formelle.

Comment migrer de Splunk Enterprise Security vers Wazuh ?

La migration se decompose en quatre phases : (1) inventaire des sources Splunk (Universal Forwarders, HTTP Event Collector, syslog), (2) cartographie des Splunk Apps et correlation searches vers les regles Wazuh equivalentes, (3) deploiement Wazuh en parallele de Splunk pendant 60-90 jours pour validation, (4) bascule progressive et decommissioning Splunk. Les correlation searches Splunk en SPL doivent etre reecrites en regles Wazuh XML, ce qui represente l'effort le plus consequent (4 a 12 semaines selon la complexite).

Pour aller plus loin sur Wazuh

Articles approfondis du site sur Wazuh et l'ecosysteme SIEM/XDR :

• Wazuh SIEM/XDR : guide de deploiement et detection des menaces
• Architecture SIEM hybride : Wazuh + Graylog + Suricata pour SOC
• Wazuh SIEM XDR open source : deploiement production
• Glossaire : SIEM (Security Information and Event Management)
• Datasets d'entrainement et benchmarks pour SOC
• Audit d'infrastructure : methodologie et perimetre

Ressources externes officielles :

• Site officiel Wazuh (wazuh.com)
• Depot GitHub officiel (github.com/wazuh/wazuh)
• Documentation officielle Wazuh