Venerdì 19 Luglio 2024 e il crash mondiale di Windows: riflettiamo.

Iniziamo con una delle considerazioni più importanti: Windows è la vittima.
Il colpevole è "Falcon", un software creato dalla CrowdStrike.

Sull'incidente è stato detto un po' di tutto, anche se mancherebbero ancora dei dati tecnici (es.: i file "corrotti" sono della build oggetto dell'aggiornamento o sono la versione precedente?).
In questo articolo facciamo qualche riflessione a voce alta. Obiettivo: impariamo!

Il fatto

Iniziamo ricostruendo l'accaduto; potrebbe non essere chiaro per tutti.
Iniziamo ricordandoci cosa è Falcon e vediamo poi cosa è successo.

1. Cosa è Falcon

Falcon è un agent prodotto dalla CrowdStrike, affermata azienda che si occupa di sicurezza.
Tramite questo piccolissimo software viene potenziata la sicurezza tramite un'analisi in tempo reale di una serie di dati (accessi, pacchetti della rete, i software cosa fanno a interrogare in rete, ecc...). I dati vengono inviati alla piattaforma cloud di CrowdStrike. Tramite un'analisi vengono scovati attacchi, bug, trend APT, ecc... e vengono create-eseguite le remediation del caso.
La sicurezza viene offerta dalla CrowdStrike come un servizio (analogo a quelli di telemetria della Juniper, Cisco, ecc...) sgravando i clienti da installazioni impegnative (come per gli antivirus), tramite un'applicazione piccola, leggera che impegna pochissima capacità di calcolo e pochissima banda.
Insomma: un bel prodotto, molto efficiente offerto, come target preferenziale, alle applicazioni server e alle aziende con applicazioni di servizio e server.

2. Cosa è successo

L'agent della CrowdStrike viene aggiornato automaticamente come succede con i database dei nostri antivirus; quindi un'operazione automatica e trasparente.
Dalla pagina di fixing pubblicata dalla CrowdStrike un paio di piccoli file binari del software Falcon erano difettosi.
Questi file erano in un pacchetto di aggiornamento (automatico) diffuso il 19 luglio. Mano a mano che l'aggiornamento si è diffuso e installato una serie di computer sono andati in blocco e riavviando si bloccavano mostrando il classico blue screen dei crash Windows.
Il problema è stato bloccante solo sui sistemi Windows server e desktop. Non era bloccante (e sembra nemmeno problematico) sui sistemi Mac, Linux e Unix.

No è stato un attacco informatico, ma un evento (imponderabile?) informatico.

Proviamo a pensare

L'evento è d’oro per alcune riflessioni.
Partiamo dalla prima evidenza che etichettiamo come "supply chain". Seguiamo con qualche pensiero sul "DevOps" (ovvero il processo di creazione e distribuzione degli aggiornamenti). Due pensieri li dedichiamo anche alla "Sistemistica". Chiudiamo con due pensieri sulla "Resilienza" vista anche la (quasi) concomitanza tra la NIS 2 e il blocco causato da Falcon.

1. Supply chain

Forse è più corretto dire "interconnessione" e "interdipendenza":

• la rete, grazie soprattutto all'aumentata banda e alla sua (quasi) stabilità, è un requisito per i nostri file collocati nel cloud (es.: i file su Drive, OneDrive, ecc...), per i nostri cellulari (cf. agende, rubriche, app, ecc...) e, da qualche tempo, requisito per il funzionamento di tanti servizi al dettaglio (es.: pagamenti con il POS, i servizi postali, i servizi PagoPA, ecc...);
• l'evento ha reso ancora evidente che la supply chain è articolata in modo profondo e diffuso tanto da causare blocchi, disagi e disfunzioni per un'estensione imprevedibile coinvolgendo anche funzioni e servizi estranei al fatto originario;
• in prima osservazione sembra persistere una progettazione ed una architettura dei servizi di/in rete che non prevede un funzionamento off-line (magari di emergenza) come era già avvenuto con il famoso blocco di tutte le reti di pagamento italiane e, precedentemente, di pagamento dei bollettini postali;
• sembra ancora persistere una fiducia a-critica e non compensata in un "mistico" potere magico della rete di sopravvivere, funzionare e garantire servizi difronte ad ogni evento;
• infine è evidente il pensiero e l'organizzazione, anche per servizi quasi critici e strategici, che problemi derivanti dalla supply chain sono così improbabili da essere non presi in considerazione.

2. DevOps - CI

Entriamo in un campo minato in quanto molto ampio e decisamente variegato.
Il DevOps è tutto il mondo dello sviluppo software con tutto quello che comprende, mente il CI (Continuous Improvement) à il miglioramento e la crescita continua del software.
La tecnologia dello sviluppo continuo è studiata da decenni. Dopo i primi passi incerti è cresciuta in una forma di scienza solida, con pratiche vincolanti e con svariate tecnologie che rendono sicura la creazione e la distribuzione delle versioni anche con meravigliose tecnologie che automatizzano il rollback difronte all'imponderabile:

• una prima spontanea riflessione è che c'è stato un errore nella catena di creazione dell'aggiornamento, testing e deploy: errore umano?
• tutte queste operazioni sono quasi completamente automatizzate:
  • l'ecosistema di DevOps e CI potrebbe essere stato imperfetto: la CrowdStrike potrebbe essere anche lei una parte lesa;
  • sono stati imposti dei salti negli automatismi impedendo la rilevazione del problema;
  • un errore umano è verosimile se l'ecosistema DevOps e CI della CrowdStrike permette la manipolazione e/o l'interpolazione.

3. Sistemistica

• Nella teoria dei sistemi operativi una delle caratteristiche di un OS server solido è la capacità di separare l'applicazione del kernel (=cuore) del sistema operativo per impedire il blocco delle macchine. Decisamente interessante osservare che i soli sistemi Windows hanno subito un blocco. Questo lascia pensare a solo due ipotesi: Windows continua ad avere un fianco debole nell'isolamento delle applicazioni e degli user-space o i file "difettosi" hanno operato su delle istruzioni-combinazioni di comandi istruzioni primitivi del tutto imprevedibili (insomma: uno zero-day);
• nel tempo sono state messe appunto diverse tecniche per scongiurare questi eventi (il controller di un reattore nucleare e del sistema avionico di un aeromobile non possono permettersi eventi del genere!):
  • potremmo riflettere sulla preparazione e formazione degli sviluppatori e degli architetti senior: conoscono queste "alternative"?
  • potremmo riflettere sul fatto che approcci come container, flatpack, snap, ecc... non siano l'approccio standard per servizi-applicazioni critiche;
• è opportuno osservare e porci alcune domande su come i sistemi colpiti non siano stati "ripristinati". Anche in questo caso entriamo in un campo ambio, variegato e complesso. La CrowdStrike ha diffuso la prima remediation circa dopo 30 minuti dall'inizio dal provisioning dell'aggiornamento. Giusto per riflettere:
  • i tecnici senior dei sistemi colpiti che livello di skill hanno e che possibilità hanno per accedere (o essere raggiunti) dagli aggiornamenti dei propri fornitori di software? Teniamo presente che Falcon è un software a pagamento con tanto di Knowledge base, canali di messaggistica istantanea, canale di chat, ecc... con tanto di SLA a contratto;
  • sempre guardando alle strutture colpite dal blocco il disaster recovery richiedeva tempi lunghi (pertanto i disservizi ci sono stati per un certo tempo malgrado il ripristino) o c'è stato un problema nel disaster recovery (es.: non lo abbiamo previsto perché abbiamo tutto in outsourcing)?

4. Resilienza

• Varie normative, a partire dagli approcci "best practices" alla recentissima NIS 2, prevedono la "business continuity" come requisito fondamentale:
  • in questo evento del 19 luglio diverse aziende hanno evidenziato una grande debolezza in questo lato di resilienza;
  • sarebbe interessante verificare se le varie certificazioni sono una compliance di documenti o se i documenti riflettono una robusto sistema hardware-software-organizzativo capace di resilienza;
• il requisito di "business continuity" (o resilienza) richiede dotazioni e organizzazioni un po’ più complesse e un po' più costose:
  • non sono state implementate per mero calcolo probabilistico?
  • sono state sacrificate per insufficiente skill degli ingegneri IT?
  • sono state la moneta di scambio tra committente e fornitore per vincere le gare di appalto?

Conclusione

Approdando a una conclusione su questa libera condivisione di ragionamenti fatti a voce alta è doveroso aggiungere ancora che parliamo di uno scenario oggi molto, molto complesso; soluzioni e semplificazioni tranchant sono sempre sbagliate (o almeno inadeguate).

Venendo al dunque stupisce l'accaduto:

• abbiamo avuto nel passato più casi simili. Notori a tutti i problemi prodotti da alcuni aggiornamenti Windows nel passato;
• emerge con una evidenza assoluta il livello di interdipendenza tra i servizi tanto da produrre una inter-interruzione colposa.

Pertanto ci possiamo chiedere perché non abbiamo ancora imparato dai problemi avuti in passato: a volte furono per l'ingenuità e la poca conoscenza in materia IT. A volte per destrezza dei delinquenti (vedi il caso SolarWinds, tanto per citare un fatto che ha avuto un esteso impatto mondiale).

Per chi lavora nei grandi sistemi e nei sistemi critici o strategici è notorio che i servizi vanno progettati ipotizzando una serie di condizioni avverse tra cui il crash dell'applicazione, l'assenza di connessione o la presenza di latenze importanti. Le soluzioni esistono anche se in diversi casi non si può risolvere, ma solo mitigare il problema (se manca la connessione non posso lavorare in sincrono sul cloud, ma posso lavorare in asincrono).
L'evento del 19 evidenzia che diversi lavorano e investono sacrificando l'implementazione asincrona quando è possibile.

Risulta piuttosto appariscente che è più importante di prima gestire i servizi IT adottando anche gli approcci di resilienza, proprio come prescrive la recente NIS 2.
Di converso il grande entusiasmo a favore del cloud, della rete, dei servizi via Internet e delle varie aziende che fanno da broker vanno gestiti insieme a dotazioni in grado di lavorare offline. I cloud delle pubbliche amministrazioni da qualche hanno hanno iniziato un ritorno a soluzioni on-premise e ibride. Anche il mondo della ricerca, dopo qualche prova, investe soprattutto in soluzioni on-premise (per storage, servizi e broker di dati).
Insomma: ottima la rete, ma realizziamo pensando che la rete può non esserci (NB; accadono ancora e non sono per nulla rari i casi di barche che inavvertitamente strappano le fibre sul fondo del mare isolando nazioni o intere aree geografiche).
Potremmo dire; buono i cloud, meglio il servizio on-premise anche se cosa di più.

Insomma: questo evento ci ha aiuta a imparare o è destinato a diventare solo un check in più sull'elenco degli item per qualche compliance?