Come analizzare un attacco informatico

Una delle domande più frequenti di chi si occupa di cybersecurity e di sicurezza a livello nazionale è capire come si presenta un vero attacco informatico e quali possono essere gli effetti causati. Questo interrogativo ha trovato risposta lo scorso luglio 2024, quando un’implementazione di software inadeguata ha causato la più grande interruzione informatica della storia e ha generato un impatto su organizzazioni e persone in tutto il mondo: dalle infrastrutture critiche, ai viaggi, all’assistenza sanitaria e altro ancora.

L’evento traumatico del luglio 2024

L’interruzione non è stata legata a un cosiddetto “cigno nero” (evento anomalo con un impatto estremo) anche se, un report del 2016 dell’Office of Cyber & Infrastructure Analysis del DHS (Department of Homeland Security) degli Stati Uniti aveva già anticipato alcune situazioni difficili che avrebbero potuto verificarsi a causa della nostra dipendenza digitale. Ma le conseguenze sono state peggiori di quanto previsto.

L’interruzione del software di CrowdStrike ha evidenziato il rischio di mancanza di resilienza e il pericolo rappresentato da un’eccessiva dipendenza da singole fonti di tecnologia e software, ed è diventato un buon esempio per gli autori di attacchi da parte degli stati nazionali per ridefinire tattiche, tecniche e procedure e causare conseguenze devastanti. Dal punto di vista della minaccia pura, la Teoria dei Bisogni con la “Piramide di Maslow” evidenzia che l’energia elettrica e l’acqua sono le risorse che influiscono direttamente sulla sicurezza della comunità, che oggi rimangono le aree più a rischio per gli attacchi più gravi.

Come funziona un problema informatico

Per mettere in difficoltà un Paese, il bersaglio dell’energia elettrica e dell’acqua produce l’effetto più significativo. Questo obiettivo rientra nella preparazione del terreno di battaglia da parte dei servizi d’intelligence o IPB (Intelligence Preparation of the Battlefield). Le vulnerabilità e gli obiettivi sono identificati e continuamente aggiornati in modo che, in caso di grosse ostilità o di un conflitto, un vero e proprio arsenale di armi informatiche possa essere utilizzato contro le infrastrutture critiche vulnerabili per ridurre e compromettere le nostre capacità di difenderci e affrontare una battaglia.

Un attacco diretto contro un intero Paese e le sue infrastrutture critiche si svilupperebbe come abbiamo visto in estate: guasti a cascata che innescherebbero malfunzionamenti di sistemi collegati tra loro. I problemi travolgerebbero la nostra capacità di rispondere immediatamente e la mancanza di risposta ai sistemi vitali innescherebbe ulteriori disfunzioni.

I servizi essenziali diventerebbero offline (per esempio, i servizi di pronto intervento per la salute). Inevitabilmente, la capacità di ripristino sarebbe direttamente influenzata dalla causa del guasto e impedirebbe il funzionamento da remoto del servizio. Quando i team di risposta devono agire fisicamente, la portata e l’ampiezza dell’impatto si amplificano: i team preposti a intervenire non sarebbero in grado di affrontare i problemi su larga scala. Invece, l’impatto più devastante sarebbe quello di una risposta di tipo 1:1: un problema e un solo operatore pronto a intervenire. L’incapacità di scalare la mitigazione e la risposta estenderebbe l’evento in modo esponenziale.

Tutto ciò pone una domanda: come si è verificata quest’ultima interruzione? Si sarebbe potuta evitare? Potrebbe succedere a qualsiasi vendor IT? E cosa possiamo imparare da questa situazione per andare avanti?

L’insegnamento dagli ultimi eventi

L’interruzione del servizio di CrowdStrike si è verificata perché la velocità era prioritaria rispetto alla stabilità e alla sicurezza e la garanzia di qualità era inadeguata. Il risultato è stato il rilascio globale di un singolo file che ha portato una vasta fetta del mondo digitale a una brusca battuta d’arresto. Se qualcuno volesse sapere quanto siamo dipendenti dalla tecnologia e dai rischi che ne derivano, l’interruzione ha portato queste preoccupazioni in primo piano.

C’è peraltro un malinteso che circola, degno dei racconti di fiction, secondo cui questo potrebbe accadere a qualsiasi vendor di software. È invece più normale che la progettazione del software, le funzionalità e gli aggiornamenti di prodotto siano completamente testati, organizzati e implementati gradualmente a livello globale per evitare che i difetti causino problemi più diffusi.

Gli effetti completi di questa interruzione devono ancora essere quantificati. Ma non c’è bisogno di una laurea in statistica per sapere che è piuttosto grave quando il servizio di pronto intervento va in tilt, l’operatività negli ospedali viene gravemente colpita e i viaggi aerei subiscono lo stesso tipo di arresto che abbiamo avuto l’11 settembre 2001.

Questa anomalia fornisce un’ottima occasione per rimettere in discussione la teoria secondo cui i singoli vendor che operano su larga scala sono la scelta prudente in tutte le circostanze e offre un caso di studio in tempo reale per una migliore preparazione e vigilanza per evitare tali guasti a cascata in futuro.

— a cura di Morgan Wright, Chief Security Advisor di SentinelOne