A meno che venerdì scorso non eravate in vacanza in modalità completamente off-line (beati voi), di sicuro saprete del venerdì nero (informaticamente parlando) che ha letteralmente paralizzato molti servizi informatici in tutto il mondo (ad esempio il settore trasporto, con voli cancellati o in ritardo di molte ore).

Il problema, secondo stime di Microsoft, ha interessato 8,5 milioni di computer basati su Windows. Ma Microsoft non centra, se non indirettamente (perchè solo i sistemi Windows sono stati colpiti).

Il blocco informatico non è dovuto ad un attacco, ma è bensì stato causato da un problema a seguito di un aggiornamento di un particolare software di sicurezza usato in molte aziende medio-grandi, questo aggiornamento ha portato all’inevitabile blocco di molti sistemi Windows, con la classica schermata di blocco di Windows (BSOD – Blue Screen Of the Death).

L’azienda del software in questione si chiama Crowdstrike ed è un’azienda specializzata in cybersecurity con base ad Austin (Texas) e fondata da un ex di McAfee. Curiosamente il loro prodotto ha avuto molto successo visto che tante aziende (soprattutto nel settore bancario/finanziari e utility) lo hanno scelto.

Ma torniamo al punto iniziale… cosa dobbiamo imparare da questo caso abbastanza ecclatante (in realtà non è stato il primo e non sarà l’ultimo)?

Tocca quanto basta altrimenti si scassa

Parto da questa affermazione che ancora oggi viene usata da alcuni amministratori di sistema secondo un’affermazione citata in un libro del secolo scorso: “I am a lazy SysAdmin. I am also a very productive SysAdmin” (David Both – The Linux Philosophy for SysAdmin).

In realtà l’affermazione ha un senso ma va contestualizzata sia al periodo storico (informaticamente parlando) del libro, sia al contesto nella quale viene detta.

Non aggiornare un sistema è una pessima prassi, se non altro perchè un sistema che oggi è “ragionevolmente” sicuro, domani, se non si applicano patch di sicurezza, sicuramente non lo sarà. Questo forse è uno dei rari casi in cui l’approccio ha pagato. Ma aggiornare è assolutamente necessario, solo che va gestito nel modo corretto (ne parliamo dopo).

L’estremo è il caso di questo articolo dove si afferma che un’azienda è restata operativa perchè usa ancora Windows 3.1… al di là del fatto che Crowdstrike probabilmente non gira su Windows 3.1 e quindi è ovvio che non è stata affetta da un problema di un software che non aveva, ma qualche dubbio sul fatto che l’azienda usi effettivamente ancora Windows 3.1 mi viene. Il problema è il messaggio sbagliato… non è che se non aggiorno non avrò problemi… in realtà ne potrei avere tanti altri!

Questo estremo aprirebbe tutto un altro discorso su quelle aziende (fortunatamente sempre meno e di solito solo in casi particolari) che utilizzano ancora Windows XP (e ce ne sono!)… sicuramente è più “moderno” rispetto a Windows 3.1 ma è comunque datato.

Piattaforma comune = propagazione dei problemi?

Una delle teorie più risibili che ho letto è che la colpa del problema sia dovuta al fatto che siamo troppo dipendenti dalla piattaforma Windows. Perchè su Linux non ci sono mai stati problemi di sicurezza (basta citare ssh o openssl)?

Pure Linux può bloccarsi se un software è scritto male o ha gravi bug… non sarà una schermata così evidente come quella del BSOD, ma esiste e capita quando il kernel di Linux va in uno stato chiamato “kernel panic”.

In questo caso, il software di Crowdstrike è un software per Windows e quindi ha ovviamente impattato SOLO quel sistema operativo.

E’ chiaro che se lo stesso software è installato in tanti sistemi, tutti questi possono essere affetti da un malfunzionamento comune. Ma questo riguarda qualunque sistema operativo (pensiamo a cosa era successo con log4j, ad esempio).

Piuttosto deve far pensare molto il fatto che, in determinati settori, ci fossero così tante aziende con uno stesso software di sicurezza… ma evidentemente erano stati bravi a proporto ed a venderlo o forse è effettivamente un buon software che risolve bene uno specifico problema.

Siamo troppo dipendenti dall’informatica?

Molti osservatori e fantomatici “esperti” hanno affermato l’ovvio. Vero… verissimo… come lo siamo dell’elettricità… e di tanto altro.

Potremmo farne a meno? Forse, ma equivale ad una regressione dal punto di vista evolutivo, tecnologico e pure dal punto di vista economico… quindi inutile discutere l’ovvio.

Change management… questo sconosciuto

Le grosse aziende interessate dovevano avere sistemi di change management per capire cosa è stato fatto… e usare un minimo di relazione causa-effetto. E ovviamente essere in grado di fare un roll-back (ma questo è un altro discorso).

Molte aziende invece venerdì mattina si sono trovati i sistemi bloccati e hanno cercato subito di dare la colpa a chi ha lavorato su questi sistema di recente (quanti consulenti hanno avuto un brutto venerdì mattina?) senza controllare che magari erano stati fatti anche altre modifiche sul sistema (come ad esempio gli aggiornamenti).

Mai lavorare direttamente sulla produzione

Tutte queste grosse aziende dovrebbero avere sistemi di pre-produzione, sistemi di test, “bolle” e/o mille altre soluzioni per testare, provare e validare qualunque tipo di modifica PRIMA di applicarla ad un ambiente in produzione.

Evidentemente molte aziende non testano gli aggiornamenti.

Ma lo stesso vale Crowdstrike che non avrebbe dovuto rilasciare un aggiornamento del genere. Ma purtroppo i problemi accadono (in inglese si usa una frase più colorita in questi casi) e bisogna prevenerli testando in un ambiente che, possibilmente, non sia quello di produzione!

Ci sarebbe poi un’altra regola non scritta che è quella di non applicare modifiche (e in particolare aggiornamenti) di venerdì, se poi non vi vuole rischiare di lavorare tutto il week-end per riparare eventuali danni. Ovviamente non vale in caso di aggiornamenti di sicurezza urgenti.

Quanto successo non era venerdì pomeriggio… era in realtà a cavallo tra giovedì e venerdì… ma poco importa…

DR… ma funziona?

Quasi tutte le grosse aziende impattate dovevano avere una soluzione di disaster recovery (persino a livello di site). Perchè non l’hanno usata?

Forse perchè ritenevano troppo lento applicare il piano di DR… voglio sperare non perchè l’ambiente di DR era afflitto dallo stesso problema o non era disponibile o si riteneva troppo costoso attivarlo!

Sicuramente non avere mai testato un piano di DR o avere un piano di DR poco efficente non aiuta!

I problemi accadono

Come già scritto i problemi possono esserci… bisogna essere pronti a reagire e gestire il roll-back o fare un failover su un ambiente “sano”. O essere bravi a risolvere i problemi in poco tempo… ma questa è più una speranza che una certezza.

Con il senno dei poi sono piene le fosse

Frase fatta, ma che rende l’idea. Il giorno dopo (in realtà già da venerdì) mille post, blog, commenti di “super esperti” che commentavano come non sarebbe dovuto succedere, come siamo legati alla tecnologia, come si stava meglio quando si stava peggio e così via… Purtroppo la disinformazione dilaga, anche se spesso è mancanza di voglia di cercare i fatti… che forse è pure peggio.

Cosa si poteva fare o cosa non si doveva fare, se analizzato in modo oggettivo, può comunque servire a migliorare i processi tecnologici (ma anche quelli aziendali) per evitare che situazioni simili si ripetano in futuro.

Come scritto nel paragrafo precedere, gli errori accadono (e di casi ecclatanti di bug software e/o hardware la storia è piena)… bisogna fare in modo di evitare o almeno mitigarn l’impatto.