Che un aggiornamento in un singolo file in una complessa piattaforma di cybersecurity abbia messo fuori gioco milioni di computer Windows può essere stata una manna per i quotidiani generalisti - che infatti non hanno lesinato i titoli catastrofici - e per i commentatori della prima ora. A bocce (più) ferme, a chi si occupa più seriamente di IT e di cybersecurity - specie nelle imprese - viene invece chiesto, ora, di astrarsi dalla cronaca e di trarre qualche morale utile dalla vicenda CrowdStrike.

Chiudere anche questa storia come l'ennesimo incidente che può accadere - e pazienza - non porterebbe vantaggi a nessuno. Ci sono aspetti che andrebbero invece meglio esaminati, da chi fa tecnologie ma soprattutto da chi le usa. Ecco quelli che, secondo noi, sono i principali.

La resilienza debole

Quello che è successo in questi giorni non è "il Millenium Bug come se fosse accaduto sul serio": un paragone che diversi esperti di sicurezza hanno portato avanti. Alla fine, se si vanno a vedere le stime di Microsoft, ad essere colpiti sono stati circa 8,5 milioni di sistemi Windows: tanti, ma grosso modo solo l'uno percento di quelli in funzione. Questo però è bastato per mettere in crisi interi servizi, con conseguenze economiche e sociali importanti.

Il messaggio che ne viene è ovvio: le infrastrutture che sostengono molti servizi e sistemi, pubblici o privati, non sono ancora pensate per una adeguata resilienza IT. Chi le progetta non può (o non sa, o non intende, o non ha il budget per) ipotizzare scenari di business continuity concreta di fronte ad eventi con impatti negativi massivi. Eppure, di "casi CrowdStrike" ne abbiamo visti diversi.

E no, "tutto in cloud" non è una soluzione. Non singolarmente, come non lo è l'AI e non lo è quant'altro le varie cybersecurity company (CrowdStrike esclusa, ovviamnente) stanno commentando in queste ore (rischiando la brutta figura quando ad essere sotto la lente d'ingrandimento saranno magari loro... un po' di scaramanzia non farebbe male). È una questione di approccio complessivo.

Il pericolo delle monoculture

È dal meticciato e dalla commistione delle diversità che nascono gli organismi più resistenti. In campo IT stiamo però facendo l'esatto opposto, favorendo le monoculture tecnologiche come inevitabile risultato delle dinamiche di mercato. Che un prodotto efficace ne scalzi altri perché è migliore, ci sta. Ma il pericolo delle "scelte ovvie" è evidente: quando qualcosa va storto in una combinazione di piattaforme usata da milioni di sistemi - in questo caso CrowdStrike più Windows - l'impatto è massivo e non ci sono alternative su cui ripiegare.

Non è una questione di "A è meglio di B", ma piuttosto che avere sia A sia B aiuta quando A o B vanno in crisi singolarmente. Certo, questo comporta una maggiore complessità di gestione (troppa, per molti) e non è una garanzia assoluta. Ma vale lo stesso la pena pensarci, laddove la business continuity è un requisito importante. Non è un caso che dal mondo dei CISO vengano sempre più segnali secondo cui avere più prodotti di sicurezza è complesso, ma è anche meglio.

La chimera dello sviluppo

Alle aziende ed alle organizzazioni è stato passato il mantra della ricerca della massima efficienza operativa, associato alla promessa delle meraviglie dell'automazione (ed ora dell'AI, ma questa è un'altra storia). Questa ricerca della massima efficienza diventa di fatto la ricerca della massima rapidità operativa, e basta il buon senso per capire che a voler andare sempre più in fretta il rischio di sbagliare (direttamente o indirettamente) aumenta. Su molti fronti.

Nelle attività di sviluppo software ci siamo inventati, negli anni, modelli più o meno "agili" e sigle "creative" (da DevOps in poi) che alla fine rimandano a un concetto quasi banale: il mandato ormai è quello di sviluppi frequenti e incrementali, con altrettanto rapide messe in produzione. Senza adeguate salvaguardie l'errore è dietro l'angolo, a causa della complessità e dell'interconnessione delle supply chain dello sviluppo.

Non sembra che se ne possa uscire, onestamente, perché innovare nel software sembra essere sinonimo di "creare sempre più funzioni, sempre più spesso" e l'idea del prodotto "completo", finito, terrorizza. Forse perché non si vende bene in abbonamento e non giustifica team, risorse, manager, riorganizzazioni in nome dello sviluppo.

L'IT senza freni

Anche lato utenti l'efficienza è diventata ricerca della velocità. E ha man mano mandato in pensione controlli e salvaguardie che una volta sembravano solo di buon senso. Ogni aggiornamento software può portare problemi e incompatibilità perché nessuno è infallibile (vedi sopra), motivo per cui una volta gli aggiornamenti venivano fatti su un pool di sistemi di test e, una volta verificata la loro affidabilità, venivano estesi a tutti gli altri. Oggi l'idea farebbe inorridire una buona percentuale di CIO, almeno tra i più "moderni".

Eppure, in uno scenario in cui una media infrastruttura IT è ormai una galassia di migliaia di componenti distribuiti, interconnessi e idealmente in sinergia fra loro, ma le cui interdipendenze in realtà non sono mai veramente chiare, la prudenza non dovrebbe essere mai troppa. Difficile portare avanti anche questo concetto, perché sono i top management stessi a volere aziende "agili" e innovative. Ma tutto va commisurato a una corretta gestione del rischio.

Chi sorveglia i sorveglianti?

È la vecchia satira di Giovenale che ogni tanto si cita: "Pone seram, cohibe, sed quis custodiet ipsos custodes?", ossia "Spranga la porta, impedisci di uscire, ma chi sorveglierà i sorveglianti stessi?". Giovenale di cybersecurity non se ne intendeva, ma l'idea che passa vale ovunque: c'è in tutti gli aspetti della nostra vita una catena della fiducia che ad un certo punto arriva ad una fiducia "a priori". Mi devo fidare dei "sorveglianti" in senso lato, altrimenti non saprei come fare, ma posso davvero farlo?

Così, è ovvio che CIO e CISO si fidino dei fornitori di cybersecurity, ma possono davvero farlo? La risposta purtroppo è ovvia: non totalmente, perché nessuno è immune da errori o da vulnerabilità. La cronaca della cybersecurity lo dimostra pienamente. Eppure - ed è qui il punto - i tentativi di (quantomeno) affrontare la questione della sicurezza intrinseca del software vengono visti sempre come idee curiose e spiacevoli che ingessano l'innovazione. Ma le norme e gli obblighi sulla sicurezza dei prodotti sono ovunque, è normale che nascano e si sviluppino anche per gli artefatti software. Facciamocene una ragione, una buona volta.