Le cattive abitudini della gestione degli incidenti informatici

Gli incidenti informatici capitano, e capiteranno. E’ irrilevante quanto tempo ci vorrà, prima o poi succede, per statistica o momento sociale/politico/economico.

Gli incidenti informatici capitano, e capiteranno. E’ irrilevante quanto tempo ci vorrà, prima o poi succede, per statistica o momento sociale/politico/economico. Per incidente informatico, poi, si possono prendere insieme svariate tipologie di eventi: il guasto elettrico o meccanico di un sistema, un’infezione da virus, un furto di informazioni (accidentale o intenzionale che sia), dal defacciamento del sito istituzionale alla creazione di siti di “phishing” o dei cosiddetti “exploit kit”, fino ad arrivare a casi più gravi di intercettazione del traffico sensibile, delle comunicazioni e-mail o delle transazioni bancarie. In sostanza: se è elettronico, è al 99% un incidente informatico.

Nel momento in cui si verifica un incidente informatico è necessario che si effettui un’analisi razionale del problema. Sfortunatamente capita che il problema venga preso sotto gamba, e l’isteria collettiva che viene generata da un simile evento crei più problemi di quanti siano realmente i benefici presunti.

L’analisi “isterica” di un incidente informatico, per quanto banale possa sembrare, porta le persone – comprensibilmente – ad affrontare il problema senza la dovuta attenzione a tutti i dettagli che lo circondano.

Ecco quindi, nella mia esperienza, una breve raccolta dei peggiori errori da non fare durante l’analisi di un incidente informatico.

Definizione dell’impatto

Generalmente quando arriva una segnalazione di un problema, il problema ha le seguenti caratteristiche: è urgentissimo, è gravissimo, è di proporzioni globali, deve essere risolto istantaneamente. Tutte le caratteristiche sono quasi sempre false, ad eccezione dell’urgenza.

É urgentissimo. L’urgenza dell’Azienda che percepisce il problema è sicuramente enorme, tuttavia considerarla una priorità assoluta è un errore madornale. Se la regola di vita e la legge di Murphy vogliono che “se qualcosa può andare storto, sicuramente lo farà”, allora è lecito dover pensare che possa verificarsi un problema che ha una priorità ancora più alta. Quindi lavorare in “emergenza” richiederebbe l’elevazione di una “super emergenza” per far frone alla prima. Gli incidenti informatici vanno affrontati, come ho già premesso prima, in modo razionale, che deve essere “ordinario”. Questo stato non indica che non sia “prioritario il ripristino dei servizi”, ma che si ha un metodo concreto e funzionante per l’approccio al problema e una sua tempestiva risoluzione. Se poi fosse necessaria una aggiunta di “drammatizzazione” della situazione, i nebulizzatori di acqua daranno la giusta apparenza di ansia e concitazione alle persone viste dall’esterno.

É gravissimo. Ogni problema che compromette la produttività di un’azienda è grave, e la sua gravità (razionale) è direttamente proporzionale all’impatto economico che genera il disservizio. La realtà dei fatti è che quello che viene percepito e trasmesso, in realtà, è lo stato d’animo delle persone, e questo è anche comprensibile. Nella pianificazione della risoluzione del problema l’ansia genera unicamente stress e confusione mentale, conducendo chi opera e dimenticare i processi di analisi e arrancare in modo pseudo casuale fino a tamponare il problema, pur di rimettere l’utente (o l’azienda) in condizioni di operare nuovamente. Un po’ come se durante una gara di motociclismo una perdita di un giunto venisse riparata con del nastro isolante, in barba alla sicurezza del pilota, per la sola necessità di tornare in pista al più presto. L’esperienza e il metodo, al contrario, consentono un’analisi più strutturata del problema ed una soluzione più solida, anche se fosse solo temporanea. In tal caso, sempre riprendendo la metafora motociclistica, la ripresa della gara sarebbe meno pericolosa e potrebbe portare all’arrivo a fine gara dell’intera squadra.

É di proporzioni globali. Questa è in assoluto una delle peggiori caratteristiche che vengono trasmesse. Quando viene segnalato un problema viene tipicamente descritto come un olocausto nucleare. Da interi sistemi bloccati, a perdita totale e assoluta dei dati, danni irreparabili agli edifici, pacemaker che smettono di funzionare, morte cerebrale. Una volta definita la proporzione si arriva, in proporzione e rispettivamente, a un programma che non risponde (intero sistema bloccato), un file finito in una cartella diversa per un errore nel trascinamento col mouse (perdita totale ed assoluta dei dati), una finestra chiusa male (danni irreparabili agli uffici), assenza di pacemaker (a quelli che smettono di funzionare) o emicrania (morte cerebrale). Volutamente esagerato, la realtà dei fatti è che spessissimo capita che i problemi siano esposti in maniera errata nell’unico intento di farne comprendere la gravità e urgenza, innescando invece un caos globalizzato nel tentativo di risolvere un problema che – veramente – non si è capito quale sia.

Risoluzione istantanea. I problemi vanno sempre risolti nel più breve tempo possibile. Laddove una soluzione (definitiva) non sia attuabile, va adottato il cosiddetto “work around”, che consiste nel rimettere l’utente (o sistema) in condizioni operative fino a quando non si applica una soluzione. Questa cattiva abitudine si traduce in due problemi: il primo è quello di adottare una soluzione che non risolva il problema realmente (ma ritornerò su questo argomento tra breve), il secondo è quello in cui un “workaround” diventa la soluzione, rendendo il sistema più pericolante di quanto lo fosse prima del problema stesso. Ci sono anche dei momenti in cui il problema non può essere risolto, e non si può – anzi per questioni etiche non si deve – ripristinare il sistema prima di aver risolto il problema. Quest’ultimo aspetto può rappresentare un preludio a problemi molto più gravi in futuro.

Banalizzare il problema

Un altro aspetto – purtroppo spesso presente dal lato tecnico e non dell’Azienda che ne è affetta – pericoloso è quello di banalizzare i problemi. I problemi non sono mai banali, possono essere semplici nella loro soluzione, ma mai banali. Un disco guasto è un problema semplice: va sostituito con uno funzionante e rimesso in servizio. Ma non è banale, perchè un disco guasto buttato nel cestino e contenente dati sensibili dell’Azienda contiene ancora i dati (e possono essere recuperati). Allo stesso modo un’infezione da virus – specie nell’ultimo periodo – potrebbe essere molto più complessa di quello che appare inizialmente.

Risolvere il problema. E basta.

Risolvere il problema è bene. Non capire come si sia verificato e adottare delle contromisure adeguate affinchè il suo impatto – dovesse ricapitare – abbia effetti meno dannosi è a sua volta un problema. Se un evento si è verificato una volta, può verificarsi nuovamente. Allora tanto vale determinare la corretta prassi per risolvere il problema, e quindi ridurre al minimo l’eventuale disagio dell’azienda. Se si è anche determinato come possa essersi verificato, ancora meglio perchè consente l’adozione di contromisure appropriate perchè i sistemi siano ancora in maggiore sicurezza.

Non documentare il problema.

Esistono delle norme UE che richiedono che gli incidenti informatici siano opportunamente documentati e, in alcuni casi, dichiarati pubblicamente. Questo non accade quasi mai. Sorvolando le normative UE, ritengo sia una questione di buon senso. La documentazione rappresenta la memoria storica di avvenimenti passati, e questi – ciclicamente – si ripresentano. Risolvere un problema e dimenticarsene può essere uno degli errori che, nel tempo e per chi li amministra, si ritorce contro chi lo ha risolto con una forza ancora maggiore. E’ fondamentale mantenere una traccia degli incidenti, perchè questo consente il perfezionamento dei propri processi di analisi e soluzione dei problemi.

Risolvere un problema in modo isterico porta ad una sua solo apparente soluzione, sempre. Adottare un metodo rigido e strutturato – o da manuale di informatica del 2000 – è altresì un errore, poichè i ritmi, complessità e problematiche che vediamo nei sistemi di oggi sono drammaticamente cambiate rispetto a due anni fa, figuriamoci rispetto all’inizio del millennio. Il buon senso nell’approccio al problema e soprattutto la corretta definizione del problema da parte della parte interessate (per prima cosa) e tecnica (in seconda analisi) è l’unico modo realmente efficiente per affrontare un incidente informatico.

C’è poi da aggiungere un’altra cosa. Gli incidenti, purtroppo, devono capitare. È una necessità, non una calamità, perché solo quando un incidente si verifica è possibile migliorare un sistema. Sarebbe come dire che esistono situazioni in cui qualcuno dovrebbe “immolarsi” per il bene di tutti? Qualcosa del genere. Affrontare i problemi è una necessità per tutti, perché è il solo momento in cui si può adottare dei cambiamenti migliorativi. Gli incidenti sono anche quei momenti che consentono una maggiore acquisizione di esperienza sul campo, dal momento che è in quel momento che viene sviluppata una soluzione che, successivamente, può essere estesa anche agli altri sistemi che si gestisce. Rimane poi da dire che “sbagliare è umano, perseverare è diabolico”: è un concetto da non dimenticare.

Disclaimer

Lavoro professionalmente nel settore IT dalla metà degli anni '90. Ho avuto occasione di sviluppare competenze orizzonatli che mi hanno consentito di approcciare pressochè qualsiasi progetto IT. Dal 2005 il mio ruolo è stato principalmente quello di CTO in diverse realtà, da piccoli ISP a System Integrator. La mia area di interesse comprende principalmente la Sicurezza di Architetture di Sistemi, Reti e Informazioni.

Dal 2017 ho iniziato a lavorare su una nuova piattaforma per la protezione della Proprietà Intellettuale e Copyright, per la gestione e tutela di asset digitali, fondando una società che prende il nome di Rights Chain. La Missione della Società è quella di creare una piattaforma efficace per la gestione e protezione della proprietà intellettuale e delle informazioni digitali, nonchè di affrontare tematiche di carattere etico quali Reputazione e Privacy.

In ambito Cyber Security mi occupo di analisi e implementazione di soluzioni per la protezione di reti e sistemi, nonchè della definizione di procedure e documentazione in ambito data protection.