Nis2, ecco le misure dell’Acn per la sicurezza delle imprese

Il nodo dell’accountability

Il principio di responsabilizzazione (accountability), emerso con forza con il GDPR nel 2016, prevede che le organizzazioni decidano autonomamente le modalità, le garanzie e i limiti delle proprie attività (nel caso del GDPR, del trattamento dei dati personali), nel rispetto delle disposizioni normative. L’imposizione di alcune misure toglie ovviamente questa autonomia.

Opportuno segnalare che il concetto di “misure minime” è presente anche nel Regolamento di esecuzione 2024/2690 della Commissione europea, rivolto ai fornitori IT (più precisamente, ai fornitori di servizi DNS, i registri dei nomi di dominio di primo livello, i fornitori di servizi di cloud computing, i fornitori di servizi di data center, i fornitori di reti di distribuzione dei contenuti, i fornitori di servizi gestiti, i fornitori di servizi di sicurezza gestiti, i fornitori di mercati online, di motori di ricerca online e di piattaforme di servizi di social network e i prestatori di servizi fiduciari).

Sembra inoltre, e purtroppo ACN non stia aiutando in questo senso, che i fornitori di servizi informatici debbano seguire sia le misure del Regolamento di esecuzione sia quelle della Determinazione 164179. Vero che molte misure ACN ricalcano quelle del Regolamento di esecuzione, ma è anche vero che si trovano sovrapposizioni e incongruenze che faranno perdere tempo e risorse alle aziende coinvolte.

Misure documentali

Politiche e procedure vanno riesaminate periodicamente o a seguito di eventi o cambiamenti significativi (GV.PO-02). Sono richieste da ACN le seguenti (GV.PO-01):

• procedura di gestione del rischio (non richiesta dalla misura specifica GV.RM-03, ma da quella generale GV.PO-01);
• ruoli e responsabilità per la sicurezza informatica, anche assegnati a terze parti (GV.RR-02, GV.SC-02);
• procedura di gestione delle credenziali e delle autorizzazioni (GV.RR-04, PR.AA-01, PR.AA-03, PR.AA-05, PR.IR-01), inclusa la valutazione dell’affidabilità delle risorse umane;
• procedura per la formazione del personale e consapevolezza (non richiesta dalla misura specifica PR.AT-01, ma da quella generale GV.PO-01; la misura specifica richiede invece un “piano” di formazione);
• misure di sicurezza fisica, inclusa la dismissione, per i dispositivi e gli apparati (PR.AA-06, PR.PS-03);
• procedura relativa allo sviluppo, configurazione, manutenzione e dismissione dei sistemi informativi e di rete (la misura specifica PR.PS-01 richiede una procedura relativa alle modalità di configurazione sicura dei dispositivi e degli apparati; gli altri argomenti sono richiesti dalla misura generale GV.PO-01);
• procedura di cifratura dei dispositivi e dei supporti di memorizzazione rimovibili (PR.DS-01);
• procedura di aggiornamento del software (PR.PS-02);
• procedura relativa agli antivirus (PR.DS-01, DE.CM-09);
• modalità di gestione dei log e del monitoraggio dei sistemi informatici (PR.PS-04, DE.CM-01);
• procedura di gestione dei backup (PR.DS-11);
• procedura di protezione delle reti e delle comunicazioni (la misura specifica PR.DS-02 riguarda solo la cifratura delle trasmissioni; argomenti più ampi sono richiesti dalla misura generale GV.PO-01)
• procedura di gestione degli incidenti (RS.MA-01, RS.CO-02, RC.RP-01, RC.CO-03);
• piano di continuità operativa e di gestione delle emergenze (ID.IM-04, PR.IR-03);
• modalità di gestione delle vulnerabilità tecniche, inclusi canali informativi attivati e modalità di trattamento (ID.RA-08);
• procedura relativa alla conformità e audit di sicurezza ai fornitori e di gestione dei rischi per la sicurezza informatica della catena di approvvigionamento (non richiesta dalla misura specifica GV.SC-01, ma da quella generale GV.PO-01);
• procedura relativa alla conformità e audit di sicurezza interni (non richiesta dalla misura specifica ID.IM-01, ma è possibile interpretare la GV.PO-01 in questo senso).

Molte critiche sono state rivolte alle misure documentali in quanto ritenute troppo numerose, tanto da imporre un modello più burocratico e inefficiente (e quindi potenzialmente inefficace) che pragmatico. Non vi è sostanziale differenza nelle richieste delle misure documentali tra le aziende essenziali e quelle importanti.

Le procedure potranno essere sintetiche, purché complete, soprattutto se il soggetto NIS è una PMI, e accorpate o incluse nelle procedure già in uso. E’ importante che il corpo documentale copra sì tutte le misure pertinenti, ma anche che assicuri la facilità di lettura da parte di tutte le parti interessate, nonché la facilità di aggiornamento.

A questo proposito, si osservi che la misura generale GV.PO-01 richiede anche una procedura di “gestione degli asset” e una di “sicurezza dei dati”. I titoli sono decisamente generici e quindi esse potrebbero includere gran parte di quelle sopra elencate, nell’ambito di un accorpamento da fare se funzionale alla facilità di lettura e di aggiornamento.

I documenti devono essere approvati dagli organi amministrativi e direttivi del soggetto NIS. Tali organi, secondo quanto specificato da ACN nella Determinazione 136117 del 2025 (reperibile al link https://www.acn.gov.it/portale/nis/la-normativa), sono gli organi che detengono il potere di direzione dell’organizzazione, incluso, ove presente, il suo Consiglio di amministrazione

Valutazione e trattamento del rischio

Alcuni controlli (GV.RM-03, ID.RA-05, ID.RA-06) richiedono di condurre una valutazione del rischio e di elaborare quindi un piano di trattamento del rischio. Questa è una misura comune a tutte le pratiche di sicurezza informatica.

In questo caso è opportuno selezionare un approccio adeguato all’organizzazione. Purtroppo è molto diffusa l’idea di seguire l’approccio di identificare e valutare gli asset, le minacce e le vulnerabilità. Questo era diffuso negli anni Ottanta, quando gli asset erano decisamente poco numerosi. Da metà degli anni Novanta, con il proliferare degli asset, un approccio così puntuale è estremamente inefficiente (e quindi inefficace).

Come gestire la valutazione del rischio

Si raccomanda di seguire un approccio qualitativo, che consideri soprattutto le minacce e le relative misure di contenimento.

La ISO/IEC 27005:2022 “Guidance on managing information security risks”, può essere considerata. Purtroppo, però, questa norma è molto confusa perché non è riuscita a presentare gli approcci tradizionale e più moderno in modo chiaro. I risultati della valutazione del rischio devono poi essere ponderati per stabilire se i singoli rischi vanno accettati o mitigati. Nel caso si scelga la mitigazione, le relative azioni devono essere documentate con scadenze e responsabilità.

Lo stato di implementazione delle azioni va riesaminato periodicamente e gli organi amministrativi e direttivi ne devono essere informati e le devono tenere sotto controllo. Va detto che in alcuni casi sembra che ACN richieda diverse valutazioni del rischio:

• valutazione di tipo gestionale e tattico (ID.RA-05, ID.RA-06, ID.IM-01), per cui è possibile condurre una valutazione che parta dai possibili eventi negativi, ne valuti la verosimiglianza e le conseguenze, ne calcoli un livello di rischio e ne identifichi le contromisure; tale valutazione permetterebbe di per identificare, per esempio:
  • gli impegni da richiedere al personale (GV.RR-04);le modalità di uso delle utenze privilegiate e il livello di robustezza delle credenziali (PR.AA-01, PR.AA-03);quali trasmissioni cifrare (PR.DS-01, PR.DS-02);quali canali di comunicazione usare in caso di emergenze (PR.IR-03);eventuali software per cui non è necessario condurre test preventivi (PR.PS-02);
  • le modalità con cui conservare i log (PR.PS-04);
• valutazione di tipo tecnologico a fronte di vulnerabilità identificate puntualmente (ID.RA-08), a fronte dei risultati di un vulnerability assessment o delle segnalazioni della threat intelligence, ossia relativa a vulnerabilità tecnologiche, di cui se ne valuta la possibilità di venire sfruttate, e quindi la verosimiglianza e le conseguenze di un attacco riuscito, ne calcoli un livello di rischio e ne identifichi l’urgenza di applicazione degli aggiornamenti, delle patch o dei workaround;
• valutazione relativo all’approvvigionamento (GV.SC-01, GV.SC-07), per cui va identificata la criticità delle singole forniture e i possibili eventi negativi che possono impattarle, per identificare le caratteristiche che devono avere i fornitori, le condizioni contrattuali da imporre e le verifiche iniziali e periodiche ai fornitori e alle forniture.

Misure organizzative

Le persone che accedono ai sistemi informatici e di rete, come utenti e come amministratori di sistema, a seconda del proprio ruolo, devono avere adeguate competenze ed essere affidabili (GV.RR-04). Questo può essere fatto documentando le loro competenze ed esperienze pregresse.

Da ricordare che, tranne alcune eccezioni, la normativa non permette di trattare dati giudiziari, neanche indirettamente. Per questo l’affidabilità deve essere valutata, per esempio, con un rigoroso processo di analisi delle competenze ed esperienze e il monitoraggio (non con il controllo a distanza, anch’esso vietato) di comportamenti anomali.

Formazione del personale

Misura comune a tutte le pratiche di sicurezza informatica è quella relativa alla formazione tecnica e alla creazione di consapevolezza (PR.AT-01, PR.AT-02).

La formazione tecnica va erogata al personale addetto all’implementazione delle misure di sicurezza e all’amministrazione dei sistemi informatici. Questa misura è richiesta più esplicitamente per i soggetti essenziali, ma deve essere considerata anche per i soggetti importanti.

A tutto il personale vanno rivolte attività relative alla consapevolezza, ossia di spiegazione delle regole da seguire e delle loro finalità. Il piano di formazione, che coinvolge anche gli organi di amministrazione e direttivi, deve essere documentato e approvato dai medesimi organi di vertice.

Interessante osservare che le misure non impongono di verificare l’acquisizione dei contenuti (la cosiddetta “efficacia della formazione”, spesso richiesta nell’ambito di audit ISO 9001 e ISO/IEC 27001), ma ne segnalano la possibilità. Per questo è possibile predisporre questionari. Va inoltre mantenuto un registro delle persone che hanno seguito le attività di formazione e consapevolezza.

Gestione dei fornitori

E’ noto che la NIS 2 ha posto l’accento sulla supply chain. Questo richiede l’attivazione di un processo, che veda anche il coinvolgimento del responsabile della sicurezza informatica:

• la valutazione del rischio del servizio richiesto al fornitore e l’identificazione delle misure di sicurezza da prevedere (GV.SC-05, GV.SC-07, con elencati alcuni elementi da considerare);
• la valutazione preventiva del potenziale fornitore, attraverso analisi, questionari o audit, a seconda della criticità (si ricorda che il questionario impone al potenziale fornitore un aumento del carico di lavoro e non fornisce sempre indicazioni utili);
• la sottoscrizione di clausole contrattuali con inclusi obblighi di sicurezza ben determinati (GV.SC-01, dove sono elencati alcuni elementi da considerare per i soggetti essenziali;  può essere utile considerarli anche per i soggetti importanti);
• il mantenimento di un elenco dei fornitori critici, dei loro servizi e dei contratti, ossia un ulteriore inventario (GV.SC-04, ID.AM-04);
• la valutazione periodica delle forniture; questo può essere fatto analizzando le prestazioni del fornitore, le esperienze pregresse o audit.

Gestione degli incidenti

La gestione degli incidenti è una misura comune a tutte le pratiche di sicurezza informatica. Viene richiesta una procedura documentata di gestione degli incidenti che includa (RS.MA-01, RC.RP-01, RC.CO-03 RS.CO-02):

• le attività previste per il ripristino dei sistemi informatici;
• un processo per contattare gli utilizzatori dei servizi in caso di incidenti o di minacce ad essi relativi;
• un processo, solo per i soggetti essenziali, per aggiornare gli utilizzatori dei servizi delle attività di ripristino.

Viene richiesto di documentare i livelli di servizio attesi per poter identificare gli incidenti significativi  (DE.CM-01). Questo non è chiaro, visto che i criteri di significatività degli incidenti sono fornito dalla stessa Direttiva NIS 2 e i livelli di servizio attesi spesso non hanno relazione con la significatività degli incidenti. Viene inoltre richiesto un processo per aggiornare, mantenere e configurare gli strumenti per rilevare gli incidenti significativi sui sistemi informativi e di rete (DE.CM-01)

Verifiche e audit

Viene richiesto di condurre audit e verifiche periodiche (ID.IM-01). Alcune verifiche riguardano l’implementazione delle misure. Ai soggetti essenziali è richiesto di documentare quali misure sono oggetto di valutazione e come sono valutate e di valutare l’efficacia delle misure di trattamento del rischio. Questo può essere fatto predisponendo una check list di audit.

Misure tecniche

Una delle prime misure tecniche riguarda l’inventario dei sistemi informativi e di rete del soggetto NIS (GV.OC-4, ID.AM-01, ID.AM-02). Questa è una misura comune a tutte le pratiche di sicurezza informatica. Infatti non è possibile fare manutenzione e proteggere sistemi che non si conoscono.

L’inventario deve essere dinamico e quindi potrebbe essere mantenuto anche con il supporto strumenti di discovery. Esso deve permettere di conoscere, almeno, l’hardware (server e dispositivi in uso alle singole persone), il sistema operativo e la versione, il servizio informatico applicativo o di supporto a cui è destinato, il responsabile o assegnatario (anche per poter ritirare il dispositivo in caso di uscita e la sua eliminazione).

Da ricordare che non è necessario avere un unico inventario: è possibile averne, per esempio, uno per i server, uno per i pc, uno per gli smartphone. Ai soggetti essenziali è anche richiesto un “inventario dei flussi di rete tra i sistemi informativi e di rete del soggetto NIS e l’esterno” (ID.AM-03). Esso richiede ovviamente una maggiore attenzione ai sistemi usati e alle loro finalità e deve essere approvato da soggetti autorizzati.

Threat intelligence

Viene richiesto di iscriversi a bollettini per avere notizie aggiornate sulle vulnerabilità note sui sistemi utilizzati (ID.RA-01). Le vulnerabilità vanno quindi mitigate il prima possibile. Le eccezioni vanno giustificate e documentate. Per questo è opportuno mantenere un registro, per esempio una tabella o un task di un sistema di ticketing, con indicate le azioni di mitigazione e le eccezioni. cacca

Il CSIRT Italia mette a disposizione un canale Telegram (t.me/s/CSIRT_Italia) e le misure richiedono esplicitamente di seguirlo. Le misure (ID.RA-08) richiedono di seguire le informazioni messe a disposizione da eventuali CERT o Information Sharing & Analysis Centre (ISAC) settoriali e dai produttori dei software utilizzati.

Credenziali e autorizzazioni

Non potevano mancare misure relative alle credenziali e alle autorizzazioni (PR.AA-01, PR.AA-03, PR.AA-05, PR.IR-01). È necessario prevedere processi per assegnare e disabilitare credenziali e autorizzazioni in caso di entrate, uscite e cambi di mansione del personale o dei collaboratori. Il processo più semplice prevede che l’Ufficio del personale comunichi all’IT le variazioni e l’IT le configuri sui sistemi IT secondo regole precedentemente definite e autorizzate. Anche eventuali eccezioni devono seguire un processo autorizzativo.

Vanno riesaminate periodicamente le utenze e le autorizzazioni configurate sui sistemi per verificare che siano allineate con quanto previsto. Spesso questo riesame avviene almeno annualmente.

Le password devono essere robuste. Oggi questo vuol dire che dovrebbero essere lunghe almeno 8 caratteri e complesse. I sistemi dovrebbero essere configurati per imporre le regole stabilite. Consigliato usare sistemi di autenticazioni a più fattori (PR.AA-03). Agli amministratori di sistema devono essere assegnate credenziali per le attività di amministrazione e altre credenziali distinte per le attività che non richiedono privilegi amministrativi.

Particolare enfasi è data alle autorizzazioni per gli accessi da remoto, ma sarebbe stato opportuno proporre misure più in linea con il fatto che questi sono ormai la normalità.

Curiosamente, l’impegno a rispettare le regole di sicurezza informatica e alla riservatezza è richiesto, in fase di assegnazione delle autorizzazioni, solo al personale dei soggetti essenziali (GV.RR-04).

Sicurezza fisica

Sono richieste misure di sicurezza fisica, in particolare di controllo degli accessi, per i dispositivi e gli apparati (PR.AA-06). Ai soggetti essenziali è richiesto (PR.PS-03) di:

• registrare le attività di manutenzione dell’hardware; per questo è possibile usare uno strumento di ticketing;
• seguire procedure documentate per il trasferimento e la dismissione sicura dell’hardware.

E’ richiesta anche attenzione alla dismissione, la cui modalità deve essere stabilita valutandone i rischi (andrebbe aggiunto che una formattazione completa è sufficiente per un elevato livello di sicurezza, considerando la tecnologia odierna).

Configurazioni sicure

Solo ai soggetti essenziali è chiesto di documentare le configurazioni di riferimento di dispositivi e apparati (PR.PS-01). Le configurazioni devono assicurare un adeguato livello di sicurezza e la loro applicazione prende il nome di hardening. Per esempio vanno disabilitate le utenze di default e disinstallati alcuni servizi potenzialmente sfruttabili da malintenzionati. Sono disponibili sul web indicazioni per ogni sistema operativo e per molte applicazioni.

Il software deve essere mantenuto aggiornato (PR.PS-02). In particolare deve essere prodotto da un soggetto che ne garantisca gli aggiornamenti di sicurezza e tali aggiornamenti devono essere installati il prima possibile. Idealmente, i sistemi dovrebbero essere configurati per installarli in automatico appena disponibili, ma è noto che questa pratica è a sua volta pericolosa. Per questo si raccomanda di installarli prima in un ambiente di test (questo è richiesto ai soggetti essenziali) o di assicurarsi la fattibilità del roll back.

Sicurezza dei dispositivi degli utenti

Per quanto riguarda laptop, smartphone e tablet (PR.DS-01, DE.CM-09):

• vanno cifrati;
• va disabilitato l’auto-run dei supporti rimovibili;
• va attivato e mantenuto aggiornato un antimalware che verifichi anche i supporti rimovibili.

I supporti rimovibili vanno cifrati.

Log e monitoraggio

Sono richiesti i seguenti log (PR.PS-04):

• accessi degli amministratori di sistema;
• eventi di sicurezza e in particolare degli accessi (che quindi dovrebbero includere i precedenti degli amministratori di sistema).

I log vanno conservati in modo sicuro e, se possibile, centralizzato. Sappiamo, con l’esperienza maturata nell’implementazione del Provvedimento del Garante per la protezione dei dati personali del 27 novembre 2008 e aggiornato il 25 giugno 2009, che questa richiesta è quella tecnologicamente più complessa ed economicamente potenzialmente più costosa.

Sono richiesti strumenti per rilevare tempestivamente gli incidenti (DE.CM-01, che fornisce dettagli su quali sistemi ed eventi monitorare). Si possono citare gli IDS e i SIEM. Per questi ultimi sono disponibili anche soluzioni open source che potrebbero essere valutate per la conservazione sicura e centralizzata dei log.

Va quindi stabilito il tempo di conservazione dei log sulla base del rischio (che andrebbe bilanciato con quello relativo alla protezione dei dati personali e al controllo a distanza dei lavoratori, ma abbiamo visto recentemente che il GPDDPP tende a imporre i risultati della propria valutazione del rischio e sanzionare il mancato adeguamento).

Backup

Vanno pianificati ed eseguiti i backup (PR.DS-11), secondo i criteri più opportuni. Vanno previste anche copie off-line, ormai necessarie per recuperare i sistemi in caso di incidenti dovuti a ransomware. Le misure ricordano la necessità di assicurare la sicurezza dei backup, con misure di tipo fisico o la cifratura.

I backup vanno verificati con prove di ripristino. Anche se è data per scontata la possibilità di ripristinare i sistemi dai backup, sono troppi gli esempi che dimostrano che sempre scontata non è.

Sviluppo sicuro

ACN richiede di adottare tecniche di sviluppo sicuro (PR.PS-06). Oggi queste sono spesso demandate all’applicazione delle regole raccomandate nel documento “OWASP Top ten”, relative però alle sole applicazioni web.

Sicuramente è una buona base di partenza, che dovrebbe essere successivamente ampliata considerando le funzioni di sicurezza che devono avere i software e la loro architettura.

Le misure di ACN non si soffermano sulla necessità di selezionare opportunamente anche il software acquisito, oltre al controllare quello sviluppato.

Gestione della rete

Si richiede (PR.IR-01) di avere attivi dei firewall per separare la rete interna almeno da Internet. Come riportato sopra, sono presenti richieste per gli accessi da remoto (PR.AA-01, PR.PS-04, PR.IR-01, DE.CM-01), per esempio di mantenere un inventario dei sistemi sui quali è possibile accedere da remoto, ma sarebbe stato opportuno proporre misure più in linea con il fatto che questi sono ormai la normalità.

Trasmissioni

Le trasmissioni vanno cifrate a seconda del rischio (PR.DS-02). Interessante osservare che le misure non riguardano solo le trasmissioni propriamente informatiche, ma anche quelle di comunicazione vocale, video e testuale.

Continuità operativa

Va stabilito un piano di continuità operativa, ossia una procedura con indicate le azioni da intraprendere in caso di interruzioni dei sistemi informatici (ID.IM-04, che specifica anche un indice di riferimento).

La misura è documentale, ma deve essere accompagnata da soluzioni tecnologiche che consentano, nei tempi ritenuti accettabili, il ripristino dei sistemi informatici in caso di incidenti che ne compromettono la disponibilità.

Interessante la richiesta, per i soggetti essenziali, di pianificare l’uso di canali di comunicazione protetti da usare in caso di emergenza (PR.IR-03). Oggi quasi tutte le comunicazioni sono protette, almeno con crittografia, ma questa misura, anche se scritta in modo molto sintetico, richiede di scegliere con cura i canali e di prevederne almeno uno alternativo a quello usato solitamente.

Vulnerability assessment e penetration test

La misura richiede ai soggetti essenziali (ID.RA-01) scansioni dei sistemi informatici, totalmente automatizzate (dette vulnerability assessment) o seguite da tentativi pratici di attacco da parte di un operatore specializzato (detti penetration test).

La Determinazione ACN non indica se tali test devono essere eseguiti da società esterne o possono essere eseguiti anche da personale interno, né se sono sufficienti test condotti da Internet o sono necessari anche test condotti dalla rete interna.

Si raccomanda di mantenere un piano dei test svolti e da svolgere, anche per dimostrare che, nel tempo, tutti i sistemi sono inclusi nell’attività.

Nis2, cosa aspettarsi dalle misure ACN

ACN ha messo in relazione le misure con quelle del framework nazionale sulla cybersecurity e la data protection, ossia con uno standard nazionale, traduzione a sua volta di uno standard nazionale statunitense, peraltro autorevole. Sarebbe stato più opportuno far riferimento a norme internazionali come la ISO/IEC 27001.

Bisogna però dire che è possibile associare facilmente le misure proposte da ACN con i requisiti e i controlli di tale standard e solo in pochi casi si discostano dalle pratiche normalmente consigliate per assicurare un buon livello di sicurezza informatica.

Nota dell’autore

Ringrazio Monica Perego per la correzione della bozza di questo articolo e per i numerosi suggerimenti per migliorarlo.