Il Caso CrowdStrike: Un confronto sui motivi.
Il 19 luglio 2024, CrowdStrike ha rilasciato un aggiornamento per il loro sensore Falcon, che ha causato un crash massivo su numerosi computer Windows, portando a disservizi globali in settori cruciali come aviazione, media, banche e sanità. L’incidente è stato causato da un errore logico in un file di configurazione aggiornato, che ha provocato un ciclo infinito di riavvii sui dispositivi interessati (CrowdStrike) (Morningstar) (Wikipedia).
In merito all’articolo
Questo è un articolo nato da una discussione ed interazione sociale sul social network professionale LinkedIn ( https://linkedin.com ) Quanto qui riportato riassume ed estende i contenuti, le opinioni ed i punti di vista discussi tra le varie persone citate all’epoca dei fatti, nei giorni successivi alla vicenda del down mondiale del prodotto commerciale, CrowdStrike Falcon (19 luglio 2024 ).
Responsabilità e Deontologia Professionale
Roberto Beneduci, CEO di CoreTech, ha espresso preoccupazione per la colpa erroneamente attribuita a Microsoft invece del reale responsabile, CrowdStrike. Beneduci ha paragonato la situazione a un escavatore che taglia cavi internet, mentre i media incolpano il provider di servizi internet per l’interruzione. Ha sottolineato l’importanza di attribuire correttamente le responsabilità e di assicurarsi che i prodotti software non causino danni.
Prospettive Tecniche e di Prodotto
Ivan Dorna, CEO di Anthilla, ha ampliato la discussione spiegando che il problema non risiede primariamente nel sistema operativo, pur riconoscendo lo stato attuale ed i suoi limiti, ma nella consapevolezza e delle scelte che vengono fatte nell’allestire un’infrastruttura che deve erogare un servizio e nell’erogazione di un servizio terzo che serve a tale infrastruttura e questo deriva dalla competenza dall’etica e dalla professionalità di chi le compie le scelte ma anche dai limiti (spesso imposti e non sempre compresi) legate alle attività da compiere.
Ha evidenziato l’importanza della competenza tecnica per risolvere rapidamente i problemi, notando il ritardo, non tanto nella diffusione del workaround, che di fatto è quello standard per i problemi dei driver su Windows, ma sul fatto che sembra strano che tale procedura non sia stata applicata prima, che dovrebbe essere nota ed alla base della conoscenza tecnica per i sistemi microsoft.
Ha anche notato che incidenti simili potrebbero verificarsi anche su Linux in circostanze analoghe.
Non c’è mai la risposta giusta o corretta per definizione, per quello va analizzato il rischio effettivo di tutti i componenti nello scenario per lo scenario specifico.
Ivan Dorna: “La colpa non è del sistema operativo, ma di chi ha compiuto una serie di scelte in modo che si verificasse quella situazione ed in primis di chi ha premuto il grilletto. Come dire che chi ha sparato è CrowdStrike e la marca del fucile è Microsoft.”
Roberto Capancioni ha osservato che la robustezza di un sistema si misura dalla sua capacità di resistere ai malfunzionamenti esterni. Se un sistema non è abbastanza robusto, l’errore può essere attribuito anche ad esso.
Punto di vista assolutamente condivisibile quello di Capancioni, ma ci sono tantissimi sistemi operativi ognuno con propri limiti e funzionalità specifiche, sicuramente nel prossimo futuro, visto l’impatto che ha avuto l’aggiornamento di CrowdStrike, ci saranno, si spera dei cambiamenti nella gestione dei servizi all’interno dei vari sistemi operativi, ma le eccezioni e gli errori in memoria di un programma non possono essere sempre verificate e gestite dal sistema operativo, a meno che non si usino determinate modalità e tecnologie come Rust, che sta prendendo sempre più piede. Il primo livello di difesa rimane il controllo della qualità su i rilasci e la riduzione delle dipendenze da software. Essendo un aggiornamento rilasciato su un canali stabile di produzione, quell’aggiornamento, con quell’errore, non doveva essere distribuito.
Impatto della Struttura Gerarchica e delle Responsabilità e l’errata valutazione di Rischio
Debora Casaliniha sollevato domande ed un interessate punto di vista riguardante la gestione del rischio e le assicurazioni, evidenziando che CrowdStrike in modo specifico (vista la notorietà) e come tipologia software è stato “selezionato” e diffuso, come elemento abilitante (ovvero componente essenziale per validare una piattaforma dal punto di vista della sicurezza ed avere una copertura assicurativa) legando ancora di più l’onere dell’erogazione di servizio, ad uno o più prodotti commerciali e quindi non ad una effettiva analisi di rischio indipendente da questo, che valutasse tecnologie e politiche di mantenimento del prodotto.
Ivan Dorna, si è confrontato su questo punto ovvero l’identificazione di CrowdStrike come “Elemento Abilitante” sia come tipologia di software, che come Marca nota e famosa, per attivare coperture assicurative a livello globale, senza considerare adeguatamente i rischi reali.
Questo ha portato a una situazione in cui le aziende hanno imposto un prodotto per i suoi vantaggi percepiti, senza valutare l’impatto in caso di malfunzionamento e questo va in opposizione rispetto all’effettiva valutazione di fattori di rischio. Non permettendo di approfondire la reale situazione.
“Il discorso di obbligatorietà per avere una copertura assicurativa è assurdo. La scelta del sistema per avere il fattore abilitante ha comportato una serie di rischi in più.”
Questo è sia vero dal punto di vista di “fattore abilitante” per le assicurazione sia per alcuni vincoli ed obblighi di leggere derivanti da best practices, come avverrà anche per NIS2 e DORA.
la notorietà di un prodotto, come in passato anche per altri marchi e prodotti, ad oggi non è più possibile che sia sufficiente a riconoscerli come “elementi abilitanti”. come per VMware non solo in merito ai cambi di direzione del 2023 e 2024, ma anche a fronte dei cambi di politica e strategie effettuate dal 2010 ad oggi.
Considerazioni Economiche e di Sicurezza
Andrea Campiotti ha menzionato che ci sono stati anche problemi con Azure AD e ha suggerito che ci potrebbe essere una colpa condivisa tra CrowdStrike e Microsoft.
Giulio Covassi ha sottolineato l’importanza della qualità prima delle nuove funzionalità, evidenziando come un software non testato possa causare danni significativi. Ha suggerito che l’approccio di platform engineering possa mitigare questi rischi.
Francesco Vollero ha ribadito che se il sistema operativo non permettesse lo sviluppo di moduli kernel eseguiti con privilegi elevati, il problema sarebbe stato meno grave. Ha criticato l’attuale struttura organizzativa che spesso porta a errori dovuti alla mancanza di test adeguati.
Luca Simoncini ha chiesto una Root Cause Analysis dettagliata da CrowdStrike per imparare dagli errori commessi.
Matei Busui ha suggerito una procedura per classificare i servizi critici e non critici e ha sottolineato l’importanza dei test di integrazione e delle procedure di rollback.
Matei Busui: “Se si eseguono servizi critici, bisogna assicurarsi che non si fermino per nessun motivo durante un aggiornamento. Inoltre, è fondamentale avere dei test di integrazione che validino che tutto funzioni come previsto dopo un aggiornamento.”
Ivan Dorna: “Applicare questo al mondo reale significa lavorare per rendere possibile tornare alla versione precedente in ogni caso, in pochi minuti.”
Discussione sul 1% e le Relazioni di Quantità
Nicola Vanin ha riportato che circa 8,5 milioni di dispositivi, meno dell’1% dei computer Windows a livello globale, sono stati colpiti dall’incidente.
Ha osservato che, nonostante la percentuale bassa, il caos generato è stato significativo.
Massimo Biagioli ha commentato che parlare in termini di percentuali può essere fuorviante, e che è più rilevante considerare i numeri assoluti per comprendere l’impatto reale.
Ivan Dorna:
“La percentuale deve essere messa in relazione al contesto e al problema specifico. L’1% di computer bloccati, equivalenti a 8,5 milioni di dispositivi, ha un impatto globale significativo, e questo dato non deve essere trascurato.”
Il mettere in relazione il valole dell’1%, non tanto con il valore assoluto ma come valore di soglia, per quello che ha rappresentato come problema il 19 Luglio 2024 è ormai importante e va tenuto in considerazione.
Ormai sia per la diffusione di software l’uso di questi in installazioni anche complesse che erogano servizi, magari anche in cloud, non si può trascurare quello che può rappresentare come impatto un problema su una compoenente software anche secondaria ma che deve essere erogata e tenuta aggiornata per tutta una serie di motivazioni.
Considerazioni sulle Procedure e la Gestione dei Servizi
Ad oggi, 21 luglio 2024, la gestione dell’esecuzione dei programmi come servizi nei sistemi operativi non è ottimale, anzi è molto primitiva. Dato che questi devono essere aggiornati frequentemente per conformità alle disposizioni di legge e best practices aziendali, soprattutto per i servizi con privilegi amministrativi e di sistema, è fondamentale migliorare la solidità di questi software e del sistema di gestione degli stessi.
Il problema verificato con CrowdStrike è dovuto a tre motivi principali:
- L’update su un canale di Stable/Produzione non è stato testato a sufficienza, soprattutto per una componente che agisce a livello privilegiato.
- Un prodotto + servizio è stato usato come “elemento abilitante” per coperture assicurative, senza un’effettiva analisi del rischio e delle procedure di ripristino.
- Oggi, con la diffusione di ITIL e framework di certificazione per la compartimentazione dei ruoli e responsabilità, sembra che le competenze e la possibilità di agire dei tecnici siano limitate. Questo solleva la domanda: ha veramente più senso oggi dare la colpa piuttosto che tenere le cose in funzione e ripristinarle?
Conclusione
Questo incidente ha messo in luce l’importanza di una gestione consapevole e competente degli aggiornamenti software e delle responsabilità aziendali. La discussione tra esperti IT sottolinea la necessità di un approccio olistico alla sicurezza informatica, che includa non solo la qualità del software, ma anche la responsabilità di chi lo sviluppa e gestisce.
