INFN CSIRT
PROCEDURA GESTIONE INCIDENTI
La presente procedura descrive il modo in cui INFN CSIRT e le strutture dell’INFN collaborano per la gestione degli incidenti di sicurezza.
Se si sospetta che un nodo (client o server) di cui si ha la responsabilità sia stato violato oppure oggetto di attacco contattare il proprio responsabile locale per la sicurezza informatica (generalmente il resp. del Servizio Calcolo). Se il responsabile locale conferma l'incidente o desidera supporto per l'investigazione allora procede secondo lo schema riportato di seguito.
In caso l'incidente sia un evidente o sospetto Data Breach, è obbligatorio seguire anche la procedura di gestione dei data breach stabilita dai nostri DPO, che trovate nel sito web dpo.infn.it alla voce "Documenti del DPO". Si sottolinea inoltre che l'eventuale comunicazione al Garante va fatta entro 72 ore.
| Evento o Azione | Tempistica | Note |
|---|---|---|
Alla scoperta di un incidente di sicurezza, creare la segnalazione per INFN CSIRT inviando una email all’indirizzo
 overo tramite form web alla URL https://www.csirt.infn.it/si.html. Verrà aperto un ticket automaticamente che dovrà essere referenziato ad ogni successiva comunicazione con INFN CSIRT semplicemetne rispondendo alla mail relativa al ticket in questione che avrà Oggetto (Subject) nel formato [INFN CSIRT #number]
| Entro 4 ore dalla scoperta dell'incidente | La segnalazione dovrà contenere come minimo gli indirizzi IP dei nodi coinvolti, divisi tra vittime e attaccanti ed i riferimenti esatti di data e ora. Ulteriori dettagli sono graditi ma non necessari. Lo scopo di questa mail è di fornire un'iniziale segnalazione dell’incidente. |
| In collaborazione con il proprio gruppo di sicurezza e con lo CSIRT, isolare i sistemi coinvolti senza eliminare le informazioni necessarie per l’analisi forense | 1 giorno (24 ore) dalla scopera dell’incidente | Se possibile, effettuare uno snapshot della macchina. Se possibile, isolare la macchina a livello di rete dalle altre. NON fare reboot o spegnere la macchina. Se la macchina compromessa è una VM, non distruggere la VM. Se necessario, staccare fisicamente la macchina dalla rete. In collaborazione con lo CSIRT significa che lo CSIRT rimane disponibile a collaborare su richiesta |
| In collaborazione con il proprio gruppo di sicurezza e con lo CSIRT, decidere se sono necessarie ulteriori analisi ed approfondimenti dell’incidente | 1 giorno (24 ore) dalla scoperta dell’incidente | A questo scopo, seguire la checklist CHECK1 alla fine della pagina per controllare quali informazioni dovrebbero essere raccolte. Se un'informazione è impossibile da recuperare o non si applica non è un problema, ma la cosa deve essere gisutificata. Se una qualunque delle altre informazioni è mancante, allora un'ulteriore analisi è necessaria. Una guida di base all’analisi forense si può trovare su questo sito |
| Se necessario, annunciare un downtime per i servizi coinvolti | 1 giorno dall’isolamento iniziale | |
| Effettuare un’analisi dell’incidente di sicurezza | Iniziare al massimo subito dopo l’isolamento della macchina, continuare fino a quando non si è in grado di fornire un report completo secondo CHECK1. In ogni caso, finire entro due settimane dalla segnalazione iniziale | Perché l’analisi sia completa, come minimo s dovrebbero avere tutte le informazioni presenti in CHECK1, escluse quelle possibilmente non rilevanti |
| Alla chiusura dell’incidente, inviare un report definitivo citando le soluzioni adottate, rispondendo al ticket aperto da INFN CSIRT | Appena possibile, al massimo entro due settimane |
Checklist CHECK1
- Chi ha segnalato l’incidente
- Host compromessi o sospetti
- Evidenze di compromissione (log, file sospetti, connessioni) (Questi devono essere messi in attach (zippati) al report)
- Indirizzo/i IP dell’attaccante
- Nome/Tipo dell’hypervisor nel caso le macchine compromesse siano virtuali
- Tipo di attacco (DoS, Esecuzione di codice, crittazione di dati, etc...)
- Modalità di compromissione iniziale (credenziali compromesse, vulnerabilità di sito web, etc...)
- Debolezze sfruttate (pwd deboli, vulnerbailità note, etc...)
- Estensione dell’attacco (Cosa ha fatto l’attaccante)
- Elenco di eventuali account compromessi
- Elenco di dati compromessi