Il 26 luglio 2024 l’Agenzia per la Cybersicurezza Nazionale (ACN) ha pubblicato la “Guida alla notifica degli incidenti al CSIRT Italia”. Si tratta di un documento di 56 pagine che raccoglie alcune informazioni interessanti che andremo ad analizzare.
Il processo di notifica
Nei prossimi paragrafi saranno trattati alcuni aspetti legati alla notifica degli incidenti informatici. Nella fattispecie saranno affrontati gli aspetti legati alle tempistiche di notifica, alle tipologie d’incidente e anche al processo di notifica.
Prima di cominciare è bene segnalare che il documento pubblicato dall’ACN è reperibile cliccando qui e che include molti aspetti rilevanti riguardo il processo di notifica di un incidente informatico. Il documento è complessivamente ben scritto ma, come spesso accade nella normativa italiana, obbliga l’utente a saltare da un riferimento normativo all’altro: nel caso di specie, ad esempio, il DPCM n. 81/2021 che include la tassonomia degli incidenti all’interno dell’Allegato A, o la Determina ACN del 3 gennaio 2023.
Per praticità tale tassonomia verrà riportata di seguito ma è importante capire che cosa includono tali tassonomie:
- la tabella con gli identificativi “ICP-A” indica le tipologie degli incidenti aventi impatto sui beni ICT o sui beni contigui da notificare entro 6 ore (definita nell’allegato A del DPCM n. 81/2021);
- la tabella con gli identificativi “ICP-B” indica le tipologie degli incidenti aventi impatto sui beni ICT o sui beni contigui da notificare entro 1 ora (definita nell’allegato A del DPCM n. 81/2021);
- la tabella con gli identificativi “ICP-C” indica le tipologie degli incidenti con impatto su reti, sistemi informativi e servizi informatici diversi dai beni ICT (definita nell’allegato A della Determina ACN del 3 gennaio 2023)
Per maggiore chiarezza è possibile fare riferimento alla tabella seguente tratta dall’immagine prodotta da ACN a pagina 16 della Guida.
| TIPOLOGIA DI EVENTO | IDENTIFICAZIONE DELL’ASSET | CLASSE IDENTIFICATIVA INCIDENTE | TIPO DI NOTIFICA | TEMPISTICHE |
|---|---|---|---|---|
| Incidente che rientra nelle classificazioni della tassonomia | BENE ICT O CONTIGUO | ICP-B | OBBLIGATORIA | ENTRO 1 ORA dal rilevamento dell’incidente |
| Incidente che rientra nelle classificazioni della tassonomia | BENE ICT O CONTIGUO | ICP-A | OBBLIGATORIA | ENTRO 6 ORE dal rilevamento dell’incidente |
| Incidente che rientra nelle classificazioni della tassonomia | DIVERSO DA BENE ICT | ICP-C | OBBLIGATORIA | Segnalazione: ENTRO 24 ORE Notifica: ENTRO 72 ORE dal rilevamento dell’incidente |
| Incidente che rientra nelle classificazioni della tassonomia | DIVERSO DA BENE ICT E DA BENE CONTIGUO | ICP-A/B | VOLONTARIA | NESSUNA TEMPISTICA |
| Incidente che non rientra nelle classificazioni della tassonomia | BENE ICT | – | VOLONTARIA | NESSUNA TEMPISTICA |
Il processo di notifica è costituito da quattro fasi principali che sono la preparazione della notifica, la notifica al CSIRT italiano, la gestione della notifica, la chiusura dell’incidente. Di seguito sono fornite alcuni dettagli per ciascuna fase.
| Fase | Descrizione |
|---|---|
| Preparazione della notifica | In questa fase è necessario comunicare almeno: – il tipo di Bene ICT impattato. – il tipo di incidente in relazione alla tassonomia definita da ACN (ICP-A, ICP-B, ICP-C). Bisogna anche procedere alla: – Raccolta delle evidenze relative all’incidente. – Autovalutazione dell’impatto sui sistemi e sull’erogazione dei servizi di business. – Pianificazione di un piano di ripristino. Infine bisogna preparare la segnalazione dell’incidente, ove prevista |
| Notifica al CSIRT | La notifica al CSIRT richiede di fornire informazioni in merito alla Tipologia di impatto in base ai seguenti criteri: – impatto su bene ICT (notifica art.3, comma 1 DPCM n. 81/2021); – impatto su reti/sistemi contigui (notifica art.3, comma 3 DPCM n .81/2021); – impatto su altri beni (notifica art.1, comma 3-bis d.l. n.105/2019); – impatto per cui non sussiste un obbligo di segnalazione; – date e ora di rilevamento dell’incidente; ulteriori dettagli dell’incidente; – lista degli IOC (Indicator Of Compromise); evidenze rilevate (logs, sample, etc…). |
| Gestione della Notifica | A seguito della segnalazione, ove prevista, e/o della notifica sarà aperto un canale di comunicazione diretto tramite il quale il CSIRT Italia offrirà supporto alle attività di incident handling, ed eventualmente potrà richiedere ulteriori informazioni ad integrazione della notifica. |
| Chiusura dell’incidente | Una volta definite ed avviate le attività di ripristino dei beni ICT impattati, il soggetto PSNC ne dà tempestiva comunicazione al CSIRT Italia, che, a questo punto, avrà la facoltà di richiedere al soggetto stesso una relazione tecnica dell’incidente riguardante gli aspetti significativi. |
Tassonomia degli incidenti del DPCM n. 81/2021
La tassonomia degli incidenti include una mappatura delle principali tipologie di “incidente informatico” con identificativo, categoria di appartenenza e descrizione. La tassonomia consta di due tabelle: gli incidenti con identificativo ICP-A fanno parte della TABELLA 1, gli incidenti con identificativo ICP-B fanno parte della TABELLA 2.
TABELLA 1
| Identificativo (incidente con impatto-ICP) | Categoria | Descrizione |
|---|---|---|
| ICP-A-1 | Infezione (Initial exploitation) | Il soggetto ha evidenza dell’effettiva esecuzione non autorizzata di codice o malware veicolato attraverso vettori di infezione o sfruttando vulnerabilità di risorse esposte in rete. |
| ICP-A-2 | Violazione del livello di servizio atteso | Definito dal soggetto incluso nel perimetro ai sensi di quanto previsto nelle misure di sicurezza di cui all’allegato B, in termini di risorse di calcolo, memoria e/o banda passante. |
| ICP-A-3 | Definito dal soggetto incluso nel perimetro ai sensi di quanto previsto nelle misure di sicurezza di cui all’allegato B, di hot-replica e/o cold-replica e/o sito(i) di disaster recovery, se previsti. | |
| ICP-A-4 | Definito dal soggetto incluso nel perimetro ai sensi di quanto previsto nelle misure di sicurezza di cui all’allegato B, in termini di indisponibilità, di perdita irreversibile o di corruzione irreversibile dei dati provenienti dalle componenti di campo (attuatori e sensori). | |
| ICP-A-5 | Dati hot-replica e/o cold-replica e/o sito(i) di disaster recovery e/o backup, se previsti, persi o corrotti in modo irreversibile. | |
| ICP-A-6 | Perdita di confidenzialità o integrità. | |
| ICP-A-7 | Perdita e/o corruzione dati irreversibile. | |
| ICP-A-8 | Perdita e/o compromissione di chiavi di cifratura e/o certificati. | |
| ICP-A-9 | Perdita e/o compromissione di credenziali utenti. | |
| ICP-A-10 | Violazione del livello di servizio atteso, definito dal soggetto incluso nel perimetro ai sensi di quanto previsto dalle misure di sicurezza di cui all’allegato B, in termini di impossibilità di accesso fisico alle componenti. | |
| ICP-A-11 | Installazione (Establish persistence) | Ottenimento di privilegi di livello superiore (Privilege Escalation). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche, condotte dall’interno della rete, utili ad ottenere permessi di livello superiore. |
| ICP-A-12 | Persistenza (Persistence). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche, condotte dall’interno della rete, utili ad ottenere persistenza di codice malevolo o d’accesso. | |
| ICP-A-13 | Evasione delle difese (Defence Evasion). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche attraverso cui sono stati effettivamente elusi i sistemi di sicurezza. | |
| ICP-A-14 | Comando e Controllo (Command and Control). Il soggetto ha evidenza di comunicazioni non autorizzate verso l’esterno della rete. | |
| ICP-A-15 | Movimenti laterali (Lateral Movement) | Esplorazione (Discovery). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche, condotte dall’interno della rete, utili a effettuare attività di ricognizione. |
| ICP-A-16 | Raccolta di credenziali (Credential Access). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili ad acquisire, dall’interno della rete, credenziali valide per l’autenticazione alle risorse di rete o ne rinviene copie non autorizzate. | |
| ICP-A-17 | Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili ad accedere o eseguire codice tra risorse interne della rete. | |
| ICP-A-18 | Azioni sugli obiettivi (Action on objs) | Raccolta (Collection). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili ad raccogliere, dall’interno della rete, dati di interesse di terze parti o ne rinviene copie non autorizzate. |
| ICP-A-19 | Esfiltrazione (Exfiltration). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili ad esfiltrare dati dall’interno della rete verso risorse esterne. |
TABELLA 2
| Identificativo | Categoria | Descrizione |
|---|---|---|
| ICP-B-1 | Inibizione delle funzioni di risposta (Inhibit Response Function) | Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili a inibire l’intervento delle funzioni di sicurezza, di protezione e di “quality assurance” dei sistemi di controllo industriale predisposte per rispondere a un disservizio o a uno stato anomalo. |
| ICP-B-2 | Compromissione dei processi di controllo (Impair Process Control). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili a manipolare, disabilitare o danneggiare i processi di controllo fisico di sistemi di controllo industriale. | |
| ICP-B-3 | Disservizio intenzionale (Impact). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili a manipolare, degradare, interrompere o distruggere i sistemi, i servizi o i dati. In tale ambito rientrano ad esempio gli eventi di tipo Denial of Service/Distributed Denial of Service che hanno impatto sui beni ICT. | |
| ICP-B-4 | Disservizio (Failure) | Violazione del livello di servizio atteso, definito dal soggetto incluso nel perimetro ai sensi di quanto previsto nelle misure di sicurezza di cui all’allegato B, specie in termini di disponibilità, del bene ICT. |
| ICP-B-5 | Divulgazione di dati corrotti o esecuzione operazioni corrotte tramite il bene ICT. | |
| ICP-B-6 | Divulgazione non autorizzata di dati digitali relativi ai beni ICT. |
Tassonomia della Determina ACN 03/01/2023
| Identificativo | Categoria | Descrizione |
|---|---|---|
| ICP-C-1 | Accesso iniziale (Initial exploitation) | Accesso iniziale (Initial access). Il soggetto ha evidenza dell’effettivo accesso non autorizzato all’interno della rete attraverso vettori di infezione, lo sfruttamento di vulnerabilità di risorse esposte pubblicamente o qualsiasi altra tecnica nota. |
| ICP-C-2 | Esecuzione (Execution) | Esecuzione (Execution). Il soggetto ha evidenza dell’effettiva esecuzione non autorizzata di codice o malware all’interno della rete aziendale. |
| ICP-C-3 | Installazione (Establish persistence) | Ottenimento di privilegi di livello superiore (Privilege Escalation). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche, condotte dall’interno della rete, utili ad ottenere permessi di livello superiore su un sistema o una rete. |
| ICP-C-4 | Persistenza (Persistence) | Persistenza (Persistence). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche, condotte su un sistema o all’interno della rete, utili ad ottenere persistenza di codice malevolo o a garantire un accesso. |
| ICP-C-5 | Evasione delle difese (Defence Evasion) | Evasione delle difese (Defence Evasion). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche, di elusione di politiche e/o sistemi di sicurezza, volte ad evitare il rilevamento durante un tentativo di compromissione. |
| ICP-C-6 | Comando e Controllo (Command and Control) | Comando e Controllo (Command and Control). Il soggetto ha evidenza di comunicazioni non autorizzate verso l’esterno della rete. |
| ICP-C-7 | Movimenti laterali (Lateral Movement) | Esplorazione (Discovery). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche, condotte dall’interno della rete, utili a effettuare attività di ricognizione per acquisire conoscenze sul sistema e sulla rete interna. |
| ICP-C-8 | Raccolta di credenziali (Credential Access) | Raccolta di credenziali (Credential Access). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili ad acquisire, dall’interno della rete, credenziali valide per l’autenticazione alle risorse di rete o ne rinviene copie non autorizzate. |
| ICP-C-9 | Movimenti laterali (Lateral Movement) | Movimenti laterali (Lateral Movement). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili ad accedere, controllare o eseguire codice tra le risorse interne della rete. |
| ICP-C-10 | Azioni sugli obiettivi (Actions on objectives) | Raccolta (Collection). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili a ricercare e/o raccogliere, dall’interno della rete, dati riservati e/o sensibili ovvero ne rilevi la presenza al di fuori dei sistemi autorizzati alla trattazione degli stessi. |
| ICP-C-11 | Esfiltrazione (Exfiltration) | Esfiltrazione (Exfiltration). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili ad esfiltrare dati dall’interno della rete verso risorse esterne. |
| ICP-C-12 | Inibizione delle funzioni di risposta (Inhibit Response Function) | Inibizione delle funzioni di risposta (Inhibit Response Function). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili a inibire l’intervento delle funzioni di sicurezza, di protezione e di “quality assurance” dei sistemi di controllo industriale predisposte per rispondere a un disservizio o a uno stato anomalo. |
| ICP-C-13 | Compromissione dei processi di controllo (Impair Process Control) | Compromissione dei processi di controllo (Impair Process Control). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili a manipolare, disabilitare o danneggiare i processi di controllo fisico di sistemi di controllo industriale. |
| ICP-C-14 | Disservizio intenzionale (Impact) | Disservizio intenzionale (Impact). Il soggetto ha evidenza dell’impiego non autorizzato di tecniche utili a manipolare, degradare, interrompere o distruggere i sistemi, i servizi o i dati. In tale ambito rientrano ad esempio gli eventi di tipo Denial of Service/Distributed Denial of Service che hanno impatto sui beni ICT. |
| ICP-C-15 | Ricognizione (Reconnaissance) riferita ad attività di spearphishing | La ricognizione consiste in tecniche che gli avversari adottano per raccogliere, attivamente o passivamente, informazioni potenzialmente sfruttabili per successive attività. Nella specifica categoria sono da ricomprendere le campagne, ancorché prive di impatto su assetti aziendali, rilevate via posta elettronica (PEO e/o PEC) e costituite da messaggi, altamente personalizzati (spearphishing), indirizzati a utenti multipli della stessa organizzazione e finalizzati alla cattura di informazioni ad esempio tramite l’uso di allegati malevoli o collegamenti web. |
Obbligatorietà e non obbligatorietà
La notifica di un incidente può essere di due categorie: essenzialmente la notifica è obbligatoria, quando rientra nelle tassonomie degli incidenti sopra riportate e non è obbligatoria quando:
- il bene ICT afflitto dall’incidente non è riconducibile a una delle tipologie della tassonomia di cui all’allegato A del DPCM n. 81/2021.
- quando riguarda reti, sistemi informativi e servizi informatici di propria pertinenza diversi dai beni ICT e dai beni contigui e che sono riconducibili ad una delle tipologie della tassonomia di cui all’allegato A del DPCM n. 81/2021.
La notifica può essere effettuata online all’indirizzo: https://www.csirt.gov.it/segnalazione
Alcune conclusioni
Il documento è certamente utile ma soffre, a parere di chi scrive, di alcune problematiche che si stanno cronicizzando.
Non è un documento autonomo
Il primo aspetto è la dipendenza da altre norme, circolari, documenti, che obbliga l’utente a non poter utilizzare veramente il documento come utensile. Al contrario il lettore si deve preparare ad una lettura “saltellante” tra una norma e l’altra sperando che nel frattempo le informazioni si siano mantenute aggiornate su tutte le fonti. Per questa ragione la guida di ACN non può essere considerata un documento “autonomo” ma deve la validità ad altri due documenti quali:
- La Determina ACN 03/01/2023
- L’Allegato A del DPCM n. 81/2021
In merito alla completezza delle tassonomie, c’è da dire che entrambe le sorgenti (la Determina e l’Allegato A del DPCM) sono molto complete e includono vari aspetti di rilievo, inclusi i movimenti laterali tipici del dwell-time.
Tempistiche sempre più complicate
La notifica sta diventando un processo complesso, che coinvolge più autorità e più intervalli di tempo, soprattutto se il soggetto è assoggettato a più regolamenti/direttive.
| Regolamento | Tempi di Notifica | Soggetto di Notifica |
|---|---|---|
| GDPR (Regolamento Generale sulla Protezione dei Dati) | Notifica entro 72 ore dalla presa di conoscenza della violazione dei dati. | Autorità di controllo competente (ad esempio, Garante per la protezione dei dati personali in Italia). |
| NIS2 (Direttiva sulla Sicurezza delle Reti e dell’Informazione) | Notifica iniziale entro 24 ore, seguita da un rapporto dettagliato entro 72 ore. | Computer Security Incident Response Team (CSIRT) nazionale o l’autorità competente designata. |
| DORA (Regolamento sulla Resilienza Operativa Digitale) | Notifica immediata (generalmente entro poche ore, anche se il termine specifico non è esplicitamente definito). | Autorità competenti nazionali o europee (come l’Autorità Bancaria Europea o altre autorità di vigilanza finanziaria). |
Sarebbe stato utile avere un processo unico che, a seconda della tipologia di dati coinvolti (ad esempio) procedesse ad una segnalazione automatica al Garante per la Protezione dei Dati. Questo per favorire la segnalazione dell’incidente e rendere più efficiente il processo.
Il ripristino richiederebbe maggior rilevanza
Durante il processo di notifica, per l’esattezza nella fase di “preparazione alla notifica“, ACN riporta tra le attività da svolgere quella di “pianificazione di un piano di ripristino“. A seguito di un incidente informatico, mentre la struttura è impegnata a capire “cosa fare”, “come farlo”, “a chi comunicare”, in uno dei massimi momenti di concitazione e di crisi, l’ACN chiede di “pianificare un piano di ripristino“.
Sarebbe stato meglio trasformare quel “pianificare un piano di ripristino” in un “attuare un piano di ripristino” perché con il verbo attuare l’ACN avrebbe dato maggiore importanza alla fase di ripristino. Bisogna infatti considerare che gli attori assoggettati alla Circolare 2/2017 di AgID (le misure minime di sicurezza ICT per le P.A.) prevedono l’istituzione di strategie di ripristino.
| ABSC_ID | |
|---|---|
| 10.2.1 | Verificare periodicamente l’utilizzabilità delle copie mediante ripristino di prova |
La regola 10.2.1 parla di realizzare un’attività periodica che verifichi l’utilizzabilità delle copie attraverso un ripristino di prova. In sostanza, durante l’attività di risposta all’incidente non si dovrebbe pianificare un piano di ripristino ma attuare un piano di ripristino, studiato e mantenuto aggiornato precedentemente al momento di crisi.
Scrivere di “pianificare un piano” significa perdere tempo con un peggioramento dei danni potenziali causati dall’incidente. Significa, inoltre, legittimare i soggetti a non fare analisi del rischio, poiché la finalità di un’analisi del rischio non è solo la conoscenza delle minacce ma l’approntamento di una risposta adeguata. Viene meno il concetto di business continuity plan, di disaster recovery plan, e di tutte quelle attività di pianificazione che dovrebbero essere svolte ex-ante l’incidente.
Infine questo “pianificare un piano” entra in perfetto conflitto con il paradigma del GDPR e della NIS2 che tentano di anticipare l’incidente attraverso una individuazione delle minacce e una pianificazione delle risposte.
Considerazioni finali
La normazione di direttive e regolamenti genera una ridondanza di tempi e procedure che vanno a detrimento degli attori finali già pienamente impegnati nella gestione dell’incidente dal punto di vista tecnico, organizzativo e di comunicazione.
L’attività di notifica, che dovrebbe essere ragionevolmente snella e pratica considerata la situazione di crisi, rischia di diventare un processo complesso, tortuoso e di mediazione tra più soggetti, ciascuno con le sue sotto-procedure e i suoi tempi.
L’Italia si affanna per creare cabine di regia, tavoli unici, agenzie centrali, principi di “once only”, ma poi distribuisce informazioni su più normative, riguardanti più soggetti, con più tempistiche e differenti responsabilità.
Sorge il dubbio se chi progetta tutte queste strutture abbia reale contezza di cosa possa significare gestire un data breach.
