La gestione degli incidenti di sicurezza informatica è la pratica attraverso cui si identificano un evento o una serie di eventi di sicurezza che sottintendono un riscontro evidente di danni. Tali danni possono verificarsi contestualmente all’identificazione degli eventi o essersi verificati precedentemente.
Qualsiasi siano la natura, l’origine, le cause e le conseguenze di un incidente, è facile incappare in una serie di problemi comportati dalla complessità e dalla difficoltà di gestione, soprattutto in ambienti di grandi dimensioni come quello delle Enterprise e in settori in cui è presente una considerevole varietà di tecnologie come quello delle telecomunicazioni. È dunque utile esaminare le problematiche più comuni della gestione degli incidenti di sicurezza informatica nelle grandi aziende del settore delle telecomunicazioni.
Indice degli argomenti
Gestione degli incidenti di sicurezza: il contesto
Il consistente numero di asset in uso per la fornitura di servizi di comunicazione elettronica è sicuramente un fattore rilevante che determina l’aumento della complessità di gestione degli incidenti.
Unitamente a ciò, anche la frammentazione e l’eterogeneità delle tecnologie in uso aumentano a loro volta la complessità e la difficoltà di gestione. È necessario, pertanto, che all’interno delle aziende, soprattutto nei team di risposta agli incidenti di sicurezza informatica (CSIRT o CERT), siano presenti competenze differenziate.
La mancanza di policy distribuite su più livelli di astrazione e di best practice emanate a livello globale possono comportare disallineamenti e mancanza di coordinazione nella gestione locale degli incidenti di sicurezza; e così la mancanza di processi globali di gestione che via via si modellano sulle realtà locali può causare spiacevoli situazioni in cui un mercato locale gestisce un incidente in modo differente rispetto ad un altro mercato, rischiando di mancare di efficienza ed efficacia.
È difficile immaginare che un singolo organo centrale di gestione degli incidenti possa essere in grado di risolvere in autonomia un problema di sicurezza che impatta diversi mercati locali, così come è difficile pensare che un singolo mercato locale possieda la visione d’insieme necessaria per gestire al meglio e per risolvere in breve tempo una situazione ove la sicurezza globale sia compromessa.
Gestione degli incidenti di sicurezza: la resilienza
La resilienza è un fattore chiave per i membri di un IRT (Incident Response Team). La gestione di un incidente di entità considerevole genera un notevole dispendio di energie per gli attori coinvolti nella sua risoluzione; ed anche la potenziale componente psicologica negativa, risultante dallo sforzo profuso e da una serie di difficoltà affrontate, non è assolutamente da sottovalutare. Gli incident responder devono dunque essere in grado di subire un duro colpo e allo stesso tempo devono avere la capacità di ritornare alle condizioni di efficienza ed efficacia possedute prima del verificarsi dell’evento.
Un aforisma di Benjamin Franklin recitava: “ricordati che il tempo è denaro”. Nulla di più veritiero anche nell’ambito della gestione degli incidenti di sicurezza informatica. La velocità di analisi e di reazione, la capacità di localizzazione del problema ed il contemplarne la possibilità di propagazione e l’eventuale velocità di propagazione sono tutti requisiti fondamentali per una corretta gestione degli incidenti.
In taluni casi una problematica di sicurezza può comportare una perdita a livello economico e in tali casi maggiore è il tempo di risoluzione dell’incidente maggiore è la perdita economica.
La fase di Post Incident Review
È di fondamentale importanza comprendere come e per quale motivo si sia verificato un incidente di sicurezza informatica. Il concetto che sta alla base di tale affermazione è molto semplice e banale: se si identificano i movimenti dell’attaccante e le motivazioni che lo hanno spinto ad agire è possibile prevederne le mosse future, comprenderne il modus operandi ed eventualmente prevedere futuri attacchi.
La fase di Post Incident Review (PIR) è la fase terminale della gestione di un incidente di sicurezza: in essa sostanzialmente si ripercorre una timeline di eventi, sia legati all’accaduto sia legati alle pratiche di contenimento, eradicazione e risoluzione, al fine di valutare se la gestione sia avvenuta nel migliore dei modi e per identificare spunti di miglioramento per il futuro.
La post incident review funge allo stesso modo da fase precursora per attività di miglioramento della sicurezza di infrastrutture esistenti.
Talvolta risulta difficile migliorare la sicurezza di infrastrutture esistenti in quanto, come l’accademia insegna, la sicurezza è “by design” e bilanciare correttamente il rischio di compromissione dei servizi rispetto al raggiungimento di un grado di sicurezza sufficiente non è sempre banale.
“Il panico è una reazione individuale e collettiva, che invade improvvisamente di fronte ad un pericolo reale o immaginario, togliendo la capacità di riflessione e spingendo alla fuga o ad atti inconsulti”. Il panico è il nemico acerrimo della gestione degli incidenti.
Si pensi ad una situazione in cui uno o più membri del team di risposta agli incidenti si facciano prendere dal panico: l’irrazionalità prenderebbe il sopravvento, si perderebbe il controllo e non si farebbe altro che rafforzare la potenza dell’attaccante. Nervi saldi, razionalità e posizioni ferme e decise sono caratteristiche ricorrenti tra gli incident manager.
Il problema della percezione si sviluppa su due fronti: la falsa percezione degli eventi e la sottovalutazione dell’importanza della sicurezza informatica.
La falsa percezione degli eventi è quel fenomeno per cui un evento viene percepito reale o possibile quando nella realtà non lo è. Un esempio classico può essere quello in cui a seguito di un periodo in cui si sono verificati una serie di eventi di sicurezza della stessa natura su di un determinato sistema, al verificarsi di un successivo evento impattante lo stesso sistema esso sia etichettato a priori come evento o problematica di sicurezza, senza aver effettuato un’analisi e senza dunque essersi basati su fatti e prove concreti.
La sottovalutazione dell’importanza della sicurezza informatica si verifica invece quando un membro di un IRT rifiuta o posticipa l’esecuzione di un’azione di rimedio ad una problematica di sicurezza giustificando la decisione con il fatto di avere altre priorità.
Si ricordi che, nella maggior parte dei casi, gli esecutori delle azioni di rimedio ad una problematica di sicurezza sono gli stessi che si occupano della normale amministrazione delle infrastrutture (Business As Usual). Le due precedenti casistiche rientrano nel caso dei falsi positivi, problema non indifferente della gestione degli incidenti di sicurezza informatica.
Security awareness nella gestione degli incidenti di sicurezza
Reperire le persone giuste al momento giusto non è sempre cosa scontata. Si pensi ad esempio ad un incidente che avviene durante le ore notturne, e che nel contempo richieda una escalation per ottenere l’autorizzazione all’isolamento di un sistema potenzialmente rischioso per la salute dell’infrastruttura.
Non sempre la reperibilità di alcune figure chiave per la risoluzione dell’incidente è di facile esecuzione, soprattutto se intercorrono nel processo di contatto ulteriori difficoltà legate alla distribuzione geografica dei team di risposta per via dei vari fusi orari.
La sensibilizzazione alla sicurezza, meglio conosciuta come security awareness, non sempre sortisce gli effetti sperati. Vi sono casi in cui utenti recidivi reiterano comportamenti errati che determinano la compromissione della sicurezza di un sistema informativo.
Esempio classico è quello del phishing dove lo stesso utente clicca recidivamente su un allegato contenente codice malevolo a più riprese nel tempo. È sufficiente, ad esempio, che un utente disattento riceva due e-mail di phishing da due mittenti diversi, in due momenti distanti nel tempo, con due distinti modus operandi e due distinti stili, per incappare nella trappola. Alla base di tutto ciò ci sono sostanzialmente due fattori: ignoranza informatica e disattenzione/superficialità.
Il processo di analisi proattiva per l’individuazione di eventi sospetti o di schemi comportamentali reiterati nel tempo da parte degli attaccanti può risultare molto complicato, soprattutto nei casi in cui l’attaccante è in grado di plasmare camaleonticamente il proprio comportamento per ingannare gli analisti di sicurezza ed agire malevolmente ed indisturbato.
Conclusioni
Abbiamo dunque presentato le più comuni problematiche della gestione di incidenti di sicurezza informatica nel mondo delle Enterprise del settore delle telecomunicazioni basandosi su un’esperienza pluriennale diretta di gestione.
I principi e le casistiche contenute nell’articolo restano comunque applicabili, seppur su scala minore, anche a realtà di dimensioni più contenute.
