Aeroporti bloccati. Ospedali costretti a rimandare interventi non urgenti. Banche inaccessibili. Compagnie aeree a terra. Tribunali che rinviavano udienze. Emergency service incapaci di accedere ai sistemi di dispatch. In poche ore il problema aveva contagiato settori critici in ogni paese del mondo.
 

Come è potuto succedere

La domanda tecnica fondamentale: come fa un singolo file difettoso a bloccare 8,5 milioni di macchine in tutto il mondo contemporaneamente?

La risposta è nella struttura del software di sicurezza enterprise moderno. Falcon di CrowdStrike gira a livello kernel — il nucleo del sistema operativo — con i privilegi più alti possibili. Questo gli permette di monitorare e intercettare qualsiasi processo in tempo reale. Ma significa anche che un errore in quel livello non viene gestito dal sistema operativo normale: produce un crash totale e irrecuperabile.

L'aggiornamento automatico è un'altra parte del problema. CrowdStrike — come praticamente tutti i software di sicurezza moderni — si aggiorna automaticamente per garantire protezione contro le minacce più recenti. Un ritardo nell'aggiornamento può significare vulnerability. Ma un aggiornamento non testato a sufficienza può significare quello che abbiamo visto venerdì.

L'aspetto più inquietante non è il bug in sé — i bug esistono e sempre esisteranno. È la concentrazione del rischio. Quando una percentuale enorme dell'infrastruttura critica mondiale dipende dallo stesso fornitore software, un singolo punto di fallimento ha effetti sistemici che nessuna analisi del rischio tradizionale aveva adeguatamente modellato.
 

Il problema "too big to fail" della cybersecurity

CrowdStrike non è l'unico player del mercato endpoint security, ma è tra i più diffusi nelle grandi organizzazioni. La sua penetrazione è alta proprio perché è considerato uno dei migliori: ottimi detection rate, aggiornamenti frequenti, integrazione profonda con i sistemi Windows.

È il paradosso della sicurezza: proprio gli strumenti più affidabili e più diffusi creano la concentrazione di rischio sistemico più pericolosa. Non per colpa loro, ma per la natura stessa del mercato che tende alla standardizzazione.

Nei giorni successivi al blackout sono emerse critiche all'assenza di un sistema di rollout graduale degli aggiornamenti — distribuirli prima su un campione di macchine, verificare che non ci siano problemi, e solo poi estenderli al parco completo. È una pratica standard nello sviluppo software ma evidentemente non applicata a questo aggiornamento. CrowdStrike ha già annunciato che cambierà il processo.
 

Il recovery: un incubo operativo

Chi ha vissuto dall'interno questa giornata sa che il problema più grave non è stato il blackout stesso, ma il recovery. La soluzione tecnica — avviare le macchine in modalità provvisoria e cancellare il file difettoso manualmente — è semplice in teoria e impraticabile su scala.

Un'azienda con 10.000 macchine Windows ha bisogno di 10.000 interventi manuali. Non si possono fare da remoto perché le macchine non bootano. Richiede tecnici fisicamente davanti a ogni dispositivo. In un'organizzazione con sedi in tutto il mondo, spesso con laptop distribuiti a dipendenti in smart working, questo ha richiesto giorni.

È il momento in cui ogni CIO e responsabile IT del pianeta si è ricordato perché il backup fisico dei sistemi critici non è mai abbastanza e perché la dipendenza totale da infrastrutture digitali senza piani di business continuity analogici è una scommessa pericolosa.
 

Lezione per le PMI italiane

La tentazione, di fronte a un evento del genere, è pensare "ma queste sono grandi organizzazioni, noi siamo una PMI, non ci riguarda". Sbagliato.

Molte PMI italiane usano software enterprise come CrowdStrike per la cybersecurity, soprattutto quelle che lavorano con aziende più grandi che lo impongono come requisito contrattuale. Ma anche quelle che non lo usano direttamente sono esposte: se il loro commercialista, la loro banca, il loro fornitore di logistica era su macchine colpite, hanno sentito l'impatto indiretto.

Le domande che ogni imprenditore dovrebbe porsi dopo questo venerdì: qual è il mio piano se i sistemi informatici smettono di funzionare per 8-24 ore? Chi sono i fornitori critici su cui dipendo? Ho un piano B per i processi operativi fondamentali?

Non si tratta di paranoia. Si tratta di resilienza operativa. E venerdì ha dimostrato che la domanda non è "se" ma "quando".
 

La nostra posizione

Questo incidente è uno dei più significativi della storia dell'IT non perché sia stato grave — lo è stato — ma perché ha reso visibile ai non addetti ai lavori una vulnerabilità sistemica che chi lavora in questo settore conosceva in forma astratta da anni.

La dipendenza da un numero ristretto di fornitori tech critici, combinata con l'aggiornamento automatico pervasivo e la mancanza di piani di continuità operativa adeguati, è una bomba a orologeria che venerdì 19 luglio è esplosa in modo relativamente controllato. La prossima volta potrebbe andare diversamente.

Speriamo che CrowdStrike porti a una riflessione seria sull'architettura della dipendenza digitale, non solo a una patch al processo di rilascio. Il problema è più grande del bug.