Skip to main content

Non solo Kaspersky. Come proteggere (di più) i nostri software

cyber

Il caso Kaspersky, l’antivirus russo usato da metà delle aziende e della Pa italiana, rischia di essere la punta dell’iceberg. C’è un tema di autonomia tecnologica che sarebbe bene affrontare prima che sia tardi. Il commento del prof. Roberto Setola, direttore del master in Homeland Security dell’università Campus Bio Medico

In questi giorni il governo sta predisponendo un decreto d’urgenza per consentire alla Pubblica Amministrazione di poter sostituire con altri prodotti l’oramai famoso antivirus prodotto dalla società Kaspersky. Qualche mese fa, sempre con una decretazione di urgenza, il governo introdusse limitazioni all’utilizzo di prodotti 5G provenienti da produttori non Ue.

In entrambi i casi le motivazioni alla base dei provvedimenti è la paura di quello che c’è, di quello che potrebbe esserci o di quello che potrà esserci in termini di elementi che mutino il comportamento nominale dei prodotti per dare un illecito vantaggio a soggetti terzi, e nello specifico a realtà statuarie che possono esercitare influenza sui produttori di questi sistemi.

La paura è che all’interno delle schede elettroniche e fra le pieghe delle migliaia di righe di codice qualche “manina” possa inserire elementi spuri il cui scopo è quello di esfiltrare illecitamente informazioni, operare come trojan per favorire l’accesso abusivo ai sistemi informativi o anche danneggiare gli stessi.

Tali provvedimenti si aggiungono all’istituzione del Cvcn e del relativo processo di valutazione dei beni e servizi che va proprio nella direzione di verificare la non esistenza di aspetti problematici nei prodotti che vengono acquistati dagli operatori di servizi essenziali. Dovremmo dire finalmente , sottolineando un ritardo nella sua messa a regime rispetto ad una tipologia di minaccia che, se vera, è presente nei nostri sistemi da diversi anni.

Purtroppo, però, anche nella più rosea delle aspettative il Cvcn non è la panacea né può esserlo.

Infatti il Cvcn, anche quando sarà a regime, potrà verificare che hardware e software “nominali” non facciano nulla di anomalo e, forse, che non contengono nulla di improprio. Ma questa verifica non può che essere fatta sulla specifica istanza soggetta a valutazione, può cioè mirare a verificare che non c’è nulla di anomalo nel prodotto AS IS, verifica che se effettuata sui prodotti oggetto di ban molto probabilmente non evidenzierebbe nulla di anomalo alla luce del fatto che nonostante le indagini svolte da diversi attori internazionali nessun elemento oggettivo dell’esistenza di significative falle di sicurezza in questi sistemi è emerso.

Il problema però è avere la certezza che neanche nel futuro questi sistemi abbiano elementi di vulnerabilità indotti. Aspetto questo molto più complesso in quanto occorrerebbe non più limitarsi ad un test in fase di acquisizione, ma ad una attività continua di verifica quanto meno a campione sulle forniture per quel che riguarda l’hardware e un attento monitoraggio degli aggiornamenti per il software.

Aspetto questo tutt’altro che semplice, soprattutto per software quali gli antivirus che richiedono aggiornamenti con cadenza anche giornaliera quanto meno delle firme per non rendere di fatto obsoleto, e quindi inutile, lo strumento.

Questo perché l’impianto del Cvcn non nasce per essere uno strumento contro i fornitori, quanto piuttosto quale elemento per far sviluppare una maggiore cultura della sicurezza in tutti gli attori andando a sollecitarli ad una progettazione e implementazione dei diversi sistemi che adotti il paradigma della security by design, ovvero sull’evitare di introdurre falle di sicurezza.

Il tutto si basa sull’assunto che esista una correttezza di fondo da parte del fornitore, ovvero che sussista un livello di trust. È proprio sulla compromissione di questa fiducia che il governo si è mosso con la normativa 5G e che si sta apprestando a muoversi per il caso Kaspersky.

Purtroppo questa tipologia di interventi non possono che essere a-posteriori, ovvero  successivi nel tempo rispetto all’acquisizione di prodotti  da parte di soggetti che successivamente vengono identificati come non affidabili. È un po’ come chiudere la stalla mentre le mucche stanno uscendo, qualcuna c’è il rischio concreto che sia già scappata.

Per ovviare a questa situazione non ci sono molte alternative rispetto a favorire una autonomia tecnologica nazionale ed europea, attività che però si andrà a realizzare su un orizzonte temporale esteso, non certo nell’immediatezza.

Per altro il problema della garanzia del trust andrebbe applicato non solo al fornitore ultimo, ma esteso a tutta la sua supply chain. Aspetto questo estremamente difficile alla luce della complessità e della globalità delle attuali catena di approvvigionamento che nel corso degli ultimi decenni sono state modellate sulla massimizzazione dell’efficientamento dei costi.

Questo perché l’eventuale manina che inserisce l’elemento spurio potrebbe agire a monte del prodotto finale alterando alcuni componenti,  attività che sarebbe totalmente ignorata da parte del fornitore ultimo che opererebbe in totale buona fede.

Senza però entrare in visioni di autarchia tecnologica che non solo sono irrealistiche ma che non sarebbero neanche in grado di garanti gli obiettivi di sicurezza, occorrono promuovere una cultura della sicurezza che si fondi su una effettiva capacità di cogliere le problematiche di rischio e che si muova nella direzione di limitare gli effetti negativi e di attuare tempestive ed efficaci azioni di reazione. In una parola: sviluppare strategie di resilienza.

Strategie che vedono nel concetto di differenziazione di fornitori, tecnologie, sistemi uno degli strumenti per limitare la possibilità di introdurre vulnerabilità sistemiche.

Tema questo che richiede forse una riflessione soprattutto all’interno della PA dove esigenze di efficientamento e di abbattimento dei costi spingono molto spesso verso l’individuazione di fornitori unici. Forse dovremmo iniziare a ragionare i termini di bilanciamento fra esigenze di efficienza e quelle di sicurezza, ovvero fra costi attuali (quelli dell’acquisto di beni e servizi) e costi futuri (quelli causati dai problemi di insicurezza).


×

Iscriviti alla newsletter