Wazuh SIEM: Incident Response in 12 Passi [2026]

Quando un team di sicurezza scopre un accesso sospetto alle tre di notte, la differenza tra un incidente contenuto in venti minuti e uno che finisce sui giornali sta quasi sempre nella visibilità. Non nel budget, non nel numero di analisti disponibili. Chi ha già i log giusti, correlati e pronti da interrogare, vince quella corsa. Chi deve prima capire dove cercare, la perde. Wazuh è uno degli strumenti open source che più aziende italiane ed europee stanno adottando proprio per colmare quel vuoto, e la versione 4.14.8, rilasciata il 23 settembre 2026, conferma che il progetto è tutt’altro che fermo: sei release stabili solo nel corso dell’anno.

In questo tutorial costruiamo da zero un ambiente di incident response basato su Wazuh: installazione del server, primo agente, File Integrity Monitoring, rilevamento vulnerabilità, regole di detection su misura, risposta automatica e integrazione con i canali di notifica. Dodici passi, un progetto funzionante alla fine, e una checklist di errori da evitare per chi lo mette in produzione sul serio.

Cos’è Wazuh e perché conviene per l’incident response

Wazuh nasce come fork di OSSEC nel 2015 e si è evoluto in una piattaforma SIEM/XDR completa: raccoglie log da endpoint, cloud e applicazioni, li correla con regole di detection, verifica la conformità a standard come PCI DSS e GDPR, e può reagire in automatico a un attacco in corso. È distribuito con licenza open source e gira sia on-premise sia in cloud, con agenti disponibili per Linux, Windows e macOS. Il repository GitHub del progetto si avvicina alle 17.000 stelle, un segnale di una community attiva che continua a testarlo e contribuire nel tempo.

La parte interessante per chi si occupa di incident response non è la raccolta dei log in sé, ma cosa succede dopo. Wazuh struttura il flusso in quattro fasi: rilevamento (le regole individuano un evento anomalo), arricchimento (l’evento viene collegato a inventario, vulnerabilità note e contesto dell’host), notifica (l’alert raggiunge Slack, email o un sistema di ticketing) e, quando configurato, risposta automatica (blocco di un IP, isolamento di un processo, disattivazione di un account). Nessuno di questi passaggi richiede licenze aggiuntive: è tutto incluso nella distribuzione core.

Le release pubblicate nel 2026 mostrano dove il progetto sta investendo: la 4.14.2 di gennaio ha aggiunto una policy SCA (Security Configuration Assessment) per Windows Server 2025, la 4.14.3 di febbraio ha introdotto il supporto CIS per macOS 26 Tahoe, mentre la 4.14.7 di luglio ha rafforzato la sicurezza delle API con pool di thread limitati, timeout sulle espressioni regolari e limiti sulla dimensione dei payload, oltre a correggere un bug nell’active response ip-customblock. Sono dettagli tecnici, ma raccontano un prodotto che viene aggiornato con la cadenza tipica di un progetto maturo, non abbandonato a se stesso dopo il lancio.

Prerequisiti: hardware, sistemi operativi e versioni

Prima di installare qualsiasi cosa vale la pena dimensionare correttamente l’ambiente. Wazuh è composto da tre elementi che nella versione “all-in-one” convivono sulla stessa macchina: il Wazuh Server (motore di analisi e API), l’Indexer (basato su tecnologia OpenSearch, memorizza gli alert) e la Dashboard (interfaccia web). Per un laboratorio o una piccola infrastruttura fino a 50 agenti, una singola VM con le seguenti caratteristiche è sufficiente.

Componente	Requisito minimo (lab)	Requisito consigliato (produzione, fino a 200 agenti)
Sistema operativo server	Ubuntu 22.04 LTS / 24.04 LTS	Ubuntu 24.04 LTS o CentOS Stream 9
CPU	4 vCPU	8 vCPU
RAM	8 GB	16 GB o più
Storage	50 GB SSD	200 GB SSD, con retention pianificata
Versione Wazuh	4.14.8 (23 settembre 2026)	4.14.8 o successiva branch stabile
Agenti supportati	Linux, Windows, macOS	Linux, Windows Server 2025, macOS 26 Tahoe

Oltre all’hardware, servono alcuni permessi e accessi: un utente con privilegi sudo sul server, le porte 1514/TCP e 1515/TCP aperte per la comunicazione con gli agenti, la porta 55000/TCP per l’API REST e la 443/TCP per la dashboard. Se il server sta dietro un firewall aziendale, va aperta anche la porta in uscita verso i repository ufficiali Wazuh durante l’installazione. Per chi lavora in un contesto regolato da GDPR o NIS2, conviene già in questa fase decidere dove finiranno i log (data center in UE, per evitare complicazioni sul trasferimento dati) e per quanto tempo verranno conservati, perché la retention incide direttamente sullo storage necessario.

Passo 1 – Dimensionare il server prima dell’installazione

Il primo errore che si commette con qualunque SIEM è installarlo su una macchina sottodimensionata e scoprirlo solo quando l’Indexer inizia a rifiutare scritture. Una regola pratica: ogni agente attivo genera in media tra 5 e 15 MB di eventi indicizzati al giorno, a seconda di quanti moduli (FIM, vulnerability detector, log collector) sono attivi. Con 50 agenti e una retention di 90 giorni, il calcolo approssimativo è 50 × 10 MB × 90 giorni, cioè circa 45 GB solo per l’indice degli alert, a cui vanno aggiunti i log grezzi se si sceglie di conservarli.

Prima di procedere, verificate anche l’orologio di sistema: Wazuh Server, Indexer e Dashboard comunicano tramite certificati TLS con controllo di validità temporale, e uno sfasamento anche di pochi minuti tra i tre nodi (nel caso di un’installazione distribuita) è una delle cause più comuni di errori di connessione durante il primo avvio. Sincronizzate NTP prima di installare, non dopo.

Passo 2 – Installare Wazuh Server con lo script all-in-one

Wazuh distribuisce uno script di installazione assistita che gestisce da solo la generazione dei certificati, l’installazione dei tre componenti e la configurazione di base. Per un ambiente di test o una piccola azienda è il metodo più rapido per avere un SIEM funzionante in meno di trenta minuti.

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash wazuh-install.sh -a

# Al termine, lo script stampa le credenziali generate per l'utente admin
# della dashboard. Salvatele subito in un password manager: non vengono
# mostrate una seconda volta senza rigenerare i certificati.

Lo script scarica ed esegue in sequenza l’installazione dell’Indexer, del Server e della Dashboard, generando automaticamente i certificati TLS per la comunicazione interna. L’intero processo richiede in genere tra i 10 e i 20 minuti su una VM con le specifiche indicate sopra, a seconda della velocità della connessione ai repository. Se preferite un’installazione distribuita su tre nodi separati (scelta consigliata oltre i 100 agenti), lo stesso script accetta parametri per generare solo i certificati o installare un singolo componente per volta, e la documentazione ufficiale copre entrambi gli scenari nel dettaglio.

Una volta completata l’installazione, verificate che i tre servizi siano attivi:

sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard

# Output atteso per ciascun servizio:
# Active: active (running) since ...

Se uno dei tre servizi risulta in stato failed, non proseguite: risolvete prima quel problema (nella sezione troubleshooting più avanti trovate le cause più frequenti), perché installare agenti su un server instabile produce solo alert persi e falsi negativi.

Passo 3 – Primo accesso alla dashboard e hardening delle password

Aprite un browser su https://IP_DEL_SERVER e accedete con le credenziali admin generate al passo precedente. La prima cosa da fare, prima ancora di collegare un agente, è cambiare la password di tutti gli utenti interni (admin, kibanaserver, logstash) usando lo strumento incluso wazuh-passwords-tool, e attivare l’autenticazione a due fattori per gli account umani che accederanno alla dashboard. Un SIEM che protegge tutta l’infrastruttura ma resta accessibile con una password di default è un paradosso che si vede più spesso di quanto si pensi.

sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh \
  -u admin -p 'NuovaPasswordComplessa!2026'

# Rigenera l'hash della password per l'utente indicato e la propaga
# all'Indexer. Ripetere per ogni account di servizio predefinito.

Da qui in poi, la dashboard mostra tre sezioni principali: Security events (gli alert generati dalle regole), Threat hunting (ricerca libera sui log indicizzati) e Endpoints (inventario e stato degli agenti). All’inizio saranno tutte vuote: è normale, perché non abbiamo ancora collegato nessun endpoint da monitorare.

Passo 4 – Installare l’agente su Linux (Ubuntu/Debian)

Gli agenti sono il modo in cui Wazuh raccoglie telemetria dagli endpoint: log di autenticazione, integrità dei file, pacchetti installati, configurazione di sistema. Su una macchina Linux da monitorare, l’installazione richiede tre comandi.

curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.8-1_amd64.deb
sudo WAZUH_MANAGER='IP_DEL_SERVER' dpkg -i ./wazuh-agent.deb

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

La variabile WAZUH_MANAGER punta l’agente verso l’indirizzo IP o il nome host del server installato al passo 2. Dopo l’avvio del servizio, tornate nella dashboard, sezione Endpoints: il nuovo agente dovrebbe comparire entro pochi secondi con stato “Active”. Se resta in stato “Pending” per più di un minuto, quasi sempre è un problema di rete tra agente e manager sulla porta 1514, non un problema dell’agente stesso.

Passo 5 – Installare l’agente su Windows Server

Buona parte degli incidenti reali in azienda coinvolge Windows Server o workstation Windows, quindi coprire questo sistema operativo non è opzionale. L’installazione via PowerShell con privilegi amministrativi è la via più veloce per un roll-out su più macchine tramite GPO o strumenti di gestione centralizzata.

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.8-1.msi -OutFile $env:tmp\wazuh-agent.msi
msiexec.exe /i $env:tmp\wazuh-agent.msi /q WAZUH_MANAGER='IP_DEL_SERVER'

NET START WazuhSvc

La release 4.14.3 ha aggiunto ai messaggi di keep-alive di Windows i metadati di hostname e architettura, un dettaglio che aiuta molto quando bisogna distinguere rapidamente decine di server con nomi simili durante un’indagine. Su Windows Server 2025 è disponibile anche la policy SCA dedicata introdotta con la 4.14.2, che confronta la configurazione del sistema con le baseline di hardening consigliate e segnala gli scostamenti direttamente in dashboard.

Passo 6 – Attivare il File Integrity Monitoring (FIM)

Il File Integrity Monitoring è probabilmente il modulo più utile in un incidente di tipo ransomware o web shell: rileva creazione, modifica, spostamento o cancellazione di file in tempo quasi reale. Si configura nel file ossec.conf dell’agente, indicando quali directory sorvegliare.

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>

  <directories realtime="yes" report_changes="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories realtime="yes">/var/www/html</directories>

  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
</syscheck>

L’attributo realtime="yes" usa inotify su Linux (o eBPF nelle release più recenti) per notificare le modifiche appena avvengono, invece di aspettare la scansione periodica ogni 43.200 secondi (12 ore). Le versioni 2026 di Wazuh hanno corretto proprio alcuni bug del FIM basato su eBPF relativi a kernel Amazon Linux meno recenti e alla gestione di spostamenti e rinomine di file, quindi se avevate provato il FIM in tempo reale in passato con risultati inconsistenti, vale la pena riprovare con la 4.14.8.

Un output tipico di un alert FIM sulla dashboard, dopo aver modificato un file monitorato, assomiglia a questo:

{
  "rule": {"level": 7, "description": "Integrity checksum changed."},
  "syscheck": {
    "path": "/var/www/html/wp-config.php",
    "event": "modified",
    "size_after": "3421",
    "md5_after": "a1b2c3d4e5f6...",
    "uid_after": "www-data"
  },
  "agent": {"name": "web-01", "id": "003"}
}

Questo tipo di alert, incrociato con l’orario e l’utente che ha effettuato l’accesso SSH nello stesso intervallo, è spesso il primo indizio concreto di una web shell caricata su un server compromesso.

Passo 7 – Attivare il Vulnerability Detector

Il modulo Vulnerability Detector confronta l’inventario software raccolto da ogni agente con database pubblici di vulnerabilità note, segnalando quali pacchetti installati corrispondono a CVE pubblicate. Si attiva lato server, non serve toccare la configurazione degli agenti.

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Riavviate il servizio con sudo systemctl restart wazuh-manager dopo la modifica. La prima sincronizzazione del feed di vulnerabilità può richiedere diversi minuti a seconda della connessione del server. Una volta completata, la sezione “Vulnerability Detection” della dashboard elenca ogni agente con il conteggio di CVE critiche, alte, medie e basse trovate sul software installato. La versione 4.14.6 ha corretto un problema relativo all’arresto non pulito dello scanner, quindi se lavorate con release precedenti e notate il modulo che si blocca a metà scansione, l’aggiornamento risolve direttamente il problema.

Passo 8 – Scrivere una regola di detection personalizzata

Le regole incluse in Wazuh coprono centinaia di scenari comuni, ma il valore reale di un SIEM emerge quando si scrivono regole su misura per l’ambiente specifico. Un caso classico: rilevare tentativi ripetuti di login SSH falliti dallo stesso indirizzo IP, un pattern tipico di brute force.

<group name="ssh,authentication_failures,">
  <rule id="100010" level="10" frequency="5" timeframe="120">
    <if_matched_sid>5716</if_matched_sid>
    <description>SSH: 5 tentativi di login falliti in 2 minuti dallo stesso IP</description>
    <group>authentication_failures,pci_dss_10.2.4,gdpr_IV_35.7.d,</group>
  </rule>
</group>

La regola 100010 si attiva quando la regola base 5716 (login SSH fallito) si ripete cinque volte nello stesso intervallo di 120 secondi dallo stesso agente, e assegna un livello di gravità 10, sufficiente a generare una notifica immediata se l’integrazione email o Slack è configurata con soglia minima 7 o superiore. I tag pci_dss_10.2.4 e gdpr_IV_35.7.d non sono decorativi: servono a mappare automaticamente l’alert ai requisiti di compliance corrispondenti, utile quando bisogna dimostrare a un auditor che il monitoraggio degli accessi falliti è effettivamente in funzione.

Salvate la regola in /var/ossec/etc/rules/local_rules.xml sul server e riavviate il manager. Testate sempre una nuova regola con lo strumento wazuh-logtest prima di considerarla pronta per la produzione: permette di incollare una riga di log reale e vedere immediatamente se e quale regola scatta, senza dover generare un evento reale sull’endpoint.

Passo 9 – Configurare l’Active Response per il blocco automatico

L’Active Response è la funzione che trasforma Wazuh da semplice sistema di allerta a strumento di contenimento automatico. Quando una regola supera una certa soglia di gravità, Wazuh può eseguire uno script sull’endpoint interessato: bloccare un IP nel firewall, disabilitare un account, terminare un processo.

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100010</rules_id>
  <timeout>600</timeout>
</active-response>

Con questa configurazione, ogni volta che scatta la regola 100010 creata al passo precedente, Wazuh blocca l’IP sorgente per 600 secondi (10 minuti) direttamente sull’endpoint colpito, tramite iptables o il firewall nativo del sistema operativo. La release 4.14.7 ha aggiunto un controllo di validazione dell’indirizzo IP proprio all’active response ip-customblock, per evitare che un IP malformato o un campo vuoto nel log sorgente generi comandi di blocco inattesi: un dettaglio piccolo ma importante quando si automatizza una risposta che tocca direttamente il firewall di produzione.

La raccomandazione pratica qui è di iniziare sempre con timeout brevi (5-10 minuti) e regole a bassa ambiguità, come i tentativi di brute force, prima di estendere l’active response a scenari più complessi. Un falso positivo che blocca per errore l’IP di un ufficio remoto per dieci minuti è gestibile, uno che lo blocca per ore genera un secondo incidente sopra il primo.

Passo 10 – Integrare Wazuh con Slack e posta elettronica

Un alert che nessuno vede non serve a niente. L’integrazione con Slack richiede un webhook e poche righe nel file ossec.conf del manager.

<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/XXX/YYY/ZZZ</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Impostando level a 10, solo gli alert di gravità pari o superiore raggiungono il canale Slack del team, evitando di sommergere gli analisti con notifiche a bassa priorità che finirebbero per essere ignorate. Per la posta elettronica, la configurazione equivalente usa il blocco <email_notification>yes</email_notification> insieme ai parametri SMTP. Per un SOC di piccole dimensioni conviene comunque affidarsi a Slack o a un sistema di ticketing per la triage quotidiana, riservando l’email agli alert critici che richiedono un’escalation notturna.

Passo 11 – Costruire un runbook di incident response

Avere Wazuh che genera alert corretti è solo metà del lavoro: senza un runbook che dica chi fa cosa quando un alert di gravità 12 arriva alle due di notte, la tecnologia da sola non riduce il tempo di risposta. Un runbook minimo, costruito attorno a Wazuh, dovrebbe coprire almeno cinque fasi.

Triage: chi riceve l’alert per primo, entro quanti minuti deve confermare la ricezione, e con quale criterio distingue un falso positivo da un incidente reale.
Scoping: quali altri host, utenti o servizi vanno controllati appena si conferma l’incidente, usando la sezione Threat hunting della dashboard per cercare indicatori correlati.
Contenimento: quali active response sono già configurate e pronte, e quali azioni manuali restano necessarie (isolamento di rete, reset password, revoca token).
Eradicazione e recovery: rimozione della causa (file malevolo, account compromesso, vulnerabilità sfruttata) e ripristino del servizio.
Lezioni apprese: revisione post-incidente per capire se serve una nuova regola di detection o un aggiustamento delle soglie esistenti.

Questo schema riprende, semplificandolo, il ciclo di incident response che GDPR e NIS2 impongono formalmente alle organizzazioni europee: il GDPR (articolo 33) richiede la notifica di una violazione dei dati personali all’autorità di controllo entro 72 ore dalla scoperta, mentre la NIS2 impone alle entità essenziali e importanti un allarme preliminare entro 24 ore e una notifica completa entro 72 ore. Avere già pronti i log e le timeline che Wazuh genera automaticamente è ciò che rende materialmente possibile rispettare quelle scadenze, invece di passare le prime 48 ore a ricostruire manualmente cosa è successo.

Passo 12 – Backup, aggiornamento e manutenzione periodica

Un SIEM che non viene mantenuto perde valore rapidamente: regole obsolete, feed di vulnerabilità non aggiornati, indici che crescono senza controllo fino a riempire il disco. Tre attività ricorrenti vanno pianificate fin dal primo giorno.

# Backup della configurazione e delle regole personalizzate (settimanale)
sudo tar -czf wazuh-config-backup-$(date +%F).tar.gz /var/ossec/etc

# Verifica spazio occupato dagli indici Wazuh (giornaliera)
curl -k -u admin:PASSWORD https://localhost:9200/_cat/indices?v | grep wazuh

# Aggiornamento a una nuova versione minore (dopo aver letto le release notes)
sudo apt update && sudo apt install wazuh-manager wazuh-indexer wazuh-dashboard

Per la gestione della retention, la policy Index State Management dell’Indexer permette di definire regole automatiche di rollover e cancellazione degli indici più vecchi di N giorni, evitando interventi manuali. Prima di ogni aggiornamento maggiore, leggete sempre le release notes ufficiali: nel 2026 diverse patch (dalla 4.14.2 alla 4.14.8) hanno toccato dipendenze di sicurezza come aiohttp, cryptography, PyJWT, starlette, urllib3 e protobuf, quindi restare troppo indietro con le versioni significa accumulare anche debito di sicurezza sullo strumento che dovrebbe proteggervi.

Errori comuni da evitare

Cinque errori ricorrono più di tutti gli altri in chi installa Wazuh per la prima volta, e vale la pena elencarli esplicitamente perché sono facili da evitare se li si conosce in anticipo.

Installare senza sincronizzare l’orologio di sistema: certificati TLS e comunicazione tra Indexer, Server e Dashboard dipendono da timestamp coerenti, e uno sfasamento di pochi minuti blocca l’intera piattaforma con errori difficili da diagnosticare.
Attivare tutte le regole di default senza tarare le soglie: porta a centinaia di alert a bassa gravità al giorno, gli analisti smettono di guardarli, e quando arriva l’alert vero si perde nel rumore.
Dimenticare l’hardening delle password di servizio (kibanaserver, logstash) dopo l’installazione automatica: sono credenziali generate dallo script, non pensate per restare invariate in produzione.
Configurare l’Active Response con timeout troppo lunghi su regole non ancora testate, rischiando di bloccare per ore indirizzi IP legittimi per un falso positivo.
Non pianificare la retention degli indici: senza una policy ILM, lo storage si riempie in poche settimane e il servizio Indexer smette di accettare nuovi eventi proprio quando servono di più.

Risoluzione dei problemi più comuni

Anche seguendo la guida alla lettera, capitano intoppi. Ecco le situazioni più frequenti segnalate da chi implementa Wazuh e come risolverle.

Problema	Causa probabile	Soluzione
L’agente resta in stato “Never connected”	Porta 1515/TCP bloccata dal firewall, usata per la registrazione iniziale	Aprire la porta 1515 solo per il traffico verso il manager e ritentare la registrazione
La dashboard mostra “Kibana server is not ready yet”	Il servizio Indexer non ha terminato l’avvio o ha esaurito la memoria heap	Verificare i log in `/var/log/wazuh-indexer/` e aumentare la heap JVM se necessario
Nessun alert compare nonostante l’agente sia attivo	Le regole per quel tipo di log non sono abilitate o il log non viene raccolto	Verificare con `wazuh-logtest` e controllare i decoder configurati
Errore di certificato durante l’installazione distribuita	Orologi di sistema non sincronizzati tra i nodi	Installare e verificare NTP su tutti i nodi prima di generare i certificati
Il Vulnerability Detector resta bloccato a metà scansione	Bug noto nelle versioni precedenti alla 4.14.6	Aggiornare a 4.14.6 o successiva, che corregge l’arresto non pulito dello scanner
L’Active Response non blocca l’IP atteso	Lo script `firewall-drop` non ha i permessi di eseguibile o iptables non è installato	Verificare permessi in `/var/ossec/active-response/bin/` e la presenza di iptables/nftables
Troppi falsi positivi sulle regole SSH	Soglia di frequenza troppo bassa per l’ambiente reale	Alzare il valore `frequency` e `timeframe` nella regola personalizzata
L’integrazione Slack non invia notifiche	URL webhook errato o livello soglia impostato troppo alto	Testare il webhook con curl separatamente e verificare il parametro `level`

Per una diagnosi più approfondita, il comando /var/ossec/bin/wazuh-control status lato server e sudo systemctl status wazuh-agent lato endpoint restano il primo passo prima di aprire i file di log, che si trovano rispettivamente in /var/ossec/logs/ossec.log su entrambi i lati dell’installazione.

Wazuh vs Elastic Security vs Splunk: quale scegliere

Nessuno dei tre strumenti è oggettivamente “migliore”: la scelta dipende dal budget, dal team disponibile e dalla scala dell’infrastruttura da coprire. Wazuh punta tutto sull’essere open source con licenza software a costo zero, lasciando i costi reali su infrastruttura e competenze operative interne. Elastic Security costruisce la sicurezza sopra lo stack Elastic già ampiamente usato per log e osservabilità, con funzionalità aggiuntive legate al livello di licenza scelto. Splunk resta il punto di riferimento per grandi organizzazioni che necessitano di SOAR maturo, UEBA e un ecosistema di integrazioni molto esteso, a fronte di un costo commerciale generalmente più alto e legato al volume di dati ingeriti.

Criterio	Wazuh	Elastic Security	Splunk
Modello di licenza	Open source, gratuito	Free tier + livelli commerciali	Commerciale
Costo principale	Infrastruttura e personale	Ingest, retention, tier di licenza	Volume dati ingeriti e moduli premium
Agenti endpoint	Wazuh Agent (Linux, Windows, macOS)	Elastic Agent	Universal Forwarder e collettori dedicati
Active response nativa	Sì, inclusa nel core	Dipende dal tier e dalle integrazioni	Tramite SOAR, spesso licenza separata
Miglior adattamento	PMI, laboratori, MSSP, contesti con budget limitato	Chi già usa Elastic per log e osservabilità	Grandi imprese con esigenze di governance estese

Per un’azienda italiana di medie dimensioni che deve dimostrare conformità a NIS2 con un budget contenuto, Wazuh è spesso il punto di partenza più ragionevole proprio perché toglie dal tavolo il costo della licenza e lascia investire quel budget in ore di configurazione e tuning delle regole, che sono comunque necessarie con qualunque piattaforma si scelga.

Consigli avanzati per ambienti di produzione

Superata la fase di primo deployment, alcuni accorgimenti fanno la differenza tra un SIEM che regge nel tempo e uno che va in affanno dopo pochi mesi. Primo: passate a un’architettura distribuita (Server, Indexer e Dashboard su nodi separati, con Indexer in cluster a tre nodi) non appena superate i 100 agenti attivi, perché la configurazione all-in-one non scala bene oltre quella soglia e ogni componente inizia a competere per le stesse risorse. Secondo: integrate Wazuh con un feed di threat intelligence esterno tramite le API REST del manager, arricchendo gli alert con reputazione IP e hash di file noti come malevoli, invece di affidarvi solo alle regole statiche incluse di default.

Terzo: automatizzate il deployment degli agenti con strumenti di configuration management (Ansible, Puppet o GPO su Windows) invece di installarli a mano host per host, perché la differenza tra un parco di 20 e uno di 200 endpoint sta tutta nella ripetibilità del processo di onboarding. Quarto: programmate revisioni trimestrali delle regole personalizzate confrontandole con gli incidenti reali dell’ultimo trimestre, chiedendovi ogni volta se una regola avrebbe rilevato prima l’attacco che avete gestito, e se serve aggiungerla. Infine, non sottovalutate l’API REST di Wazuh per costruire dashboard di reporting su misura per il management: un SOC che sa raccontare in numeri il proprio lavoro (tempo medio di rilevamento, tempo medio di risposta, numero di incidenti contenuti prima dell’escalation) ottiene più facilmente il budget per continuare a migliorare.

Il progetto completo: cosa avete costruito

Seguendo i dodici passi di questa guida avete messo in piedi un ambiente di incident response funzionante: un server Wazuh 4.14.8 con Indexer e Dashboard attivi, almeno un agente Linux e uno Windows che inviano telemetria, il File Integrity Monitoring attivo sulle directory critiche, il Vulnerability Detector che confronta l’inventario software con le CVE note, una regola di detection personalizzata per i tentativi di brute force SSH, un’Active Response che blocca automaticamente gli IP sospetti, notifiche Slack per gli alert ad alta gravità e un runbook scritto che definisce chi fa cosa durante un incidente reale.

Non è ancora un SOC completo, ma è già molto più di quello che la maggior parte delle piccole e medie imprese italiane ha in funzione oggi. E, cosa non secondaria, è tutto costruito su software open source: nessun costo di licenza da giustificare a bilancio, e piena libertà di adattare regole e integrazioni man mano che l’infrastruttura cresce.

Domande frequenti

Wazuh è davvero gratuito o ci sono costi nascosti?

Il software Wazuh (server, indexer, dashboard, agenti) è open source e non richiede licenze. I costi reali riguardano l’infrastruttura su cui gira (server, storage, banda) e il tempo del personale necessario per configurarlo, mantenerlo e tarare le regole di detection. Chi non ha competenze interne può rivolgersi a fornitori terzi che offrono supporto gestito basato su Wazuh, e in quel caso il costo diventa un servizio, non una licenza software.

Quanti agenti può gestire un singolo server Wazuh?

Un’installazione all-in-one su una VM con 8 vCPU e 16 GB di RAM regge in genere fino a un centinaio di agenti attivi, a seconda dei moduli abilitati e del volume di log generato. Oltre questa soglia conviene passare a un’architettura distribuita con Indexer in cluster su più nodi, per evitare colli di bottiglia su CPU e I/O disco.

Wazuh sostituisce un antivirus o un EDR tradizionale?

No. Wazuh è un SIEM/XDR orientato alla raccolta, correlazione e risposta su eventi di sicurezza, non un motore antivirus con firme e analisi comportamentale del malware allo stesso livello di un EDR dedicato. Molte organizzazioni lo usano in combinazione con un antivirus o EDR esistente, sfruttando Wazuh per correlare gli alert generati da quegli strumenti con il resto della telemetria di sistema.

Serve competenza in XML per usare Wazuh ogni giorno?

Per l’uso quotidiano (consultare alert, cercare eventi, gestire endpoint) no: la dashboard copre queste attività con un’interfaccia grafica. La sintassi XML entra in gioco quando si scrivono regole personalizzate, decoder o configurazioni avanzate di Active Response, attività tipicamente riservate a chi amministra la piattaforma piuttosto che a tutti gli analisti che la consultano.

Wazuh include gruppi di regole già mappati su requisiti di compliance come PCI DSS, HIPAA e GDPR, che permettono di filtrare gli alert per requisito normativo specifico. Questo non sostituisce una valutazione legale di conformità, ma fornisce la base tecnica (log centralizzati, timeline degli eventi, evidenza delle misure di monitoraggio) che serve poi a dimostrare la due diligence richiesta da GDPR e NIS2 in caso di controllo o di notifica di una violazione.

Cosa cambia tra le versioni 4.14 e le voci su Wazuh 5.0?

Alla data di questa guida, la release stabile ufficiale pubblicata dal progetto è la 4.14.8, del 23 settembre 2026. Informazioni su una versione 5.0 circolano in fonti terze ma non risultano confermate come release stabile ufficiale: prima di pianificare un aggiornamento a una major version, verificate sempre la pagina ufficiale delle release notes di Wazuh.

Posso installare Wazuh in cloud invece che on-premise?

Sì, l’installazione funziona allo stesso modo su una VM cloud (AWS, Azure, GCP) o on-premise: l’unica differenza pratica riguarda la configurazione di rete e dei security group per aprire le porte necessarie. Per organizzazioni europee soggette a GDPR, la scelta della region cloud dove ospitare server Wazuh e relativi log va valutata insieme al proprio responsabile della protezione dei dati, in particolare se i log includono dati personali degli utenti monitorati.

Quanto tempo serve per vedere i primi alert utili?

Seguendo questa guida, un server funzionante con il primo agente collegato richiede in genere meno di un’ora. I primi alert generati dalle regole di default compaiono immediatamente, ma la fase di tuning (eliminare i falsi positivi, scrivere regole specifiche per il proprio ambiente) richiede tipicamente due o tre settimane di osservazione prima che il sistema produca segnali davvero affidabili e utilizzabili in un runbook di incident response.

Fonti e approfondimenti ufficiali: note di rilascio ufficiali di Wazuh, repository GitHub del progetto, OWASP, NIST Cybersecurity Framework e testo consolidato del GDPR.