A qualche giorno di distanza dall’incidente che ha bloccato gli utenti di Crowdstrike, causando la famigerata schermata blu e miliardi di dollari di danni (almeno 5) ad aziende (con disservizi a utenti di trasporti, banche e di ospedali, tra l’altro), si può fare qualche ragionamento più a freddo su cosa non ha funzionato.
E cosa si possa fare per ridurre il rischio che problemi come questo si presentino nuovamente.
Il tema non è naturalmente cosa farà Crowdstrike: Crowdstrike è solo uno dei tanti prodotti che, nella nostra società così dipendente dai sistemi informativi, ha la possibilità di causare un disservizio, e non è neanche uno dei più preoccupanti, dato che è utilizzato da una percentuale tutto sommato limitata delle organizzazioni critiche.
È utile però valutare le affermazioni che in questo periodo sono state fatte dai diversi soggetti considerati come buoni o cattivi esempi di resilienza rispetto a questi problemi.
Incidente Crowdstrike, gli attori
Sicuramente uno degli attori principali è stata Microsoft, che ha avuto modo di dichiarare che Crowdstrike ha potuto causare un danno così ampio perché, per operare efficacemente, ha accesso al nucleo del sistema operativo Windows (il kernel), e questo sarebbe dovuto alle richieste dell’Unione Europea volte a favorire la concorrenza sul mercato della cybersecurity [1]. Con l’accesso al kernel, tutti i software di cyber – e non solo quelli di Microsoft – possono giocare sullo stesso terreno ad armi pari.
Microsoft rende comunque disponibile il proprio prodotto Defender come alternativa. L’implicazione sarebbe che se l’Unione Europea non avesse costretto Microsoft ad “aprire” l’accesso al kernel, il problema non si sarebbe verificato, e gli utenti avrebbero usato Defender senza problemi.
Naturalmente, il ragionamento crolla quando si considera che nessuno costringe le aziende a spendere nell’acquisto di un prodotto come Crowdstrike, certamente non economico: se la gran parte delle grandi aziende acquista prodotti aggiuntivi, sarà perché con Defender non si trova sufficientemente protetta. Detto in altre parole, un kernel chiuso avrebbe evitato questo problema di un giorno, ma probabilmente in tutti gli altri giorni avrebbe causato altri problemi più diffusi. Problemi che comunque gli utenti di altri prodotti di sicurezza diversi da Crowdstrike non hanno (per ora) avuto.
Le cause del problema Crowdstrike
Per quanto riguarda Crowdstrike, ha dichiarato[2] che il problema è stato causato da un difetto negli strumenti di test degli aggiornamenti prima del rilascio, e che si sta muovendo in due direzioni: un rilascio “progressivo” degli aggiornamenti e il miglioramento del processo di test.
Il rilascio progressivo degli aggiornamenti vuole dire in generale che gli aggiornamenti sono rilasciati prima ad un piccolo gruppo di utenti disposti a fare da cavie (o inconsapevoli di esserlo), sui quali vengono verificati eventuali problemi prima del rilascio alla totalità dei clienti. Una tecnica efficace in generale, ma non banale da applicare sugli aggiornamenti sempre più rapidi che sono richiesti dal contrasto al malware. E poi, naturalmente, c’è il miglioramento del processo di test.
La soluzione non soluzione: migliorare i test
Utile certamente, e sicuramente un difetto che causi il blocco immediato di tutte le installazioni dell’aggiornamento dovrebbe essere intercettato, ma sarebbe un errore pensare che il miglioramento dei test risolva il problema, semplicemente perché il problema, in sé, non ha una “soluzione”.
I sistemi operativi sono oggetti estremamente complessi, come molti altri prodotti software, fra cui quelli della categoria di Crowdstrike.
L’idea che dei test, per quanto approfonditi, possano intercettare qualsiasi difetto che possa causare il blocco di un sistema è semplicemente sbagliata. Lo sa bene anche Microsoft, che da decenni lotta con questa difficoltà, e che ha enormemente migliorato i propri processi negli anni, ma che nonostante questo periodicamente inciampa in problemi simili[3].
Che è successo e come evitare riaccada: la nota tecnica di CrowdStrike
Crowdstrike ha fornito la seguente spiegazione tecnica, mentre dichiara che il 97 per cento dei sistemi colpiti (8,5 milioni dice Microsoft) sono tornati online.
Il 19 luglio 2024, alle 04:09 UTC, è stato pubblicato un aggiornamento del contenuto di risposta rapida per il sensore Falcon agli host Windows che eseguono la versione 7.11 e successive del sensore.
Il problema tecnico
Questo aggiornamento doveva raccogliere telemetria sulle nuove tecniche di minaccia osservate da CrowdStrike, ma ha provocato arresti anomali (BSOD) sui sistemi che erano online tra le 04:09 e le 05:27 UTC. Gli host Mac e Linux non sono stati colpiti.
Gli host Windows che non erano online o non si sono connessi durante questo periodo non sono stati colpiti.
Gli arresti anomali erano dovuti a un difetto del contenuto di Rapid Response, non rilevato durante i controlli di convalida.
Quando il contenuto è stato caricato dal sensore Falcon, ha causato una lettura della memoria fuori dai limiti, con conseguente crash di Windows (BSOD).
Crowdstrike ha fornito un fix della patch, che in certi casi è stata installata in automatico sui sistemi colpiti; in altri, ha richiesto un intervento manuale di tecnici specializzati (si tenga conto che molti dei computer affetti non sono personali ma in datacenter, dove solo poche persone autorizzate possono accedere).
Cosa sta facendo CrowdStrike per evitare che questo accada di nuovo?
● Miglioramento dei test di risposta rapida sui contenuti utilizzando tipi di test quali: sviluppatore locale, aggiornamento e rollback dei contenuti, stress, fuzzing, iniezione di errori, stabilità e test dell’interfaccia dei contenuti. Introdurre controlli di convalida aggiuntivi nel Validatore di contenuti per prevenire problemi simili.
● Rafforzare i meccanismi di gestione degli errori nel sensore Falcon per garantire che gli errori causati da contenuti problematici siano gestiti con grazia.
● Adottare una strategia di distribuzione scaglionata, iniziando con una distribuzione canary a un piccolo sottoinsieme di sistemi prima di un’ulteriore distribuzione scaglionata.
- Migliorare il monitoraggio delle prestazioni dei sensori e dei sistemi durante la distribuzione scaglionata dei contenuti per identificare e ridurre tempestivamente i problemi.
- Fornire ai clienti un maggiore controllo sulla distribuzione degli aggiornamenti dei contenuti di risposta rapida, consentendo una selezione granulare di quando e dove vengono distribuiti gli aggiornamenti.
- Fornire notifiche sugli aggiornamenti dei contenuti e sulla loro tempistica.
● Eseguire più revisioni del codice di sicurezza da parte di terzi indipendenti. Conducete revisioni indipendenti dei processi di qualità end-to-end, dallo sviluppo alla distribuzione.
Redazione
Il tema dell’accesso al Kernel
Ma non è solo una questione di test e rilascio: un altro tema fondamentale, ad esempio, anch’esso parte della storia dei sistemi operativi, è come avere la minore quantità possibile di codice che viene eseguita nel kernel, quindi con la possibilità di causare blocchi così gravi, tenendo invece buona parte del codice ad un livello meno critico, riducendo quindi anche la necessità di aggiornare spesso proprio il componente nel kernel.
Si parla quindi di security (e in questo caso, resilience) by design, ovvero per progettazione. Questo è solo uno dei tanti modi in cui l’affidabilità del software critico può essere migliorata.
Naturalmente, non possiamo dire, da questo punto di vista, se il disegno di Crowdstrike sia o meno valido.
Perché un altro problema, quando si parla di rischio, è che non è detto che chi ha avuto l’incidente sia il prodotto peggiore: stiamo parlando di eventi a bassa probabilità, e quindi può essere tranquillamente che qualcuno dei suoi concorrenti, che in questo momento sta guardando le disgrazie di Crowdstrike e che magari ha anche una base di utenti più ampia, possa avere lo stesso problema domani.
L’importanza delle regole
Da questo punto di vista, aiuterà sicuramente il Cyber Resilience Act, che non a caso si chiama così. Proprio per i prodotti più critici, l’immissione sul mercato comporterà verifiche a priori, documentate e di terza parte, per dare maggiori garanzie sia dal punto di vista della progettazione che dei processi di realizzazione e test. Non solo: nel caso di un incidente come questo, sarà molto più semplice, per le autorità di controllo designate, indagare sull’incidente e, se del caso, richiedere azioni di miglioramento o addirittura ritirare il prodotto dal mercato.
Il problema chiave: dipendenza da pochi fornitori
Può bastare? Certo che no. Crowdstrike è una goccia nel mare. La dipendenza da pochi fornitori per componenti molto più critici è praticamente totale. L’incidente di Crowdstrike è, tutto sommato, semplice e limitato: i sistemi si fermano, nel giro di qualche ora si trova la soluzione e poi si fanno ripartire.
Pensiamo cosa succederebbe, per puro esempio, se un aggiornamento di qualcuna delle principali piattaforme di virtualizzazione introducesse un difetto che causasse la progressiva corruzione dei dati, ovvero delle macchine virtuali, delle loro configurazioni e dei dati che trattano (e quindi anche dei dati di ripristino sui quali tanti fanno affidamento).
È solo un esempio: i casi sono talmente tanti che è inevitabile che qualche altro prima o poi si presenti. Non c’è una soluzione semplice.
Quali soluzioni perché non riaccada di nuovo e peggio
Da un punto di vista generale, potrebbe essere opportuno che uno stesso fornitore non possa avere una quota di mercato troppo ampia nell’ambito delle infrastrutture critiche.
Ma, all’interno di una singola azienda classificata come infrastruttura critica, si dovrebbe lavorare in modo importante su una continuità operativa che consideri come scenario anche un guasto dei servizi e prodotti di un fornitore ICT, o l’intero sistema informativo (dopotutto, tipicamente, se un incidente colpisce le infrastrutture di virtualizzazione o il sistema operativo di maggiore utilizzo, c’è poco che rimanga in piedi).
Le soluzioni esistono. Prendiamo ad esempio il settore della sanità, uno di quelli di cui si è parlato anche in questo caso. La capacità di strutture diverse di continuare a mantenere operativi i processi più critici durante un incidente da malware, e poi di riprendersi, è evidentemente diversa in funzione del grado di preparazione all’incidente.
Un guasto dovuto ad un fornitore critico difficilmente avrebbe conseguenze più gravi, e quindi le stesse procedure dovrebbero aiutare anche a mitigare gli impatti di questo tipo di disservizi. Naturalmente, non tutto sarebbe gestibile ma, come sempre quando si parla di rischio, si tratta di mitigare il più possibile, non di risolvere.
Già avere delle procedure di gestione della crisi che permettano di far fronte a questo tipo di incidenti sarebbe un passo avanti ed una tranquillità notevole.
Anche su questo, le istituzioni europee si sono mosse, sia come normativa (i temi di continuità operativa indicati dalla Direttiva NIS2), sia come azioni di verifica della capacità concreta delle organizzazioni di gestire un incidente cyber[4].
Questo perché la nostra dipendenza dai sistemi informativi è nota. Purtroppo, mentre è relativamente semplice affrontare il problema “a valle”, richiedendo alle aziende forti investimenti per la propria resilienza, affrontare il tema della dipendenza da pochi soggetti critici sembra essere molto più complesso.
Note
[1] https://www.theregister.com/2024/07/22/windows_crowdstrike_kernel_eu/
[2] https://www.bloomberg.com/news/articles/2024-07-24/crowdstrike-blames-defect-in-content-update-for-epic-it-crash
[3] https://www.techradar.com/computing/windows/microsoft-pauses-windows-11-update-as-its-sending-some-pcs-into-an-infinite-reboot-hell
[4] https://www.bankingsupervision.europa.eu/press/pr/date/2024/html/ssm.pr240726~06d5776a02.en.html
