Incident Response
Nel caso in cui i nostri sforzi durante la gestione del rischio non fossero sufficienti, esiste una procedura spesso chiamata Incident Response, per reagire a tali eventi.
La fase di Incident Response dovrebbe essere orientata principalmente agli elementi che riteniamo essere i punti deboli di un’organizzazione, che, dopo aver effettuato l’analisi dei rischi, dovremmo ormai conoscere.
La reazione a tali incidenti dovrebbe essere basata, per quanto possibile, su piani di Incident Response documentati, che vengono regolarmente riesaminati, testati e praticati da coloro che saranno delegati ad adottarli in caso di reale necessità.
L’evento di emergenza (durante un attacco), non è il momento per tentare di seguire la documentazione citata. In questa fase è completamente inutile seguire la procedura, perchè (teoricamente) bisognerebbe già conoscere e saper applicare le divese fasi di incident response.
Inoltre, spesso, i piani documentati di incident response vengono trascurati, non aggiornati e abbandonati su qualche scaffale in attesa di essere applicati. Peccato che in caso di necessità questi documenti risultano obsoleti perchè (se non aggiornati) si riferiscono a processi o sistemi che sono cambiati pesantemente o non esistono più.
Il processo di incident response, ad alto livello, è costituito da:
- Preparazione
- Rilevazione e Analisi
- Contenimento
- Eliminazione
- Recupero
- Attività post attacco
Preparazione
La fase di preparazione della risposta di un incident response consiste in tutte le attività che possiamo svolgere, in anticipo, per consentire di gestire meglio la criticità.
Ciò implica tipicamente l’adozione delle politiche e delle procedure che regolano la risposta e la gestione degli incidenti, svolgendo attività di formazione e istruzione sia per chi dovrà gestire gli incidenti che per quelli che si prevede dovranno segnalare tali incidenti, sviluppo della documentazione e numerose altre attività
L’importanza di questa fase non va sottovalutata.
Senza una preparazione adeguata, è estremamente improbabile che la risposta ad un incidente andrà bene e/o nella direzione in cui ci aspettiamo che vada.
Il tempo determina ciò che deve essere fatto, chi dovrà farlo e come farlo.
Non è quando ci si trova di fronte ad un’emergenza che bisogna pensare a prepararsi per gestire una minaccia!
Rilevazione e Analisi
La fase di rilevazione e analisi è dove avviene l’azione nel nostro processo di incident response.
In questa fase si determina il verificarsi di un problema e si decide se è davvero il caso di procedere come se fosse un incidente cosi da poter rispondere in modo puntuale e appropriato.
La fase di rilevamento sarà spesso il risultato di un precedente monitoraggio o di un avviso sulla base dell’output di uno strumento o servizio di sicurezza.
Questo output può essere generato da un sistema di rilevamento delle intrusioni (IDS), software antivirus, registri firewall, avviso di uno strumento di sicurezza e di monitoraggio eventi (SIEM) se il programma è interno o gestore di servizi di sicurezza se il programma è esterno.
La parte di analisi di questa fase, invece, è spesso il risultato di una combinazione di strumenti automatici (di solito un SIEM) e giudizio umano.
Mentre spesso possiamo usare una specie di soglia per dire che il numero di eventi X in una determinata quantità di tempo è normale o che una certa combinazione di eventi non è normale (due login falliti seguito da un successo, seguito da una modifica della password, seguita da una creazione di un nuovo account, per esempio), spesso vogliamo che l’intervento umano ad un certo punto discuti sulla risposta degli incidenti.
Tale intervento umano comporterà spesso la revisione dei registri prodotti da vari dispositivi di sicurezza, di rete e infrastrutture, il contatto con la parte che ha segnalato l’incidente e una valutazione generale della situazione.
Quando il responsabile della gestione degli incidenti valuta la situazione, deciderà se il problema costituisce un incidente o meno, una valutazione iniziale sulla criticità dell’incidente (se presente) e deciderà di attivare/contattare tutte le risorse aggiuntive necessarie per procedere alla fase successiva.
Contenimento, Eliminazione e Recupero
La fase di contenimento, eliminazione e recupero è dove avviene la maggioranza dei lavori per risolvere effettivamente l’incidente, almeno a breve termine.
Il contenimento comporta l’adozione di provvedimenti per garantire che la situazione non provochi più danni di quanto abbia già provocato, o perlomeno risulta utile per limitare i danni in atto.
Se il problema riguarda un server malintenzionato attivamente controllato da un attacccante remoto, ciò potrebbe significare scollegare il server dalla rete, mettere le regole del firewall in atto per bloccare l’aggressore e aggiornare le firme o le regole su un sistema di prevenzione delle intrusioni (IPS) per fermare il traffico dal malware.
Durante l’eliminazione, cercheremo di rimuovere gli effetti del problema dal nostro ambiente.
Nel caso del nostro server infettato dal malware, supponiamo di aver già isolato il sistema e di averlo tagliato fuori dalla rete di comando e controllo.
Ora dovremo rimuovere il malware dal server e assicurarci che non esista altrove nel nostro ambiente.
Ciò potrebbe comportare la scansione aggiuntiva di altri host nell’ambiente per garantire che il malware non sia presente, l’esame dei registri sul server e le attività dei dispositivi attaccanti sulla rete al fine di determinare con quale altro sistema il server infetto era in comunicazione.
Con i malware, e in particolare con le versioni recenti, questo potrebbe essere un compito arduo e sarà difficile capire se e quando avremo completato l’eliminazione.
Ogniqualvolta esiste un dubbio sul fatto che il malware o l’attaccante siano stati effettivamente “sfrattati” dal nostro ambiente, dobbiamo essere cauti, bilanciando l’impatto sulle operazioni.
Ogni evento richiede una valutazione dei rischi.
Infine, dobbiamo recuperare uno stato del sistema migliore rispetto a quello attuale (attraverso un recovery).
Ciò potrebbe comportare il ripristino di dispositivi o dati da supporti di backup, sistemi di ricostruzione, applicazioni di ricarica o qualsiasi altra attività simile.
Inoltre dobbiamo mitigare il vettore di attacco che è stato utilizzato.
Ancora una volta, questo può essere un compito più doloroso di quanto inizialmente sembra essere, basato su una conoscenza potenzialmente incompleta o poco chiara della situazione intorno all’incidente e che cosa è accaduto esattamente.
Possiamo scoprire che non siamo in grado di verificare che il supporto di backup sia effettivamente pulito e privo di infezioni, i media di backup potrebbero essere interamente cattivi, potrebbero non essere disponibili i bit di installazione di applicazioni, i file di configurazione potrebbero non essere disponibili…
Attività post attacco
L’attività post incidente, come la fase di preparazione, è una fase che possiamo facilmente trascurare, ma dovremmo comunque assicurarci di non farlo.
Nella fase dell’attività post attacco, spesso definita come un postmortem, cerchiamo di determinare in dettaglio ciò che è accaduto, perché è accaduto e cosa possiamo fare per impedirlo di nuovo.
Questa non è solo una revisione tecnica poiché potrebbero essere necessari cambiamenti di politiche o infrastrutture.
Lo scopo di questa fase non è quello di puntare il dito o di dare la colpa a qualcuno, ma di provare a diminuire in ultima analisi l’impatto di tali incidenti futuri.
