Articolo Pubblicazioni
Incident response: le fasi della gestione di un incidente informatico e il ruolo della digital forensics
di Vincenzo Calabrò · Pubblicato il 7 maggio 2014 - Aggiornato il 14 novembre 2026 · Tratto da «Risposta agli Incidenti Informatici»
Abstract
L’articolo riprende il seminario «Risposta agli Incidenti Informatici» del 7 maggio 2014, tenuto nell’ambito di un corso di digital forensics. Confronta l’approccio improvvisato con quello organizzato, elenca le valutazioni da fare prima di un incidente, descrive la composizione e i ruoli di un CSIRT e le fasi del piano di risposta, dalla prima valutazione al contenimento, dalla raccolta delle prove alla comunicazione esterna, fino alla valutazione dei costi e alla revisione del piano.
SCARICA LE SLIDE: «Risposta agli Incidenti Informatici» Calabrò V., 2014, PDF di 37 pagine
Prima dell’incidente
Il seminario metteva a confronto due approcci. Quello improvvisato comincia quando l’incidente è già in corso, cerca una soluzione rapida e, quando fallisce, convive a lungo con l’incidente. Quello organizzato comincia prima, in un momento di calma. Rende gli incidenti parte delle attività, del budget e delle politiche di sicurezza, definisce i processi, individua con calma i partner esterni e valuta il trasferimento di parte del rischio alle assicurazioni. Costa meno e sostituisce il panico con procedure.
La preparazione parte da alcune domande:
- come si fanno i backup, con quale frequenza, dove si conservano e se i ripristini vengono provati;
- quali asset vanno protetti, a quali rischi fisici e logici sono esposti e quali vulnerabilità vanno tenute sotto controllo;
- se il traffico di rete è monitorato, quali comunicazioni sono normali e quali servizi sono esposti all’esterno;
- chi può inviare posta e con quali misure di sicurezza.
I livelli da valutare comprendono dati, applicazioni, dispositivi, rete, perimetro e locali, documentazione cartacea, persone e competenze, processi e politiche. Le prime attività sono semplici. Definire le politiche, organizzare il personale, programmare la formazione, valutare periodicamente le vulnerabilità con le autorizzazioni necessarie, compresi i test di ingegneria sociale, aggiornare i sistemi, fissare regole rigide sulle password, conoscere il comportamento normale di sistemi e rete, analizzare i log e verificare i backup.
Il CSIRT
Il Computer Security Incident Response Team è il gruppo che interviene in risposta all’incidente. Va costituito in tempi tranquilli, con ruoli chiari, in modo che nessuno possa dire «non è compito mio». Oltre a rispondere agli incidenti monitora vulnerabilità e rischi, riceve e documenta le segnalazioni, promuove la consapevolezza in azienda e fa da riferimento in caso di audit o di intervento dell’autorità giudiziaria. I suoi membri devono conoscere gli strumenti, disporne in fretta, custodire in forma cifrata password, configurazioni e procedure, e avere i contatti di legali, polizia giudiziaria, fornitori di accesso e stampa.
La composizione indicata nel seminario prevedeva:
- un team leader, che organizza il lavoro;
- un incident leader per ogni incidente, scelto in base al caso;
- gli incaricati della gestione;
- alcuni membri associati, cioè un referente IT, un referente legale per gli aspetti civili e penali, un referente di informatica forense che raccoglie le prove, un referente per le relazioni esterne e il management, che valuta l’impatto sull’azienda.
Per ogni fase una matrice indica chi è responsabile, chi esegue, chi collabora e chi va informato. La raccolta delle evidenze, per esempio, è responsabilità del referente forense, i rapporti con l’autorità giudiziaria del referente legale, la comunicazione esterna del management con il referente per le relazioni esterne.
Che cos’è un incidente
Un incidente è ogni violazione delle regole di sicurezza, come l’accesso non autorizzato a un sistema o ai dati, l’uso di un account non assegnato o altrui, lo sfruttamento di una vulnerabilità e anche l’uso improprio del proprio account. Gli esempi vanno dall’uso non autorizzato di servizi e apparecchiature aziendali ai server personali in rete, dal furto di un notebook alla copia di dati su supporti rimovibili. Chi lo subisce deve capire in fretta se l’evento è davvero un incidente, decidere le operazioni da svolgere e programmare l’investigazione per reperire le fonti di prova.
Le fasi del piano di risposta
- Valutazione iniziale. Escludere un semplice problema di configurazione, stimare tipo e gravità, registrare tutto e informare il CSIRT.
- Contenimento. Proteggere prima i dati classificati e sensibili, poi gli altri dati, poi hardware e software, riducendo al minimo l’interruzione dei servizi. Si chiude il punto di ingresso, si ricostruisce da zero il sistema violato e si cambiano le password.
- Natura e gravità dell’attacco. Stabilire origine, obiettivi, sistemi compromessi e file consultati, cercando nuovi membri nei gruppi amministrativi, programmi avviati in automatico, lacune nei log, permessi cambiati e dati estranei all’azienda.
- Raccolta delle prove. Acquisire sempre, meglio in doppia copia e su supporti diversi, documentando ogni operazione. Le copie servono a recuperare i dati, ad analizzare l’accaduto e a raccogliere prove.
- Comunicazione esterna. Valutare con il legale il contatto con le forze di polizia, le agenzie di sicurezza e gli specialisti di malware, e il tipo di dichiarazione pubblica in base all’azienda, ai clienti e agli effetti dell’incidente.
- Documentazione. Ricostruire che attacco è stato, chi ha risposto, quando e perché, esaminando il materiale con il legale e verificando l’ipotesi di un insider.
- Valutazione dei costi. Contare i costi diretti e indiretti, dalla perdita di competitività all’inattività, dalle spese legali e di indagine al ripristino, alla sostituzione di hardware e software e ai danni di reputazione.
- Revisione. Chiedersi che cosa ha funzionato e che cosa no, e aggiornare politiche e piano.
Il ruolo della digital forensics
La risposta all’incidente e l’informatica forense si incontrano nelle fasi di rilevamento, identificazione, conservazione e analisi. Si riconosce il potenziale incidente, si identificano le possibili prove avviando subito la catena di custodia, si conservano le prove garantendone integrità e attendibilità nel tempo e infine si analizzano. Un incidente gestito senza queste cautele può essere risolto sul piano tecnico e lasciare l’organizzazione senza prove da portare in giudizio.
Vedi anche: l’intervento del 2019 Incident Response: cosa fare prima, durante e dopo e l’articolo del 2024 Incident Management: raccomandazioni per un’implementazione ottimale.
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn