In queste ore sta riprendendo faticosamente l’operatività di strutture pubbliche, banche, ospedali, trasporti, emittenza radiotelevisiva di mezzo mondo rimaste bloccate non da un attacco su larga scala di attori ostili o gruppi criminali ma di un errore di programmazione contenuto in un aggiornamento software per il sistema operativo Microsoft Windows veicolato da una multinazionale della cybersecurity, Crowdstrike, in tutte le infrastrutture che utilizzano la componente locale della piattaforma denominata Crowdstrike Falcon.

In sintesi, questo approccio alla gestione della cybersecurity prevede che su ogni singolo computer da proteggere venga installato un componente software che poi interagisce con la piattaforma centralizzata del fornitore, che è anche impiegata per veicolare gli aggiornamenti locali. È proprio il difetto in uno di questi aggiornamenti ad avere causato il blocco dei computer sui quali era installata la componente periferica del sistema di sicurezza. L’aggiornamento si è propagato come un virus, paralizzando così il funzionamento anche dei servizi essenziali che utilizzano la piattaforma in questione.

Questa vicenda fornisce spunti di analisi a più livelli, da quelli strettamente giuridici, a quelli relativi alle scelte strategiche dei decisori unionali in materia di cybersecurity, e alle loro ricadute sui modelli di servizio della gestione della sicurezza dei sistemi informativi.

La responsabilità per il danno da software difettoso

L’aspetto più immediato che balza all’occhio è quello della risarcibilità del danno causato da software difettoso. Benché normativamente il codice civile già stabilisca l’obbligo generale di risarcire il danno causato ingiustamente e le attività di sviluppo software e prestazione di servizi informatici siano sottoposte alle regole della responsabilità contrattuale, in concreto questo risarcimento è difficilmente ottenibile.

Le ragioni sono diverse e complesse, ma possono essere sintetizzate nella difficoltà di individuare —anche se non è questo il caso— l’effettiva responsabilità del produttore del software, nella non semplice prova del nesso fra difetto e danno e, soprattutto, nella capacità di affrontare un contenzioso basato su contrattualistica statunitense, che ammette ampie limitazioni di responsabilità, al punto che un eventuale successo giudiziario potrebbe risolversi in una vittoria di Pirro.

Le criticità dell’approccio UE basato sulla responsabilizzazione degli utenti

Questo stato di fatto, che permane tal quale dagli albori dell’informatica, è sempre stato lontano dall’attenzione dei decisori europei che hanno scelto di responsabilizzare gli utilizzatori degli strumenti software ma non chi li produce. Il caso paradigmatico è il regolamento sulla protezione dei dati personali (ma anche l’articolata normativa europea sulle infrastrutture critiche), il cui sistema di adempimento alle prescrizioni in materia di sicurezza è concepito proprio in questo modo.

Sulla carta, l’impostazione generalpreventiva basata sull’analisi del rischio che caratterizza trasversalmente questi ambiti dovrebbe essere in grado di prevenire eventi del genere. Nel caso specifico di questo incidente, si può addirittura arrivare a ipotizzare una responsabilità prevalente dell’utilizzatore rispetto a quella del produttore perché è una best practice riconosciuta quella di eseguire verifiche di ogni singolo nuovo aggiornamento software da installare prima di procedere concretamente. Dunque, entrando negli aspetti tecnico-giuridici, si dovrebbe verificare il riparto di responsabilità fra la diffusione dell’aggiornamento difettoso e l’omesso controllo della sua potenziale pericolosità; ed è ben possibile che le autorità di controllo possano sanzionare gli enti sottoposti a vigilanza proprio per non avere eseguito queste verifiche preliminari.

Il punto è, tuttavia, che in concreto queste verifiche sono difficilmente esigibili specie quando si parla di infrastrutture tecnologiche complesse o critiche, dove la sicurezza deve essere garantita in tempo pressoché reale. Il che significa, da parte dei destinatari delle norme, privilegiare modelli di gestione della cybersecurity basati sull’esternalizzazione a scapito del controllo diretto ed immediato affidato a una struttura interna.

Anche in questo caso la differenza fra teoria a pratica è rilevante, ma rimane il punto che un modello basato sull’esternalizzazione verso un unico fornitore e sull’automazione delle attività di cybersecurity ha come grossa controindicazione proprio quella della reazione a catena che poi, in caso di incidenti, si traduce in una catastrofe.

La burocratizzazione unionale della cybersecurity

Questa spinta verso la decentralizzazione è stata accelerata dalla mole di adempimenti imposta dalla normativa unionale. Se alle norme già citate aggiungiamo, tanto per citarne alcuni, il regolamento sulla resilienza operativa (DORA), quello sull’AI, il futuro regolamento sulla cyber resilience, gli aspetti di sicurezza dell’EIDAS2 non è difficile rendersi conto della mole di adempimenti da svolgere che spinge alla inevitabile tendenza a privilegiare una conformità puramente formale e a scaricare compiti (ma non responsabilità) su fornitori esterni, preferibilmente extracomunitari e come tali meno raggiungibili dalle autorità nazionali. Questo porta alla creazione se non di un oligopolio, di un mercato nel quale l’offerta è composta da un numero limitato di soggetti. La conseguenza è che se cade uno di questi, si trascina dietro un numero enorme di infrastrutture, creando problemi potenzialmente esiziali all’intero sistema Paese.

L’interdipendenza fra sistemi e reti di comunicazione elettronica

Il tema della concentrazione dei servizi di cybersecurity nelle mani di un numero limitato di soggetti si ripropone tal quale anche nell’ambito delle reti di comunicazione fisica, mobile e satellitare. Un mercato composto da un numero limitato di operatori amplifica le conseguenze di attacchi diretti a una singola infrastruttura o di malfunzionamenti interni o causati, ancora una volta, da un elemento della filiera che consente l’erogazione dei servizi o ancora da un fornitore di tecnologia e software.

Anche in questo caso, dunque, una scelta strategica che limitasse le possibilità di diversificazione tecnologica e spingesse verso una standardizzazione esasperata richiederebbe di essere valutata con estrema attenzione.

Conclusioni

Il caso Crowdstrike evidenzia chiaramente la necessità, da un lato, di prevedere precise responsabilità per i cybersecurity provider ma, dall’altro, l’importanza di tornare a un modello di gestione della cybersecurity meno basato su aspetti formali e più orientato all’attività sul campo.

Questo sarebbe possibile creando un quadro normativo che semplifichi gli adempimenti puramente burocratici, per esempio unificandoli, che agevoli lo sviluppo della ricerca indipendente sulle vulnerabilità di software e sistemi e che dunque spinga le software house a migliorare i propri prodotti sapendo di essere sotto il controllo della comunità della cybersecurity, secondo un modello ampiamente da tempo sperimentato negli Stati Uniti.