La NIS2 viene spesso presentata come un insieme di obblighi normativi. Dal punto di vista informatico, però, il suo messaggio centrale è molto concreto: un'organizzazione deve conoscere i propri rischi digitali, proteggere i sistemi da cui dipende e saper reagire quando qualcosa va storto.
Questo articolo affronta la NIS2 esclusivamente dal punto di vista tecnico e organizzativo della sicurezza informatica. Non costituisce consulenza legale e non determina se una specifica organizzazione rientri o meno nell'ambito di applicazione della normativa. Per una valutazione formale è necessario rivolgersi a professionisti competenti in materia legale e normativa.
1. Che cos'è la NIS2?
La Direttiva UE 2022/2555, conosciuta come NIS2, mira ad aumentare il livello comune di cybersicurezza nell'Unione europea. In Italia è stata recepita con il Decreto legislativo 4 settembre 2024, n. 138.
La normativa riguarda determinati soggetti pubblici e privati appartenenti a settori considerati importanti o essenziali. Dimensione, attività svolta e ruolo nella filiera possono incidere sull'applicabilità: non è quindi corretto affermare che ogni impresa sia automaticamente soggetta alla NIS2.
Anche un'organizzazione non direttamente inclusa può però ricevere richieste di sicurezza da clienti, committenti o partner che devono controllare i rischi della propria catena di fornitura.
2. Cosa significa gestire il rischio informatico?
Gestire il rischio informatico non significa acquistare un singolo prodotto o installare un antivirus. Significa capire quali servizi devono continuare a funzionare, quali dati devono essere protetti, quali incidenti potrebbero bloccare il lavoro e quali misure riducono realmente probabilità e impatto.
Un'analisi tecnica dovrebbe almeno identificare:
- dispositivi, server, servizi cloud e applicazioni utilizzate;
- account amministrativi e persone autorizzate;
- dati importanti e sistemi che li elaborano;
- dipendenze da fornitori tecnologici;
- possibili conseguenze di un guasto, un errore o un attacco;
- protezioni già presenti e controlli ancora mancanti.
Il risultato dovrebbe essere un elenco di priorità comprensibile anche alla direzione, non soltanto un documento tecnico difficile da applicare.
3. Account, accessi e autenticazione
Molti incidenti iniziano da credenziali rubate, password riutilizzate o account rimasti attivi dopo un cambio di ruolo. Una gestione ordinata degli accessi è quindi una delle prime misure da verificare.
Dal punto di vista pratico è utile:
- assegnare account personali ed evitare utenze condivise;
- attivare l'autenticazione a più fattori, soprattutto per email, cloud e amministratori;
- concedere soltanto i permessi necessari;
- separare gli account amministrativi da quelli utilizzati ogni giorno;
- controllare periodicamente utenti, ruoli e sessioni aperte;
- revocare rapidamente gli accessi non più necessari.
4. Aggiornamenti, vulnerabilità e configurazioni
Sistemi operativi, applicazioni, router, firewall e dispositivi devono ricevere aggiornamenti di sicurezza.
Non basta però aggiornare quando ci si ricorda: servono responsabilità, tempi e verifiche.
È importante conoscere quali prodotti sono presenti, quali versioni utilizzano e se ricevono ancora supporto dal produttore. I sistemi obsoleti o non aggiornabili devono essere sostituiti, isolati oppure protetti con misure compensative adeguate.
Anche le configurazioni contano: servizi esposti inutilmente, credenziali predefinite, protocolli superati e permessi eccessivi possono trasformare una vulnerabilità gestibile in un incidente grave.
5. Backup e continuità operativa
Un backup è utile soltanto se è aggiornato, protetto e realmente recuperabile. Le copie collegate continuamente agli stessi sistemi possono essere cifrate o cancellate insieme ai dati originali.
Una strategia efficace dovrebbe prevedere:
- più copie dei dati importanti;
- supporti o destinazioni differenti;
- almeno una copia separata o protetta dalle modifiche;
- controlli automatici sull'esito dei backup;
- prove periodiche di ripristino;
- tempi di recupero coerenti con le esigenze operative.
La continuità operativa comprende anche procedure alternative: chi decide cosa ripristinare per primo, come si comunica durante un blocco e quali attività possono continuare temporaneamente senza i sistemi principali.
6. Gestione degli incidenti
Riconoscere un incidente rapidamente può ridurne l'impatto. Per questo servono strumenti di monitoraggio proporzionati, registri utili e un canale chiaro attraverso cui dipendenti e collaboratori possano segnalare anomalie.
Un piano di risposta dovrebbe indicare:
- chi deve essere contattato;
- come isolare un dispositivo senza distruggere informazioni utili;
- quali dati e log conservare;
- come valutare servizi e persone coinvolte;
- quando attivare fornitori, consulenti e responsabili interni;
- come documentare decisioni, tempi e attività svolte.
Gli obblighi formali di notifica previsti dalla NIS2 richiedono una valutazione specifica. Dal punto di vista informatico, la condizione indispensabile è comunque accorgersi dell'incidente, raccogliere informazioni affidabili e comunicarle tempestivamente a chi deve decidere.
7. Log management e SIEM: vedere cosa accade nei sistemi
I log registrano eventi come accessi, errori, modifiche alle configurazioni e attività di rete. Se sono raccolti e controllati correttamente, aiutano a riconoscere comportamenti anomali, ricostruire un incidente e capire quali sistemi o account sono stati coinvolti.
Un SIEM (Security Information and Event Management) centralizza i log provenienti da fonti diverse, li correla e può generare avvisi quando rileva condizioni sospette. È particolarmente utile quando l'organizzazione gestisce molti sistemi, sedi o servizi cloud, ma richiede configurazione, manutenzione e persone capaci di analizzare gli avvisi.
La NIS2 non impone l'acquisto di uno specifico prodotto SIEM. La soluzione deve essere proporzionata ai rischi, alle dimensioni e alla complessità dell'organizzazione. Per realtà meno strutturate può essere più efficace iniziare con una gestione ordinata dei log dei sistemi più importanti e con servizi di monitoraggio gestiti.
Dal punto di vista operativo conviene definire:
- quali eventi devono essere registrati;
- quali sistemi sono prioritari, per esempio firewall, server, email, cloud e account amministrativi;
- per quanto tempo conservare i log in base alle esigenze operative e agli obblighi applicabili;
- come proteggere i registri da cancellazioni e modifiche non autorizzate;
- chi controlla gli avvisi e con quali tempi;
- come sincronizzare l'orario dei sistemi per ricostruire correttamente la sequenza degli eventi;
- quali procedure seguire quando viene rilevata un'anomalia.
Raccogliere grandi quantità di log senza controllarli non aumenta automaticamente la sicurezza. L'obiettivo è conservare informazioni utili, generare segnalazioni gestibili e collegare il monitoraggio al piano di risposta agli incidenti.
8. Sicurezza dei fornitori e servizi cloud
Un'organizzazione può essere protetta internamente ma dipendere da un fornitore vulnerabile. Software gestionali, assistenza remota, hosting, posta elettronica, backup e servizi cloud fanno parte della superficie di rischio.
Prima di affidare dati o funzioni importanti è utile chiarire:
- quali misure di sicurezza applica il fornitore;
- chi può accedere ai dati e ai sistemi;
- come vengono gestiti aggiornamenti e vulnerabilità;
- quali backup sono previsti e come avviene il ripristino;
- come e quando vengono comunicati gli incidenti;
- come recuperare dati e configurazioni al termine del rapporto.
Non si tratta di accumulare documenti, ma di conoscere le dipendenze critiche e prevedere alternative quando possibile.
9. Formazione e responsabilità interne
La sicurezza non può essere delegata interamente al tecnico informatico.
La direzione deve conoscere i rischi che possono interrompere l'attività, mentre le persone devono sapere come usare correttamente account, dispositivi e dati.
Una formazione efficace parte da situazioni reali: messaggi di phishing, richieste urgenti di pagamento, condivisione di documenti, dispositivi smarriti e segnalazione di comportamenti anomali.
Brevi attività periodiche sono spesso più utili di un unico corso dimenticato dopo pochi mesi.
10. Da dove iniziare concretamente?
Per trasformare i principi in un piano operativo si può partire da cinque attività:
- inventariare sistemi, servizi, dati e fornitori principali;
- verificare account, privilegi e autenticazione a più fattori;
- controllare aggiornamenti, configurazioni e protezioni dei dispositivi;
- provare il ripristino dei backup;
- definire una procedura semplice per riconoscere e gestire gli incidenti.
Successivamente è possibile assegnare priorità, responsabili e scadenze, conservando evidenze dei controlli eseguiti. La documentazione è utile quando descrive attività realmente svolte, non quando rimane separata dal funzionamento quotidiano.
11. Conformità e sicurezza non sono la stessa cosa
La conformità aiuta a definire responsabilità e requisiti, ma non garantisce da sola che i sistemi siano protetti. Allo stesso modo, alcune buone misure tecniche non dimostrano automaticamente la conformità normativa.
L'approccio più solido tiene insieme i due aspetti: una valutazione legale per comprendere obblighi e perimetro, e una valutazione informatica per verificare che controlli, strumenti e procedure funzionino davvero.
In sintesi, guardare alla NIS2 dal punto di vista informatico significa usare la normativa come occasione per conoscere meglio infrastruttura, dipendenze e rischi. Anche quando un'organizzazione non è direttamente soggetta, molte delle misure richieste rappresentano buone pratiche utili a ridurre interruzioni, perdita di dati e accessi non autorizzati.