Wazuh può aiutare i soggetti NIS 2 a costruire log centralizzati, rilevamento, visibilità sulle vulnerabilità ed evidenze auditabili. Non rende un’organizzazione “conforme NIS 2” da solo. È un controllo tecnico che deve essere inserito in governance, gestione incidenti, gestione evidenze e trattamento del rischio documentato.
Fonti: sito ufficiale Wazuh, documentazione architettura Wazuh, determinazione ACN sugli obblighi di base, guida tecnica ENISA NIS2.
Punti chiave
- Wazuh è una piattaforma di sicurezza free e open source con capacità SIEM e XDR.
- L’architettura documentata usa agent multipiattaforma, server Wazuh, indexer e dashboard.
- Per la NIS 2 è rilevante per log, monitoraggio, alert, vulnerabilità ed evidenze operative.
- Il risultato di conformità dipende comunque da modello operativo, procedure, retention e accountability.
- Il deployment DIY riduce i costi di licenza, ma aumenta attività interne di engineering e manutenzione.
Ambito di questo articolo
Questo articolo spiega cos’è Wazuh e quando può supportare un programma di conformità NIS 2. Non sostituisce una valutazione legale, un’analisi del perimetro ACN o un disegno SOC completo.
Cos’è Wazuh?
Wazuh è una piattaforma di sicurezza open source usata per casi d’uso SIEM e XDR. In pratica raccoglie segnali da endpoint e infrastrutture, normalizza e analizza eventi, genera alert e mette a disposizione dashboard operative. La documentazione Wazuh indica che la piattaforma è free e open source, con componenti distribuiti sotto GPLv2 e Apache License 2.0.
Per le PMI il vantaggio è evidente: capacità simile a un SIEM senza un modello classico di licenza per GB o endpoint. Il tradeoff è altrettanto chiaro: l’organizzazione deve progettare, gestire, mettere in sicurezza, tarare e dimostrare la piattaforma.
Architettura Wazuh: agent, server, indexer, dashboard
| Componente | Ruolo | Rilevanza NIS 2 |
|---|---|---|
| Agent Wazuh | Raccoglie telemetria endpoint e inoltra eventi al manager. | Visibilità endpoint, evidenze asset, raccolta eventi. |
| Server Wazuh | Analizza eventi, applica decoder e regole, coordina gli agent. | Logica di rilevamento, alert, evidenze operative. |
| Indexer Wazuh | Indicizza e conserva alert ed eventi per ricerca e analisi. | Retention log, investigation, audit trail. |
| Dashboard Wazuh | Fornisce interfaccia web per alert, configurazioni e visualizzazioni. | Monitoraggio operativo e reporting. |
L’architettura può essere all-in-one per laboratori e ambienti piccoli, single-node con componenti separati per ambienti medi, oppure multi-node per throughput e alta disponibilità. Wazuh supporta anche monitoraggio agentless e ingestione syslog per dispositivi dove un agent non è possibile.
Perché Wazuh è rilevante per la NIS 2
La NIS 2 e il modello italiano di attuazione richiedono misure di gestione del rischio, gestione incidenti ed evidenze sull’operatività dei controlli. Materiali ACN ed ENISA rendono centrali log, monitoraggio, rilevamento ed evidenze di risposta.
Wazuh può supportare queste esigenze in quattro modi:
- Log centralizzati: agent e syslog possono alimentare una base comune di evidenze.
- Rilevamento: decoder e regole possono individuare attività sospette e violazioni policy.
- Visibilità vulnerabilità: inventory software e vulnerability detection supportano il trattamento del rischio.
- Reporting: dashboard ed export aiutano a dimostrare controlli operativi a management e auditor.
Confronto: Wazuh vs SIEM commerciali
| Criterio | Wazuh | SIEM commerciale |
|---|---|---|
| Licenza | Core open source, costo di ingresso più basso. | Spesso subscription, ingestion o prezzo per endpoint. |
| Deployment | Richiede skill interne Linux, storage, indexer e sicurezza. | Spesso supportato da vendor o integratore. |
| Detection content | Buona base, ma richiede tuning sull’ambiente. | Contenuti vendor spesso ampi, ma comunque da tarare. |
| Evidenze di conformità | Possibili, se governance e retention sono progettate bene. | Spesso più facili da pacchettizzare, ma non automatiche. |
| Responsabilità | Prevalentemente sull’organizzazione che implementa. | Condivisa con vendor, MSSP o integratore secondo contratto. |
Quando scegliere Wazuh
Wazuh è una buona opzione quando l’organizzazione ha competenze Linux e security engineering, vuole trasparenza sulla detection logic e può gestire retention, hardening, backup e processi di risposta. È adatto anche a laboratori, programmi NIS 2 graduali e organizzazioni che vogliono più visibilità prima di acquistare un SIEM commerciale.
Quando non sceglierlo
Wazuh non è il punto di partenza migliore se nessuno presidia triage giornaliero, onboarding delle sorgenti log, tuning regole ed escalation incidenti. Uno strumento senza capacità operativa diventa shelfware. Per soggetti regolati, questo crea falsa conformità ed evidenze deboli.
Limiti operativi e TCO
- Storage e capacità indexer vanno dimensionati su volume eventi e retention.
- Le regole richiedono tuning per ridurre falsi positivi e detection mancata.
- Disponibilità, backup, cifratura e accessi amministrativi vanno progettati.
- La notifica incidente resta un obbligo di processo. Wazuh può allertare, ma non decide da solo la notifica regolatoria.
Coordinamento con un servizio managed
Le organizzazioni che apprezzano Wazuh ma non hanno capacità SOC possono usarlo in un modello managed. La Cyber Console e il servizio vCISO Aegister aiutano a collegare telemetria, governance, evidenze e reporting direzionale.
Modello di implementazione per un programma NIS 2
Un programma Wazuh pratico dovrebbe essere gestito come progetto di implementazione controlli. L’organizzazione deve prima definire i servizi in perimetro, poi identificare i sistemi che li supportano, quindi decidere quali eventi servono per dimostrare monitoraggio e risposta. Questo evita l’errore comune di raccogliere log facili, ma non rilevanti.
Il pacchetto minimo di governance dovrebbe includere registro sorgenti log, matrice ownership SIEM, decisione di retention, procedura di review alert e mappa escalation incidente. Non è burocrazia. È il collegamento tra strumento tecnico ed evidenze attese in un contesto regolato.
Checklist evidenze per readiness Wazuh
| Evidenza | Perché conta | Owner |
|---|---|---|
| Registro sorgenti log | Mostra quali sistemi critici sono monitorati e quali no. | IT/security operations |
| Policy retention | Spiega per quanto tempo alert e archive log sono conservati. | CISO/legale |
| Record tuning regole | Documenta perché le soglie di detection sono state cambiate. | SOC o security lead |
| Procedura escalation | Collega alert, risposta incidente e triage regolatorio. | Incident manager |
| Report management | Mostra copertura, rischi aperti e maturità controlli alla direzione. | CISO/vCISO |
Errori frequenti di implementazione
- Deployment tool-first: Wazuh viene installato prima di definire cosa deve provare.
- Alert senza owner: gli alert esistono, ma nessun ruolo ne cura triage e chiusura.
- Retention senza restore: i log sono conservati, ma backup e recupero SIEM non sono testati.
- Accessi admin troppo ampi: dashboard e API hanno privilegi più estesi del necessario.
- Nessun routing regolatorio: gli incidenti sono gestiti tecnicamente, ma non mappati alla notifica NIS 2.
Come posizionare Wazuh nello stack controlli
Wazuh va trattato come una parte dello stack controlli. Può fornire telemetria e alert, ma deve integrarsi con asset management, vulnerability management, ticketing, backup, rischio fornitore e reporting direzionale. Senza questi collegamenti, il SIEM resta un’isola di monitoraggio.
Il target maturo è una catena tracciabile: servizio critico → asset di supporto → sorgenti log monitorate → regole → alert → ticket → decisione incidente → evidenza management. Questa catena rende la piattaforma utile per compliance e governance rischio.
Roadmap di adozione in 90 giorni
| Fase | Obiettivo | Output |
|---|---|---|
| Giorni 1-30 | Definire scope e architettura pilot. | Mappa servizi, registro sorgenti log, pilot. |
| Giorni 31-60 | Onboard sistemi prioritari e validare alert. | Agent connessi, alert test, escalation. |
| Giorni 61-90 | Preparare evidenze e decidere modello operativo. | Report management, gap list, runbook. |
Questa roadmap mantiene focalizzato il primo deployment. Evita lo schema in cui il team installa la piattaforma, collega troppe sorgenti rumorose e non trasforma gli alert in evidenze utilizzabili.
Modello di copertura per servizi
Per la NIS 2 conta più la copertura dei servizi che il numero di endpoint. Pochi sistemi critici possono pesare più di centinaia di endpoint a basso impatto. Il modello deve partire dai servizi, mappare dipendenze e poi elencare le sorgenti log. Così le priorità di monitoraggio sono difendibili.
Passaggio a governance operativa
Alla fine della prima fase, l’ownership Wazuh deve passare da progetto a operatività. Il passaggio deve nominare owner per salute piattaforma, tuning regole, onboarding sorgenti, export evidenze, test backup e reporting. Senza questo passaggio, il SIEM resta un artefatto di progetto.
Navigazione della serie
- deployment passo-passo di Wazuh
- gestione centralizzata dei log con Wazuh
- confronto Wazuh vs SIEM commerciale
- rilevamento ed event monitoring NIS2
- registri operativi, log, backup e ripristino
FAQ
Wazuh basta per essere conformi alla NIS 2?
No. Wazuh supporta diversi controlli tecnici, ma la conformità richiede governance, policy, gestione del rischio, procedure incidente ed evidenze.
Wazuh è davvero open source?
La documentazione Wazuh descrive la piattaforma come free e open source, con componenti sotto GPLv2 e Apache License 2.0. Ogni organizzazione deve comunque verificare licensing e integrazioni.
Wazuh può sostituire un SOC?
No. Può supportare workflow SOC, ma qualcuno deve monitorare alert, investigare, tarare regole e riportare gli esiti.