All’indomani di un weekend che sarà a lungo ricordato da tutti i dipendenti e responsabili della funzione IT, costretti a straordinari e rientri forzati per ripristinare i sistemi colpiti dal bug dell’aggiornamento CrowdStrike, vale la pena fissare alcuni punti su cui riflettere sullo stato delle nostre infrastrutture e capire come evitare che un incidente simile possa ripetersi in futuro.

Il tutto anche in previsione di normative sempre più stringenti come NIS 2 e DORA che impegnano i dirigenti delle aziende, e non solo quelli della funzione IT, ad attuare strategie che rendano i servizi informativi resilienti a qualsiasi attacco o incidente.

Un’analisi più approfondita deve essere rimandata a quando saranno più chiare le cause dell’incidente, al momento non ancora ufficializzate. Di sicuro, la causa non deve essere ricercata solo nella tecnologia, ma soprattutto nelle procedure organizzative che hanno consentito a un update difettoso di essere inviato a milioni di pc e server in tutto il mondo.

In molti in questi giorni avranno rivolto pensieri che vanno dalla compassione alla maledizione pluri generazionale nei confronti del programmatore che ha scritto la riga di codice incriminata, ma di sicuro non è il solo responsabile. Ci devono essere misure di test e controllo che impediscano l’errore, che prima o poi succede a tutti, e anche il dolo eventuale.

Oltre agli aspetti tecnologici e organizzativi, sarà necessario anche riflettere sulle questioni di responsabilità legale e sull’efficacia e attuabilità delle norme, e su loro possibili effetti contradditorie e controproducenti.

Il single point of failure

Possibile che un piccolissimo file, forse solo una riga di codice, abbia causato così tanti danni? La ricostruzione attuale identificherebbe il problema in un’eccezione di memoria, forse dovuta a un mancato controllo nell’utilizzo di un puntatore. Questo avrebbe scatenato un blocco del sistema con schermata blu e – visto che i sistemi di sicurezza vengono caricati all’inizio della fase di boot – impedito anche il successivo riavvio della macchina.

Una volta capito il problema è stata trovata una soluzione semplicissima in teoria (riavviare in Safe mode e rimuovere un file), che si è però rivelata molto più complicata nella pratica. Innanzi tutto, richiede comunque che l’operazione sia eseguita da un amministratore di sistema, e già questo è un problema per chi gestisce centinaia o migliaia di client. Nel caso in cui il computer non fosse raggiungibile con strumenti di amministrazione remota, è stato necessario mettere fisicamente le mani sul pc.

Alcune delle aziende che utilizzano la cifratura del disco Bitlocker, come è ragionevole fare per maggiore sicurezza, si sono trovate poi un ulteriore problema: le chiavi di sicurezza per poter fare le modifiche necessarie sono distribuite dal server Active Directory/Entra ID. Che in alcuni casi era down per lo stesso problema che affliggeva i client. Davvero una situazione difficile per molti sistemisti.

È normale che i passeggeri delle linee aeree, i clienti delle banche o degli altri servizi colpiti se la siano presa in prima battuta con chi stava negando loro una prestazione, ma c’era davvero poco che le aziende colpite potessero fare.

File di questo tipo vengono diffusi anche più volte al giorno per garantire una pronta risposta ai nuovi attacchi

È importante notare che l’aggiornamento non riguardava l’eseguibile dell’agent CrowdStrike Falcon Sensor, che avrebbe potuto essere esaminato dagli amministratori IT prima della sua distribuzione sui client, ma un file con le informazioni su come rilevare e contrastare un nuovo attacco. File di questo tipo vengono diffusi anche più volte al giorno, cosa che garantisce una pronta risposta ai nuovi attacchi.

Linguaggi obsoleti e problemi dei sistemi operativi

Alcuni analisti ritengono che l’uso di linguaggi di programmazione vecchi come C++, utilizzato sia da CrowdStrike che da Microsoft per il kernel di Windows, sia parte del problema, perché non offrono sufficienti protezioni contro un utilizzo improprio della memoria da parte del programmatore. Un problema evidenziato anche dalle autorità USA per la cybersecurity, e che è tanto più grave in un prodotto di security, che – come dicevamo – agisce a un livello molto basso del sistema operativo, a livello del kernel.

Proprio l’accesso diretto al kernel di Windows è al centro della polemica più recente: un portavoce Microsoft ha dichiarato al Wall Street Journal che il motivo per cui i vendor di sicurezza possono interagire con il kernel di Windows a un livello così profondo è dovuto a un accordo stretto con l’Unione Europea, che ha chiesto a Microsoft di garantire ai concorrenti lo stesso livello di accesso di cui dispone Defender, il servizio di cybersecurity della casa. Sarà, ma Apple nel 2020 ha preso una strada diversa, prevedendo per le soluzioni di sicurezza l’uso di estensioni al sistema operativo che agiscono nello spazio utente, e non nel kernel.

Di chi è la responsabilità?

Mentre il CEO di CrowdStrike George Kurtz è atteso alla Camera USA per riferire sull’incidente, si cominciano a spulciare i contratti e a rileggere i Service Level Agreement per capire chi dovrà pagare il conto del disservizio globale (una curiosità: nel 2010 Kurtz era CTO di McAfee quando un aggiornamento fallato dell’antivirus ha bloccato decine di migliaia di pc in tutto il mondo).

I legali delle aziende colpite dibatteranno a lungo con i CIO riguardo ai contenuti dell’EULA di CrowdStrike, nella cui sezione 8.6 si legge che l’azienda non si assume responsabilità sul fatto che i prodotti siano liberi da errori, che funzioneranno senza soluzione di continuità o che siano adeguati a svolgere una qualsivoglia funzione.

Crowdstrike eula

L’azienda si solleva anche da eventuali danni a cose o persone generati da un malfunzionamento, e specifica che il prodotto non dovrebbe essere usato in sistemi in cui un malfunzionamento può portare a morte o danni fisici (sistemi di supporto vitale, traffico aereo, centrali nucleari eccetera). Assicurare un utilizzo sicuro è quindi responsabilità del cliente.

Chiariamoci: non si tratta solo di CrowdStrike. Formule simili si possono trovare nei termini e condizioni d’uso di quasi ogni software.

La difficile posizione dei CISO, CIO e CEO

Possiamo biasimare i responsabili IT per aver scelto un vendor che Gartner ha posizionato al livello più alto del quadrante 2023 sulla Endpoint Protection, sia come visione che come capacità di esecuzione? No.

Possiamo chiedere di ritardare l’applicazione di aggiornamenti quotidiani, ispezionando e testando ogni singolo file alla ricerca di bug oscuri? Forse, ma al prezzo di ritardarne l’utilizzo e lasciare le aziende esposte alle nuove vulnerabilità.

Quanti di loro hanno il potere contrattuale per stringere accordi con le multinazionali dei software sulle garanzie di servizio che le impegnino a garantire responsabilità normalmente escluse dai contratti?

Eppure la direttiva NIS 2 fa ricadere sui dirigenti delle aziende clienti la responsabilità per la continuità dei servizi, inclusa la selezione dei vendor e dei fornitori e la loro validazione. E, ricordiamolo, NIS 2 non riguarda solo grandi servizi centrali, ma anche l’azienda che fornisce l’acqua al piccolo comune o tutti i fornitori delle aziende che gestiscono servizi critici. Molti di questi fornitori sono piccole imprese o amministrazioni locali.

NIS 2 e DORA sono quanto mai importanti, ma servono strumenti chiari per una loro applicazione inequivocabile

Intendiamoci: norme come NIS 2 e DORA sono quanto mai importanti, e l’incidente CrowdStrike non può che confermarne la necessità. Servono però anche strumenti chiari per una loro applicazione inequivocabile.

Si dice che i confronti tra industria automobilistica e informatica sono spesso fallaci, ma ha ragione il presidente del Clusit Gabriele Faggioli quando sottolinea che la legge non chiede a ogni singola azienda di trasporto, taxista o padroncino di valutare le caratteristiche di sicurezza su strada del veicolo che acquista. Ci sono norme che vincolano i produttori all’adozione di determinate misure, così come strutture centrali di omologazione e procedure per le revisioni periodiche.

Per quanto complicato possa essere, anche l’IT, e in particolare la cybersecurity, deve prendere una strada simile. Qualcosa si muove in questa direzione, anche in Italia con il catalogo di qualificazione dei fornitori cloud di ACN, che dal 1 agosto entrerà nella sua fase ordinaria di funzionamento.

Un passo nella giusta direzione, ma la strada da fare è ancora lunga.

(immagine di apertura: Ali Imron Rosyadi / Shutterstock.com)