Il Cybersecurity Executive Order del presidente Usa detta regole ambiziose per la protezione delle infrastrutture critiche americane ma, come la normativa italiana, manca di un elemento fondamentale. L’approfondimento di Andrea Monti, professore incaricato di digital law, Università di Chieti-Pescara – Originariamente pubblicato da Formiche.net
Il 12 maggio 2021 il presidente Biden ha firmato un Executive Order per incrementare la sicurezza delle infrastrutture (anche) critiche degli Usa.
La strategia americana per la resilienza informatica è composta di sette elementi: maggiore condivisione fra istituzioni e settore privato di informazioni sugli incidenti, miglioramento degli standard di sicurezza adottati nelle istituzioni federali, incremento della sicurezza nello sviluppo software e attribuzione di un “bollino di sicurezza”, istituzione di un tavolo permanente al quale far sedere anche il settore privato per individuare e formulare raccomandazioni al governo, standardizzare le procedure di risposta agli incidenti informatici, aumentare la capacità di rilevarli e quella di reagire alle conseguenze.
In linea di principio, l’impostazione di questo Executive Order è molto simile al (complesso) corpo normativo italiano che regola il funzionamento delle infrastrutture critiche. Anche in Italia, infatti, gli incidenti che colpiscono le infrastrutture critiche vanno comunicati all’apposita struttura istituita nella presidenza del Consiglio e (inspiegabilmente) all’Autorità garante per la protezione dei dati personali, uno specifico organismo (il Centro di valutazione e certificazione nazionale) deve valutare la sicurezza degli apparati e dei software utilizzati nell’ambito delle infrastrutture critiche e il Mise, che già aveva iniziato ad occuparsi di gestione del rischio informatico ha aperto una consultazione pubblica che scadrà il prossimo 6 giugno per decidere come certificare dal punto di vista della sicurezza i prodotti utilizzati nelle infrastrutture di telecomunicazioni nell’ambito delle prescrizioni stabilite dal regolamento europeo 2019/881 sulla sicurezza cibernetica.
Sia l’Executive Order americano sia la normativa europea e la sua prossima implementazione nazionale, tuttavia, trascurano di prendere in considerazione un anello fondamentale della catena di sicurezza: la necessità di rendere chi produce software (anche) penalmente responsabile per la messa in circolazione di programmi difettosi o vulnerabili. In altri termini: a condizione che il tutto non si traduca in inutili complicazioni burocratiche è sicuramente necessario avere controlli sugli apparati utilizzati, procedure comuni di notifica incidente e via discorrendo. Ma se non si garantisce la massima robustezza al primo anello della catena —la sicurezza del software, appunto— tutto ciò che da questo anello dipende sarà ineluttabilmente meno efficace.
Come riconosce espressamente la Casa Bianca
too much of our software, including critical software, is shipped with significant vulnerabilities that our adversaries exploit. This is a long-standing, well-known problem, but for too long we have kicked the can down the road [*. per troppo tempo il nostro software, incluso quello critico, è diffuso con rilevanti vulnerabilità sfruttate dai nostri avversari. È un problema noto, ma che abbiamo trascurato troppo a lungo].
Se, dunque, la vulnerabilità dei software è una criticità —e lo è senza dubbio— sarebbe logico aspettarsi, di conseguenza, l’emanazione di norme che stabiliscano sanzioni pesanti per coloro che non adottano adeguate attenzioni prima di mettere in commercio un prodotto o un servizio. Di queste norme, tuttavia, non si discute né in Europa né dall’altro lato dell’Atlantico. È abbastanza intuitivo capire che stabilire la responsabilità anche penale dei produttori di software avrebbe un impatto clamoroso sull’industria digitale. È anche abbastanza ragionevole pensare che i gruppi di interesse coinvolti vigilino accuratamente per evitare che proposte del genere entrino nell’agenda politica. Tuttavia non si può continuare a far finta che il problema non esista, e accettare un modello industriale basato sull’accettazione acritica del fatto che il software è intrinsecamente difettoso, e che l’unico modo di gestire questo problema è affidarsi alle “pezze a colore” (le patch) o alle “versioni successive”. È vero che in software complessi la presenza di errori è inevitabile, ma questo non autorizza a commercializzare prodotti che, come dimostrano gli aggiornamenti frequentissimi, sono evidentemente mal progettati.
Sanzionare penalmente chi produce software vulnerabile — anche prevedendo il divieto di contrattare con la pubblica amministrazione — servirebbe anche a “sanare” l’enorme parco informatico attualmente utilizzato da istituzioni e importanti soggetti privati. A poco servirebbe, infatti, limitarsi a certificare prodotti e programmi di futuro impiego, se nel frattempo non si fa nulla per quelli già in uso e che non verranno sostituiti nel prossimo futuro.
Come ricorda efficacemente il presidente Biden, non possiamo continuare a tergiversare sul tema delle vulnerabilità che affliggono i software. Ritardare la presa di coscienza che senza delle basi solide qualsiasi infrastruttura, non importa quanto grande, è destinata a crollare è il miglior modo perché il disastro accada.
Chiedere al Colosso di Rodi per informazioni.
Possibly Related Posts:
- Chi ci protegge dal dossieraggio tecnologico?
- Webscraping e Dataset AI: se il fine è di interesse pubblico non c’è violazione di copyright
- Perché Apple ha ritirato la causa contro la società israeliana dietro lo spyware Pegasus?
- Le sanzioni UE ad Apple e Google aprono un altro fronte nella guerra contro Big Tech (e incrinano quello interno)
- La rottura tra Stati e big tech non è mai stata così forte