Di tutte le novità di Wazuh 5.0, la normalizzazione è quella di cui si parla meno e che cambia di più. Non è una feature tra le altre: è il presupposto tecnico da cui dipendono le regole Sigma, la dashboard unificata, il mapping MITRE automatico e l’arricchimento con threat intelligence. Capire come funziona significa capire perché Wazuh 5.0 è una rottura e non un aggiornamento.
In sintesi
- Normalizzare significa mappare i campi di log provenienti da sorgenti diverse su un insieme di campi comuni: l’IP sorgente di un log Apache e quello di un evento Windows finiscono nello stesso campo.
- In Wazuh 5.0 la normalizzazione avviene nel decoder, prima che le regole valutino l’evento. La detection lavora quindi su dati già uniformi.
- È ciò che rende affidabili le regole Sigma: nessuna confusione sui nomi dei campi, nessuna eccezione specifica per sorgente.
- Abilita la vista unica: un attacco su Windows e uno su Linux compaiono nella stessa dashboard, con gli stessi campi.
- Abilita l’automazione: mapping MITRE ATT&CK, compliance e arricchimento CTI applicati a ogni match, senza lavoro manuale.
Il problema che la normalizzazione risolve
Chi ha gestito un SIEM conosce bene il fastidio. Un tentativo di accesso fallito su un server Windows genera un evento con una certa struttura e certi nomi di campo. Lo stesso tentativo su un server Linux, via SSH, produce un log PAM completamente diverso: altro formato, altri campi, altra semantica. Un firewall ne produce un terzo. Un applicativo verticale un quarto.
In Wazuh 4.x la conseguenza era doppia. Da un lato, le regole dovevano conoscere ogni sorgente: nomi di campo diversi, eccezioni, condizioni specifiche. Dall’altro, l’analista doveva saltare da una dashboard all’altra per ricostruire che quei tre eventi erano lo stesso attacco visto da tre angolazioni.
Il costo non è teorico: è tempo di triage, sono detection che non scattano perché il campo si chiamava diversamente, sono correlazioni che nessuno fa perché sono troppo faticose da fare a mano.
Cos’è la normalizzazione in Wazuh 5.0
La normalizzazione è il processo con cui Wazuh 5.0 traduce ogni log, qualunque sia la sua origine, in un insieme di campi comuni e condivisi. Non conta più come la sorgente chiama l’indirizzo IP di provenienza: dopo la normalizzazione quell’informazione si trova sempre nello stesso posto.
La differenza rispetto a 4.x è dove avviene. In Wazuh 5.0 la normalizzazione è parte integrante del decoder ed è la prima cosa che accade al dato, prima che qualunque regola lo veda. Le regole non ricevono più log grezzi eterogenei: ricevono eventi già strutturati.
In una frase: in Wazuh 4.x la regola doveva adattarsi al log. In Wazuh 5.0 è il log che si adatta a uno schema comune, e la regola può finalmente essere scritta una volta sola.
Per il quadro completo di tutte le novità della release, vedi la nostra analisi: Wazuh 5.0: tutte le novità e le differenze rispetto a Wazuh 4.x.
Come funziona: la pipeline in cinque passaggi
- Ingestione. Il log arriva dall’agente o dall’integrazione configurata (un firewall, un server web, un database).
- Parse. Il decoder estrae i pezzi dal log grezzo usando pattern e template. È la fase meccanica: prendere la stringa e spezzarla nei suoi componenti.
- Normalize. La fase decisiva. I pezzi estratti vengono mappati sui campi comuni. L’IP sorgente identificato in un log Apache viene scritto nel campo
sourcestandard, dove ogni regola si aspetta di trovarlo. - Detection. Le regole Sigma valutano l’evento normalizzato. La condizione è leggibile e non contiene eccezioni per sorgente, perché non ne ha bisogno.
- Enrichment. A ogni match vengono applicati automaticamente il mapping MITRE ATT&CK, i riferimenti di compliance e l’arricchimento con threat intelligence.
Il decoder: dove avviene il lavoro
Un decoder Wazuh 5.0 è composto da tre parti, e vale la pena guardarle da vicino perché è qui che si concentra il lavoro di chi dovrà migrare.
- Il blocco di identità — nome, autore, versione. Metadati.
- Il parent decoder — il decoder da cui si eredita. Non serve ripartire da zero per ogni sorgente: si può appoggiarsi ai decoder core o al generic message decoder e specializzare solo ciò che è davvero specifico. È un principio di riuso che riduce molto il lavoro, se lo si sfrutta.
- Il blocco parse e normalize — l’estrazione dei campi dal log grezzo e la loro mappatura sullo schema comune.
Il punto che sfugge a molti in fase di stima: migrare un decoder non è tradurne la sintassi, è decidere la mappatura. Per ogni informazione che il vostro decoder custom estraeva, bisogna stabilire su quale campo normalizzato va scritta. È una decisione di progettazione, non un’operazione meccanica — ed è la ragione per cui non esiste un convertitore automatico. Approfondiamo il tema qui: da XML a YAML: perché regole e decoder vanno riscritti.
Un esempio concreto: brute force su Windows e su Linux
Prendiamo uno scenario concreto: un attacco brute force lanciato in parallelo contro un server Windows esposto via RDP e un server Linux via SSH.
Le due sorgenti producono log completamente diversi: un evento di sicurezza Windows di autenticazione fallita da una parte, un log PAM di autenticazione fallita dall’altra. In Wazuh 4.x sarebbero stati due formati, due set di campi, due dashboard.
In Wazuh 5.0 entrambi vengono normalizzati sugli stessi campi e compaiono nella stessa vista, con lo stesso filtro, nella stessa ricerca. L’analista vede un unico attacco su due fronti, non due incidenti separati da correlare a mano.
La differenza si vede anche sull’arricchimento: il brute force proveniente da un IP “pulito” produce un finding essenziale, con geolocalizzazione e campi normalizzati. Quello proveniente da un IP già noto come malevolo arriva all’analista completo di contesto CTI — confidence score al 100%, prima osservazione dell’indicatore, alias e tipologia del software malevolo associato. Stesso attacco, due livelli di informazione, zero lavoro manuale.
Cosa abilita, concretamente, la normalizzazione
| Capacità | Perché dipende dalla normalizzazione |
|---|---|
| Regole Sigma affidabili | Sigma presuppone campi con nomi noti. Senza normalizzazione, ogni regola andrebbe adattata alla sorgente e lo standard perderebbe senso. |
| Dashboard unica (Findings) | Una vista sola può contenere Windows e Linux solo se i loro eventi condividono gli stessi campi. |
| MITRE ATT&CK automatico | Il tagging delle tecniche a ogni match richiede che il match avvenga su una struttura prevedibile. |
| Compliance mapping | I riferimenti normativi (ISO 27001, CMMC, NIST e gli altri già supportati) vengono associati al finding in modo sistematico. |
| Enrichment CTI | Per confrontare un IP con un IOC bisogna sapere con certezza in quale campo si trova quell’IP, qualunque sia la sorgente. |
Detto in modo diretto: la normalizzazione è l’investimento che rende automatico tutto il resto. È anche il motivo per cui il lavoro di migrazione si concentra sui decoder — sono loro a produrre il dato pulito su cui tutta la catena poggia. Un decoder mappato male non rompe solo una regola: degrada silenziosamente la detection, il mapping MITRE, la compliance e l’arricchimento CTI di tutta quella sorgente.
Cosa significa per chi ha già Wazuh in produzione
Se avete Wazuh 4.x con decoder custom su sorgenti proprietarie — un gestionale interno, un applicativo verticale, un apparato di rete non standard — la normalizzazione è al tempo stesso la cosa che guadagnerete e il lavoro che dovrete fare.
Il guadagno è reale: detection che smettono di rompersi quando una sorgente cambia formato, un’unica vista di incident, correlazione tra piattaforme che prima richiedeva lavoro manuale.
Il lavoro, altrettanto: ogni decoder custom va ripensato in termini di mappatura sui campi comuni. È un’attività che si può iniziare oggi, prima ancora che esca la versione stabile, perché non dipende dagli strumenti: dipende dalla conoscenza delle vostre sorgenti. Ed è l’attività che, quando la release stabile arriverà, farà la differenza tra chi migra in settimane e chi ci mette mesi.
Domande frequenti sulla normalizzazione in Wazuh 5.0
Che cos’è la normalizzazione dei log in Wazuh 5.0?
È il processo con cui i decoder mappano i campi di log provenienti da sorgenti diverse su un insieme di campi comuni. L’indirizzo IP sorgente di un log Apache e quello di un evento Windows finiscono nello stesso campo, così le regole possono valutarli allo stesso modo.
Dove avviene la normalizzazione: nel decoder o nella regola?
Nel decoder. Il decoder prima estrae i pezzi dal log grezzo (parse), poi li mappa sui campi comuni (normalize). Le regole Sigma ricevono già l’evento normalizzato e non devono conoscere il formato originale della sorgente.
Perché la normalizzazione è importante per le regole Sigma?
Perché Sigma presuppone che i campi abbiano nomi noti e stabili. Senza normalizzazione ogni regola andrebbe adattata alla singola sorgente, con eccezioni e casi particolari, e il vantaggio dello standard aperto verrebbe meno.
La normalizzazione permette di vedere Windows e Linux nella stessa dashboard?
Sì. È uno degli effetti più concreti: eventi di autenticazione fallita su Windows e su Linux, pur avendo formati di log completamente diversi, vengono normalizzati sugli stessi campi e compaiono nella stessa vista Findings, senza dashboard separate.
I miei decoder custom di Wazuh 4.x vanno riscritti?
Sì. I decoder XML di Wazuh 4.x non funzionano su Wazuh 5.0. La riscrittura non è una semplice traduzione di sintassi: per ogni informazione estratta bisogna decidere su quale campo normalizzato mapparla. È un lavoro di progettazione, ed è la ragione per cui non esiste un convertitore automatico.
Posso riutilizzare i decoder standard invece di scriverne di nuovi?
Sì, ed è consigliabile. Wazuh 5.0 prevede il concetto di parent decoder: si può ereditare da un decoder core o dal generic message decoder e specializzare soltanto ciò che è realmente specifico della propria sorgente, riducendo il lavoro di migrazione.
Wazuh Gold Partner
I vostri decoder sono pronti per la normalizzazione?
La mappatura dei campi è il lavoro che decide la qualità della detection dopo la migrazione — e si può iniziare subito, senza aspettare la release stabile. Cyberdef è Wazuh Gold Partner: analizziamo le vostre sorgenti di log, progettiamo la mappatura sui campi normalizzati di Wazuh 5.0 e riscriviamo decoder e regole senza lasciare buchi nel presidio.
Sapere cosa sta accadendo è il primo livello di difesa.
Parliamo dei vostri log →Scopri di più: Cyberdef, Wazuh Gold Partner · I nostri servizi Wazuh
