Il colpevole non e' mai il cameriere.
Ora che la polvere si e' diradata e molta gente ha dato opinioni variegate (delle quali molte insensate), posso cercare di spiegare, riassumendo, quanto successo quando CrowdStrike ha deciso di fare harakiri tentando di assassinare il mondo.
Per comprendere a pieno cause ed effetti, elenchero' di seguito i colpevoli, in ordine di importanza:
L'ordine di importanza e' voluto, dato che, quanto successo, riflette a pieno la cultura del risparmio ad ogni costo che in troppe realta' si porta avanti. Vedere la voce di spesa "Reparto IT", esclusivamente come un costo quando ormai, per la maggior parte delle aziende, rappresenta il fulcro nevralgico del loro funzionamento, ha portato a conseguenze come questa, dove un outage si e' protratto per giorni e giorni, o addirittura per una settimana intera.
Troppi IT manager, superficialmente, scartano questo tipo di eventi con "ma non succede mai", non considerando la quantita' abnorme di soldi persi per risparmiare poco, a confronto.
In varie discussioni sul fediverso dove tentavo di portare chiarezza, un punto emerso molto chiaramente e con il quale concordo in pieno e' stato: "Dove stavano i piani di disaster recovery?"
Chiunque abbia lavorato su sistemi enterprise si sara' trovato ad eseguire un upgrade di qualcosa in un sistema di produzione. Avra' notato che, qualsiasi processo si segua (Il CAB di ITIL, o la “Go/NoGo meeting”, o qualsiasi altra cosa si faccia, si discute comunque di qualcosa: la strategia di Rollback.
Anche questa si puo' chiamare in tanti modi, ma la domanda che sta dietro e': dal momento che Murphy e' inarrestabile, cosa facciamo se passa da queste parti e l'upgrade fallisce? Bella domanda.
-- Uriel Fanelli
Fin troppe volte ho visto, nelle realta' nelle quali ho lavorato, piani di disaster recovery essere considerati, al piu', una casella da spuntare. I test fatti erano ridicoli, dato che "tanto non succede mai" e l'opinione alla quale vi rimando (e che racconta la sacrosanta verita'), descrive appieno le enormi responsabilita' di aziende miliardarie nel non proteggere i propri asset IT:
La domanda: "cosa facciamo se il nostro datancer esplode", piu' si che no viene ignorata, oppure, diventa un continuo lamentio riguardo i costi per una soluzione di DR adeguata (sostanzialmente significa duplicare TUTTA la vostra infrastruttura, per essere in grado di spostare tutti i workloads da un datacenter ad un altro).
Per non parlare di backup, strategie di recovery basate su snapshots (se si usano macchine virtuali) e simili. quante volte avete testato i vostri backup? Quante snapshots tenete per quanto riguarda i vostri sistemi piu' importanti, se vi trovate su un cloud o su una infrastruttura di virtualizzazione privata? Che cosa fate se un incidente simile colpisce uno o piu', dei SaaS fondamentali per il funzionamento delle parti critiche del vostro business?
Tutto questo, costa soldi (tanti), tempo, pianificazione e test. In particolare la prima voce, e' quella che fa sobbalzare il management di turno, dato che non sono soldi produttivi, quindi magari a livello di infrastruttura c'e', ma viene tenuta spenta per risparmiare il quattrino.
Le aziende sono le prime colpevoli di questo disastro e tentano, invano, di ribaltare la responsabiita' su CrowdStrike per loro incompetenza. In questo, troppa gente parla a vanvera dandogli ragione.
Non hanno fatto un assessment del software, non ne hanno verificate le implicazione riguardo l'intrusivita' sui loro sistemi. Pero' ora vogliono scaricare la responsabilita' delle scelte fatte su qualcun altro, per distrarre l'opinione pubblica dal fallimento. Hanno installato CrowdStrike solo per mettere una pecetta sul quadratino di una lista, alla fine.
Delta airlines, in tutta la sua codardia.
Ne ha molte, a mio parere, dato il funzionamento del software che sviluppa e la mancanza di best practices nello sviluppare un software come un EDR.
Per i meno scafati, che cosa e', effettivamente, un EDR?
Un "EDR" (Endpoint, Protection and Response) e', per i meno avvezzi, circa l'equivalente dell'antivirus che funziona sul vostro computer personale, pero' applicato a livello enterprise. Un software di questo tipo si occupa di:
Essendo che CrowdStrike vende se stessa come "compagnia di cybersecurity" ed essendo il mercato della sicurezza informatica pieno di gente che se ne va in giro a puntare il dito e blaterare contro TUTTI, quelli che non seguono il loro vangelo, ci si aspetta che un software prodotto da una compagnia di sicurezza segua tutte le best practices possibili ed immaginabili, che sia iper-sicuro e a prova di bug. Corretto?
No. Soprattutto dato il design di un software EDR e di come deve funzionare. Ma come funziona un tale software?
Per farla breve: ha due componenti principali: la parte che gira in userland, in modo non privilegiato ed un driver che funziona a livello kernel del sistema operativo, quindi con tutti i privilegi possibili. Il sistema puo' ricevere aggiornamenti software (su Windows possono essere gestiti tramite SUS e la loro installazione puo' essere fatta in modo "canary" su una flotta di sistemi in modo scaglionato), oppure aggiornamenti delle "definizioni". In pratica, un database contenente le signature di malware e simili. Il problema e' che Crowdstrike, tramite i file delle definizioni, non rilascia esclusivamente aggiornamenti per un database, ma anche CODICE ESEGUIBILE A RUNTIME, per aggirare le limitazioni di Windows, rendendo tutto piu' complicato.
Ora, nel disegnare un software come questo, ci si aspetta che la componente funzionante nel kernel del sistema operativo sia il piu' piccola possibile ed il piu' testata possibile. In uno qualunque dei sistemi operativi, commerciali oppure open source, attualmente sul mercato, un crash di un driver funzionante a livello kernel, significa il blocco istantaneo della macchina, o kernel dump. Si capisce bene che, con un tale componente, non si scherza. Poi, sono un'azienda LEADER nella sicurezza informatica, giusto?
Non proprio. CrowdStrike e' sempre stata molto "Agile" nello svilppare il proprio software.
Dove sta allora, il suo fallimento?
L'ultimo punto, potrebbe aver senso. Tu vuoi che il tuo EDR sia presente il prima possibile, per cercare di proteggerti da eventuali minacce. In ogni caso, il design e' passibile di miglioramenti. Guardando la lista di fallimenti sopra, inoltre, non sarei sorpreso se il loro codice non avesse testsuite di sorta. Fortuna che i clown della sicurezza informatica puntano tanto il dito contro tutti, vero?
Se usate CrowdStrike, vi consiglio di cambiare fornitore, o di cercare una soluzione con un approccio diverso, se si tratta della protezione dei vostri dati aziendali, rispetto ad un driver malfatto da far girare nel cuore del vostro sistema operativo.
In tutta questa storia, Windows ha una sola colpa, che e' abbastanza grande in se': Microsoft non ha mai voluto, per qualsivoglia motivo, creare una serie di API da esporre per i vari EDR in userland, in modo di poter rimuovere l'anacronismo che sono gli hook all'interno del proprio kernel.
Hanno citato un giudizio della comunita' Europea del 2009, in merito, ma a maggiore indagine, questo non ha senso. La verita' e' che Microsoft stessa, avrebbe dovuto far funzionare Windows defender in userland, con le conseguenze del caso. Questo deriva da una, idiota, scelta di design, dove "admin", non deve avere boundaries di sicurezza fra il kernel e la userland. Di qui, il porcaio che sono i driver come CrowdStrike.
Apple, per quanto personalmente la odi, ha deciso che i loadable modules sono deprecati. Tant'e' che saranno rimossi a breve e software come CrowdStrike, seppur i fornitori protestarono al tempo, sono obbligati a girare fuori dal kernel, utilizzando delle API apposite per effettuare le proprie analisi. Stessa scelta che fece OpenBSD ormai dieci anni fa. I loadable modules sono problematici per mille motivi. Vuoi un'API per agganciarti ad un sottosistema? Discutiamone, ma niente piu' codice a runtime nel kernel. Thank you very much.
Chi dice che Windows avrebbe dovuto poter fare rollback dell'aggiornamento, sbaglia, non si trattava di un aggiornamento del software, gestibile tramite group policy, ma di un aggiornamento di definizioni gestito interamente da CrowdStrike che, quindi, sfuggiva a questa possibilita'.
Inoltre e qui Windows si comporta correttamente, se un driver dice al sistema operativo: "io ti servo per fare il boot", Il sistema operativo NON deve andare avanti, data questa direttiva, in quanto, in caso contrario, non sarebbe predicibile lo stato del sistema dopo il boot. Un "required boot driver", significa proprio questo. Se tu driver non funzioni, io OS mi devo fermare.
Tutto il resto e' e rimane, un design decisamente problematico. Microsoft dovrebbe creare tutte le API necessarie agli antivitus ed EDR per funzionare e sbatterli fuori dal kernel. Oppure creare un qualcosa come eBPF su Linux, dove almeno, come citato da altri, qualche piccola garanzia a livello di pre-check viene fatta. Pero' CrowdStrike ha colpito anche li' (RedHat, in questo caso):
E piu' di una volta.
Quindi no: usare Linux, o un BSD, se si ha la possibilita' di caricare codice da moduli esterni a runtime, non vi avrebbe salvato. Inoltre, CrowdStrike su Linux, e' riuscito a far crashare sistemi abusando eBPF. Non un gran testimonial, per la qualita' di quello che fanno.
Come detto all'inizio e come in tutti i migliori thrillers, il cameriere non e' mai il colpevole.
