Wazuh 5.0 è la nuova major release del SIEM/XDR open source Wazuh. Non è un aggiornamento incrementale: cambiano il formato delle regole (da XML a YAML/Sigma), il modello di normalizzazione dei log, l’organizzazione del contenuto di detection e diversi moduli chiave. In questo articolo analizziamo tutte le differenze rispetto a Wazuh 4.x, cosa comporta l’upgrade e come prepararsi.
In sintesi
- Le regole passano da XML a YAML in formato Sigma. Le regole e i decoder scritti per Wazuh 4.x non funzionano su Wazuh 5.0: vanno riscritti.
- I livelli di severità cambiano: non più
rule levelda 0 a 15, macritical / high / medium / low. - Arriva la normalizzazione nativa: log di sorgenti diverse (Windows, Linux, firewall) vengono mappati sugli stessi campi comuni, quindi una sola regola e una sola dashboard li coprono entrambi.
- Nuovo modulo Security Analytics: il tab Events è sostituito da Findings.
- Le KVDB sostituiscono le CDB list per whitelist, blacklist e liste di lookup.
- Non serve più riavviare il manager per attivare una nuova regola.
- Non esiste (ancora) un tool di migrazione automatico da 4.x a 5.0. La riscrittura è manuale o affidata a un partner.
Analisi tecnica a cura di Cyberdef, Wazuh Gold Partner. Le funzionalità descritte si riferiscono alla nuova major release: aggiorneremo l’articolo con l’uscita della versione stabile e della documentazione ufficiale.
Cos’è Wazuh 5.0
Wazuh 5.0 è la major release che riscrive il motore di analisi di Wazuh attorno a due principi: normalizzazione dei dati all’ingestione e detection in formato Sigma. In Wazuh 4.x ogni sorgente di log manteneva i propri nomi di campo, e le regole XML dovevano gestire le eccezioni sorgente per sorgente. In Wazuh 5.0 i decoder mappano i log su uno schema di campi comune prima che le regole li valutino: la detection lavora su dati già uniformi.
La conseguenza pratica è che la stessa regola funziona su sorgenti diverse — un tentativo di accesso fallito su Windows e uno su Linux finiscono negli stessi campi, nella stessa vista, senza dashboard separate.
Wazuh 4.x e Wazuh 5.0 a confronto
| Ambito | Wazuh 4.x | Wazuh 5.0 |
|---|---|---|
| Formato regole | XML proprietario | YAML in formato Sigma |
| Severità | rule level 0–15 |
critical / high / medium / low |
| Normalizzazione | Parziale, campi specifici per sorgente | Nativa, schema di campi comune |
| Liste di lookup | CDB list | KVDB (key-value database) |
| Organizzazione contenuti | File di configurazione sul manager | Spaces: Draft → Test → Custom / Standard |
| Attivazione regole | Richiede riavvio del manager | Nessun riavvio, live al ciclo successivo |
| Analisi eventi | Tab Events | Modulo Security Analytics, tab Findings |
| SCA | Verifica per singolo agente | Query globali su tutto il parco agenti |
| Compliance mapping | PCI DSS, GDPR, NIST, HIPAA, TSC… | Idem + CMMC + ISO 27001 |
| Threat intelligence | Integrazioni da configurare | CTI cloud, IOC e regole aggiornati ogni ora |
Le novità di Wazuh 5.0, una per una
1. Regole Sigma in YAML
Il cambiamento più visibile. Una regola Wazuh 5.0 è un file YAML in formato Sigma, con un blocco di metadati (id, prodotto, tecniche e tattiche MITRE ATT&CK), un blocco detection con la condizione, il livello di severità e uno status che distingue le regole stable (pronte per la produzione) da quelle experiment (in collaudo).
Sigma è uno standard aperto e diffuso: significa poter attingere a regole di detection scritte dalla community e ridurre il lock-in sul formato proprietario. Il rovescio della medaglia è che tutto il contenuto XML esistente va riscritto. Ne parliamo in dettaglio nell’articolo dedicato: da XML a YAML: perché regole e decoder vanno riscritti.
2. Normalizzazione nativa dei log
I decoder di Wazuh 5.0 fanno due cose: estraggono i pezzi dal log grezzo (parse) e li mappano su campi comuni (normalize). L’IP sorgente di un log Apache e quello di un evento Windows finiscono nello stesso campo. Da qui derivano quasi tutti gli altri vantaggi della release: regole affidabili, dashboard unificate, mapping MITRE e compliance automatici. Approfondimento: la normalizzazione in Wazuh 5.0.
3. Gli “spaces”: Draft, Test, Custom, Standard
Wazuh 5.0 introduce un ciclo di vita esplicito per il contenuto di detection. Regole, decoder, integrazioni e KVDB vivono in quattro spazi, e il contenuto viene promosso da sinistra a destra:
- Draft — l’area di lavoro. Niente di ciò che sta qui è attivo. Si scrive e si costruisce.
- Test — si valida ciò che si è costruito lanciando eventi sintetici, prima di andare in produzione.
- Custom — la produzione. Le regole e i decoder che il team scrive e mantiene.
- Standard — il contenuto ufficiale Wazuh, distribuito dal cloud CTI. È disattivabile se si vuole lavorare solo con contenuto proprio.
È un modello che porta finalmente una logica da detection engineering dentro la piattaforma: si smette di modificare file di produzione a mano e si adotta un flusso con collaudo esplicito.
4. KVDB al posto delle CDB list
Le KVDB (key-value database) sostituiscono le CDB list per gestire whitelist e blacklist di IP, domini e hash. La funzione è la stessa — liste di lookup interrogate dalle regole — ma cambia il formato: chi ha liste popolate in 4.x dovrà riversarle nel nuovo formato.
5. Deploy senza riavvio del manager
In Wazuh 4.x ogni nuova regola richiedeva il riavvio del manager. In Wazuh 5.0 si scrive o si incolla la regola direttamente da browser e diventa attiva al ciclo successivo, senza restart. Per chi gestisce ambienti in produzione con SLA è una differenza operativa concreta: la finestra di manutenzione per aggiungere una detection sparisce.
La piattaforma include anche un test integrato delle regole: si incolla un log campione e si osserva come viene normalizzato e se genera un alert, senza dover ricorrere a strumenti esterni.
6. Threat intelligence (CTI) con enrichment automatico
Wazuh 5.0 sincronizza IOC e nuove regole dal cloud CTI ogni ora, automaticamente. Ogni evento che matcha un indicatore viene arricchito con contesto: confidence score, prima osservazione dell’indicatore, alias e tipologia del malware, geolocalizzazione dell’IP sorgente.
La differenza è netta: lo stesso attacco brute force lanciato da un IP “pulito” produce un finding essenziale, mentre lo stesso attacco da un IP già noto come malevolo arriva all’analista completo di contesto e confidence al 100%. Meno lavoro manuale di arricchimento, triage più rapido.
7. SCA con query globali
Il modulo Security Configuration Assessment in Wazuh 4.x lavorava per singolo agente: per sapere quali macchine avevano il firewall disabilitato su un parco di migliaia di endpoint, bisognava interrogarle una per una. In Wazuh 5.0 le query sono globali: una domanda, una risposta su tutto il parco.
È un cambiamento che pesa più di quanto sembri. Le tre porte d’ingresso più comuni di un attaccante sono credenziali rubate, una vulnerabilità nota e non sanata, e una misconfigurazione rilevata ma mai corretta. SCA dà la visibilità: la remediation resta un processo che l’organizzazione deve presidiare.
8. Compliance: arrivano CMMC e ISO 27001
Al mapping di compliance già presente si aggiungono CMMC e ISO 27001, visibili direttamente nel dettaglio della regola insieme alle tattiche e tecniche MITRE ATT&CK. Ogni finding porta con sé i controlli normativi che tocca — utile per chi deve dimostrare copertura in un audit o in un percorso NIS2.
9. Security Analytics: da “Events” a “Findings”
Il nuovo modulo Security Analytics sostituisce la vecchia vista Events con il tab Findings. La differenza non è cosmetica: grazie alla normalizzazione, una singola dashboard ricostruisce l’intera kill chain — beaconing verso C2, drop del malware, system discovery, credential dumping, defense evasion, esfiltrazione — con ogni fase taggata automaticamente alla tecnica MITRE corrispondente, e con eventi Windows e Linux nello stesso pannello.
10. Active Response configurabile da dashboard
Le azioni di risposta automatica (cancellare un file riconosciuto come malevolo, chiudere una sessione RDP durante un tentativo di esfiltrazione) si configurano direttamente dalla dashboard, senza mettere mano al backend: condizione basata sul titolo o sulla severità della regola, azione, notifica. I canali di notifica supportati includono Slack, Microsoft Teams, Discord, email, Jira, PagerDuty e Shuffle.
Attenzione: l’Active Response non è attivo di default. Va configurato esplicitamente. È una scelta di progetto sensata — una risposta automatica su un falso positivo può cancellare un file legittimo — ma significa che non va dato per scontato in fase di collaudo.
11. AI e LLM: mettiamo ordine
Su questo punto circola parecchia confusione, quindi vale la pena essere precisi. Wazuh 5.0 non include un motore AI o un LLM locale integrato di default. L’enrichment “automatico” di cui si parla è basato su CTI: regole, decoder e vulnerabilità sincronizzati dal cloud di threat intelligence, non un modello linguistico che ragiona sugli alert.
È possibile integrare LLM esterni (ChatGPT, Gemini e simili) per arricchire o spiegare i finding, ma l’integrazione è manuale, richiede accesso al manager e va progettata caso per caso. Non esiste ancora documentazione ufficiale in merito.
Cosa comporta l’upgrade da Wazuh 4.x
Qui sta il punto che ogni organizzazione con Wazuh in produzione deve mettere a bilancio: l’upgrade a Wazuh 5.0 non è un semplice update.
- Le regole e i decoder XML non funzionano su 5.0. Vanno riscritti in YAML/Sigma — e non è solo una conversione di sintassi: cambia anche la semantica delle condizioni.
- Non esiste un tool di migrazione automatico. Wazuh offre supporto professionale a pagamento per la migrazione.
- Le CDB list vanno riversate in KVDB.
- L’Active Response va riconfigurato nel nuovo modello.
Più contenuto custom avete costruito in questi anni, più il lavoro di migrazione pesa. Un ambiente con poche decine di regole custom si riscrive in tempi contenuti; un ambiente maturo, con decoder su sorgenti proprietarie e regole di correlazione stratificate, richiede una pianificazione seria.
Conviene passare subito a Wazuh 5.0?
La nostra indicazione, oggi: testare sì, migrare la produzione non ancora.
La beta è scaricabile e utilizzabile per farsi un’idea concreta. Allo stato attuale mancano però ancora due elementi non secondari: la documentazione ufficiale su come scrivere regole e decoder nel nuovo formato, e un validatore di sintassi che segnali gli errori prima del deploy. Entrambi sono attesi con la release stabile.
La strategia ragionevole è quindi: allestire un ambiente di test con la 5.0, inventariare il contenuto custom in produzione, stimare il lavoro di riscrittura e pianificare la migrazione quando la versione stabile e la sua documentazione saranno disponibili. Chi si fa trovare pronto non subirà l’upgrade: lo governerà.
Domande frequenti su Wazuh 5.0
Le regole di Wazuh 4.x funzionano su Wazuh 5.0?
No. Le regole e i decoder scritti in XML per Wazuh 4.x non sono compatibili con Wazuh 5.0, che utilizza YAML in formato Sigma. Vanno riscritti, sia nella sintassi sia nella logica delle condizioni.
Esiste un tool per migrare automaticamente le regole da Wazuh 4.x a 5.0?
Al momento non esiste un tool di migrazione automatico. La riscrittura è manuale. Wazuh mette a disposizione servizi professionali a pagamento per accompagnare la migrazione, e un partner certificato può gestire l’intero processo.
Cosa sono gli “spaces” in Wazuh 5.0?
Gli spaces sono i quattro contenitori in cui vive il contenuto di detection: Draft (bozza, non attivo), Test (validazione con eventi sintetici), Custom (produzione, contenuto proprio) e Standard (contenuto ufficiale Wazuh dal cloud CTI). Il contenuto viene promosso da Draft verso Custom.
In Wazuh 5.0 esistono ancora i rule level da 0 a 15?
No. I livelli numerici 0–15 di Wazuh 4.x sono sostituiti da quattro livelli di severità: critical, high, medium e low.
Wazuh 5.0 ha un’intelligenza artificiale integrata?
No, non di default. Wazuh 5.0 non include un LLM locale. L’arricchimento automatico degli alert è basato sul cloud di threat intelligence (CTI), non su un modello linguistico. È possibile integrare LLM esterni, ma richiede un’integrazione manuale sul manager.
Bisogna riavviare il manager per attivare una regola in Wazuh 5.0?
No. In Wazuh 5.0 le regole diventano attive al ciclo successivo senza riavvio del manager, a differenza di Wazuh 4.x dove il restart era necessario.
Quando esce la versione stabile di Wazuh 5.0?
Il rilascio della versione stabile è previsto a breve. Con la release stabile sono attese anche la documentazione ufficiale per la scrittura di regole e decoder e le funzionalità di validazione della sintassi.
Wazuh Gold Partner
State valutando il passaggio a Wazuh 5.0?
Cyberdef è Wazuh Gold Partner: progettiamo, installiamo e gestiamo ambienti Wazuh in produzione per aziende e Pubbliche Amministrazioni. Possiamo aiutarvi a inventariare le regole e i decoder custom in uso, stimare il lavoro di migrazione a Wazuh 5.0 e pianificare l’upgrade senza interruzioni del presidio di sicurezza.
Vedere prima, reagire meglio. Anche durante una migrazione.
Parliamo della vostra migrazione →Scopri di più: Cyberdef, Wazuh Gold Partner · I nostri servizi Wazuh
