Decreto legislativo - 18/05/2018 - n. 65 art. 12 - Obblighi in materia di sicurezza e notifica degli incidenti1

Il rischio

Al comma 1 dell'art. 12 d.lgs. n. 65/2018 è stabilito che «gli operatori di servizi essenziali adottano misure tecniche e organizzative adeguate e proporzionate alla gestione dei rischi posti alla sicurezza della rete e dei sistemi informativi che utilizzano nelle loro operazioni. Tenuto conto delle conoscenze più aggiornate in materia, dette misure assicurano un livello di sicurezza della rete e dei sistemi informativi adeguato al rischio esistente». Si presuppone che l'individuazione e la valutazione del rischio debba necessariamente basarsi su riconosciuti standard internazionali. Il principale e il più idoneo standard per definire il rischio nell'ambito di applicazione del d.lgs. n. 65/2018 è rappresentato dalla norma ISO/IEC 27001 poiché integra al suo interno le definizioni di evento di sicurezza ed incidente ovvero alcune delle parole chiave della Direttiva NIS. È d'uopo precisare, inoltre, come sia L'Information Commissioner's Office che è il regolatore indipendente del Regno Unito per la protezione dei dati e la libertà di informazione, sia ENISA, l'agenzia europea per la sicurezza delle reti e dell'informazione, facciano esplicito riferimento alla norma ISO/IEC 27001 come standard valido a tal fine (a tal proposito si veda art. 32 GDPR).

Il rischio è definito dalla norma ISO/IEC 27000 come effetto dell'incertezza sugli obiettivi, dovuta ad eventi che possono avere impatti negativi. La gestione del rischio consta di 5 fasi: stabilire il contesto, identificazione del rischio, analisi del rischio, valutazione del rischio e trattamento del rischio ed è composta da due componenti principali che sono la valutazione e il trattamento. La ISO 31000 e la ISO 27005 rappresentano degli standard per quanto riguarda la gestione del rischio. La preparazione concettuale, che rappresenta la vera esecuzione della valutazione del rischio e del suo trattamento, sono elementi della pianificazione a cui fa riferimento la norma ISO/IEC 27001. Tale pianificazione si estrinseca tramite la preparazione di un processo. Il processo viene definito per essere applicato, esso può consistere in un documento scritto oppure un tool informatico con delle caratteristiche note e la regolazione dei processi varia all'interno delle organizzazioni parametrandosi ai settori e ai diversi contesti. La procedura è ciò che definisce e descrive il processo e la sua esistenza è prodromica a dimostrarne il funzionamento. All'interno della norma ISO/IEC 27001 la presenza di una procedura formalizzata non è obbligatoria mentre il legislatore italiano, nel Decreto 12 dicembre 2018 denominato “Misure di sicurezza ed integrità delle reti di comunicazione elettronica e notifica degli incidenti significativi”, all'art. 4, comma 1, lett. a) n. 3, pare fornire connotazioni di obbligatorietà alla presenza di procedure relative ad ogni aspetto della gestione del rischio e degli incidenti di sicurezza. Tale decreto, infatti, rappresenta un importante tassello interpretativo per quanto riguarda gli artt. 12 e 14 del d.lgs. n. 65/2018 poiché si ritiene che l'elenco di misure in esso contenute possa essere la base dell'“accountability-NIS” ovvero una serie di controlli che forniscono la base interpretativa della contestualizzazione necessaria all'implementazione delle misure di sicurezza, che prescinde dalle misure che ciascuna organizzazione ritiene di dover applicare in base alle proprie analisi dei rischi, come precedentemente valutato relativamente all'abrogato Allegato B del d.lgs. n. 196/03 rispetto all'art. 32GDPR (v. art. 32 GDPR nel presente manuale).

Pertanto, risulta necessario contemperare i vari aspetti che definiscono una disciplina complessa che si basa sulle best practice derivanti dagli standard internazionali e dagli obblighi derivanti dalle fonti legislative, che a tali standard sembrano ispirarsi ma che ad essi aggiungono una obbligatorietà che gli standard ISO non prevedono.

All'interno della norma ISO 27001, infatti, vige un criterio di responsabilità che consiste nell'obbligo per l'organizzazione di dimostrare efficacia e conformità del proprio sistema di gestione delle informazioni. Tale conformità è da intendersi come capacità dell'organizzazione di stabilire i criteri di rischio, i criteri di accettabilità del rischio stesso, i criteri per effettuare la valutazione ed essere in grado di agire coerentemente rispetto a quanto stabilito. L'obbligatorietà relativa alla redazione di una politica di sicurezza per tutti gli aspetti elencati dal succitato decreto, pertanto, risulta non coerente con quanto contenuto all'interno della norma ISO/IEC 27001, snaturando la ratio dello standard.

È necessario precisare come il summenzionato decreto risulta pur sempre essere una base interpretativa di ciò che si intende per adeguate misure di sicurezza ex art. 12 d.lgs. n. 65/2018. Sarebbe, pertanto, da considerarsi obbligatoria la previsione di cui all'art. 4, comma 1, lett. a), n. 3 del Decreto sulle Misure di sicurezza unicamente rispetto ai fornitori di servizi di comunicazione elettronica individuati dall'art. 3 del decreto stesso ovvero a quei fornitori di accesso alla rete fissa o mobile da postazione fissa e di accesso alla rete fissa o mobile da terminale mobile che servono un numero di utenti effettivo pari o superiore all'1% della base di utenti nazionale o superiore ad un milione.

Risulta, pertanto, indispensabile distinguere l'esigenza di formalizzare le procedure relative ai processi all'interno delle organizzazioni, al fine di rispettare quanto richiesto dal suddetto decreto, rispetto all'esigenza di formalizzare procedure relative a processi in quanto misure di mitigazione organizzative derivanti dalle analisi dei rischi.

Per quanto riguarda il secondo aspetto, la gestione del rischio relativo alla sicurezza delle informazioni, richiede un adeguato metodo di valutazione e trattamento del rischio che sarà contestualizzato dal punto di vista del settore di appartenenza dell'organizzazione e del quadro economico in cui si muove l'organizzazione stessa.

La valutazione del rischio è volta ad individuare i rischi in maniera tale che i risultati dell'analisi costituiscano le linee guida su cui basare le azioni e le priorità relative all'implementazione di misure di mitigazioni dei rischi identificati. Tale valutazione dovrebbe avvenire su base periodica, con ciclicità predeterminata, al fine di attenzionare i possibili cambiamenti dell'organizzazione rispetto a tutte le variabili prese in considerazione.

La norma ISO/IEC 27005 rappresenta un'utile guida per la gestione del rischio, stabilendo dei criteri da seguire per effettuare la valutazione del rischio e il trattamento del rischio, per guidare nello stabilire quando accettare il rischio e come monitorarlo.

Le misure

Il comma 2 dell'art. 12 del d.lgs. n. 65/2018 obbliga gli «operatori di servizi essenziali ad adottare misure adeguate per prevenire e minimizzare l'impatto di incidenti a carico della sicurezza della rete e dei sistemi informativi utilizzati per la fornitura dei servizi essenziali». Al fine di individuare correttamente le misure da implementare è utile, per gli OSE, procedere ad un'analisi dei rischi e trattare i rischi considerati non accettabili. Le misure di sicurezza di cui all'art. 12 del d.lgs. n. 65/2018 saranno identificate, pertanto, attraverso l'applicazione di opportuni controlli che possano mitigare i rischi individuati. Tali controlli dovrebbero essere predisposti al fine di garantire che i rischi individuati scendano al di sotto di un valore che l'operatore possa considerare accettabile o non agevolmente mitigabile, prendendo in considerazione diversi elementi. I principali elementi che la norma ISO/IEC 27001 identifica riguardano i requisiti normativi, gli obiettivi che l'organizzazione si è posta, i vincoli a cui è sottoposta e non ultimo il budget a disposizione senza tralasciare però il necessario bilanciamento tra l'implementazione dei controlli e le perdite potenziali che potrebbero verificarsi a seguito di incidenti.

Occorre sottolineare come i controlli derivanti dall'Annex A dello standard ISO/IEC 27001 potrebbero non soddisfare le specifiche necessità di un operatore.

Gli standard ISO, come le linee guida ENISA, rappresentano delle best practice non dissimili da quelle individuate circa le misure tecniche ed organizzative relative al trattamento dei dati personali ex art. 32 GDPR. (si rimanda all'art. 32 GDPR).

Pertanto, si può concludere che ogni operatore e più in generale ogni organizzazione potrà decidere di sviluppare ex novo un insieme di controlli finalizzati a mitigare i rischi individuati.

ENISA, nel dicembre del 2017, ha rilasciato delle linee guida per quanto riguarda la mappatura dei requisiti di sicurezza relativi agli specifici settori impattati dalla direttiva NIS, che risultano quindi, ex art. 12, comma 3 d.lgs. n. 65/2018, di primaria importanza nell'individuazione delle misure di cui ai commi 1 e 2.

Le linee guida di cui sopra, sono il prodotto dell'elaborazione da parte di ENISA del contenuto degli standard ISO/IEC 27001, ANSI ISA/IEC 62443 e “NIST Framework for improving critical infrastructure cybersecurity” e sono composte da 3 parti. La prima riguarda introduzione, contestualizzazione, scopi e metodologia, la seconda parte è relativa alla suddivisione settoriale e all'individuazione delle best practice per energia, trasporti, finanza e banche, sanità, acqua potabile e distribuzione della stessa, infrastrutture digitali. La terza parte riguarda l'individuazione delle misure che sono adottabili indifferentemente in tutti i settori. È utile sottolineare come gli standard succitati non soddisfano ogni settore considerato, pertanto ENISA segnala ulteriori standard internazionali come fonte delle best practice per l'individuazione delle misure adeguate.

Si riporta l'elenco delle best practice e degli standard individuati da ENISA in quanto idonei trasversalmente per tutti i settori impattati dalla direttiva NIS: ANSI/ISA, Series “ISA-62443: Security for industrial automation and control system”; ISO 27001 Information Technology Security Techniques Information Security Management Systems Requirements; NIST Framework for Improving Critical Infrastructure Cybersecurity; ISO/IEC 27002:2013: Code of practice for information security controls; ISO 27003 – Information technology – Security techniques – Information security management system implementation guidance; ISO/IEC 27004:2016 Information technology – Security techniques – Information security management – Monitoring, measurement, analysis and evaluation; ISO/IEC 20000-1:2011 Information technology – Service management – Part 1: Service management system requirements; ISO/IEC 27010:2015 Information technology – Security techniques – Information security management for inter-sector and inter-organizational communications; ISO/IEC 21827:2008 Information technology – Security techniques – Systems Security Engineering – Capability Maturity Model® (SSE-CMM®); ISO/IEC 10181-2:1996 Information technology – Open Systems Interconnection – Security frameworks for open systems: Authentication framework; ISO/IEC 27013:2015 Information technology – Security techniques – Guidance on the integrated implementation of ISO/IEC 27001 and ISO/IEC 20000-1; ISO/IEC 27014:2013 Information technology – Security techniques – Governance of information security; ISO/IEC 27032:2012 Information technology – Security techniques – Guidelines for cybersecurity; ISO/IEC 27033-1:2015 Information technology – Security techniques – Network security – Part 1: Overview and concepts; ISO/IEC 27034-1:2011 Information technology – Security techniques – Application security – Part 1: Overview and concepts; ISO/IEC TR 19791:2010 Information technology – Security techniques – Security assessment of operational systems; The CIS Critical Security Controls for Effective Cyber Defence Version 6.1; Organisation for Economic Co-operation and Development (OECD), Guidelines for the Security of Information Systems and Networks, 2002; Generally Accepted Information Security Principles (GAISP) – ISSA; The Open Group Open Information Security Management Maturity Model (O-ISM3); ISACA BMIS; IT Baseline Protection Manual Standard Security Measures – BSI; UK Cyber Essentials (CREST); Cyber Defence Capability Assessment Tool (CDCAT®) – CESG; HMG Security Policy Framework (SPF) – CESG; NIST/NSA/DISA/DoD Security Technical Implementation Guides (STIGs); Carnegie Melon Capability Maturity Model (CMM) Mapping of OES Security Requirements to Specific Sectors 55; European Telecommunications Standards Institute (ETSI) Cybersecurity Standards; TR 103 303 – TR 103 309 CYBER series; TR 103 331 CYBER; Structured threat information sharing; TR 103 369 CYBER; Design requirements ecosystem; TS 103 487 CYBER; Baseline security requirements regarding sensitive functions for NFV and related platforms; IT Infrastructure Library (ITIL) v3; NIST SP 800-53; Information Assurance for SMEs (IASME); ISF Standard of Good Practice for Information Security; ITU X series: Information security management framework.

Il gruppo di cooperazione di cui all'art. 12, comma 3 d.lgs. n. 65/2018 ha accompagnato le linee guida succitate da un documento di riferimento che ne stabilisce i principi generali. (Documento di riferimento sulle misure di sicurezza per gli operatori di servizi essenziali – Pubblicazione CG 01/2018).

Innanzitutto, per ENISA, le misure di sicurezza dovrebbero essere efficaci in relazione al panorama attuale delle minacce, rapportate all'effort necessario per implementarle, compatibili in termini di trasversalità settoriale, proporzionate ai rischi intesi nel senso di non privilegiare l'applicazione di misure di sicurezza relative unicamente ai sistemi informativi considerati critici; concretamente attuate e di agevole utilizzo; la cui implementazione è verificabile; inclusive, per includere tutti i domini di sicurezza che possano contribuire a rafforzare l'infrastruttura.

Oltre a questi principi, ENISA, incoraggia gli Stati a riconoscere il valore del partenariato pubblico e privato, in particolare per quanto riguarda l'attuazione delle misure di sicurezza. Tali partenariati possono rappresentare dei punti di contatto che agevolano l'identificazione delle misure intersettoriali e settoriali e consentire di instaurare un dialogo permanente tra gli operatori di servizi essenziali finalizzato all'effettiva attuazione delle misure individuate.

Le misure individuate nelle linee guida e nel documento di riferimento redatto da ENISA e dal gruppo di cooperazione sono a loro volta suddivise in 4 macro-categorie. La prima riguarda il sistema di gestione delle informazioni e di gestione del rischio, la seconda e la terza macro-categoria sono relative rispettivamente ai sistemi di protezione e di difesa mentre la quarta riguarda la resilienza dell'organizzazione.

Per quanto riguarda la prima parte, relativa al sistema di gestione delle informazioni e di gestione del rischio, occorre prendere in considerazione come siano principalmente ricorrenti controlli relativi all'analisi del rischio, alla presenza di policy di sicurezza formalizzate relative alle informazioni, alla presenza di audit, alla gestione degli asset e alla mappatura dell'ecosistema dell'organizzazione inteso come mappatura dei flussi di dati e delle infrastrutture sulle quali risiedono.

Relativamente alla macro-categoria precedentemente definita “protezione”, ENISA riscontra come nei diversi standard presi in considerazione ricorra la presenza di controlli relativi all'architettura informatica che si dettagliano nella presenza di sistemi preconfigurati ed eventualmente segregati in un'ottica di gestione centralizzata, soggetti all'azione di un filtro per il traffico di rete e protetti con tecniche crittografiche. Maggiormente ricorrente risulta la necessità di prestare attenzione agli account amministrativi ovvero quegli account dotati di permessi elevati su sistemi e applicazioni e, più generalmente, prendere in considerazione identificazione, autenticazione e permessi su tutte le utenze in uso all'interno del perimetro informatico dell'operatore. Risulta inoltre frequente il richiamo alla corretta gestione della manutenzione, intesa come controllo degli accessi remoti e delle procedure ad esso inerenti. In ultimo si segnala come sia considerata rilevante anche la sicurezza fisica e ambientale degli apparati, intesa come insieme di procedure che possono mitigare svariati rischi quali furto e distruzione.

Si riscontra come la macro-categoria relativa alla difesa consti di sei controlli ricorrenti, a loro volta suddivisi in “rilevazione” e “gestione dell'incidente di sicurezza”. ENISA riporta come siano ricorrenti i controlli relativi al rilevamento inteso come segnalazione dell'occorrenza di un evento di sicurezza e alla relativa produzione e correlazione di log di sicurezza e alla presenza di report e flussi di comunicazione interni ed esterni finalizzati a gestire gli incidenti di sicurezza stessi.

La macro-categoria relativa alla resilienza è ulteriormente suddivisa in due categorie contenenti rispettivamente due controlli ciascuna. Per quanto riguarda la categoria denominata “continuità delle operazioni”, ENISA riscontra come sia ricorrente in tutti gli standard settoriali la presenza di un piano di gestione della continuità operativa e un piano di gestione del disaster recovery. La categoria denominata “gestione della crisi” consta di due controlli di natura organizzativa ovvero la presenza di un sistema di gestione della crisi all'interno dell'organizzazione e di un processo formalizzato ad essa relativo.

Il decreto 12 dicembre 2018, relativo alle misure di sicurezza ed integrità delle reti di comunicazione elettronica e notifica degli incidenti significativi già citato, consente di estrapolare ulteriori misure di sicurezza che possono far parte di quell'insieme di controlli che assumono rilevanza anche per quanto riguarda l'applicazione della normativa NIS.

Il decreto, all'art. 4 d.m. 12 dicembre 2018, dispone che i fornitori di reti e servizi di comunicazione elettronica sono tenuti ad adottare le misure di sicurezza e integrità delle reti e dei servizi, creando un collegamento logico-giuridico con gli artt. 12 e 14 d.lgs. n. 65/2018.

La ratio delle misure di sicurezza elencate al comma 1 dell'art. 4 del decreto sembra derivare dalla metodologia dello standard ISO/IEC 27001 e, soprattutto, dall'Annex A dello standard, contenente le proposte misure di mitigazione del rischio.

Analizzando adeguatamente il decreto si nota, come già precedentemente accennato, che ciò che la norma ISO/IEC 27001 delinea in termini di facoltatività, assume invece per il legislatore delle connotazioni di obbligatorietà almeno per quanto riguarda gli operatori individuati dall'art. 3 d.m. 12 dicembre 2018. Tale carattere di obbligatorietà pone gli operatori di fronte alla possibilità di interpretare come prioritaria l'adozione delle misure di cui al decreto in luogo dell'adozione delle misure derivanti delle linee guida di ENISA ed in luogo di quelle individuate a seguito dell'analisi dei rischi da svolgersi internamente all'organizzazione. In tal senso si ritiene di dover sottolineare come, per quanto non vi è una sostanziale difformità tra l'Annex A della norma ISO/IEC 27001 e le misure dettagliate dall'art. 4 del decreto, risulta invece particolarmente ampia la distanza tra norma e decreto quando si legge il numero 3 della lettera a) del comma 1 dell'art. 4 ovvero “definire e mantenere aggiornata una politica di sicurezza per tutti gli aspetti elencati nelle successive lettere”. Una politica di sicurezza non può che consistere nella formalizzazione di una policy e di specifiche procedure che ad essa si ispirano, interna all'organizzazione; una policy che dettagli la posizione dell'organizzazione e la proceduralizzazione dei processi relativi a ciascun controllo. L'adesione alla norma ISO/IEC 27001 non obbliga a tale processo di formalizzazione relativamente a ciascun controllo bensì al loro insieme. L'applicazione di tale decreto risulta pertanto consistente in un rafforzamento in termini di formalizzazione delle politiche di gestione di quanto previsto dalla norma ISO/IEC 27001 e sposta sul piano dell'idoneità ad una norma di legge ciò che invece è il rispetto di uno standard finalizzato ad ottenere una certificazione sul sistema di gestione delle informazioni. Vi sono pochi dubbi relativamente alla circostanza che vede il legislatore italiano all'avanguardia nella trasposizione del contenuto di uno standard di sicurezza internazionalmente valido e riconosciuto dalla stessa ENISA nelle sue linee guida, se non fosse che la previsione di processi di formalizzazione delle politiche aziendali attinenti a ciascun controllo individuato dall'Annex A della norma ISO/IEC 27001 potrebbe risultare in contraddizione con l'applicazione del principio delineato dal comma 1 dell'art. 12 d.lgs. n. 65/2018 che pare priorizzare l'analisi dei rischi e il necessario processo di contestualizzazione ad essa afferente. Dall'applicazione del decreto, anche esclusivamente per analogia e non poiché operatori direttamente interessati dallo stesso, discenderebbe come l'identificazione di misure di sicurezza derivanti dall'analisi dei rischi in via autonoma da parte di un'organizzazione e l'implementazione delle misure di sicurezza individuate nelle linee guida di ENISA, abbiano caratteri di residualità rispetto all'implementazione delle misure di sicurezza individuate nel decreto e alla loro formalizzazione nelle policy e procedure che le regolano nel contesto organizzativo aziendale. Da ciò si potrebbe dedurre come le misure di sicurezza, di cui agli artt. 12 e 14 del d.lgs. n. 65/2018, siano principalmente quelle delineate nel decreto 12 dicembre 2018 relativo alle misure di sicurezza ed integrità delle reti di comunicazione elettronica e notifica degli incidenti significativi per il principio lex specialis derogat generali per cui, nel summenzionato caso di antinomia, la prevalenza spetterebbe alla norma che maggiormente dettaglia quanto richiesto dal d.lgs. n. 65/2018.

Occorre pertanto analizzare quali siano le misure di sicurezza richieste dal suddetto decreto per poter successivamente interpretare con quali strumenti poterle implementare all'interno delle architetture informatiche ed organizzative degli operatori di servizi essenziali.

La lett. a) del comma 1 dell'art. 4 del decreto delinea la necessità di una politica di sicurezza formalizzata relativa alla sicurezza e all'integrità delle reti e dei servizi forniti, per gli asset critici e per i i processi aziendali e per tutte le misure di sicurezza elencate nelle lettere successive.

All'interno del dettato normativo della lett. b) del comma 1 dell'art. 4 ricorre il principio di centralità dell'analisi dei rischi già più volte analizzato, obbligando i fornitori di reti e servizi di comunicazione elettronica ad ”individuare i principali rischi per la sicurezza e l'integrità delle reti e dei servizi di comunicazione elettronica forniti, tenendo conto delle minacce che insistono sugli asset critici” ed a “definire una metodologia di gestione dei rischi e utilizzare strumenti basati sugli standard di settore”. Da ciò si desume come sia necessario operare delle analisi dei rischi genericamente sull'infrastruttura e specificatamente sugli asset definiti critici all'interno della stessa, formalizzando la ciclicità di tali valutazioni sulla base dell'applicazione degli standard settoriali. Il principale standard che soddisfa lo scopo fissato è individuato da ENISA nelle linee guida sopraddette ed è rappresentato dallo standard ISO/IEC 27005. Ulteriormente la lett. b) dispone come sia necessario, per il fornitore di servizi di rete e comunicazione elettronica, “verificare l'effettivo utilizzo di tali metodologie e strumenti di gestione del rischio da parte del personale” ed “assicurarsi che i rischi residui, anche derivanti da vincoli realizzativi, siano minimizzati rispetto alla probabilità del verificarsi di incidenti significativi e che siano accettati dalla Direzione”. La verifica periodica dell'esperimento di analisi dei rischi e la ciclicità già precedentemente accennata sono parte integrante della norma ISO/IEC 27001 e la minimizzazione dei rischi individuati risulta essere un'estrinsecazione del principio relativo alla mitigazione dei rischi identificati nell'analisi del rischio.

La lett. c) del comma 1 dell'art. 4 del decreto obbliga i fornitori di reti e servizi di comunicazione elettronica a dotarsi di una struttura organizzativa che potrebbe essere definita cybersecurity-by-design. Trattasi dell'obbligo di “identificare ruoli per il personale e le relative responsabilità in autonomia di esercizio”; “conferire, con formale nomina, ruoli e responsabilità al personale” ed “assicurare la reperibilità, in caso di incidenti di sicurezza, del personale responsabile”. Tali disposizioni implicano la presenza di un modello organizzativo cybersecurity con relativa designazione di figure quali uno Chief Information Security Officer che possa coordinare i responsabili dell'architettura informatica che dovranno a loro volta assicurare reperibilità. La lettera d) del comma 1 dell'art. 4 del decreto inquadra la problematica di una corretta gestione della cd. supply chain, ovvero la gestione di servizi e prodotti forniti da terze parti, obbligando i fornitori di reti e di servizi di comunicazione elettronica a “definire i requisiti di sicurezza nei contratti con terze parti”; “verificare il rispetto dei requisiti fissati nei contratti”; “assicurare che i rischi residui che non sono gestiti dalla terza parte siano minimizzati rispetto alla probabilità del verificarsi di incidenti e che siano accettati dalla Direzione”; “tenere traccia ed eventualmente gestire gli incidenti di sicurezza relativi a terze parti o da esse causati che si ripercuotono sulla rete o sul servizio erogato”. Potrebbe quindi essere necessaria la predisposizione di una checklist, in fase precontrattuale, che possa agevolare nella definizione dei requisiti di sicurezza necessari, da sottoporre ai fornitori, predisponendo successivamente dei service level agreement e operando degli audit di seconda parte per verificare l'effettiva implementazione di quanto richiesto e/o dichiarato. Risulta altresì necessario adoperarsi nella gestione dei rischi residui non idoneamente mitigati dai fornitori e tenere traccia di eventuali incidenti da essi derivanti tramite appositi registri. Risulta, dal contenuto letterale che non sarebbe sufficiente delegare la terza parte che abbia causato un incidente di sicurezza alla gestione dello stesso ma che dovrà essere il fornitore di reti e servizi di comunicazione elettronica ad adoperarsi attivamente nell'eventualità che tale incidente impatti sui propri sistemi.

La lett. d) del comma 1 dell'art. 4 del decreto inquadra la problematica di una corretta gestione della cd. supply chain, ovvero la gestione di servizi e prodotti forniti da terze parti, obbligando i fornitori di reti e di servizi di comunicazione elettronica a “definire i requisiti di sicurezza nei contratti con terze parti”; “verificare il rispetto dei requisiti fissati nei contratti”; “assicurare che i rischi residui che non sono gestiti dalla terza parte siano minimizzati rispetto alla probabilità del verificarsi di incidenti e che siano accettati dalla Direzione”; “tenere traccia ed eventualmente gestire gli incidenti di sicurezza relativi a terze parti o da esse causati che si ripercuotono sulla rete o sul servizio erogato”. Potrebbe quindi essere necessaria la predisposizione di una checklist, in fase precontrattuale, che possa agevolare nella definizione dei requisiti di sicurezza necessari, da sottoporre ai fornitori, predisponendo successivamente dei service level agreement e operando degli audit di seconda parte per verificare l'effettiva implementazione di quanto richiesto e/o dichiarato. Risulta altresì necessario adoperarsi nella gestione dei rischi residui non idoneamente mitigati dai fornitori e tenere traccia di eventuali incidenti da essi derivanti tramite appositi registri. Risulta, dal contenuto letterale, che non sarebbe sufficiente delegare la terza parte, che abbia causato un incidente di sicurezza, alla gestione dello stesso, ma che dovrà essere il fornitore di reti e servizi di comunicazione elettronica ad adoperarsi attivamente nell'eventualità che tale incidente impatti sui propri sistemi.

Per quanto riguarda il contenuto della lett. e) del comma 1 dell'art. 4 del decreto, si riscontra come assuma carattere di obbligatorietà l'adozione di un piano di formazione del personale sia in quanto dotato di responsabilità specifiche relative alla sicurezza, sia generalmente inteso. Tale formazione dovrà consistere in corsi e sessioni di sensibilizzazione e dovrà essere soggetta a verifica. Il legislatore, pertanto, ritiene come sia necessario rendere edotto il personale circa la possibilità di incorrere in incidenti di sicurezza, sottolineando la rilevanza della formazione e della sensibilizzazione, nel ridurre il rischio di attacchi cyber. L'anello più debole della catena della sicurezza potrebbe spesso essere rappresentato da dipendenti incauti o non sufficientemente formati e/o sensibilizzati alle tematiche di sicurezza informatica, risulta pertanto come tale disposizione normativa sia particolarmente idonea a raggiungere gli scopi prefissati. Risulta, inoltre, come sia necessario definire appropriate procedure per la gestione dei neoassunti e come sia ritenuto obbligatorio definire delle procedure per la rotazione del personale che ricopre ruoli di responsabilità, in maniera tale da ridurre il rischio di concretizzazione di minacce che arrivino dall'interno dell'organizzazione. Sarà necessario, inoltre, revocare i diritti d'accesso se non più giustificati e prevedere sanzioni ex art. 7 l. n. 300/1970 per i dipendenti che non rispettino le policy dell'organizzazione.

La lett. f) del comma 1 dell'art. 4 del decreto prevede l'implementazione di misure relative alla sicurezza fisica e logica dei sistemi. Si riscontra come sia obbligatoria la presenza di appropriati meccanismi di autenticazione, definiti di “adaptive authentication”, ovvero contestualizzati rispetto alla tipologia di accesso e al sistema che con tale misura di sicurezza si intende proteggere. Risulta come sia, inoltre, necessario definire le condizioni, responsabilità e le procedure per assegnare e revocare i diritti d'accesso e per approvare eventuali eccezioni. La lett. f) richiama il contenuto dell'abrogato allegato B del d.lgs. n. 196/2003, dal momento che rende obbligatoria la verifica del possesso di ID univoci per ciascun utente. In ultimo si riscontra come, alla luce dell'applicazione del decreto, sia necessario “prevedere meccanismi di protezione degli impianti funzionali all'erogazione del servizio, quali, a titolo esemplificativo ma non esaustivo, elettricità e gas”.

La lett. g) del comma 1 dell'art. 4 del decreto prevede l'adozione di sistemi di protezione e rilevamento di malware che possano alterare la funzionalità dei sistemi e l'ulteriore implementazione di strumenti che possano garantire l'assenza di manomissione per quanto riguarda i software utilizzati all'interno dell'organizzazione. Risulta altresì obbligatorio per l'organizzazione “assicurarsi che i dati critici sulla sicurezza, quali, a titolo esemplificativo ma non esaustivo, password e chiavi private, non siano divulgati o manomessi” prevedendo, a norma dell'art. 4, comma 1, lett. a), n. 3, una relativa policy che delinei le modalità in cui si garantisce la presenza di tale misura di sicurezza organizzativa.

Per quanto riguarda il contenuto della lett. h) del comma 1 dell'art. 4 del decreto, il legislatore pone l'attenzione sulla presenza di sistemi critici regolando le modalità di gestione operativa sugli stessi. Il decreto, pertanto, rende obbligatorio predisporre procedure operative e individuare i responsabili per il funzionamento dei sistemi critici, predisporre procedure di gestione del cambiamento e attenersi generalmente alle procedure predefinite quando si opera sui sistemi critici. Si rende, inoltre, necessario registrare e documentare ogni modifica effettuata, predisponendo e aggiornando delle baseline per poter agevolmente ripristinare tali sistemi in caso di necessità. Condizione necessaria per cui si possa rispettare tali previsioni è la predisposizione e un costante aggiornamento di un inventario degli asset ritenuti critici.

La lett. i) del comma 1 dell'art. 4 del decreto è relativa alla gestione degli incidenti di sicurezza. Si evidenzia come sia necessario per i fornitori di servizi di rete e comunicazione elettronica “prevedere una struttura tecnica con adeguata competenza e disponibilità incaricata della gestione degli incidenti”; «predisporre e aggiornare un database degli incidenti”; “esaminare i principali incidenti e redigere relazioni sugli stessi, che contengano informazioni sulle azioni intraprese e sulle raccomandazioni per ridurre il rischio del ripetersi di incidenti analoghi”; “definire e implementare processi e sistemi per il rilevamento degli incidenti”; “definire procedure per informare gli utenti su incidenti in corso o risolti, oltreché il CSIRT italiano e l'Istituto superiore delle comunicazioni e delle tecnologie dell'informazione del Ministero dello sviluppo economico (di seguito anche ISCTI) secondo quanto previsto dal presente decreto, informando, comunque, preventivamente il CSIRT e l'ISCTI”; “definire procedure per la segnalazione degli incidenti significativi ai sensi del successivo art. 5” del decreto. Tali obblighi risultano coincidenti con quelli derivanti dall'applicazione del d.lgs. n. 65/2018 agli artt. 12 comma 4 e 14 comma 5, relativi alla notifica degli incidenti di sicurezza operata verso il CSIRT, ma non sufficienti. Infatti, per quanto riguarda esclusivamente i fornitori di servizi di rete e comunicazione elettronica, è prevista una notifica anche verso ISCTI. La definizione di procedure di notifica dell'incidente e di sua preventiva gestione risultano pertanto necessarie in applicazione sia del decreto summenzionato sia del d.lgs. n. 65/2018. Se l'incidente di sicurezza dovesse presentare rischi per le libertà e i diritti degli interessati, coinvolgendo dati personali degli stessi, gli operatori dovranno pertanto anche informare l'Autorità Garante (per ulteriori approfondimenti si veda art. 33 GDPR). Emerge come possa essere necessario regolamentare un flusso informativo interno ed esterno all'azienda predisponendo policy e procedure che possano regolamentare le casistiche di incidente sia quando esso riguardi l'operatività dei sistemi sia quando esso riguardi i dati personali, formalizzando delle strategie di gestione dell'incidente che possano condurre ad una tempestiva notifica verso le autorità preposte con il risultato di limitare l'impatto che un incidente di sicurezza possa comportare verso i cittadini dell'Unione.

La lett. j) del comma 1 dell'art. 4 del decreto delinea le misure relative alla continuità operativa. Sarà obbligo del fornitore di servizi di rete e comunicazione elettronica “predisporre e implementare piani di emergenza per gli asset critici” e monitorare l'esecuzione ed attivazione di tali piani, avendo cura di registrare i tempi di ripristino dell'operatività del servizio. Risulta inoltre come sia necessario «predisporre e mantenere una appropriata capacità di disaster recovery” e “implementare procedure per le attività di ripristino dell'operatività e dei servizi». La ratio legis sottesa alla presenza di tali misure è in parte coincidente con la ratio legis sottesa al d.lgs. n. 65/2018 e generalmente alla direttiva NIS ovvero aumentare la capacità di ripristino di servizi ritenuti essenziali per i cittadini, a seguito di incidenti.

In ultimo, la lett. k) del comma 1 dell'art. 4 del decreto riguarda le misure relative al monitoraggio, test e controllo necessario al fine di mantenere aggiornato quanto implementato. Risulta come sia necessario ”sottoporre a test reti, sistemi informativi e nuove versioni del software prima di utilizzarli o collegarli a sistemi esistenti”, al fine di prevenire la messa in produzione di software vulnerabile e l'implementazione di apparati che possano generare conflitti e disfunzioni all'interno dell'architettura; “implementare il monitoraggio e la registrazione dello stato e degli eventi dei sistemi critici”, inteso come implementazione di un sistema di operational intelligence in grado di raccogliere i log dei sistemi critici; “impostare gli strumenti per raccogliere e archiviare i registri dei sistemi critici”, intesa come capacità di salvaguardare i log di cui alla previsione precedente dalla distruzione e dalla possibilità di esaurimento dello spazio a disposizione per la loro archiviazione; “configurare strumenti per la raccolta e l'analisi automatizzata di dati e registri di monitoraggio”, intesa come predisposizione di un SIEM (security information and event management software) o di una soluzione similare che possa produrre delle segnalazioni in caso di riscontro di anomalie nell'infrastruttura informatica; “predisporre un programma per la realizzazione di esercitazioni periodiche per testare piani di disaster recovery e di ripristino dei backup”, al fine di evitare la circostanza di malfunzionamenti in caso di necessità; “implementare strumenti per test automatizzati”, intesa presumibilmente come implementazione di tool automatizzati per il vulnerability assessment che in ogni caso non dovranno sostituire operazioni manuali condotte in tal senso e necessarie al fine di esaurire la portata della misura di sicurezza; “assicurarsi che i sistemi critici siano sottoposti a scansioni e test di sicurezza regolarmente, in particolare quando vengono introdotti nuovi sistemi e in seguito a modifiche”, al fine di non assorbire all'interno dell'infrastruttura vulnerabilità non sufficientemente attenzionate; “monitorare la conformità agli standard e alle disposizioni normative”, al fine di mantenere le conoscenze sulle best practice e sugli standard costantemente aggiornati in maniera tale da essere sempre in grado di rispondere adeguatamente alle minacce globalmente individuate.

In conclusione, l'art. 12, comma 4 d.lgs. n. 65/2018 apre alla possibilità che ulteriori misure di sicurezza possano essere identificate da parte delle autorità competenti NIS, mantenendo saldo il principio di un costante necessario aggiornamento delle cautele da adottare nell'approccio alle minacce relative alla sicurezza informatica.

La notifica

L'art. 1 della Direttiva (UE) 2016/1148, “Direttiva NIS” definisce un “incidente” come «qualsiasi evento che abbia un concreto effetto negativo sulla sicurezza di rete e dei sistemi di informazione». In combinato disposto con la definizione di “sicurezza della rete e dei sistemi di informazione”, risulta ampiamente in linea con gli standard esistenti in materia di sicurezza delle informazioni. Infatti la definizione di “incidente” all'interno della pubblicazione speciale NIST 800-53 ha significato di «un evento che in modo imminente mette a repentaglio, senza l'autorizzazione legale, la riservatezza, l'integrità o la disponibilità di informazioni o un sistema di informazioni».

Si è tenuti ad informare il CSIRT di qualsiasi incidente che abbia un impatto sostanziale sulla fornitura dei servizi essenziali. È necessario valutare se l'incidente abbia causato “un impatto sostanziale sulla fornitura dei servizi essenziali” ex art. 12, comma 5 d.lgs. n. 65/2018 al fine di decidere se è necessario notificarlo. Quando si valuta se si ha bisogno di notificare, è necessario, inoltre, prendere in considerazione una serie di fattori tra cui il numero di utenti interessati, la durata dell'incidente, la diffusione geografica, l'entità dell'interruzione e l'entità dell'impatto dell'incidente. È necessario informare il CSIRT senza indebito ritardo ex art. 12, comma 5 d.lgs. n. 65/2018. Ciò si allinea sostanzialmente con gli obblighi di segnalazione per le violazioni dei dati personali nell'ambito dell'applicazione dell'art. 33 GDPR.

Il Regolamento europeo 2018/151 contiene al suo interno le norme per una corretta applicazione della direttiva NIS e fornisce quindi elementi che devono essere necessariamente presi in considerazione dai fornitori di servizi digitali ma che possono risultare altrettanto utili nel fornire una linea interpretativa per agevolare il rispetto degli obblighi imposti dal d.lgs. n. 65/2018, anche per quanto riguarda gli operatori di servizi essenziali. Nel Regolamento 2018/151, per durata dell'incidente, si intende il periodo di tempo trascorso dall'interruzione del servizio fino al suo ripristino. L'art. 3, paragrafo 3, del regolamento precisa che la diffusione geografica rispetto all'area colpita si riferisce alla capacità di identificare se l'incidente riguarda la prestazione dei servizi in altri Stati membri: in altre parole, è necessario determinare se l'incidente ha un impatto transnazionale. L'art. 3, paragrafo 4, del regolamento 2018/151 richiede che l'operatore sia in grado di misurare se l'incidente abbia compromesso uno o più dei seguenti elementi: la disponibilità di dati o servizi correlati; l'autenticità dei dati o dei servizi connessi; l'integrità dei dati o dei servizi correlati e la riservatezza dei dati o dei servizi correlati. L'art. 3, paragrafo 5, del regolamento 2018/151 richiede che l'utente sia in grado di stabilire se l'incidente: “ha causato notevoli perdite materiali o immateriali per gli utenti in relazione a salute, sicurezza o danni alla proprietà”.

La notifica deve includere il nome dell'organizzazione; il momento in cui è avvenuto l'incidente; la durata dell'incidente; le informazioni riguardo l'impatto e la natura dell'incidente; le informazioni riguardo qualsiasi impatto all'estero poiché, ex art. 12, comma 9 e 12 d.lgs. n. 65/2018 “sulla base delle informazioni fornite nella notifica da parte dell'operatore di servizi essenziali, il CSIRT italiano informa gli eventuali altri Stati membri interessati in cui l'incidente ha un impatto rilevante sulla continuità dei servizi essenziali” e, “su richiesta dell'autorità competente NIS o del CSIRT italiano, il punto di contatto unico trasmette, previa verifica dei presupposti, le notifiche ai punti di contatto unici degli altri Stati membri interessati”. La notifica deve altresì contenere qualsiasi altra informazione che possa aiutare il CSIRT che sia sufficiente per consentire di determinare la rilevanza dell'incidente. Al fine di agevolare il processo di notifica, il CSIRT italiano ha predisposto un template di notifica e ha fornito istruzioni sulla stessa all'interno del sito internet dedicato.

Inoltre, è opportuno sottolineare come il CSIRT italiano «preserva, conformemente al diritto dell'Unione europea e alla legislazione nazionale, la sicurezza e gli interessi commerciali dell'operatore di servizi essenziali, nonché la riservatezza delle informazioni fornite nella notifica secondo quanto previsto dall'art. 1, comma 5», pertanto la notifica è da considerarsi riservata e verrà, quindi, inoltrata tramite canali protetti predisposti tramite il sito internet suddetto.

Viene richiesto di informare il CSIRT solo se le soglie sopra citate sono soddisfatte. Tuttavia, l'art. 20 della Direttiva NIS e l'art. 18 del d.lgs. n. 65/2018 invitano a fornire rapporti di notifica volontariamente su altri incidenti come si vedrà in seguito. Ciò potrebbe avere una notevole rilevanza poiché nulla vieta che «ove le circostanze lo consentano, il CSIRT italiano fornisce all'operatore di servizi essenziali, che effettua la notifica, le pertinenti informazioni relative al seguito della notifica stessa, nonché le informazioni che possono facilitare un trattamento efficace dell'incidente», guidando de facto l'operatore verso l'implementazione di misure di sicurezza potenzialmente già individuate dagli organi competenti.

È importante capire che, se l'incidente risulta in una violazione dei dati personali, i suddetti fattori e soglie non si applicano. Essenzialmente, l'incidente potrebbe non soddisfare nessuna delle soglie sopracitate, ma se i dati personali sono stati compromessi, è necessario valutare se ciò potrebbe comportare un rischio per i diritti e le libertà delle persone ex art. 33 GDPR.

In ultimo occorre sottolineare due aspetti dell'art. 12 d.lgs. n. 65/2018 contenuti nei commi 13 e 14. L'autorità competente NIS d'intesa con il CSIRT italiano potrebbe ritenere necessario informare dell'incidente la cittadinanza al fine di sensibilizzare per evitare altri incidenti o per agevolare la gestione di un incidente in corso. Tali obblighi di comunicazione, quindi, a differenza dell'art. 34 GDPR, non saranno posti in capo all'operatore di servizi essenziali ma saranno una facoltà dell'autorità competente NIS. Il comma 14 dell'art. 12 d.lgs. n. 65/2018 chiarisce inoltre come l'impatto economico dell'applicazione della disciplina relativa alla direttiva non potrà far derivare un onere a carico dello Stato ma dovrà essere cura dell'operatore di servizi essenziali adeguarsi alla normativa con il budget a propria disposizione.