Un progetto NIS2 in una PMI manifatturiera: come progettiamo e governiamo infrastruttura, sicurezza e continuità operativa

Il punto di partenza: conoscere l'infrastruttura prima di proteggerla

L'azienda è manifatturiera, con più aree operative e produttive e un'infrastruttura IT cresciuta per stratificazione: diverse macchine virtuali con carichi di lavoro differenti, un sistema MES che collega l'ufficio al reparto, dispositivi industriali, numerosi endpoint Windows, dispositivi mobili, storage di rete, Microsoft 365 e più fornitori tecnologici.

L'assessment ha fatto emergere un quadro tipico di molte PMI:

• virtualizzazione su tecnologia VMware legacy, con un ciclo di vita dell'hypervisor da governare, e sistemi operativi server datati;
• monitoraggio e gestione proattiva da migliorare;
• un modello di backup da rafforzare, con repliche operative che non equivalgono a un backup immutabile;
• governance di identità, MFA e controllo degli accessi da rafforzare;
• log non centralizzati e vulnerability management non continuativo;
• asset e fornitori da censire meglio, documentazione da migliorare;
• IT e OT da portare in un unico modello di governance.

Nessuno di questi punti, da solo, è uno scandalo. Insieme descrivono un'azienda che funziona, ma che non sa con precisione cosa ha, cosa dipende da cosa e che cosa succederebbe se una parte si fermasse. È il punto di partenza più comune, ed è il motivo per cui il primo lavoro è conoscitivo.

NIS2: il primo passo è sapere cosa bisogna proteggere

Il decreto di recepimento (D.Lgs. 138/2024) chiede ai soggetti che rientrano nel perimetro di adottare misure tecniche, operative e organizzative adeguate e proporzionate, con un approccio multi-rischio. All'articolo 24 elenca, tra gli elementi minimi, le politiche di analisi dei rischi, la gestione degli incidenti, la continuità operativa (compresa la gestione dei backup e il ripristino in caso di disastro), la sicurezza della catena di approvvigionamento, la gestione delle vulnerabilità, il controllo degli accessi e la gestione dei beni, l'uso dell'autenticazione a più fattori dove opportuno.

Due osservazioni guidano il nostro metodo. La prima: il testo parla di proporzionalità rispetto a esposizione al rischio, dimensioni e probabilità degli incidenti, e non indica prodotti né architetture. Nessuna norma impone una tecnologia specifica, e chi lo sostiene sta vendendo, non spiegando. La seconda: quasi ogni elemento dell'elenco presuppone di sapere cosa si possiede. Non si gestisce un asset sconosciuto, non si valuta un fornitore non censito, non si ripristina un sistema di cui si ignorano le dipendenze.

Per questo il progetto parte da un inventario, non da una scelta di prodotti. Le specifiche di base e i termini per adottarle sono fissati dall'ACN e decorrono dalla comunicazione di inserimento nell'elenco dei soggetti NIS: sono un tema da verificare caso per caso.

Dall'assessment alla roadmap tecnica

L'assessment ha previsto la raccolta strutturata di quattro famiglie di informazioni:

• Asset inventory: hardware, software, server e macchine virtuali, endpoint, dispositivi industriali, asset collegati al MES, servizi cloud, Microsoft 365, identità e account;
• Network mapping: switch, collegamenti, segmentazione, firewall, storage di rete, sistemi OT e rete di produzione;
• Supplier mapping: i fornitori, che cosa gestiscono e con quali modalità accedono ai sistemi;
• Documentation: lo stato della documentazione esistente e le lacune da colmare, con un responsabile per ciascun documento.

Il valore dell'assessment non è l'elenco: è la mappa delle dipendenze. Sapere che un servizio produttivo dipende da certe macchine virtuali, da uno storage condiviso, da un collegamento di rete e da un fornitore esterno permette di decidere in che ordine proteggere e, soprattutto, in che ordine ripristinare.

Dall'assessment nasce la roadmap: un documento di priorità, non un preventivo. Ogni intervento è legato a un rischio e a una decisione, e questo lo rende difendibile davanti alla direzione. La tabella riassume il ragionamento.

Situazione	Rischio	Decisione	Misura
Virtualizzazione legacy	Patching e ciclo di vita non governati	Modernizzare	Roadmap verso Proxmox VE e alta affidabilità
Replica operativa	Insufficiente contro ransomware e disastro	Separare replica e backup	Backup immutabile e test di ripristino
Identità poco governate	Compromissione degli account	Rafforzare la gestione delle identità	MFA, Conditional Access, privilegi minimi
Log distribuiti	Visibilità ridotta	Centralizzare	SIEM, correlazione, retention
Vulnerabilità rilevate ma non governate	Esposizione che si trascina	Processo continuativo	Identificazione, remediation, verifica
Sistemi critici gestiti in modo reattivo	Problemi scoperti tardi	Gestione proattiva	Servizio gestito, monitoraggio, SLA

Dall'assistenza a chiamata alla gestione proattiva

Un cambio di modello sta sotto molte righe della tabella. L'assistenza utenti risponde a un bisogno reale: qualcuno ha un problema, apre una richiesta, il problema si risolve. Ma è reattiva per definizione, e un sistema critico non deve essere controllato soltanto quando un utente apre un ticket.

La gestione proattiva ribalta la prospettiva: è l'infrastruttura a segnalare che qualcosa non va, prima dell'utente. Nel progetto il servizio gestito (MSP) prevede monitoraggio continuo, gestione di server e macchine virtuali, patch management, monitoraggio della capacità, allarmi, verifica dei backup, controllo di rete e servizi critici, gestione di Microsoft 365, SIEM, vulnerability management, reporting, SLA con regole di escalation e documentazione. Hanno un tratto comune: producono evidenze. Un'attività che lascia traccia (un report, un ticket, un log) è un'attività governabile. Il modello è descritto nella pagina sui contratti di assistenza informatica.

Infrastruttura e sistemi legacy: governare il ciclo di vita

"Legacy" non significa "da buttare subito". Significa che ogni componente ha un ciclo di vita, e che serve qualcuno che lo governi: sapere quando il supporto del produttore finisce, cosa si può mitigare nel frattempo, quando conviene sostituire. Un hypervisor o un sistema operativo server datati diventano un problema quando nessuno ha deciso cosa farne, non quando esistono.

Per i sistemi legacy il progetto prevede tre strade, a seconda del caso: sostituzione pianificata, mitigazione temporanea con isolamento e controlli compensativi, accettazione del rischio documentata e riesaminata nel tempo. La terza è legittima se è una decisione scritta, con un responsabile e una data di revisione, e non una dimenticanza. In un sistema di gestione del rischio anche "per ora lo teniamo così" è una misura, a patto che sia deliberata e tracciata. È il lavoro che facciamo nella progettazione dei sistemi IT e nell'infrastruttura aziendale sicura e resiliente: rendere esplicite le decisioni che altrimenti si prendono per inerzia.

Virtualizzazione e continuità dei workload

Se la piattaforma che ospita i carichi di lavoro è fragile, lo sono anche backup, monitoraggio e ripristino. Per questo la virtualizzazione dei server è uno dei punti centrali della roadmap.

La roadmap verso Proxmox VE e l'alta affidabilità

Come piattaforma di destinazione la roadmap prevede Proxmox VE, con cui lavoriamo regolarmente (qui il nostro approccio a Proxmox). Per onestà: è una roadmap, la migrazione non è avvenuta. Ecco come l'abbiamo progettata:

• un cluster con più nodi per l'alta affidabilità: se un nodo si ferma, i carichi di lavoro ripartono altrove;
• uno storage replicato, con scelta tra ZFS e Ceph secondo il progetto definitivo e non per preferenza di principio;
• Proxmox Backup Server come componente della strategia di backup;
• migrazione progressiva delle macchine virtuali, a ondate;
• finestre di manutenzione concordate con la produzione, con un piano di rollback per ciascuna;
• test prima e dopo ogni passaggio, a tutela della continuità dei carichi di lavoro.

Una migrazione in uno stabilimento che produce è un progetto di continuità operativa, non solo IT: va pianificata con chi risponde della produzione.

Replica, backup e disaster recovery non sono la stessa cosa

È la confusione più frequente, e la più pericolosa. Le tre parole descrivono tre cose diverse.

• Replica: una copia aggiornata di un sistema, mantenuta in un altro luogo, pensata per ripartire in fretta se l'originale si ferma. Risponde a un guasto. Ma replica anche gli errori: se un file viene cancellato o cifrato da un ransomware, la copia replicata diventa a sua volta cancellata o cifrata.
• Backup: una copia storica, con più punti di ripristino nel tempo, conservata in modo da non poter essere alterata da chi ha compromesso il sistema originale. Risponde all'errore umano, alla corruzione e all'attacco. Perché lo faccia davvero deve essere separata dall'ambiente che protegge e, se possibile, immutabile.
• Disaster recovery: il piano, non la tecnologia. Dice che cosa si ripristina, in quale ordine, con quali risorse, in quanto tempo e chi decide. Una replica e un backup sono ingredienti del disaster recovery; da soli non sono un piano.

Nella situazione di partenza esistevano repliche operative, utili ma non sostitutive di un backup immutabile. Il modello che abbiamo progettato è multilivello: backup delle macchine virtuali, una copia locale per i ripristini rapidi, una copia esterna o in cloud per i casi gravi, storage immutabile per resistere a una compromissione, con retention definite, controllo dei job e dei fallimenti e test periodici di ripristino.

Due parametri tengono insieme il disegno. L'RPO (recovery point objective) indica quanti dati l'azienda può permettersi di perdere, misurati in tempo; l'RTO (recovery time objective) indica in quanto tempo un servizio deve tornare disponibile. Non esistono valori giusti in assoluto: per fare un esempio didattico, una linea produttiva ferma costa di norma più di un archivio documentale, quindi merita un RTO più stretto. Li stabiliscono i responsabili di processo, e la tecnologia si dimensiona di conseguenza. Il nostro approccio è descritto nella pagina su backup e disaster recovery.

Un backup non provato è un'ipotesi. Solo i test di ripristino periodici dicono se il piano funziona e in quale ordine ripristinare: l'ordine discende dalle dipendenze emerse nell'assessment, non dall'intuito del momento.

Per Microsoft 365 (Exchange Online, OneDrive, SharePoint, Teams) i dati restano responsabilità dell'azienda. Il progetto prevede un backup separato dal tenant, con retention, ripristino granulare, protezione da cancellazione e da compromissione, e audit dell'attività.

Endpoint, EDR e cifratura

Molti incidenti iniziano da un endpoint, e in un'azienda manifatturiera ce ne sono di molti tipi: postazioni d'ufficio, PC industriali, portatili, dispositivi mobili. Il progetto prevede misure coordinate: protezione con EDR, gestione centralizzata, patch, inventario, difesa dal ransomware, controllo delle applicazioni, cifratura dei dischi con BitLocker gestito in modo centrale, policy uniformi.

Le tecnologie (lavoriamo con soluzioni come WatchGuard e Panda) contano meno del governo che le circonda. Un EDR senza qualcuno che guardi gli avvisi dà una falsa sicurezza: la competenza che portiamo è l'integrazione con inventario, SIEM e verifica delle policy. Approfondisci i nostri sistemi EDR.

Centralizzare i log con un SIEM

Con i log sparsi su server, firewall, switch e postazioni, ricostruire cosa è successo dopo un incidente è un lavoro da investigatori. Il progetto prevede un SIEM gestito, basato su Wazuh e OpenSearch, che raccoglie i log in un unico punto, li correla, genera rilevazioni, conserva le evidenze per audit e produce report.

Le sorgenti previste sono Windows, Linux, Active Directory, Microsoft 365, firewall, switch, storage di rete, endpoint, altri apparati compatibili e, quando possibile, l'ambiente OT. Un SIEM non è un obbligo e non rende conformi: è uno strumento di visibilità. Serve ad accorgersi in tempo di ciò che accade e ad avere le prove per capire dopo ciò che è accaduto.

Dalla vulnerabilità alla remediation

Una scansione produce un elenco. Un processo produce una chiusura. Il vulnerability management che abbiamo progettato è un ciclo continuo: assessment, scansione, prioritizzazione, remediation, nuova verifica, chiusura, documentazione. La differenza sta nell'ultima parola: se non c'è la chiusura documentata, non c'è gestione.

La prioritizzazione è la parte più delicata. Il punteggio CVSS misura la gravità tecnica di una vulnerabilità, non il rischio per quell'azienda; l'EPSS stima la probabilità che venga sfruttata nei trenta giorni successivi. Nessuno dei due, da solo, dice cosa correggere per primo: vanno incrociati con l'esposizione del sistema (raggiungibile da internet o solo dalla rete interna), con la sua criticità per il business e con i controlli compensativi presenti. Sui sistemi legacy, dove la patch spesso non esiste o non è applicabile, si lavora con mitigazioni o con un'accettazione del rischio documentata e riesaminata.

A noi spetta governare il ciclo. Il quadro si completa con un penetration test, che guarda i sistemi con gli occhi di un attaccante ma è una fotografia puntuale: non sostituisce il processo continuo.

Microsoft 365, identità e controllo degli accessi

Per molte PMI Microsoft 365 contiene la posta, i documenti e l'identità di tutti: chi controlla le identità controlla l'azienda. Per questo la parte identitaria della roadmap è tra le prime a produrre valore.

Le misure previste: MFA estesa, Conditional Access con regole basate su contesto e rischio, account amministrativi separati da quelli ordinari, privilegi minimi, revisione periodica dei ruoli, onboarding e offboarding con revoca delle sessioni, audit log e monitoraggio degli eventi di sicurezza su Entra ID, protezione della posta, più il backup di cui si è detto. L'identità è il nuovo perimetro, e la revisione periodica degli accessi è tra le attività più economiche ed efficaci che si possano introdurre.

IT e OT: proteggere anche l'ambiente produttivo

In uno stabilimento IT e OT hanno logiche diverse: l'IT privilegia riservatezza e aggiornamento, l'OT disponibilità e stabilità, con cicli di vita lunghi. Il MES fa da ponte fra gestionale e linee; attorno ci sono PLC, sistemi embedded, pannelli, dispositivi e PC industriali.

Il progetto integra i due mondi con tre principi. Primo, segmentazione: la rete di produzione è separata da quella aziendale, con flussi consentiti definiti e documentati. Secondo, monitoraggio non invasivo: raggiungibilità e latenza dei sistemi critici, e logging dove il dispositivo lo consente. Terzo, prudenza: in OT non tutte le scansioni usate in IT sono appropriate, perché possono interferire con la produzione; si scelgono strumenti e finestre compatibili con le macchine e ogni attività si coordina con chi risponde della produzione.

Sul perimetro, il disegno comprende firewall in alta affidabilità, IDS/IPS, monitoraggio e logging, con supervisione tecnica continuativa. Il tema è parte della nostra consulenza sulla sicurezza informatica.

Automazione e supervisione: il ruolo di Hector LIS

La piattaforma Hector LIS è lo strumento proprietario che sviluppiamo in TN Solutions per il monitoraggio continuo: riceve i segnali di firewall, server, postazioni e rete, li analizza in modo automatico e ininterrotto, individua le anomalie e passa ai nostri tecnici quelle rilevanti, secondo le modalità definite dal contratto. Nasce per integrarsi con i firewall che gestiamo, e i dati di monitoraggio restano sulla nostra infrastruttura.

Nel progetto la supervisione dei firewall si appoggia a Hector LIS e si integra con il resto del monitoraggio gestito. La distinzione che per noi conta è questa: l'automazione copre le ventiquattro ore, il presidio umano valuta e decide. Hector LIS non sostituisce il personale che si occupa di sicurezza, ne amplia la capacità di vedere; e non è il titolare dell'intento NIS2, che resta dell'azienda e della sua direzione.

Quando accade un incidente, la tecnologia da sola non basta

Il decreto prevede, per gli incidenti significativi, tre momenti verso il CSIRT Italia: una pre-notifica entro 24 ore da quando si viene a conoscenza dell'incidente, una notifica con una prima valutazione entro 72 ore, una relazione finale entro un mese dalla notifica (art. 25 del D.Lgs. 138/2024). Chi è nel perimetro deve verificare quali incidenti ricadano nella definizione di "significativo" e quali specifiche di base si applichino.

Rispettare quei tempi richiede più di un buon antivirus: rilevare l'incidente (monitoraggio, EDR, SIEM), aprire un ticket, classificarlo, attivare l'escalation, raccogliere informazioni e conservare i log, comunicare in modo coerente, produrre un report. La tecnologia genera il segnale; un processo scritto e provato lo trasforma in azione. Nel progetto il supporto alla gestione dell'incidente comprende rilevazione, classificazione, raccolta delle evidenze, supporto operativo e reporting. La decisione di notificare resta però all'azienda.

Governance: accessi, fornitori, asset e documentazione

Tutto quanto descritto sopra si degrada se nessuno lo mantiene. La governance è la parte meno vistosa e più decisiva. Nel progetto comprende:

• account nominativi, MFA, privilegi minimi e revisione periodica dei privilegi;
• inventario degli accessi e dei fornitori, con una regola semplice: ogni accesso esterno è motivato, tracciato e revocabile;
• inventario degli asset aggiornato, non fotografato una volta;
• registri, configurazioni e procedure documentati, con un responsabile della documentazione;
• logging e reporting periodici;
• SLA e regole di escalation che dicono chi fa che cosa, e in quanto tempo.

Una configurazione che esiste solo nella testa di una persona è un rischio operativo, prima ancora che normativo.

Progettare, implementare, governare

Il filo del progetto si riassume in tre fasi, che non sono sequenziali ma si alimentano a vicenda.

• Progettare: assessment, inventari, analisi dei rischi, architetture, priorità, roadmap.
• Implementare: infrastrutture, modernizzazione, integrazione, cybersecurity, backup, SIEM, identità, monitoraggio.
• Governare: monitorare, aggiornare, gestire gli allarmi, verificare i backup e le vulnerabilità, rispettare gli SLA, rivedere gli accessi, seguire i fornitori, produrre report, mantenere la documentazione.

Lo schema concettuale mette in relazione i livelli:

Livello	Contenuto
Punto di partenza	NIS2, assessment, progettazione
Infrastruttura	Server e macchine virtuali, rete, ambiente IT/OT
Cybersecurity	EDR, SIEM, firewall, vulnerability management
Governance	Asset, fornitori, accessi
Continuità	Backup e disaster recovery, Microsoft 365
Operatività	Servizio gestito, monitoraggio, Hector LIS, report e SLA

Cosa insegna un progetto NIS2 reale

Alcune lezioni valgono oltre questo progetto.

1. Si parte dalla conoscenza, non dagli strumenti. Un inventario onesto vale più di un acquisto frettoloso.
2. Replica, backup e disaster recovery vanno separati. Chi ha solo la replica non ha un backup.
3. L'identità è il perimetro. MFA e revisione degli accessi sono tra le misure con il miglior rapporto costo/efficacia.
4. Il legacy si governa, non si ignora. Anche accettare un rischio è una decisione, se è scritta.
5. In OT la prudenza viene prima della copertura. Non tutto si scansiona né si aggiorna quando si vuole.
6. Una misura che non produce evidenze non è governabile.
7. La tecnologia non è l'intento. La direzione risponde; noi progettiamo e gestiamo gli strumenti che le permettono di farlo con consapevolezza.

Come possiamo aiutarti

Se la tua azienda è in un percorso NIS2, o vuole capire se lo è, il punto di partenza è sempre lo stesso: un assessment che dica cosa hai, da cosa dipende e quali rischi contano davvero. Da lì si costruisce una roadmap tecnica che tenga insieme infrastruttura, sicurezza e continuità, e un modello di gestione che la mantenga viva. TN Solutions aiuta le aziende ad adeguarsi; non certifica la conformità di nessuno, e la valutazione dell'obbligo e delle scadenze resta all'azienda e ai suoi consulenti.

Per le norme citate abbiamo consultato le fonti ufficiali: il testo vigente del D.Lgs. 138/2024 su Normattiva e la pagina ACN sulle modalità e specifiche di base.

Parla con un nostro consulente