L’incidente di CrowdStrike ha messo in evidenza in modo dirompente il tema della nostra dipendenza dai sistemi informativi e, nello stesso tempo, la criticità data dalla prevalenza in tanti ambiti di pochi fornitori a livello globale.
Si tratta di una combinazione particolarmente tossica dal punto di vista della continuità operativa delle singole aziende, ma anche in termini di resilienza dei servizi critici a livello europeo e globale.
Indice degli argomenti
CrowdStrike: come si è arrivati al crash globale
Prima di tutto, riassumiamo molto brevemente i fatti come sono noti finora. CrowdStrike opera nel settore della protezione dei sistemi informatici e offre, fra l’altro, un proprio prodotto per la protezione degli endpoint (ovvero i PC delle postazioni di lavoro utente, ma anche i PC dei totem, dei pannelli per gli annunci ecc.).
È un settore non affollatissimo, ma neanche scarso di fornitori. Gartner colloca CrowdStrike come leader in un settore in cui riporta altri sedici nomi, tutte aziende di livello mondiale. Non stiamo quindi parlando di un’azienda da scantinato.
Nonostante questo, venerdì scorso CrowdStrike ha distribuito un aggiornamento difettoso del proprio componente Falcon per la protezione degli endpoint Windows.
Gli strumenti di endpoint protection, per poter proteggere efficacemente i PC, hanno la necessità di integrarsi profondamente con il sistema operativo (in questo caso, appunto, Windows).
La conseguenza del difetto è stata che dove fosse utilizzato quel prodotto di CrowdStrike, Windows ha smesso di funzionare, visualizzando la famigerata “schermata blu” del blocco completo del sistema.
Il problema è stato riconosciuto abbastanza rapidamente e la soluzione temporanea, in attesa della produzione di un aggiornamento corretto, è stata subito individuata e resa pubblica.
Disponibilità di sistemi e servizi: problema non da poco
Però, sempre per poter essere efficaci, gli strumenti antimalware, all’avvio di Windows, sono fra i primi ad essere lanciati, proprio per poter essere già attivi qualora dovesse attivarsi un malware. Il risultato è che, in caso di malfunzionamenti come quello in discussione, la schermata blu è quasi immediata, prima che possa essere avviata qualsiasi azione di rimedio da remoto.
Infatti, nelle aziende in cui si devono gestire centinaia o migliaia di postazioni di lavoro, magari distribuite in diversi edifici o diverse città, gli aggiornamenti non vengono certo installati a mano PC per PC. Si usano, invece, strumenti di amministrazione remota. In questo caso però, la schermata blu arrivava prima che sia avviato lo strumento di amministrazione remota che consente di rimuovere il problema.
I PC devono, quindi, essere in generale sistemati a mano uno per uno e di qui i tempi lunghi dell’incidente, pur conoscendo da venerdì mattina sia il problema sia la soluzione.
Si vede, quindi, che non ci sono stati attacchi e il problema è esclusivamente di disponibilità dei sistemi, e quindi dei servizi che li utilizzano. Che, però, non è un problema da poco.
Come prevenire e contenere incidenti simili
La distribuzione di aggiornamenti è notoriamente un momento critico, in cui si possono creare disservizi ai clienti.
Per questo, qualsiasi software house dignitosa investe tempo e risorse in procedure approfondite di verifica degli aggiornamenti prima di distribuirli.
Eppure, anche dove le verifiche sono attente, i problemi ci sono, seppure normalmente non così gravi e diffusi, a causa della complessità dei sistemi, del software e dei contesti di installazione.
Dove possibile, si seguono anche procedure che prevedono una distribuzione graduale, in modo da intercettare su un piccolo gruppo di utenti i problemi che si dovessero verificare, prima di distribuire l’aggiornamento alla totalità dei clienti.
Questa soluzione, però, è complessa per gli aggiornamenti ed i prodotti di sicurezza, dove la tempestività è fondamentale.
È utile quindi riflettere su cosa si possa fare per prevenire, e poi contenere, incidenti di questa gravità, o anche peggiori, in una logica di resilienza dei sistemi critici rispetto ad incidenti nella propria supply chain.
Superare la dipendenza da pochi fornitori
La prima criticità è certamente la dipendenza da pochi fornitori: incidenti derivanti da uno di essi può avere conseguenze molto ampie.
Da questo punto di vista, il caso di CrowdStrike non è neanche quello peggiore: pensiamo a quanto pochi e dominanti sul mercato siano i fornitori di processori, di sistemi operativi, di piattaforme cloud, di suite di office automation, ma anche di soluzioni verticali in un gran numero di contesti.
In ognuno di questi casi, un problema diffuso potrebbe avere conseguenze difficili da gestire.
Non solo: le dipendenze esistono anche fra i fornitori stessi, basti pensare ai pochi e critici fornitori di soluzioni di virtualizzazione.
Naturalmente, il problema è noto anche a queste stesse aziende, e ci si aspetta che facciano il possibile per ridurre il rischio.
Basare la sicurezza delle nostre infrastrutture critiche su un’aspettativa, però, non è sano. Per questo, a livello europeo è in fase di approvazione, seppure con qualche rallentamento, il Cyber Resilience Act, che interesserà qualsiasi prodotto connesso, sia hardware o software, assicurando che determinati aspetti siano effettivamente garantiti, compresa ad esempio la minimizzazione del loro impatto negativo sulla disponibilità dei servizi forniti da altri dispositivi o reti[1].
Questo regolamento, una volta approvato, richiederebbe ai produttori, importatori e distributori di dare adeguate garanzie su un gran numero di temi di sicurezza prima di poter immettere un prodotto sul mercato europeo.
Il punto è, però, che anche dove i controlli siano attenti, e nessuno finora ha messo in discussione la gestione di CrowdStrike, questi incidenti possono accadere e accadono.
Non basta, quindi, assicurare che la probabilità di incidenti di questo tipo sia quanto minore possibile, serve anche poterne limitare le conseguenze.
Essere in grado di mantenere i processi critici “a mano”
Quando si parla di resilienza, un concetto fondamentale è avere soluzioni alternative. Un modo per avere soluzioni alternative a sistemi informatici non disponibili è, ad esempio, essere in grado di mantenere i processi più critici “a mano”, seppure a un livello di servizio peggiore.
Lo abbiamo visto venerdì, quando il personale di alcuni aeroporti riportava le informazioni sui voli a mano su lavagne, ma in alcuni contesti sono procedure acquisite in modo più generalizzato.
Negli ospedali, ad esempio, dove il problema sia stato affrontato, esistono procedure manuali per gestire a mano almeno le attività essenziali dei pronto soccorso, delle sale operatorie e delle terapie intensive.
Questo, naturalmente, non vuole dire che si possa fare ameno dei sistemi informativi, vuole dire però che si possono evitare le conseguenze più gravi, almeno per un tempo limitato.
Non vuole neanche dire che tutti gli ospedali siano pronti allo stesso modo a gestire queste emergenze: purtroppo, il livello di preparazione può variare molto da caso a caso.
Non tutte le aziende sono però preparate a questo tipo di gestione e, soprattutto, non tutte le attività critiche possono ormai essere gestite a mano.
Attraverso i sistemi informatici gestiamo da anni una complessità che prima era impensabile, e credere che si possa tornare a fare tutto a mano, seppure in emergenza, non è realistico. Anche quando è possibile, inoltre, si tratta comunque di gestire problemi limitati nel tempo, tipicamente a poche ore o al più a qualche giorno.
È anche bene sottolineare che si tratta di una gestione in emergenza, quindi con maggiore probabilità di errore, tempi più lunghi e minore capacità. In un ospedale, ad esempio, vuole dire minore livello delle cure e maggiore rischio per la salute dei pazienti.
Diversificare le risorse e le forniture
Ma una forte dipendenza da fornitori esterni può portare a interruzioni di durata anche maggiore.
La seconda soluzione importante è quindi la diversificazione: dove si ha una forte dipendenza da una risorsa critica, si cerca di diversificare la risorsa o la fornitura.
Ad esempio, una manifattura che dipenda da una fornitura di una materia prima, cercherà di avere almeno due fornitori, magari da due aree geografiche diverse, in modo che in caso di problemi con un fornitore o in un’area geografica, sia disponibile un’alternativa.
Il prezzo di questa scelta, naturalmente, è una complessità di gestione maggiore ed una minore efficienza in termini di costi.
Serve una strategia resiliente sul lungo termine
Spostandoci più nell’ambito dei sistemi informativi, l’utilizzo di soluzioni di disaster recovery attraverso un datacenter secondario o un servizio in cloud, corrisponde di nuovo ad avere un’alternativa in caso di indisponibilità del datacenter principale.
In questo caso, è ancora più evidente il problema principale, che è il costo di una duplicazione che difficilmente può avere l’efficienza della concentrazione delle risorse su un unico datacenter.
La tendenza all’efficienza, in effetti, porta spesso a sistemi più fragili dal punto di vista della resilienza, si pensi alle logiche di efficienza dietro concetti come il “just-in-time”, messe in crisi pochi anni fa dalla crisi della logistica mondiale.
Potremmo dire con una certa approssimazione che logiche di gestione che puntano all’efficienza sul breve o medio periodo portano facilmente a sistemi fragili sul lungo periodo, e questa tendenza va costantemente mitigata con azioni di governo che garantiscano una strategia resiliente sul lungo termine, ad esempio accettando, per rimanere sull’esempio delle materie prime, una minore efficienza in termini di prezzi e magazzino, a favore di una maggiore resilienza a problemi di approvvigionamento.
Superare la tendenza all’efficientamento “fragile”
Se per certi tipi di fornitura il ragionamento può essere relativamente semplice, seppure mai banale, e comunque sempre costoso, quando si parla di prodotti e servizi, software in particolare, il ragionamento si fa particolarmente complesso.
Innanzitutto, la tendenza all’efficientamento “fragile” si vede ad esempio quando un’azienda sposa completamente una piattaforma di servizi cloud, portandovi tutti i propri servizi, o quando decide di utilizzare un unico fornitore di sistema operativo per tutti i propri sistemi.
A livello più ampio, lo si vede con la prevalenza di alcuni fornitori su interi mercati. Ma proprio qui si vedono anche la complessità e costo delle alternative.
Supponiamo, ad esempio, di prevedere che parte delle postazioni di lavoro utilizzabili per i servizi più critici di un’azienda sia basata Windows, e una parte sia basata su Linux (in questi giorni, le battute sui sistemi Linux che non sono stati toccati dall’incidente si sono sprecate).
Avere postazioni di lavoro Windows e Linux vorrebbe dire avere utenti che riescono a utilizzare interfacce Windows e Linux (comunque diverse anche quando simili), applicazioni che possono essere eseguite sia su Windows che su Linux, tecnici che sanno gestire sistemi Windows e Linux è abbastanza evidente non solo il tema dei costi, ma anche quello della maggiore complessità, e la complessità a sua volta è fonte di errori.
Per di più, siamo in un momento in cui è già difficile trovare le competenze per gestire i sistemi informativi così come sono, senza maggiori complessità. Probabilmente, l’azienda si troverebbe con buone competenze su uno dei due sistemi, e una gestione scadente sull’altro.
Non solo: se un’azienda ha scelto un prodotto, in generale è perché lo ha valutato come più adatto alle proprie esigenze. Un altro prodotto potrebbe ad esempio non avere tutte le funzionalità necessarie.
La strada della standardizzazione e della portabilità
Insomma, il problema è difficile. Una strada che può aiutare è quella della standardizzazione e della portabilità, che renderebbe meno critica la diversificazione.
Certamente, non ci si possono aspettare soluzioni dai grandi fornitori, per i quali il lock-in dei clienti è una risorsa inestimabile.
Le soluzioni devono, quindi, essere trovate a livello di governo delle infrastrutture critiche, ad esempio a livello europeo.
In questa direzione si muove certamente la Direttiva CER sulle entità critiche, ma il tema è ben più complesso, e richiede di accettare compromessi in termini di costi ed efficienza.
Essere interlocutori forti dei grandi fornitori
Un’ultima considerazione si può fare rispetto all’ipotesi per cui le aziende sarebbero più resilienti tenendo in casa le competenze anziché esternalizzando i servizi, ipotesi che viene sollevata spesso e che è stata naturalmente proposta anche in conseguenza di questo incidente.
Ci sono, al momento, delle economie di scala con le quali neppure le grandi pubbliche amministrazioni, o le grandi imprese per le quali l’ICT non sia il core business, si possono confrontare.
Per tornare a CrowdStrike, nessuna azienda può pensare di gestire in casa un servizio che abbia lontanamente la capacità di contrastare il cyber crime con l’efficacia di un servizio come quello di CrowdStrike.
Se vogliamo parlare di diversificazione, è molto più probabile che un fornitore esterno di gestione delle postazioni di lavoro abbia buone competenze nella gestione di sistemi sia Windows che Linux, piuttosto che sperare che ce l’abbiano le singole aziende o pubbliche amministrazioni.
Naturalmente, parliamo di grandi fornitori. Anche nel settore ICT, in Italia in particolare, c’è il problema della frammentazione in microimprese, dove molte aziende hanno i sistemi informativi gestiti da piccoli fornitori che gestiscono pochi clienti, quindi con poca capacità di avere tutte le competenze necessarie a garantire un livello adeguato di qualità.
Anziché cercare di tenere in casa servizi che non saranno in grado di gestire, le aziende e le pubbliche amministrazioni dovrebbero agire in modo da avere la massa critica necessaria per riuscire ad essere interlocutori forti anche nei confronti dei grandi fornitori, ad esempio attraverso associazioni settoriali e attraverso i governi nazionali ed europeo.
Poi, naturalmente, se si riuscisse ad avere un mercato ICT con più attori europei, i cui interessi siano più facilmente allineati con quelli dell’Unione Europea anziché con quelli di altri paesi, sarebbe una gran bella cosa.
[1] “minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks”, bozza del Cyber Resilience Act, Appendix I, Part I, (2).i.
