Obbligo di reporting
Attraverso questa direttiva, le autorità dell’Unione Europea richiedono alle organizzazioni essenziali e importanti di divulgare i principali incidenti informatici.
Potresti chiederti perché la divulgazione di incidenti maggiori avvia il processo di gestione degli incidenti a livello europeo.
Una volta segnalato un incidente da parte di un’organizzazione, altre organizzazioni vulnerabili possono essere messe in guardia. Adeguate risorse possono essere assegnate per aiutare a indagare e risolvere l’incidente. Le autorità possono coordinare le risposte agli incidenti maggiori che attraversano i confini nazionali o i settori industriali.
Articolo 23
L’articolo 23 è un articolo lungo e impegnativo che richiede alle organizzazioni di infrastrutture critiche di segnalare incidenti significativi alle autorità e ai clienti o utenti dei loro servizi interessati.
Questo video esplora gli obblighi di segnalazione ai sensi di questa direttiva.
Spiegheremo inoltre cosa si intende per incidenti significativi. L’articolo 23 della direttiva definisce un incidente come un evento che compromette la disponibilità, autenticità, integrità o riservatezza dei dati archiviati, trasmessi o elaborati, o dei servizi offerti o accessibili tramite i sistemi di rete e informazione.
Incidenti significativi
La direttiva richiede solo la segnalazione di incidenti informatici significativi, ossia incidenti che hanno un impatto significativo sulla fornitura dei servizi. Significativo è ulteriormente definito come: “causando o essendo in grado di causare gravi interruzioni operative dei servizi, o perdite finanziarie per l’organizzazione interessata o arrecando danni considerevoli a persone o organizzazioni”.
Incidente da ransomware
Un esempio di incidente ransomware, di solito causa o porta alla completa interruzione dei servizi IT presso la struttura interessata, bloccando qualsiasi attività aziendale che dipenda dai sistemi, reti, comunicazioni e dati IT.
La pratica mostra che solo una piccola percentuale delle attività aziendali all’interno delle organizzazioni di infrastrutture critiche può continuare manualmente.
Estensione e durata
Il Considerando 101 nel preambolo della direttiva fornisce alcune indicazioni per determinare se un incidente è significativo, ad esempio utilizzando indicatori come l’estensione in cui il funzionamento del servizio è interessato, la durata di un incidente o il numero di destinatari dei servizi interessati.
Esempio di incidente non significativo
Un incidente informatico che interrompe il servizio di prenotazione online per un fisioterapista ospedaliero, ad esempio, può influire solo su una piccola parte dei servizi sanitari dell’ospedale e probabilmente non sarebbe considerato significativo, soprattutto se i fisioterapisti fossero in grado di accettare appuntamenti manuali o utilizzare un diverso servizio di prenotazione basato su cloud, causando solo lievi inconvenienti per alcuni pazienti.
I team di risposta: CSIRT
Le organizzazioni che devono conformarsi alle direttive, enti essenziali e importanti, devono segnalare incidenti significativi alle autorità competenti. I team di risposta agli incidenti di sicurezza informatica promossi dal governo (i computer security incident response team) generalmente ricevono e gestiscono le segnalazioni di incidenti in ciascun stato europeo.
I destinatari del servizio, i clienti, dovrebbero essere informati se un incidente potrebbe avere un impatto significativo su di loro, se è necessario. Questo può comportare far sapere loro se c’è qualcosa che possono fare per evitare, prevenire o mitigare l’effetto dell’incidente e condividere informazioni su agenti di minaccia significativi, se questi sono noti.
Articolo 23
Avvertire prontamente le autorità e le organizzazioni competenti riguardo agli incidenti significativi permette loro di alzare le loro difese.
L’articolo 23 richiede un primo avviso entro 24 ore, divulgando se si pensa che l’incidente informatico sia stato causato illegalmente o in modo dannoso, o se potrebbe avere un impatto transfrontaliero.
A questo stadio iniziale, le informazioni possono essere incomplete e inaffidabili, soprattutto nel caotico seguito di un disastro fisico o digitale. Il requisito di avviso precoce delle direttive, richiede alle organizzazioni di infrastrutture critiche di ottimizzare i loro processi per raccogliere e valutare le informazioni. Con l’evolversi rapido degli incidenti informatici maggiori, meccanismi di reportistica interna strutturati e resilienti possono aiutare in questo.
L’importanza di sistemi di comunicazione alternativi
Tuttavia, i soliti sistemi e meccanismi di comunicazione interna possono essere fuori uso o inaffidabili a questo punto, e forse anche i servizi di comunicazione pubblica, come linee fisse, telefoni cellulari, email o internet, una situazione difficile da considerare in anticipo.
Un incidente informatico significativo che interrompe le comunicazioni potrebbe ritardare la segnalazione, sottolineando il valore della flessibilità e di mezzi alternativi di comunicazione durante e nonostante gli incidenti.
Dopo l’avviso iniziale, è necessaria una notifica dell’incidente entro 72 ore dal momento in cui l’organizzazione prende coscienza dell’incidente.
La notifica dell’incidente
La notifica dell’incidente deve fornire ulteriori informazioni e una valutazione iniziale della gravità e dell’impatto dell’incidente, oltre a eventuali indicatori di compromissione identificati, come file particolari o impostazioni di configurazione indicativi di un’infezione da malware o attacco hacker.
Il CSIRT o le autorità possono richiedere un rapporto intermedio che fornisca un ulteriore aggiornamento dello stato se la notifica dell’incidente non fornisce informazioni sufficienti.
L’importanza delle notifiche
Produrre avvisi iniziali e notifiche di incidenti entro uno e tre giorni rispettivamente è probabilmente una sfida per molti incidenti informatici, soprattutto per quelli seri abbastanza da qualificarsi come significativi ai sensi delle direttive.
La ragione di scadenze così strette è permettere alle autorità di poter avviare il processo di gestione degli incidenti su scala più ampia e coordinare la risposta il prima possibile.
I rapporti intermedi e finale dell’incidente
I rapporti intermedi non hanno una tempistica definita, ma è probabile che le autorità premano per informazioni, clienti, lavoratori, altri stakeholder e i media potrebbero tutti richiedere dettagli, rendendo questo un periodo teso e stressante per i dirigenti oltre che per gli specialisti che lavorano per diagnosticare e risolvere l’incidente stesso.
Altri fattori come la natura, la gravità e la complessità dell’incidente, le dimensioni e le risorse dell’organizzazione e la fattibilità della segnalazione tempestiva possono essere rilevanti.
Un rapporto finale sull’incidente deve essere presentato entro un mese dalla notifica dell’incidente. Tuttavia, se l’incidente è in corso, è richiesto un rapporto di avanzamento al punto di un mese, seguito da un rapporto finale una volta risolto.
Il rapporto finale
L’articolo 23 afferma che il rapporto finale deve contenere una descrizione dettagliata dell’incidente, inclusa la sua gravità e impatto, nonché il suo impatto transfrontaliero, se applicabile. Il tipo di minaccia o causa probabile dell’incidente, come un incidente, un’infezione da malware, un hack, un difetto di progettazione software, un guasto hardware, un attacco di ingegneria sociale o sabotaggio. Misure di mitigazione utilizzate per contenere l’incidente e controlli in corso per prevenire una ricorrenza.
Quali intuizioni si sono avute e quali cambiamenti sono stati fatti come risultato di questo incidente.
Ulteriori info e comunicazioni
Ulteriori informazioni possono essere fornite volontariamente, come la cronologia dell’incidente dall’origine alla rilevazione e mitigazione, sforzi per risolvere, cooperando con le autorità che possono comportare ulteriori divulgazioni e accesso a informazioni sensibili durante un’indagine.
Potrebbe essere necessario per le autorità o l’organizzazione fare divulgazioni pubbliche riguardanti incidenti maggiori, nel qual caso è fortemente consigliato un parere legale e di relazioni pubbliche competente.
Per soddisfare i loro obblighi di conformità, gli enti essenziali e importanti richiedono procedure ottimizzate con rapida escalation alla gestione senior prima della reportistica esterna.
Divulgazioni significative
Divulgazioni significative di incidenti informatici sono sia un imperativo di conformità che un dovere pubblico nel senso che la trasparenza aiuta gli altri a gestire le conseguenze e apprendere le lezioni.
Concludiamo suggerendo un piano d’azione come parte della pianificazione della risposta agli incidenti.
Stabilire procedure interne per la segnalazione degli incidenti e garantire un’escalation tempestiva ai rilevanti stakeholder. Incarnare chiaramente i requisiti di segnalazione esterna e i criteri delle direttive nelle procedure e nei punti di decisione. Preparare modelli e metodi di comunicazione per facilitare la segnalazione tempestiva anche sotto stress.
Piano d’azione
Esercitarsi, praticare e perfezionare le disposizioni di segnalazione su incidenti minori e simulazioni di incidenti maggiori. Idealmente, come parte integrante della gestione degli incidenti, raccogliere metriche rilevanti, utilizzandole per promuovere eventuali cambiamenti necessari affinché il processo di segnalazione raggiunga i suoi obiettivi. Sviluppare costantemente disposizioni appropriate per ricevere, valutare e agire sulle informazioni riguardanti incidenti e quasi incidenti rivelati da altre organizzazioni, integrando l’intelligence su minacce e vulnerabilità per costruire una migliore comprensione dei rischi informatici.