Il bug presente nel software di Endpoint Security della CrowdStrike, che il 19 luglio 2024 ha causato il blocco dei computer con sistema operativo Windows, ha, ancora una volta, evidenziato tre criticità strettamente correlate tra loro: la nostra forte interdipendenza dai sistemi dell’ICT, la rilevanza dell’analisi dei rischi e il problema della business continuity.
Nei giorni successivi al crash globale, gli esperti del settore hanno provato ad analizzare il problema e sono arrivati alla conclusione che si sia trattato del maggiore down della storia dell’information technology dopo il millennium bug.
In realtà, durante il lockdown del Covid-19 abbiamo subito un’interruzione dei servizi di portata maggiore. In quel caso le motivazioni erano di natura diversa, ma, se considerassimo i sistemi informativi come un insieme comprendente persone, funzioni, applicazioni, reti tecnologiche e procedure che interagiscono tra di loro per il raggiungimento dell’obiettivo, allora potremmo assimilare i due eventi.
Analizziamo cosa sia accaduto nell’ottica di capire come sia possibile ridurre questa minaccia.
Indice degli argomenti
Cosa è successo nel caso CrowdStrike
Se andassimo a rileggere la storia degli incidenti informatici, troveremmo diversi casi di entità simile a quella accaduta quel venerdì 19.
In genere si parla di attacchi informatici causati da attivisti o criminali, mentre in questo caso siamo di fronte ad un bug software e, la cosa paradossale, ha riguardato uno dei migliori sistemi di sicurezza pensato proprio per aiutare le grandi società impegnate in settori strategici a proteggersi dagli attacchi informatici.
Nello specifico, nella notte tra giovedì e venerdì, la società CrowdStrike ha inviato un aggiornamento del suo software di Endpoint Security denominato Falcon. Nell’aggiornamento era presente un errore che mal interagiva con il sistema operativo Windows.
Per cui, tutti i computer che hanno installato l’aggiornamento sono stati inutilizzabili per ore, a volte giorni, perché al riavvio andavano in crash e occorreva effettuare manualmente una procedura di ripristino, non alla portata dell’utente comune, che consentisse di ripristinare il corretto funzionamento del sistema operativo.
Da una prima analisi del problema emerge una criticità nella gestione degli aggiornamenti. Molto probabilmente l’errore sarebbe stato scoperto, se fosse stata effettuata una valutazione o un testing più approfondito e, di conseguenza, non si sarebbe diffuso in maniera così impattante. Questa non è l’unica soluzione al problema delle forniture di terze parti e, certamente, in futuro assisteremo ad altre tipologie di incidenti che richiederanno approcci diversi.
Se, invece, esaminassimo questo incidente non solo dal punto di vista operativo, ma anche da quello strategico, riusciremmo a trovare una sintesi che ci aiuterebbe a ridurre notevolmente la portata dell’impatto in caso di incidenti con conseguenze bloccanti.
Cosa andava fatto prima dell’incidente
Proviamo, quindi, ad apprendere la lezione effettuando la post-analisi dell’incidente.
Policy degli aggiornamenti (operativo)
Nel caso specifico, evidentemente, non è stata effettuata una valutazione corretta del rischio che si potesse verificare un bug nel sistema di sicurezza degli endpoint o nel sistema operativo (solitamente questa minaccia è valutata a bassissimo rischio) oppure non è stata eseguita la giusta mitigazione del rischio derivante dalla supply chain.
Una soluzione per mitigare questa tipologia di minacce consiste nel distribuire gli aggiornamenti prima su macchine non critiche e, dopo aver superato la fase di valutazione, estendere il deployment a tutte le postazioni.
Business continuity plan (strategico)
Le principali organizzazioni che hanno subito l’interruzione dei servizi a causa del bug della CrowdStrike appartengono alle cosiddette infrastrutture critiche (trasporti, banche, sanità ecc.), ovvero quei sistemi, risorse, processi, insiemi di servizi digitali, la cui distruzione, interruzione o anche parziale o momentanea indisponibilità ha l’effetto di indebolire in maniera significativa l’efficienza e il funzionamento normale di un Paese, ma anche la sicurezza e il sistema economico-finanziario e sociale, con conseguenti perdite in ordine di danni economici, reputazionali, disponibilità eccetera.
Per tali motivazioni, le organizzazioni che implementino e gestiscano infrastrutture critiche sarebbero obbligate a dotarsi di un piano di business continuity in grado di garantire la resilienza dei servizi offerti, determinando la capacità di mantenere o riprendere il servizio a seguito di incidenti o interruzioni, anche in situazioni di crash generalizzato, adottando procedure alternative in caso di emergenza.
Cosa andava fatto durante l’incidente
Recovery (operativo)
Il tempo necessario per recuperare la funzionalità rappresenta una variabile rilevante per valutare l’efficacia di un piano di incident response perché da ciò può dipendere l’entità dell’impatto.
Nel caso specifico l’identificazione del bug è stata relativamente rapida, ma non si può dire altrettanto per quanto riguarda il tempo di recupero. In realtà bastava effettuare il ripristino del sistema al momento precedente l’aggiornamento, ma questa operazione, abbastanza semplice per un tecnico IT, è poco conosciuta dall’utente medio e, soprattutto, inibita nei contesti aziendali per motivi di sicurezza.
Occorre prevedere procedure di self-recovery o semplificate per gli endpoint, ovvero senza l’ausilio di un tecnico IT, per ridurre il machine downtime.
Campagna di comunicazione (strategico)
Come è noto, la funzione di comunicazione durante un incidente ha una rilevanza strategica. In primis, per salvaguardare l’azienda, ma è importante anche per tutelare gli stakeholders.
Una comunicazione dell’incidente, dalla fase di identification a quella di recovery, non gestita rischia di aumentare esponenzialmente i danni.
Nel caso analizzato è stata avviata una massiccia campagna di disinformazione, finalizzata alla truffa o al furto dei dati, che prometteva di risolvere il problema del crash con tools o comandi che nulla avevano a che fare con il ripristino della funzionalità dei sistemi.
Occorre sempre attuare un piano di comunicazione degli incidenti e stabilire un canale di comunicazione verificato con i propri stakeholder per evitare interferenze malevoli.
Cosa andava fatto dopo l’incidente
Post-Incident Analysis (operativo)
L’analisi post-incidente consente di condurre una ricerca approfondita delle cause che hanno causato l’anomalia di funzionamento del sistema informatico e di acquisire la lezione appresa e le opportunità di miglioramento.
Nel caso specifico sono evidenti le conseguenze di una sottovalutazione del problema della supply chain. Non basta effettuare una valutazione del fornitore e dei prodotti/servizi in fase di acquisizione, ma è necessario attuare un monitoraggio continuo dei prodotti/servizi importati nella propria organizzazione per rivelare eventuali anomalie.
È sempre opportuno effettuare una valutazione post-incidente per rivedere cosa è andato bene, cosa potrebbe essere migliorato e le azioni da intraprendere per fronteggiare i futuri incidenti.
Risk assesment (strategico)
Il risk assesment è un processo ciclico che deve essere attuato con cadenza temporale prestabilita o in caso di incidente rilevante.
Come già evidenziato, l’incidente è riconducibile a più fattori di rischio: il rischio derivante dalla supply chain, il rischio derivante dal deployment degli aggiornamenti, il rischio derivante dal crash del sistema, il rischio dell’interruzione dell’operatività.
Sono rischi presenti in tutti i contesti, ma che assumono rilevanza nei sistemi critici. Pertanto, occorre valutare misure di mitigazione specifiche, in grado di coniugare la riduzione del rischio e la business continuity.
Non è concepibile che un sistema informativo critico abbia bottleneck con un impatto così rilevante. È necessario eliminare queste criticità o valutare misure alternative che consentano di bypassare questa minaccia.
Conclusioni
Tutte le organizzazioni, sia quelle che hanno avuto un impatto diretto, che quelle abbastanza fortunate da non averlo subito, devono riconoscere che sarebbe potuto accadere con la stessa facilità; pertanto, è meglio essere preparati, che essere fortunati.
Innanzitutto, si è potuto constatare, ancora una volta, l’interdipendenza critica delle infrastrutture digitali moderne. Le istituzioni hanno perfettamente capito l’entità del fenomeno e, in tal senso, hanno approvato una serie di provvedimenti utili a ridurre le conseguenze negative (p.e. la NIS 2, Direttiva (EU) 2022/2555 relativa a misure per un livello comune elevato di cibersicurezza; la CER, Direttiva (UE) 2022/2557 sulla resilienza dei soggetti critici; DORA, il Regolamento (UE) 2022/2554 relativo alla resilienza operativa digitale per il settore finanziario ecc.).
Non tutti i soggetti destinatari di tali provvedimenti, le cosiddette infrastrutture critiche, adottando lo stesso livello di consapevolezza. Spesso scaricano le responsabilità di eventuali criticità nell’ambito digitale verso i propri fornitori e non considerano i diritti dei propri stakeholders (enti pubblici, società private o semplici utenti finali).
Il caso analizzato ha riguardato un incidente dipeso da fornitore di terze parti, quindi, dal punto di vista del Risk Assesment potremmo trattarlo come un qualsiasi Supply Chain o Vendor Risk, ma, dal punto di vista della Business Continuity, è necessario affrontarlo in maniera più generalizzata, poiché le cause che possono determinare un’interruzione di servizio sono molteplici e vanno affrontate con lo stesso approccio.
Occorre migliorare la resilienza. Ciò comporta investimenti nella manutenzione, nella sicurezza, nel monitoraggio e nella pianificazione di percorsi alternativi in caso di emergenza.
La business continuity riguarda la pianificazione e la preparazione per garantire che le operazioni possano riprendere il più velocemente possibile dopo un’interruzione, attraverso piani di emergenza interni, protocolli di comunicazione, manutenzione delle infrastrutture e strategie per gestire interruzioni temporanee del servizio.
In sintesi, il legame tra infrastrutture critiche, resilienza e business continuity si deve concentrare su come possono essere progettati, gestiti e protetti i sistemi informativi per garantire la continuità operativa e la capacità di ripristinare rapidamente il servizio in caso di eventi imprevisti.
In tal senso, le esercitazioni possono avere un ruolo determinante, perché consentono di testare le procedure, allenare le organizzazioni e, soprattutto, evidenziare e risolvere potenziali situazioni non gestite.
