Nell’ambito del decreto-legge che introduce misure urgenti per contrastare gli effetti economici e umanitari della guerra in Ucraina approvato nel Consiglio dei ministri n.68 il 18 marzo 2022 ritroviamo all’articolo 28 il testo che impone alle pubbliche amministrazioni che hanno adottato soluzioni commerciali di cybersicurezza di provenienza russa, in particolare prodotti di End Point Detection & Response (EDR) e Web Application Firewall (WAF) di procedere ad una loro diversificazione.
La stragrande maggioranza degli addetti ai lavori ha voluto leggere questo articolo come una estromissione della società Kaspersky dal mercato della cybersicurezza italiano. Ma, a nostro modo di vedere, il testo invece si presta ad interpretazioni molto meno banali e scontate.
Ecco il decreto “Kaspersky”, perché è chiave la sovranità tecnologica
Cosa dice l’articolo 28 del decreto “Ucraina”
Letteralmente l’articolo di legge recita: “…le medesime amministrazioni procedono tempestivamente alla diversificazione dei prodotti in uso.”
Nell’articolo 28 quindi non si parla di sostituzione ma di diversificazione e diversificare non necessariamente implica sostituire. Una pubblica amministrazione che affiancasse a prodotti software EDR e WAF di provenienza russa, soluzioni EDR e WAF sviluppate da altri fornitori non solo non violerebbe il dettato di legge ma rafforzerebbe il proprio sistema di sicurezza.
Premesso che il legislatore ha escluso a priori il fatto che i prodotti in questione possano essere utilizzati per veicolare azioni di sabotaggio cibernetico specificando chiaramente che il rischio considerato è “che le aziende produttrici di prodotti e servizi tecnologici di sicurezza informatica legate alla Federazione Russa non siano in grado di fornire servizi e aggiornamenti ai propri prodotti ”non c’è ragione di dismettere questi prodotti tout-court, affiancargli però un “gemello” che ne verifichi il corretto funzionamento e in ogni momento possa subentrargli è una strategia che può risultare vincente e che dovrebbe essere considerata anche in altri contesti.
Ridondanza e fault tolerance nei sistemi critici
Si chiama ridondanza, è molto nota e usata nel contesto della fault tolerance in sistemi critici, impiegata diffusamente a livello hardware viene usata solo in contesti molto specifici a livello software.
Volendo banalizzare, consiste nell’avere all’interno di un sistema, per ogni funzionalità critica, almeno due programmi diversi che la svolgono. In caso di malfunzionamento di un programma l’altro può continuare a lavorare. Il tutto si basa sul presupposto che la probabilità che due programmi realizzati da team di sviluppo diversi presentino le stesse “debolezze” è del tutto trascurabile.
Detto in altro modo, è il principio della diversità biologica applicato al digitale. Se vogliamo avere la garanzia che un sistema digitale sopravviva a varie forme di attacco/malfunzionamento, la strategia migliore che possiamo adottare è quella di garantire che al suo interno una serie di funzionalità sia svolta da una diversità di sistemi e applicazioni. Difficilmente un attacco informatico è in grado di compromettere contemporaneamente applicazioni e/o piattaforme diverse, ovvero un malfunzionamento si presenterà contemporaneamente nei due ambiti.
Golden Power, super poteri al Governo: ecco gli impatti del decreto Ucraina
Le implicazioni (economiche e non solo) del raddoppiamento delle installazioni software
Certo sono soluzioni che vanno accuratamente studiate. Come sicuramente il lettore avrà intuito, stiamo parlando di soluzioni che richiedono un notevole sforzo economico e gestionale dovendo raddoppiare le installazioni software. Vanno ovviamente ristrette a sistemi e funzionalità più critiche, ma sicuramente l’impatto sia sul budget che sul management non è trascurabile. Un altro problema molto serio da considerare è legato all’incompatibilità tra prodotti, ad esempio nel caso che stiamo analizzando non vedo problemi per soluzioni WAF ridondate, ne vedo per soluzioni EDR che spesso sono mutuamente incompatibili, cioè spesso non è possibile far operare sullo stesso endpoint soluzioni di due vendor diversi.
Il problema della dipendenza tecnologica
Fatti quindi i dovuti distinguo, credo valga la pena approfondire questa strategia che se correttamente applicata consentirebbe di risolvere il problema della dipendenza tecnologica di cui il “caso Kaspersky” è forse il primo caso concreto che il nostro paese si trova ad affrontare, ma che in futuro potrebbe riguardare altri prodotti per i quali magari il mercato non offre alternative immediate come invece accade per il caso in questione. In questi casi, difficilmente si sarebbe potuto pubblicare un articolato come quello che stiamo discutendo, e necessariamente si sarebbe dovuto scendere a patti con il “nemico”. Il caso “gas naturale” insegna.
Non sono poche le voci, sia a livello europeo che a livello nazionale, che si sono sollevate auspicando come unica via d’uscita dal problema della dipendenza tecnologica la cosiddetta “sovranità digitale”. Un obiettivo che però non credo possa essere raggiunto in un arco di 30/40 anni, ammettendo che ci si incominci a lavorare seriamente già dalla prossima settimana.
L’Italia a partire dalla dismissione della Ing. C. Olivetti non ha più esibito alcun piano di sviluppo industriale mirato alle tecnologie ICT e l’Europa nel suo complesso non ha mai stimolato questo tipo di attività. Di fronte all’onda della rivoluzione digitale che ha caratterizzato la fine del secolo scorso sia Europa che Italia sono state alla finestra a guardare. Per guadagnare il tempo perduto sarebbero necessari investimenti significativi, l’apertura di centri di ricerca specializzati, e soprattutto persone capaci e motivate. Vedo molto poco di tutto questo.
Insistere sulla “diversità e compatibilità”
La risposta più efficace e fattiva che l’Europa può dare al problema della dipendenza tecnologica è insistere sulla “diversità e compatibilità”. Sfruttando il suo ruolo di grande acquirente di prodotti ICT, l’Europa deve da una parte esercitare pressione sui produttori affinché per tutta una serie di funzioni tipiche dei sistemi ICT esistano più prodotti in grado di svolgerle e dove questi esistano richiedere la loro compatibilità. Dall’altra deve promuovere tra gli stati membri l’adozione di prodotti software ridondati, per tutti i sistemi che svolgono funzioni critiche. Negli anni addietro si era già tentato di raggiungere almeno in parte questi obiettivi con il ricorso e la promozione dei prodotti open source, nel corso degli anni questo slancio è venuto meno, ma potrebbe essere un ambito da rilanciare sulla scorta di quando sinora detto.
Se si dovesse percorrere questa linea, nel medio termine si potrebbe significativamente ridimensionare il problema della dipendenza tecnologica, si migliorerebbe la qualità dei prodotti incrementando la competitività tra i produttori, si avrebbero sistemi più sicuri e si eviterebbero progetti faraonici dall’esito se non scontato molto incerto.
L’augurio finale è che non vi sia più alcuna guerra per cui ricorrere alla “diversificazione” di servizi e sistemi, ma solo la ricerca del continuo miglioramento della rete e dei suoi servizi per il benessere di tutte le popolazioni.
