5.Procedura

Il processo di gestione degli incidenti viene attivato nel momento in cui un evento inerente alla sicurezza delle informazioni viene qualificato come incidente. Tale processo è finalizzato a garantire l’individuazione tempestiva degli incidenti, la loro corretta classificazione, la riduzione dei tempi di analisi e risoluzione, la rapida attivazione delle eventuali misure di continuità operativa, nonché una comunicazione efficace e conforme verso i soggetti interni ed esterni coinvolti nel processo di gestione degli incidenti che si articola nelle seguenti macro-fasi: prevenzione e misure proattive, identificazione, valutazione e classificazione, gestione, chiusura, post-incident, lessons learned e monitoraggio. 

5.1 Prevenzione e misure proattive 

In questa fase sono definite le azioni preventive e le misure proattive volte a ridurre il rischio di incidenti. 

L’Ateneo adotta un approccio proattivo alla sicurezza informatica, orientato alla prevenzione degli incidenti e alla riduzione dell’esposizione al rischio, in conformità a quanto previsto dal D.Lgs. 138/2024. 

A tal fine, vengono implementate misure tecniche e organizzative che includono, in particolare: 

• la valutazione periodica del rischio informatico in relazione ai processi critici dell’Ateneo; 

• il monitoraggio continuo della rete e dei sistemi informativi, finalizzato all’individuazione tempestiva di vulnerabilità, anomalie o comportamenti sospetti; 

• la definizione e l’applicazione di policy e procedure per la gestione degli accessi; 

• la formazione e la sensibilizzazione di tutto il personale sui temi della sicurezza informatica e sui comportamenti corretti da adottare nell’utilizzo delle risorse digitali; 

• la gestione delle vulnerabilità mediante l’applicazione tempestiva di aggiornamenti e patch di sicurezza, al fine di proteggere i dati e le risorse critiche. 

Rientrano inoltre in questo ambito le attività di manutenzione dei server e dei sistemi operativi. Tali misure fanno parte di un sistema di gestione della sicurezza delle informazioni, soggetto a verifiche e aggiornamenti periodici, anche sulla base delle analisi post-incidente e dell’evoluzione delle minacce. 

5.2 Identificazione 

L’attività di identificazione e segnalazione di un evento di sicurezza informatica si articola in due momenti distinti e complementari: 

• rilevazione, intesa come individuazione di un evento anomalo o potenzialmente critico; 

• segnalazione, intesa come comunicazione formale dell’evento all’interno dell’Organizzazione, al fine di avviare il processo di gestione dell’incidente. 

Fase di rilevazione 

La rilevazione consiste nel riconoscimento di un possibile evento di sicurezza informatica e può avvenire attraverso: 

• l’individuazione di anomalie riscontrate durante il normale svolgimento delle attività, quando emergono comportamenti inattesi o non conformi alla consueta operatività dei sistemi; 

• l’identificazione di eventi di sicurezza tramite le attività di monitoraggio continuo svolte dall’Area dei Servizi ICT, trasmissione di bollettini di sicurezza da parte enti (s. ACN, GARR-CERT, Polizia Postale) o fornitori IT (rif. PRO007-Procedura per la Threat Intelligence). 

Fase di segnalazione 

Una volta rilevato un evento sospetto o un incidente, si procede alla fase di segnalazione, che consiste nella trasmissione formale delle informazioni necessarie all’avvio del processo di gestione degli incidenti. 

Il soggetto che ha individuato l’evento ha l’obbligo di segnalarlo tempestivamente, inviando una comunicazione all’indirizzo e-mail sicurezzainformatica@units.it. 

5.3 Valutazione e classificazione 

In questa fase vengono svolte le attività di analisi e categorizzazione degli incidenti (rif. MOD07 - Segnalazione evento, incidente, data breach) in base alla loro gravità e all’impatto potenziale o effettivo, al fine di determinare le azioni di risposta più appropriate. 

L’attività di valutazione e classificazione degli incidenti, che segue immediatamente la fase di identificazione, ha lo scopo di stabilire se un evento rientri tra quelli qualificabili come significativi ai sensi del Decreto Legislativo 138/2024, di recepimento della Direttiva (UE) 2022/2555 (NIS 2).  Ai sensi dell’articolo 2, comma 1, lettera t) del D.Lgs. 138/2024, per incidente si intende “un evento che compromette la disponibilità, l’autenticità, l’integrità o la riservatezza dei dati conservati, trasmessi o elaborati, nonché dei servizi forniti dai sistemi informativi e di rete o accessibili tramite essi”. 

Considerata la molteplicità delle modalità con cui un incidente può manifestarsi, è innanzitutto necessario distinguere tra le seguenti categorie: 

Eventi o anomalie sui sistemi: rientrano in questa categoria gli eventi che causano un’interruzione o un degrado temporaneo dei servizi dell’Ateneo senza essere riconducibili a minacce informatiche. Si tratta di eventi di natura tecnica, operativa o accidentale che, pur non derivando da azioni intenzionali, possono incidere sulla disponibilità dei sistemi e sulla continuità dei servizi. Esempi tipici includono guasti hardware su server, apparati di rete o sistemi di archiviazione, interruzioni dell’alimentazione elettrica, malfunzionamenti degli impianti di condizionamento delle sale server, errori di configurazione dovuti a interventi umani o perdita e corruzione di dati causate da difetti tecnici. Sebbene non abbiano origine cibernetica, tali eventi devono essere gestiti secondo le procedure operative interne, in quanto potenzialmente impattanti sui servizi istituzionali; Incidenti cyber: gli incidenti cyber comprendono tutti gli eventi che comportano, o tentano di comportare, una violazione della riservatezza, dell’integrità o della disponibilità di dati e sistemi informativi dell’Ateneo. Essi possono derivare, direttamente o indirettamente, da azioni malevole o accidentali, quali malware, accessi non autorizzati, campagne di phishing o attacchi mirati; Quasi-incidenti: i quasi-incidenti sono eventi che avrebbero potuto configurare un incidente vero e proprio, ma che sono stati evitati o neutralizzati efficacemente. Ne sono esempi un’e-mail di phishing bloccata dai sistemi antispam, il rilevamento e la bonifica tempestiva di un malware su una postazione isolata o tentativi di accesso non autorizzato respinti dai meccanismi di autenticazione. Data Breach: è un incidente che coinvolge dati personali. È una violazione di sicurezza che comporta - accidentalmente o in modo illecito - la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trasmessi, conservati o comunque trattati. Una violazione dei dati personali può compromettere la riservatezza, l’integrità o la disponibilità di dati personali. Per tale tipologia di incidente si rimanda al documento dedicato: Procedura per la gestione dei Data Breach. 

Tutti gli eventi sopradescritti devono essere segnalati all’indirizzo sicurezzainformatica@units.it. Anche qualora un evento appaia di scarsa rilevanza, deve essere sempre segnalato; pur non avendo generalmente una priorità elevata, tali segnalazioni devono essere monitorate e gestite secondo le procedure interne, in quanto possono costituire indicatori di minacce più ampie o di vulnerabilità sistemiche. 

Le segnalazioni verificate dal SOC sono comunicate al RSGSI per le eventuali valutazioni e azioni sul Sistema di Gestione della Sicurezza delle Informazioni (SGSI) all’indirizzo ict.sgsi@units.it. Ai sensi del D.Lgs. 138/2024, e come richiamato nel capitolo “Definizioni”, un incidente è considerato significativo quando ha causato o è in grado di causare una grave perturbazione operativa dei servizi, perdite finanziarie per il soggetto interessato, oppure ripercussioni rilevanti su altre persone fisiche o giuridiche, determinando perdite materiali o immateriali di significativa entità. 

A integrazione del quadro normativo, l’Agenzia per la Cybersicurezza Nazionale ha emanato la Determinazione n. 379907/2025, che fornisce ulteriori chiarimenti e indicazioni operative per individuare gli eventi qualificabili come incidenti significativi. In particolare, un incidente è considerato significativo quando l’Ateneo acquisisce evidenza oggettiva di eventi che comportano la perdita di riservatezza o di integrità dei dati, oppure la violazione dei livelli di servizio attesi. 

Nello specifico, si configura un incidente significativo quando: 

• l’Ateneo ha evidenza della perdita verso l’esterno della riservatezza di dati digitali di sua proprietà o sui quali esercita, anche parzialmente, il controllo. 

 Esempio: diffusione non autorizzata di elenchi contenenti dati personali di studenti o personale tramite e-mail o repository pubblicamente accessibili. 

• l’Ateneo ha evidenza della perdita di integrità di dati di sua proprietà o sotto il suo controllo, con impatti verso l’esterno. 

 Esempio: alterazione di documenti ufficiali pubblicati sul portale istituzionale o manipolazione dei risultati d’esame nel sistema informativo didattico. 

• l’Ateneo ha evidenza della violazione dei livelli di servizio attesi dei propri servizi o delle proprie attività, sulla base dei livelli di servizio (SL) definiti. 

 Esempio: indisponibilità prolungata del portale studenti o della piattaforma e-learning a seguito di un attacco DDoS o della compromissione di un sistema. 

Gli incidenti classificati come significativi devono essere gestiti con la massima tempestività, ricevere priorità elevata ed essere oggetto di un’analisi approfondita volta a valutare l’impatto effettivo o potenziale sulla sicurezza dei dati, sulla disponibilità dei servizi critici e sul rispetto degli obblighi normativi. 

Tali incidenti devono essere comunicati dal SOC al RSGSI e al Direttore dell’Area dei Servizi ICT, nonché notificati al CSIRT Italia entro i termini previsti dal D.Lgs. 138/2024, secondo quanto indicato successivamente. 

5.4 Gestione 

Questa fase riguarda la definizione e l’attuazione delle misure necessarie per il contenimento dell’incidente e il ripristino dei sistemi e dei servizi coinvolti. In tale ambito rientrano anche le comunicazioni e le notifiche, interne ed esterne, previste dalla normativa vigente. L’attività di gestione dell’incidente è articolata in tre fasi operative e prevede il coinvolgimento del Security Operations Center (SOC) e degli amministratori di sistema, sotto il coordinamento del SOC Manager. 

Fase di contenimento 

La fase di contenimento ha l’obiettivo di limitare l’impatto dell’incidente, isolando il problema e impedendone la propagazione ad altri sistemi dell’infrastruttura informatica dell’Ateneo. Il SOC Manager, con il supporto del SOC e degli Amministratori di Sistema (AdS), definisce la strategia di risposta più adeguata, stabilendo le contromisure necessarie, le responsabilità per la loro attuazione e le modalità di verifica. 

Nella scelta delle misure si valutano i potenziali danni, l’impatto sui servizi, le risorse e i tempi richiesti, l’effetto atteso e l’eventuale necessità di raccogliere e preservare le evidenze dell’incidente. Le azioni devono garantire, per quanto possibile, la continuità dei servizi. Il SOC Manager coordina le priorità e le risorse coinvolte, inclusi eventuali fornitori esterni. 

Fase di ripristino 

Completata la fase di contenimento, si procede al ripristino dei sistemi e delle applicazioni coinvolte, con l’obiettivo di riportarli ai livelli di servizio e sicurezza precedenti all’incidente. Gli Amministratori di Sistema (AdS) definiscono e attuano le attività necessarie, che possono comprendere: il recupero dei dati compromessi; il ripristino completo del servizio; l’implementazione di procedure temporanee alternative per garantire la continuità operativa; il ripristino parziale o con prestazioni limitate, in attesa del ripristino definitivo. 

Ove opportuno, possono essere effettuati ripristini parziali o temporanei anche durante la gestione dell’incidente, al fine di ridurre l’interruzione delle attività istituzionali. 

Durante questa fase, l’AdS o una figura da esso incaricata analizza il servizio oggetto di attacco e, se possibile, ne crea una copia virtuale per consentire le analisi della fase successiva. 

Fase di raccolta e analisi 

Il SOC Manager, con il supporto del SOC e degli amministratori di sistema coinvolti, raccoglie i dati pertinenti all’incidente per comprenderne cause, modalità di accadimento e azioni di rimedio adottate. L’analisi delle evidenze consente di delimitare i sistemi coinvolti, ricostruire le diverse fasi dell’incidente — a partire dall’evento originario — e valutare l’efficacia delle misure di contenimento e di ripristino adottate, nonché individuare eventuali azioni correttive per evitare il ripetersi dell’evento. Tutte le evidenze devono essere documentate e trasmesse al RSGSI all’indirizzo ict.sgsi@units.it. 

Su richiesta del CSIRT Italia, l’Ateneo è tenuto a condividere una relazione intermedia sull’incidente, al fine di mantenere aggiornato il CSIRT in merito allo stato di avanzamento delle attività di gestione e mitigazione. 

Tale adempimento è previsto dall’articolo 25, comma 5, lettera c) del D.Lgs. 138/2024, e ha l’obiettivo di garantire un flusso informativo continuo tra l’Ateneo e le autorità competenti, assicurando il coordinamento e la coerenza delle azioni intraprese in materia di sicurezza informatica (si rimanda ai capitoli successivi sugli obblighi e sulle tempistiche di segnalazione). 

5.5 Chiusura 

In questa fase si procede alla chiusura formale dell’incidente: una volta completate le operazioni di contenimento e, se necessario, di ripristino, l’incidente di sicurezza può essere considerato chiuso. Il SOC Manager redige il rapporto finale e registra la chiusura dell’incidente (rif. MOD019-Incident Report) e invia le evidenze al RSGSI che le conserva in apposito repository documentale e aggiorna il registro degli incidenti (rif. MOD023- Registro eventi, incidenti, data breach). La chiusura dell’incidente viene comunicata a tutti i soggetti interessati. 

5.6 Post-incident, lessons learned e monitoraggio 

Dopo la chiusura dell’incidente, si avvia una fase di analisi conclusiva per trasformare l’esperienza in un’opportunità di miglioramento. L’obiettivo è prevenire eventi analoghi e ridurre i tempi di reazione in futuro. 

Il RSGSI convoca una riunione con le parti interessate per: esaminare l’incidente, le cause, le modalità di ripristino e gli eventuali errori. Se necessario si procede a: aggiornare la procedura di disaster recovery; valutare rischi su servizi analoghi e proporre misure preventive; predisporre un documento condiviso con raccomandazioni operative e tecniche. Le informazioni raccolte si traducono quindi in interventi concreti: aggiornamento delle policy, rafforzamento delle misure di sicurezza e formazione del personale e degli utenti. 

La Direzione, in collaborazione con il RSGSI e il SOC Manager, verifica se sia necessario adottare azioni correttive.  A supporto di tale fase, il SOC manager e il RSGSI possono compilare il questionario Lessons Learned (rif. MOD020- Questionario Lessons Learned), che raccoglie evidenze e suggerisce aree di miglioramento.