Michele PinassiTL;DR La sicurezza delle soluzioni software (e hardware) passa necessariamente dalla possibilità d’ispezionarne l’interno, il codice sorgente, per analizzarne il funzionamento alla ricerca di potenziali criticità. È evidente, quindi, che il software opensource dovrà essere la scelta privilegiata per le PA italiane, nell’ottica di rafforzare la sicurezza cyber del perimetro nazionale.
Nelle pieghe del Decreto Legge n. 21 del 21 marzo 2022 “Misure urgenti per contrastare gli effetti economici e umanitari della crisi ucraina.“, all’art. 29, sembra esserci un velato riferimento, poi ripreso anche da alcune testate giornalistiche come Cybersecurity Italia, a una circolare dell’ACN che dovrebbe indicare alle PA hardware e software “sicuri”.
Circolare che dovrebbe contenere la risposta alla domanda che, purtroppo, gli addetti ai lavori si son sentiti rivolgere nelle ultime 48 ore (“tolgo Kaspersky. Che antivirus metto, ora?“) ma, soprattutto, definire finalmente un bel catalogo di soluzioni hardware e software considerate sicure dell’Agenzia Cybersecurity Nazionale.
Sarà la volta buona che, come previsto dal Decreto legge del 7 marzo 2005, n. 82, comunemente conosciuto come CAD, “Codice dell’Amministrazione Digitale”, le PA procederanno a effettuare l’analisi comparativa prevista, privilegiando soluzioni sviluppate in house, di cui detengono i sorgenti o, proprio, a sorgente aperto?
Già, perché nel CAD, all’art. 68 “Analisi comparativa delle soluzioni”, è chiaramente indicato che:
1. Le pubbliche amministrazioni acquisiscono programmi informatici o parti di essi nel rispetto dei principi di economicità e di efficienza, tutela degli investimenti, riuso e neutralità tecnologica, a seguito di una valutazione comparativa di tipo tecnico ed economico tra le seguenti soluzioni disponibili sul mercato: a) software sviluppato per conto della pubblica amministrazione; b) riutilizzo di software o parti di esso sviluppati per conto della pubblica amministrazione; c) software libero o a codice sorgente aperto; d) software fruibile in modalità cloud computing; e) software di tipo proprietario mediante ricorso a licenza d'uso; f) software combinazione delle precedenti soluzioni. 1-bis. A tal fine, le pubbliche amministrazioni prima di procedere all'acquisto, secondo le procedure di cui al codice di cui al decreto legislativo n. 50 del 2016, effettuano una valutazione comparativa delle diverse soluzioni disponibili sulla base dei seguenti criteri: a) costo complessivo del programma o soluzione quale costo di acquisto, di implementazione, di mantenimento e supporto; b) livello di utilizzo di formati di dati e di interfacce di tipo aperto nonché di standard in grado di assicurare l'interoperabilità e la cooperazione applicativa tra i diversi sistemi informatici della pubblica amministrazione; c) garanzie del fornitore in materia di livelli di sicurezza, conformità alla normativa in materia di protezione dei dati personali, livelli di servizio tenuto conto della tipologia di software acquisito. 1-ter. Ove dalla valutazione comparativa di tipo tecnico ed economico, secondo i criteri di cui al comma 1-bis, risulti motivatamente l'impossibilità di accedere a soluzioni già disponibili all'interno della pubblica amministrazione, o a software liberi o a codici sorgente aperto, adeguati alle esigenze da soddisfare, è consentita l'acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d'uso. La valutazione di cui al presente comma è effettuata secondo le modalità e i criteri definiti dall'AgID.
In merito alla circolare di cui si parla al comma 1-ter, una ricerca sul web ha resuscitato la Circolare 6 dicembre 2013 n.63 –Linee guida per la valutazione comparativa prevista dall’art. 68 del D.Lgs. 7 marzo 2005, n. 82 “Codice dell’Amministrazione digitale”– che, al punto 3.3.5 “Garanzie del fornitore in materia di livelli di sicurezza“, indicava in modo molto lungimirante la strada che la PA avrebbe già dover avuto intraprendere (da anni):
Vien da sé, quindi, la speranza che il catalogo dei software sicuri che l’ACS starebbe (il condizionale è d’obbligo) predisponendo comprenda soprattutto, se non esclusivamente, software open source.
Il motivo è semplice quanto banale: solo analizzando il codice sorgente del software è possibile capirne esattamente il funzionamento e, quindi, stabilire se ha funzionalità potenzialmente pericolose per le infrastrutture informatiche nazionali.
Il che vale, ovviamente, anche per i dati prodotti da quelle soluzioni software. Che solo un formato aperto, o comunque noto e pubblico, permette di definire sicuro o meno.
È chiaro che questa analisi deve essere fatta da personale con specifiche competenze, in grado di analizzare, comprendere e valutare il codice sorgente sottoposto all’attenzione: un lavoro assolutamente non banale ma che rappresenta l’unica strada per poter definire sicura una certa soluzione software.
Banalizzando, per riuscire a farmi capire anche da chi non è esperto del settore, è come se dovessimo valutare la sicurezza e l’affidabilità di una flotta di veicoli: oltre a dover chiedere a chi ha specifiche competenze (es. meccanici, ingegneri, progettisti), è anche necessario che il cofano dei veicoli sia apribile per poterne ispezionare l’interno. Analogamente a una soluzione software proprietaria, chi dichiarerebbe sicuro un veicolo per il quale non può neppure aprire il cofano motore?
Per finire, chissà se questo terribile momento storico porterà i Paesi a considerare la sicurezza del software (e il DL 21 del 21.03.2022 va proprio in quella direzione, seppure in un modo che reputo discutibile e parziale) come una priorità da perseguire a ogni costo (ma con innumerevoli vantaggi).
P.S. Vale la pena ricordare che con l’ultima modifica al CAD, attuata dal DL “Semplificazioni-BIS” del maggio 2021, è stato introdotto l’art. 18-bis “Violazione degli obblighi di transizione digitale” che da all’AgID poteri “di vigilanza, verifica, controllo e monitoraggio sul rispetto delle disposizioni del presente Codice e di ogni altra norma in materia d’innovazione tecnologica e digitalizzazione della pubblica amministrazione, ivi comprese quelle contenute nelle Linee guida e nel Piano triennale per l’informatica nella pubblica amministrazione“.
N.B. nell’articolo non ho parlato della parte hardware, più difficile da verificare e analizzare. Esistono tuttavia iniziative interessanti in tal senso, come la OpenHardware.io, che puntano sulla progettazione aperta e liberamente disponibile delle componenti hardware. Al momento, però, siamo ben lontani da avere una “massa critica” in tale ambito, purtroppo.
Hai imparato qualcosa di nuovo?
