Come installare Wazuh: guida deployment passo-passo per la NIS 2

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

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 -a

Per 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-agent

Usare 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

1. Confermare connessione degli agent prioritari.
2. Generare eventi di test controllati e verificare gli alert.
3. Controllare retention e crescita indici rispetto allo storage.
4. Testare ingestione syslog per dispositivi di rete.
5. Eseguire restore backup in ambiente non produttivo.
6. 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.

Checklist hardening di produzione

1. Collocare i componenti Wazuh in segmento di rete controllato.
2. Limitare porte di management alle reti amministrative.
3. Usare account nominativi ed evitare credenziali amministrative condivise.
4. Proteggere certificati, segreti di enrollment e password generate.
5. Definire finestre patching per i nodi Wazuh.
6. Attivare backup di configurazioni e indici critici.
7. 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

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

Per le organizzazioni che preferiscono un approccio gestito rispetto al self-deployment, Aegister offre il servizio Virtual CISO con security operations erogate tramite la piattaforma Cyber Console: revisione log centralizzata, mappatura controlli NIS 2 e workflow di notifica CSIRT pronti all'uso.

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.

Fonti ufficiali

• Guida installazione Wazuh
• Deployment agent Linux Wazuh
• Configurazione syslog Wazuh
• Determinazione ACN obblighi di base
• Guida ACN alle specifiche di base