Un deployment Wazuh per la NIS 2 deve partire da architettura ed evidenze, non dallo script di installazione. L’obiettivo pratico è raccogliere gli eventi corretti, proteggere il SIEM, conservare evidenze utilizzabili e collegare gli alert alle procedure di risposta.
Fonti: guida installazione Wazuh, deployment agent Linux Wazuh, architettura Wazuh, determinazione ACN obblighi di base.
Punti chiave
- Usare la documentazione ufficiale Wazuh per comandi e versioni correnti.
- Scegliere all-in-one solo per lab o ambienti piccoli; separare i componenti quando serve disponibilità.
- Mettere in sicurezza accessi amministrativi, TLS, backup e retention prima di acquisire log sensibili.
- Il rollout agent deve seguire criticità degli asset, non comodità operativa.
- La validazione deve includere alert, retention, restore backup ed escalation.
Prerequisiti hardware, software e modello operativo
Prima dell’installazione, definire numero endpoint, volume log, retention, modello amministratori, posizione backup e workflow di escalation. La documentazione Wazuh supporta componenti centrali su host unico o configurazioni distribuite. Un programma NIS 2 deve anche definire chi rivede gli alert e chi decide l’escalation.
Architetture di deployment
| Architettura | Uso tipico | Attenzione NIS 2 |
|---|---|---|
| All-in-one | Lab, pilot, ambiente molto piccolo. | Single point of failure; resilienza limitata. |
| Componenti separati single-node | Ambiente medio, ruoli più chiari. | Richiede disegno rete e TLS. |
| Multi-node | Alta disponibilità e throughput più elevato. | Richiede competenze cluster e backup. |
| Cloud/SaaS | Minore carico infrastrutturale. | Verificare dati, contratto, evidenze e rischio fornitore. |
Installazione dei componenti centrali Wazuh
La guida ufficiale documenta la sequenza: indexer Wazuh, server Wazuh e dashboard Wazuh. Per un lab è disponibile anche un quickstart all-in-one. Il seguente esempio è un pattern, non sostituisce la guida ufficiale.
# Esempio: verificare sempre i comandi correnti nella documentazione Wazuh
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
sudo bash ./wazuh-install.sh -aPer produzione, usare il workflow step-by-step dei componenti centrali. Conservare le credenziali generate in modo sicuro e ruotarle secondo la policy sugli accessi privilegiati.
Configurazione di indexer e dashboard
Dopo il deployment, validare accesso dashboard, account amministrativi, certificati TLS, salute degli indici, allocazione disco e autenticazione. La dashboard entra nella catena delle evidenze regolatorie, quindi ruoli e access log vanno governati.
Deployment degli agent Wazuh
Gli agent Wazuh possono essere installati su Linux, Windows, macOS e altre piattaforme supportate. Iniziare da sistemi che supportano servizi essenziali, identità, asset esposti a Internet e tooling di sicurezza.
# Pattern Linux agent dal workflow pacchetti ufficiale
WAZUH_MANAGER="wazuh-manager.example.local" apt-get install wazuh-agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agentUsare gruppi per classe server, servizio business, ambiente e criticità. Non mescolare endpoint produzione e test senza tagging chiaro.
Configurazione iniziale: gruppi, regole, decoder
La configurazione iniziale deve definire gruppi agent, regole baseline, soglie di severità e copertura delle sorgenti log. Regole e decoder sono potenti, ma modifiche non governate creano rumore o zone cieche. Ogni tuning deve avere un change log.
Hardening e sicurezza dell’installazione
- Limitare amministrazione dashboard a utenti nominativi e MFA dove disponibile.
- Esporre in rete solo le porte necessarie.
- Separare compiti amministrativi e attività analyst giornaliere.
- Proteggere backup di configurazioni, certificati e credenziali.
- Documentare retention e cancellazione rispetto a requisiti legali e operativi.
Backup e disaster recovery
Per la NIS 2, disponibilità di log e SIEM conta durante gli incidenti. Eseguire backup di configurazioni, certificati, dashboard, regole e indici rilevanti. Testare il restore, non solo la creazione del backup.
Validazione del deployment
- Confermare connessione degli agent prioritari.
- Generare eventi di test controllati e verificare gli alert.
- Controllare retention e crescita indici rispetto allo storage.
- Testare ingestione syslog per dispositivi di rete.
- Eseguire restore backup in ambiente non produttivo.
- Mappare escalation alert alla procedura di gestione incidenti.
Decisioni di design prima del build
Prima di eseguire comandi, documentare le decisioni che incidono sulle evidenze di conformità. Decidere se dati di produzione possono uscire dall’organizzazione, se serve alta disponibilità, quali amministratori accedono alla dashboard e quali sistemi sono monitorati nella prima wave.
| Decisione | Risposta minima prima del deployment |
|---|---|
| Retention | Target per alert e archive, regole cancellazione e backup. |
| Disponibilità | Downtime accettabile per SIEM, indexer e dashboard. |
| Accessi | Amministratori nominativi, ruoli analyst e accesso emergenza. |
| Perimetro dati | Servizi, endpoint, dispositivi rete e cloud della prima wave. |
| Escalation | Chi riceve alert severi e quando parte il processo incidente. |
Checklist hardening di produzione
- Collocare i componenti Wazuh in segmento di rete controllato.
- Limitare porte di management alle reti amministrative.
- Usare account nominativi ed evitare credenziali amministrative condivise.
- Proteggere certificati, segreti di enrollment e password generate.
- Definire finestre patching per i nodi Wazuh.
- Attivare backup di configurazioni e indici critici.
- Documentare accesso emergenza e procedure di recovery.
Rollout agent per criticità
Un rollout solido non parte da tutti gli endpoint. Parte dai sistemi che supportano servizi essenziali. I target della prima wave sono spesso domain controller, identity provider, VPN, server esposti, backup, host privilegiati e application server di produzione.
Dopo la prima wave, estendere a endpoint utenti, workload cloud, host container e apparati di rete. Per ogni wave, mantenere un acceptance test: agent connesso, log attesi visibili, alert di test completato, owner confermato e rollback documentato.
Checklist troubleshooting
- Se gli agent non appaiono, verificare hostname manager, porte, enrollment e servizio locale.
- Se la dashboard non consente login, controllare certificati, API Wazuh e salute indexer.
- Se mancano eventi, verificare localfile, listener syslog e firewall sorgente.
- Se il disco cresce troppo, rivedere archive, sorgenti rumorose, retention e lifecycle indici.
- Se gli alert sono troppi, tarare le regole con change process documentato.
Matrice test di validazione NIS 2
| Test | Risultato atteso | Evidenza |
|---|---|---|
| Fallimento autenticazione | Alert visibile con severità assegnata. | Screenshot o export, ticket, nota analyst. |
| Agent offline | Perdita di visibilità rilevata. | Record monitoraggio e azione risposta. |
| Dispositivo syslog | Evento apparato ricevuto. | Evento raw, evento decodificato, mapping sorgente. |
| Restore backup | Configurazione ripristinabile. | Log restore e sign-off. |
| Simulazione escalation | Alert severo raggiunge owner incidente. | Report esercitazione e lesson learned. |
Runbook dettagliato di deployment
Un runbook di produzione dovrebbe essere scritto prima dell’installazione e aggiornato durante l’implementazione. Deve includere hostname, reti, porte, certificati, account privilegiati, path backup, sequenza onboarding sorgenti, criteri rollback e test validazione. Diventa evidenza di deployment controllato.
Fase 1: preparazione ambiente
Preparare sistemi operativi, DNS, sincronizzazione tempo, firewall, partizioni disco, repository pacchetti e accessi amministrativi. La sincronizzazione tempo è importante perché le timeline degli alert perdono valore se gli orologi divergono.
Fase 2: deployment componenti centrali
Installare i componenti secondo il workflow ufficiale Wazuh. Registrare versioni pacchetti, file modificati, credenziali generate, certificati e deviazioni dalla documentazione. Se si sceglie all-in-one, documentare perché il design è accettabile.
Fase 3: amministrazione sicura
Dopo l’accesso dashboard, ridurre l’esposizione. Cambiare credenziali temporanee, rivedere ruoli admin, documentare accesso emergenza e limitare interfacce management. Le azioni amministrative devono essere tracciabili perché incidono su detection ed evidenze.
Fase 4: onboarding sorgenti
Collegare solo la prima wave approvata di sistemi. Per ogni sorgente, registrare log attesi, owner business, owner tecnico, criticità e acceptance test. Una sorgente non è completa quando l’agent è installato. È completa quando gli eventi attesi sono visibili e spiegabili.
Fase 5: accettazione operativa
Prima del go-live, eseguire una sessione breve. Generare eventi controllati di autenticazione, privilegio, malware-test, failure servizio e syslog dove sicuro. Confermare che il team vede l’evento, capisce l’alert, assegna owner e chiude il ticket con evidenza.
Note di sicurezza sui comandi
Gli snippet pubblici non vanno copiati ciecamente in produzione. La documentazione Wazuh cambia, le versioni evolvono e gli ambienti differiscono. Gli snippet sono struttura per il runbook. La fonte esecutiva resta la documentazione ufficiale Wazuh verificata alla data di deployment.
Cadenza operativa post-installazione
| Cadenza | Attività |
|---|---|
| Giornaliera | Rivedere alert severi, agent offline e failure ingestion. |
| Settimanale | Rivedere regole rumorose, nuovi asset e vulnerabilità aperte. |
| Mensile | Test restore backup, review accessi admin ed export evidence pack. |
| Trimestrale | Eseguire tabletop e aggiornare report copertura detection. |
Se preferite un supporto rispetto a un'installazione gestita in autonomia, il nostro Virtual CISO valuta con voi le misure NIS 2, imposta le attività in Cyber Console e prepara i documenti richiesti; il SIEM resta al vostro team o al vostro MSSP.
Navigazione della serie
- introduzione a Wazuh
- gestione log Wazuh per NIS 2
- Wazuh vs SIEM commerciale
- rilevamento ed event monitoring NIS2
- registri operativi e log
FAQ e troubleshooting
Ogni asset deve avere subito un agent?
No. Prioritizzare sistemi critici, servizi di identità, asset esposti a Internet e sistemi che supportano attività NIS.
Wazuh può ricevere log da dispositivi di rete?
Sì. La documentazione Wazuh descrive raccolta syslog per dispositivi dove non è possibile installare agent.
Cosa testare prima della produzione?
Connettività agent, visibilità alert, syslog, restore backup, controllo accessi e procedure di escalation.