8,5 milioni di computer in crash per un solo file che nessuno dalla tua parte ha rivisto

Un amico che gestisce la sicurezza di una compagnia aerea di medie dimensioni mi ha inviato una foto per messaggio durante la colazione del 19 luglio 2024. Era un tabellone delle partenze, solo che ogni pannello era della stessa tonalità di blu, con lo stesso testo di errore bianco ripetuto pannello dopo pannello per tutto il terminal. Non ha scritto nulla ad accompagnarla. Non ne aveva bisogno.

Quando ebbi finito il caffè, il numero era di 8,5 milioni di macchine Windows, andate in crash in meno di novanta minuti. Non un malware. Non uno zero-day. Un ordinario aggiornamento di contenuti da CrowdStrike, un fornitore che quelle aziende pagavano proprio per tenerle al sicuro. Ciò che proteggeva gli endpoint era la stessa cosa che li aveva resi inutilizzabili.

Da allora ho trascorso il tempo a costruire lo strato che avrebbe dovuto stare tra quei fornitori e quelle macchine — quello che oggi chiamiamo integrità del deployment degli aggiornamenti software, un checkpoint indipendente tra la pipeline di aggiornamento di un fornitore e la tua flotta di produzione. Questo saggio parla del perché quello strato non esisteva, del perché il modo ovvio di costruirlo è sbagliato, e di cosa è cambiato per ogni azienda che esegue agenti a livello kernel nel momento in cui quel tabellone blu si è illuminato.

Il 21° campo

Ho letto la CrowdStrike External Root Cause Analysis la notte in cui è stata pubblicata, nell'agosto 2024, e la causa era così piccola da risultare quasi offensiva.

Falcon, il sensore di CrowdStrike, distribuisce la logica di rilevamento attraverso un meccanismo che chiama Rapid Response Content — piccoli aggiornamenti di configurazione che gli permettono di reagire a nuove minacce senza dover distribuire un intero nuovo binario. Il 19 luglio ha distribuito due nuove Template Instances per il rilevamento della comunicazione tra processi. Quelle istanze facevano riferimento a un 21° parametro di input. Il Content Validator cloud-based di CrowdStrike ha verificato l'aggiornamento rispetto al nuovo schema a 21 campi, ha visto che era valido e lo ha approvato.

Il problema era il Content Interpreter in esecuzione all'interno del kernel di Windows, al Ring 0, lo strato più privilegiato del sistema operativo. Si aspettava ancora 20 campi. Quando ha cercato di raggiungere il 21°, ha letto una memoria che non c'era, e la macchina è andata istantaneamente in schermata blu.

Un validatore nel cloud ha approvato un aggiornamento rispetto alle nuove regole. Il kernel che lo ha ricevuto viveva ancora secondo le vecchie. Nessuno stava verificando che i due fossero d'accordo.

Ecco la parte che come ingegnere mi disturba ancora di più. Il crash è avvenuto così presto nella sequenza di avvio che lo stesso agente di gestione di Falcon non è mai partito. Così gli endpoint non potevano ricevere il comando di rollback che CrowdStrike aveva distribuito, perché il software destinato a ricevere quel comando era la stessa cosa che mandava in crash la macchina. Il settore ha un nome cupo per questo — il ciclo dell'agente morto. Il ripristino non era un pulsante. Era un essere umano, a ogni macchina, che avviava in Modalità provvisoria, navigava fino a C:\Windows\System32\drivers\CrowdStrike\, ed eliminava a mano il file difettoso C-00000291-*.sys. Delta lo ha fatto su 40.000 server. Il ripristino ha richiesto cinque giorni.

Non si è mai trattato di un solo fornitore

La storia facile è che CrowdStrike sia stata negligente. È anche la lezione sbagliata, e inseguirla mi avrebbe portato a costruire il prodotto sbagliato.

Perché il modello non è di CrowdStrike. Apri l'inventario degli endpoint di qualsiasi grande azienda e troverai da otto a dodici agenti in esecuzione a livello kernel o con privilegi elevati — l'agente EDR, un agente di data-loss-prevention, un agente di crittografia, un agente di patching, un client VPN, un agente di device-management. Otto righe su un foglio di calcolo, e otto canali di aggiornamento separati, ciascuno che spinge secondo il proprio calendario, ciascuno lasciato passare.

Quell'estate continuavo a porre ai CISO la stessa domanda: chi rivede questi aggiornamenti dei fornitori prima che raggiungano la produzione? La risposta, ogni volta, era una qualche versione di abbiamo un change advisory board. E poi, un istante dopo, la parte onesta: il change advisory board rivede i deployment interni riga per riga, ma gli aggiornamenti dei fornitori saltano la coda dei ticket, saltano lo staging e vanno dritti a ogni endpoint — perché "ci fidiamo del fornitore." Quella frase reggeva l'intero settore, e non aveva alcun meccanismo dietro di sé.

C'è una seconda modalità di guasto di cui non parla quasi nessuno, ed è peggiore da diagnosticare. Quando due fornitori aggiornano le interfacce del kernel lo stesso giorno, i loro driver possono entrare in conflitto e produrre esattamente la stessa schermata blu di un bug di un singolo fornitore. Solo che ora l'analisi delle cause profonde richiede settimane invece di ore, perché stai triangolando tra due team di supporto di fornitori che, ciascuno ragionevolmente, dà la colpa all'altro.

La versione che abbiamo costruito per prima, e perché è fallita

Quando abbiamo iniziato, ero sicuro che la risposta fosse il rilevamento. Osservare gli endpoint, imparare che aspetto ha la normalità e gridare nell'istante in cui un aggiornamento inizia a comportarsi male. È l'istinto che l'intero mercato dell'observability ci ha addestrato ad avere — Datadog, Dynatrace, Splunk, tutti brillanti nel dirti cosa è appena successo.

Ne abbiamo costruito una versione. L'abbiamo eseguita su un replay di guasti causati da aggiornamenti. E ha funzionato, nel modo più inutile possibile: ha colto il problema magnificamente, dopo che le prime macchine erano già andate giù.

Ricordo la chiamata in cui questo mi è arrivato. Un CISO pilota ha guardato la nostra dashboard illuminarsi qualche secondo dopo l'avvio di un rollout difettoso simulato e ha detto, più o meno, che non aveva bisogno di un modo più veloce per scoprire di essere già in fiamme. Aveva bisogno che l'aggiornamento non raggiungesse mai tutti i suoi endpoint contemporaneamente in primo luogo. Il rilevamento dopo il deployment, per un guasto che impiega novanta minuti a colpire 8,5 milioni di macchine, è un rilevatore di fumo che suona quando la casa è ormai andata.

L'observability ti dice che l'edificio sta bruciando. A quel punto l'unica domanda rimasta è quanti giorni ci vorranno per la ricostruzione.

Quello fu il mese in cui avevo silenziosamente scommesso il lavoro sullo strato sbagliato, e vedere quella dashboard dimostrarlo fu la cosa più utile che ci accadde. Il problema non è mai stato la velocità di rilevamento. Era che non c'era alcun checkpoint prima che l'aggiornamento arrivasse.

Allora perché gli strumenti esistenti non lo intercettano?

Si presume che la sicurezza della supply chain del software copra già questo. Non è così, e la ragione è precisa.

Gli strumenti SBOM e di software-composition-analysis — Snyk, Sonatype — verificano il tuo albero delle dipendenze open-source. Sono costruiti per dirti che un pacchetto npm tre livelli più in profondità ha una vulnerabilità nota. Ma il Rapid Response Content di un fornitore, un file di canale, un blob di configurazione proprietario firmato e spinto da CrowdStrike o da qualsiasi altro fornitore analogo — quello è invisibile per loro. Non è nel tuo albero delle dipendenze. Viene spinto intorno a esso, dritto nel kernel. Gli strumenti destinati a proteggere la tua supply chain del software stanno verificando lo strato completamente sbagliato.

ITIL e il tuo change advisory board? Procedurali. Sono liste di controllo e approvazioni progettate per i cambiamenti che tu avvii, e non sono mai stati collegati al ritmo di rilascio di un fornitore.

E la stessa remediation di CrowdStrike — modalità di self-recovery, content pinning, "customer deployment controls" scaglionati, un framework Resilient-by-Design preso in prestito dalla CISA — è un lavoro reale, e non lo liquido. Ma leggi cosa è in realtà: ognuno di quei controlli è autoregolamentazione del fornitore. La stessa azienda che ha distribuito il 21° campo è quella che certifica che ora è sicuro. Non c'è ancora alcuna parte indipendente che si frapponga tra la spinta del fornitore e il tuo endpoint. La gross retention di CrowdStrike si è attestata sopra il 97% nel trimestre successivo al blackout, il che ti dice che il mercato non li ha puniti — e non ti dice nulla sul fatto che la lacuna sottostante si sia chiusa. Non si è chiusa.

Quella lacuna è l'intero prodotto. Il posto giusto in cui stare non è sull'endpoint a osservare l'incendio, e non è dentro il fornitore a fidarsi della sua parola. È nel mezzo: un checkpoint neutrale rispetto al fornitore che prende l'aggiornamento prima che raggiunga la produzione, lo fa passare attraverso una sandbox che rispecchia la tua flotta reale, verifica il contenuto rispetto a ciò che il tuo kernel effettivamente si aspetta, e modella il raggio d'impatto se è sbagliato. Quello è lo strato che abbiamo finito per costruire, e puoi vederne la forma sulla nostra pagina della soluzione. Una discrepanza di schema come il bug dei 21-contro-20 campi è esattamente il tipo di cosa che una sandbox pre-deployment fa emergere in un canary ring invece che su 8,5 milioni di macchine contemporaneamente.

Il terreno legale si è spostato, e la maggior parte dei contratti non si è adeguata

Per un po' ho trattato il lato normativo come rumore di fondo. Mi sbagliavo, e i clienti mi hanno mostrato perché: i contratti nei loro cassetti non li proteggono più nel modo in cui pensano.

Inizia da Delta contro CrowdStrike. Nel maggio 2025, alla Fulton County Superior Court, il giudice Ellerbe ha lasciato procedere le richieste per colpa grave, computer trespass e frode per omissione — oltre il tetto di responsabilità contrattuale di CrowdStrike. Il punto del computer trespass è quello che dovrebbe far rizzare le orecchie a ogni CISO: Delta aveva disattivato gli aggiornamenti automatici, e il file di canale ha raggiunto comunque il kernel. Se un fornitore può spingere contenuti Ring 0 attraverso un canale che le tue impostazioni non governano, le preferenze di aggiornamento nel tuo accordo potrebbero essere inapplicabili. La maggior parte degli MSA aziendali non distingue nemmeno un aggiornamento completo del sensore dal rapid-response content. Dovrebbero.

Poi si è mossa l'UE, e questa è la parte che ora sollevo in ogni rinegoziazione contrattuale a cui partecipo. La rivista Product Liability Directive ora classifica il software esplicitamente come un "prodotto" soggetto a responsabilità oggettiva, e afferma che le aziende non possono escludere contrattualmente la responsabilità per i difetti del software e della cybersecurity. Il tetto di responsabilità di pochi milioni che il tuo fornitore ha cerchiato nel contratto potrebbe semplicemente non reggere nelle giurisdizioni dell'UE. Insieme a essa, il Cyber Resilience Act dell'UE avvia la segnalazione obbligatoria delle vulnerabilità l'11 settembre 2026 — un orologio di 24 ore che, cosa cruciale, parte da quando tu ne vieni a conoscenza, non da quando il fornitore ti notifica. Il blackout di un fornitore può diventare rapidamente il tuo obbligo di segnalazione.

E negli Stati Uniti, la SEC ora richiede alle società quotate di divulgare gli incidenti di cybersecurity rilevanti entro quattro giorni lavorativi e di descrivere il rischio della supply chain del software nei loro documenti 10-K. Fai i conti con i dati sui costi: lo studio di New Relic del settembre 2025 ha stimato il costo mediano di un significativo downtime IT in 2 milioni di dollari all'ora, e il 41% delle aziende medio-grandi colloca la propria cifra tra 1 e 5 milioni di dollari all'ora. Un blackout di quattro ore causato da un aggiornamento di un fornitore che il tuo change board non ha mai visto supera da solo la soglia di rilevanza. Il tuo team di investor relations ha bisogno di un playbook per i blackout dei fornitori, non solo di un playbook per le violazioni.

Un blackout di quattro ore causato da un aggiornamento che nessuno dalla tua parte ha rivisto arriva a circa 8 milioni di dollari al valore mediano — il tipo di numero che atterra sulla scrivania del CFO, non su quella del CISO.

"Potrebbe succedere a noi?"

Dopo il luglio 2024, ogni consiglio di amministrazione del mondo ha posto al proprio CISO le stesse quattro parole. E i CISO con cui ho parlato per lo più non avevano una risposta strutturata — il che non è una critica nei loro confronti. I dati di IANS Research dell'inizio del 2026 hanno rilevato che solo il 29% dei membri dei consigli di amministrazione considera la reportistica di sicurezza del proprio CISO "molto efficace", e il rischio di deployment degli aggiornamenti è esattamente il tipo di cosa che è reale, costosa e quasi impossibile da quantificare con gli strumenti che la maggior parte dei team ha.

Quella è la metà più silenziosa di ciò che abbiamo costruito. Non solo il checkpoint tecnico, ma la cosa che trasforma "potrebbe succedere a noi" in una risposta pronta per il consiglio: un inventario di ogni agente privilegiato e del suo canale di aggiornamento, un modello quantificato del raggio d'impatto per fornitore, un registro di quali aggiornamenti sono stati testati in sandbox e cosa vi hanno fatto. Converte una slide che diceva "ci fidiamo dei nostri fornitori" in una che mostra il lavoro svolto.

Le persone mi chiedono se questo sia davvero necessario ora che Microsoft sta spingendo i fornitori di sicurezza fuori dal kernel — la Windows Resiliency Initiative, con Quick Machine Recovery e il graduale spostamento della sicurezza degli endpoint dalla modalità kernel alla modalità utente. È uno spostamento strutturale genuinamente positivo, e ridurrà nel tempo il peggior raggio d'impatto. Ma la tempistica si estende attraverso il 2026 e il 2027, passerai tutta quella finestra a gestire una flotta mista in mezzo alla migrazione, e "meno catastrofico" non è "verificato." Un agente in modalità utente che distribuisce una configurazione difettosa può comunque mettere fuori uso ciò di cui è responsabile. La necessità di un controllo indipendente non scompare quando scompare il kernel; si sposta semplicemente uno strato più in alto.

L'altra cosa che le persone dicono è che aggiungere un checkpoint rallenta tutto — che l'intero senso del Rapid Response Content è la velocità contro le minacce in tempo reale. Giusto. Ma la scelta non è mai stata velocità contro sicurezza. Il validatore cloud di CrowdStrike ha girato velocemente e ha comunque approvato l'aggiornamento difettoso, perché ha verificato il file rispetto al nuovo schema e non ha mai verificato che il kernel fosse d'accordo. La velocità non è stata il guasto. Lo è stata l'assenza di un controllo indipendente. Un canary ring che intercetta una discrepanza di schema in 30 macchine ti costa minuti. L'alternativa è costata a Delta cinque giorni e 550 milioni di dollari.

Cosa significava davvero il tabellone blu?

Continuo a tornare alla foto del mio amico di quel tabellone delle partenze. Per una mattina, l'astrazione dentro cui vive ogni azienda — i nostri fornitori fidati ci tengono al sicuro — è stata resa in un blu letterale, pannello dopo pannello, in un edificio pieno di persone bloccate.

I fornitori non hanno fallito perché erano sconsiderati. Hanno fallito perché noi, collettivamente, abbiamo costruito un settore in cui un singolo file di configurazione da un singolo fornitore poteva raggiungere ogni endpoint contemporaneamente senza alcuna parte indipendente a verificare i conti. CrowdStrike è stato quello a cui è uscito il numero. La struttura che lo ha permesso è presente, proprio adesso, nell'inventario degli endpoint di quasi ogni azienda che puoi nominare — da otto a dodici agenti privilegiati, da otto a dodici canali, e nessuno nel mezzo.

Puoi leggere l'architettura completa del checkpoint che abbiamo costruito qui. Ma la parte con cui vorrei che un CISO se ne andasse è più semplice di qualsiasi prodotto. Il prossimo blackout di questo tipo non si annuncerà come un incidente di sicurezza. Arriverà firmato, fidato e approvato — esattamente nel modo in cui è arrivato l'ultimo. L'unica cosa che cambia il finale è qualcuno che si frappone tra la spinta e la flotta di produzione, verificando che l'aggiornamento e la macchina siano ancora d'accordo prima che tutti e 8,5 milioni di essi lo scoprano contemporaneamente.