Wazuh 5.0: da XML a YAML. Perché regole e decoder vanno riscritti

È la prima domanda che ci fanno i clienti da quando è stata annunciata la nuova major release: “le mie regole Wazuh continueranno a funzionare?”. La risposta è netta, ed è meglio conoscerla ora che scoprirla durante un upgrade: no. In Wazuh 5.0 le regole passano da XML a YAML in formato Sigma, e tutto il contenuto di detection custom va riscritto. Vediamo cosa cambia esattamente, quanto lavoro comporta e come affrontarlo in modo ordinato.

Perché Wazuh ha abbandonato l’XML

Il formato XML delle regole Wazuh ha accompagnato la piattaforma per anni, ma portava con sé due limiti strutturali. Il primo: era un formato proprietario, che costringeva a riscrivere da zero ogni detection nata altrove. Il secondo, più insidioso: le regole dovevano fare i conti con i nomi di campo specifici di ogni sorgente, moltiplicando eccezioni e casi particolari.

Wazuh 5.0 risolve entrambi i problemi con una scelta unica: le regole diventano Sigma in YAML e girano su dati già normalizzati. Sigma è lo standard aperto di riferimento per le regole di detection — significa poter attingere alla vastissima libreria della community e ridurre il lock-in. La normalizzazione fa il resto: le condizioni lavorano su campi comuni, senza confusione di nomi. Ne parliamo qui: la normalizzazione in Wazuh 5.0.

Il prezzo di questo salto è la discontinuità. Non c’è retrocompatibilità: il vecchio contenuto non gira.

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.

Cosa cambia concretamente: XML 4.x contro YAML/Sigma 5.0

Anatomia di una regola Wazuh 5.0

Una regola in Wazuh 5.0 è un documento YAML strutturato. I blocchi che la compongono:

• Metadati — identificativo della regola, prodotto di riferimento (per esempio Windows), autore, versione.
• MITRE ATT&CK — tattiche e tecniche associate, dichiarate una volta e applicate automaticamente a ogni match.
• detection — il cuore della regola: la condizione, espressa in forma leggibile sui campi normalizzati (per esempio: una connessione che corrisponde a un IP malevolo noto).
• level — la severità: critical, high, medium o low.
• status — stable se la regola è pronta per la produzione, experiment se è ancora in collaudo. Un dettaglio prezioso: rende esplicito, a chi legge, se può fidarsi di quella detection.
• enabled — regola attiva o disattiva.

Anatomia di un decoder Wazuh 5.0

Il decoder è il pezzo che spesso viene sottovalutato nella pianificazione della migrazione, e che invece determina se le regole funzioneranno. In Wazuh 5.0 un decoder ha tre parti:

1. Identità — nome, autore, versione.
2. Parent — il decoder padre da cui eredita. Non serve ricostruire tutto da zero: si può partire dai decoder core o dal generic message decoder e specializzare solo ciò che serve.
3. Parse e normalize — la parte decisiva. Il blocco di parse estrae i pezzi dal log grezzo usando pattern; il blocco di normalize li mappa sui campi comuni. L’IP sorgente di un log Apache viene mappato sul campo source standard, e da lì in poi ogni regola Sigma lo trova dove si aspetta di trovarlo.

Chi ha scritto decoder custom su sorgenti proprietarie in 4.x — un gestionale interno, un apparato di rete non standard, un applicativo verticale — deve mettere in conto che questi decoder vanno ripensati, non tradotti: il lavoro non è riscrivere l’espressione di parsing, ma decidere su quali campi normalizzati mappare ogni informazione estratta.

Dai rule level 0–15 ai quattro livelli di severità

Chi lavora con Wazuh da anni ha costruito automatismi, soglie di alerting e integrazioni sui rule level numerici. In Wazuh 5.0 questa scala sparisce e lascia il posto a quattro livelli: critical, high, medium, low.

Il rimappaggio non è solo interno alle regole. Va rivisto tutto ciò che a valle dipendeva dal livello numerico: filtri di notifica, soglie di escalation, integrazioni con ticketing, script di active response, report. È una voce di lavoro che nelle stime viene quasi sempre dimenticata, e che invece va censita.

Il nuovo ciclo di vita: Draft, Test, Custom

Wazuh 5.0 non cambia solo il formato: cambia il modo di lavorare. Il contenuto di detection vive in spazi distinti e viene promosso in avanti.

• Draft — dove si scrive. Nulla è attivo. Prima si crea l’integrazione (il firewall, il database, l’applicativo), poi il decoder, poi la regola, poi eventualmente la KVDB.
• Test — dove si valida. Si incolla un log campione e si osserva come viene normalizzato e se genera l’alert atteso, prima di andare in produzione.
• Custom — la produzione. Il contenuto che il vostro team possiede e mantiene.
• Standard — il contenuto ufficiale Wazuh, sincronizzato dal cloud CTI. Disattivabile se si vuole lavorare solo con regole proprie.

Per chi ha sempre modificato file di configurazione direttamente sul manager, è un cambio di abitudini: la piattaforma ora impone un percorso di collaudo. È una buona notizia. Riduce drasticamente il rischio di mandare in produzione una regola che genera migliaia di falsi positivi.

E, non secondario: non serve più riavviare il manager. La regola scritta da browser diventa attiva al ciclo successivo. La finestra di manutenzione per aggiungere una detection sparisce.

Cosa manca ancora (e va tenuto presente)

Sono tre buone ragioni per non precipitarsi a migrare la produzione oggi — e altrettante per iniziare subito il lavoro di analisi, che non dipende da nessuno dei tre.

Come affrontare la migrazione: il metodo in sei passi

Questo è l’approccio con cui stiamo pianificando la migrazione per i nostri clienti. Funziona perché separa il lavoro che si può fare ora da quello che va fatto dopo la release stabile.

1. Inventario. Censire ogni regola custom, ogni decoder custom, ogni CDB list, ogni configurazione di active response e ogni integrazione a valle che dipende dal rule level. Senza inventario non esiste stima. Si può fare oggi.
2. Prioritizzazione. Non tutte le regole custom meritano di sopravvivere. La migrazione è l’occasione per eliminare le detection morte, quelle che generano solo rumore e quelle ormai coperte dal contenuto Standard di Wazuh. Spesso si scopre che una quota rilevante del contenuto custom è ridondante.
3. Mappatura dei campi. Per ogni sorgente proprietaria, decidere su quali campi normalizzati mappare le informazioni. È il lavoro intellettuale vero della migrazione, e va fatto prima di scrivere una riga di YAML.
4. Riscrittura in Draft. Decoder prima, regole poi. Sfruttando i parent decoder per non riscrivere ciò che esiste già.
5. Collaudo in Test. Con log reali prelevati dall’ambiente di produzione, non con esempi teorici. È qui che si scoprono le condizioni che non si comportano come ci si aspettava.
6. Promozione in Custom e verifica a valle. Compresa la revisione di notifiche, soglie e integrazioni rimappate sui nuovi livelli di severità.

Quanto lavoro comporta davvero?

Dipende interamente da quanto contenuto custom avete costruito. Un ambiente con poche decine di regole personalizzate e nessun decoder proprietario si riscrive in tempi contenuti. Un ambiente maturo — decoder su applicativi verticali, regole di correlazione stratificate negli anni, liste CDB popolate, active response cablate sui livelli numerici — richiede un progetto vero, con analisi, riscrittura, collaudo e finestra di switch.

Il rischio da evitare è uno solo: arrivare all’upgrade senza aver fatto l’inventario, scoprire a migrazione avviata che metà delle detection non funziona più, e restare scoperti proprio nel momento in cui si stanno toccando i sistemi. Un SIEM che non rileva è peggio di un SIEM assente: dà una falsa sensazione di presidio.

La sicurezza non è un costo: è continuità. E una migrazione governata è esattamente il modo in cui si difende quella continuità.

Domande frequenti sulla migrazione a Wazuh 5.0

Devo riscrivere tutte le regole per passare a Wazuh 5.0?

Sì, tutte le regole e i decoder custom scritti in XML per Wazuh 4.x vanno riscritti in YAML formato Sigma. Le regole del contenuto Standard di Wazuh sono invece già fornite nel nuovo formato: la riscrittura riguarda solo ciò che avete personalizzato.

Posso convertire automaticamente le regole XML in YAML?

Al momento non esiste un tool ufficiale di conversione automatica. E la conversione non sarebbe comunque puramente meccanica: cambia anche la semantica delle condizioni, che vanno rimappate sui campi normalizzati del nuovo schema.

Cosa succede alle mie CDB list?

Le CDB list sono sostituite dalle KVDB (key-value database). La funzione è la stessa — whitelist, blacklist di IP, domini e hash — ma il formato cambia e le liste esistenti vanno riversate.

Cosa succede alle mie configurazioni di Active Response?

Vanno riconfigurate nel nuovo modello. In Wazuh 5.0 l’Active Response si configura dalla dashboard, con condizioni basate sul titolo o sulla severità della regola. Attenzione: non è attivo di default, va abilitato esplicitamente.

Che cos’è Sigma e perché Wazuh lo ha adottato?

Sigma è uno standard aperto per scrivere regole di detection in YAML, indipendente dal SIEM. Wazuh lo ha adottato per allinearsi a un formato condiviso dalla community, ridurre il lock-in su un formato proprietario e permettere di riutilizzare regole scritte al di fuori dell’ecosistema Wazuh.

Conviene migrare subito a Wazuh 5.0?

La nostra indicazione è provare la nuova versione in un ambiente dedicato e avviare subito l’inventario del contenuto custom, ma attendere la release stabile per migrare la produzione: mancano ancora la documentazione ufficiale sulla scrittura di regole e decoder e un validatore di sintassi.

Chi può aiutarmi nella migrazione delle regole Wazuh?

Wazuh offre servizi professionali a pagamento per la migrazione. In alternativa, un partner certificato può gestire l’intero processo: inventario, prioritizzazione, riscrittura di regole e decoder, collaudo e switch in produzione. Cyberdef è Wazuh Gold Partner e segue migrazioni di ambienti in produzione.

Wazuh Gold Partner

Quante regole custom avete in produzione oggi?

Se la risposta non è immediata, l’inventario è il primo passo — ed è anche quello che si può fare subito, senza aspettare la release stabile. Cyberdef è Wazuh Gold Partner: censiamo il vostro contenuto custom, individuiamo cosa merita di sopravvivere alla migrazione, riscriviamo regole e decoder in YAML/Sigma e collaudiamo tutto prima dello switch.

Non interveniamo quando succede. Lavoriamo perché non succeda.

Richiedi un assessment di migrazione →

Scopri di più: Cyberdef, Wazuh Gold Partner · I nostri servizi Wazuh