Come previsto dalla NIS2 (Direttiva UE 2022/2555), il 17 ottobre 2024 è stato pubblicato il regolamento di esecuzione (UE) 2024/2690 della Commissione che stabilisce “i requisiti tecnici e metodologici delle misure di cui al paragrafo 2 per quanto riguarda i 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, nonché i prestatori di servizi fiduciari”.
Prima di procedere a una sua dettagliata analisi, è bene sottolineare che questo regolamento di esecuzione (Implementing regulation) è applicabile solo ad alcuni settori in ambito NIS2.
Indice degli argomenti
NIS2: struttura del regolamento di esecuzione
Il Regolamento di esecuzione è diviso in due parti:
Norma ISO 31700 e privacy by design: cosa devono sapere aziende e consulenti
- la prima parte, articoli 3-13, precisa cosa si intende per “incidenti significativi” per i diversi settori di riferimento (servizi DNS, registri dei nomi di dominio, eccetera); molto importante perché specifica le soglie che determinano quando comunicare un incidente all’autorità (in Italia ACN);
- la seconda parte, l’Allegato, specifica più nel dettaglio le misure di sicurezza che la Direttiva elenca all’articolo 21 e il nostro D. Lgs. 138 elenca all’articolo 24.
Per quanto riguarda le definizioni di “incidenti significativi” le organizzazioni interessate dovranno aggiornare opportunamente le proprie procedure di gestione degli incidenti per valutare se rientrano nelle soglie indicate e, nel caso, notificarli all’autorità nazionale.
Le misure di sicurezza previste dalla NIS2
Per quanto riguarda le misure di sicurezza, sembra che siano ispirate a quelle già presenti nella ISO/IEC 27001 e, dove dettagliate, in linea con i tempi e anche con le risorse tipiche delle aziende europee, ossia molte PMI.
Le richieste non sono particolarmente dettagliate, contrariamente, per esempio, alla check list ACN del cosiddetto Regolamento cloud, ma richiedono attenzione, soprattutto per la parte documentale.
Molte organizzazioni dovranno prevedere investimenti almeno nello studio completo delle 20 pagine dell’allegato per valutare se le misure sono già presenti o se è necessario avviare progetti.
Nella tabella seguenti sono riportate le voci dell’allegato con qualche commento.
| Misura | Commento |
| Politica di sicurezza dei sistemi informativi e di rete (1.1). | Sono precisate le voci da prevedere nella politica di sicurezza, non molto dissimili da quanto già richiesto dalla ISO/IEC 27001. |
| Ruoli e responsabilità (1.2). | I requisiti sono generici, in linea con quanto già richiesto dalla ISO/IEC 27001. |
| Politica di gestione dei rischi (2.1). | Simile a quanto già richiesto dalla ISO/IEC 27001 per l’approccio per valutare i rischi relativi alla sicurezza delle informazioni. Come già dalla Direttiva NIS2, sono presenti precisazioni in più in merito alla catena di approvvigionamento. |
| Monitoraggio della conformità (2.2). | I requisiti sono generici, in linea con quanto già richiesto dalla ISO/IEC 27001 come parte del ciclo PDCA più ampio. |
| Riesame indipendente della sicurezza dei sistemi informativi e di rete (2.3). | I requisiti sono generici, in linea con quanto già richiesto dalla ISO/IEC 27001 in merito agli audit interni. |
| Gestione degli incidenti (3.1, 3.3, 3.4, 3.5, 3.6). | Sono fornite indicazioni in merito al processo di gestione degli incidenti (documentazione al 3.1, segnalazione al 3.3, valutazione e classificazione al 3.4, risposta al 3.5, riesame al 3.5). Nulla di diverso o più rigoroso da quanto richiesto dalle più diffuse best practice, inclusa ovviamente la ISO/IEC 27001. Da sottolineare la richiesta di eseguire i test delle procedure di gestione degli incidenti, non sempre eseguiti neanche dalle aziende certificate ISO/IEC 27001. |
| Monitoraggio e logging (3.2). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001, sono però riportati nel capitolo relativo alla gestione degli incidenti. La traduzione italiana traduce “logging” con “registrazioni”, creare così potenziali confusioni interpretative. Sono elencate alcune attività da sottoporre a log ed è richiesto di “riesaminarli regolarmente”, senza accennare alla necessaria automazione. |
| Continuità operativa e gestione delle crisi (4). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. Relativamente alle crisi, i requisiti riguardano le modalità di comunicazione, senza approfondimenti particolari. Sono riportati anche i requisiti relativi ai backup e ne sono richieste esplicitamente prove di ripristino. |
| Sicurezza della catena di approvvigionamento (5). | Come già richiesto dalla Direttiva 2555, i requisiti precisano le attività di selezione e controllo dei fornitori. Nei contratti devono debbano essere specificati i requisiti di cibersicurezza; questo vuol dire che non vanno previsti questionari, ma fatte richieste precise ai fornitori. Si osservi, a questo punto, che le normative europee usano “cibersicurezza” per tradurre “cybersecurity”. |
| Sicurezza nell’acquisizione di servizi o prodotti ICT (6.1). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. Da sottolineare la richiesta di stabilire e verificare, preventivamente all’acquisto, i requisiti di sicurezza dei prodotti e servizi. Questo non sempre è fatto, neanche dalle aziende certificate ISO/IEC 27001. In italiano, ICT è stato tradotto con TIC. |
| Ciclo di vita dello sviluppo sicuro (6.2). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. Le precisazioni di questo Regolamento di esecuzione non permettono di sottovalutare, come spesso succede anche in aziende certificate ISO/IEC 27001, la definizione dei requisiti di sicurezza e delle pratiche di ingegnerizzazione e codifica sicura. |
| Gestione delle configurazioni sicure (6.3). | Questi requisiti riguardano l’impostazione sicura dei sistemi e l’”hardening”. Purtroppo, come nella ISO/IEC 27001, è ignorato il fatto che la “Gestione della configurazione” nell’ambito del software e dei servizi (p.e. ITIL) riguarda il censimento dei componenti e delle loro correlazioni. I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. |
| Gestione delle modifiche, riparazioni e manutenzione (6.4). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001 per i sistemi, la rete e il software. Si richiama il fatto che tutte le modifiche vanno documentate e questo non sempre succede, neanche in alcune aziende certificate ISO/IEC 27001. |
| Test di sicurezza (6.5). | Sono richiesti, come prevedibile, vulnerability assessment e penetration test. I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. Si segnala la traduzione automatica di “scope” con “portata” e non “ambito”. |
| Gestione delle patch di sicurezza (6.6). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. È precisato che vanno monitorati i tempi di installazione delle patch dalla loro disponibilità e che vanno eseguiti test preventivi. La misurazione dei tempi è questione di non facile automazione per tutti i sistemi. |
| Sicurezza delle reti (6.7) e segmentazione della rete (6.8). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. Viene anche chiesto di documentare l’architettura della rete. Qui, ma anche altrove, alcuni controlli sono difficilmente applicabili da chi fa ricorso a servizi cloud (per esempio, si parla di DMZ, quando oggi molte architetture non la prevedono). |
| Protezione da software malevoli e non autorizzati (6.9). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. |
| Gestione e divulgazione delle vulnerabilità (6.10). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. |
| Strategie e procedure per valutare l’efficacia delle misure di gestione dei rischi di cibersicurezza (7). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. Da prestare attenzione al fatto che misurare le misure di sicurezza è spesso una pratica inefficace e pertanto il requisito andrà correttamente interpretato dalle organizzazioni e dagli auditor per evitare inefficienze. Si raccomanda, per questo, di far riferimento alla ISO/IEC 27004, che presenta numerosi esempi di misurazione. |
| Pratiche di igiene informatica di base e formazione in materia di sicurezza (8). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. Interessante come sono precisate le attività di sensibilizzazione e come sono ben distinte da quelle di formazione. |
| Crittografia (9). | È richiesto, con molta precisione, di documentare la gestione delle chiavi crittografiche, con un elenco degli argomenti da prevedere. |
| Sicurezza delle risorse umane (10). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. |
| Controllo dell’accesso (11). | I requisiti, per quanto numerosi, sono in linea con quanto già richiesto dalla ISO/IEC 27001. Viene richiesta l’autenticazione a più fattori. Si coglie anche qui l’occasione per biasimare la traduzione automatica di “controllo dell’accesso” anziché “controllo degli accessi”. |
| Classificazione delle risorse (12.1). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. Non viene richiesta, fortunatamente, l’etichettatura delle informazioni, pratica molto complessa (quindi inefficiente) e spesso non efficace. |
| Gestione delle risorse (12.2). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001 in merito alla gestione degli asset (acquisizione, uso, conservazione, trasporto ed eliminazione). |
| Politica in materia di supporti rimovibili (12.3). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. |
| Inventario delle risorse (12.4). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. |
| Deposito, restituzione o cancellazione delle risorse al momento della cessazione del rapporto di lavoro (12.5). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. |
| Sicurezza ambientale e fisica (13). | I requisiti sono in linea con quanto già richiesto dalla ISO/IEC 27001. |
Conclusioni
È chiaro che tutti i controlli sono facilmente riconducibili alla ISO/IEC 27001, anche in linea con il considerando 59 della Direttiva 2555 (“promuovere gli allineamenti agli standard internazionali”) e l’articolo 21 (“Nell’elaborare gli atti di esecuzione di cui al primo e secondo comma del presente paragrafo, la Commissione segue, nella misura del possibile, le norme europee e internazionali”).
Si ricorda che tutte le parti interessate possono partecipare alla redazione degli standard ISO, IEC e ISO/IEC, seguendo le appropriate procedure in vigore nel proprio Paese.
È quindi confermata la correttezza di una strada per adeguarsi alla NIS2, ossia adottare la ISO/IEC 27001, sia perché le misure sono facilmente correlabili, sia perché su di essa c’è un’esperienza diffusa che può essere di aiuto.
