Finalmente, si direbbe.
Troppe falle di sicurezza, troppi attori malevoli che hanno avuto vita facile in questi anni. Da qui a non molto, infatti, bisognerà mettere in piedi comprovate procedure di tracciamento per dimostrare che il software è stato realizzato in un ambiente sicuro, secondo buone pratiche di sviluppo e test; e si dovrà rendere conto della provenienza dei codici sorgente, dandone riscontro con artefatti standardizzati. Ed infine si dovrà dare atto all’utenza non più solo delle condizioni d’uso, ma aggiungere una etichettatura di sicurezza ed una SBOM (Software Bill Of Materials): la distinta base che ne elenca le componenti e la provenienza.
Insomma, andare a comprar software finirà con l’essere molto simile a quando dobbiamo acquistare la nuova lavatrice, attenti a verificare l’etichettatura energetica per verificare i consumi di corrente elettrica o l’inquinamento acustico; oppure analogamente a quando ci aggiriamo tra le corsie dei supermercati, intenti a verificare la tabella degli ingredienti dei biscotti alla ricerca di quelli più sani, genuini, a chilometro zero, con meno calorie e senza allergeni. Oppure ancora quando al ristorante siamo alla ricerca della bottiglia di vino di qualità, richiedendo quella DOC piuttosto che che quella contrassegnata da una Denominazione di Origine Controllata e Garantita.
Ma andiamo con ordine e proviamo a capire cosa sta accadendo. E soprattutto se sarà davvero sufficiente.
Negli ultimi mesi sono stati avviate due iniziative strutturali da parte del Governo americano: la prima, finalizzata a mettere in sicurezza la catena di fornitura dei software; la seconda, quella diretta a portare l’ambiente tecnologico dei sistemi di controllo industriale ad un livello di cybersicurezza almeno pari a quello che si è oggi raggiunto nei sistemi IT.
La catena di fornitura dei software è oramai molto sviluppata e capillarmente distribuita, tanto che oramai può dirsi che “chiunque fa software”. E nel concetto di “chiunque” vi è quello - correlato - di “indeterminato”, che oggi costituisce la principale vulnerabilità alla base della maggior parte degli incidenti informatici: non solo non sappiamo infatti di chi sia con esattezza la paternità dei software che utilizziamo, al quale eventualmente far risalire responsabilità civili, penali ed amministrative per danno arrecato o per l’avvenuta esposizione a pericoli; ma non sappiamo neanche se questo qualcuno, anche quando abbia agito in buona fede, si sia dotato di risorse, strutture e tecniche operative per sviluppare e provare in sicurezza il prodotto, nonché adeguati controlli che ne impediscano la manomissione.
E tutto ciò, se vale genericamente per tutti i software, assume una valenza decisiva per la categoria dei cosiddetti software critici, cioè quelli che eseguono funzioni di garanzia e di sicurezza, come ad esempio quelli necessari per gestire e verificare i privilegi degli amministratori del sistema o che consentono l’accesso diretto alle risorse di macchina o di rete.
La strategia che si sta mettendo in campo proverà dunque a garantire, con processi ripetibili e comprovabili, queste tre dimensioni: paternità, sicurezza e genuinità. Vediamo come.
Si inizierà a pretendere che i software vengano realizzati in ambienti di sviluppo compartimentati rispetto a quelli in cui verranno successivamente testati, nonché da quelli in cui verranno - a regime - utilizzati; e le informazioni al consumatore dovranno dare evidenza delle procedure di sicurezza utilizzate per assicurare tale segregazione ambientale. Poi, bisognerà impiegare automatismi che permettano sia la verifica della provenienza e dell’integrità dei codici sorgente utilizzati per sviluppare il software, che una costante ricerca delle vulnerabilità e dei relativi rimedi. Ed anche di questo si dovrà dare atto nelle informazioni all’utenza, non mancando di indicare la descrizione sommaria dei rischi valutati e mitigati. Sarà da tenere anche un inventario puntuale dei dati relativi alla provenienza dei codici sorgente o dei componenti dei software non sviluppati in casa, nonché dei controlli implementati e degli audit eseguiti sulle componenti software, sui servizi e sugli strumenti di sviluppo, sia interni che di terze parti. Per quanto possibile, sarà obbligatorio certificare l'integrità e la provenienza del software open source utilizzato all'interno di qualsiasi porzione di un prodotto. Infine si dovrà dimostrare di avere in piedi un sistema di controllo interno che sia in grado di divulgare per tempo le vulnerabilità rilevate nei software prodotti.
All’esito o a complemento delle azioni sopra indicate, bisognerà creare le etichette di sicurezza e le distinte base per i consumatori.
E’ da attendersi che tutto ciò migliorerà sensibilmente la tracciatura della provenienza, dell’integrità e della sicurezza dei software, ma determinerà anche un aumento significativo dei costi di realizzazione e dunque dei prezzi al pubblico.
Ma l’uomo comune, con il divario digitale che caratterizza la cultura di massa attuale, abituato com’è a scaricare software “craccato” a costo zero dal web, sarà disposto a spendere cifre sensibilmente diverse per acquistare tal fatta di software sicuro? Abbiamo bisogno di agire in parallelo affinché, di pari passo con la messa in sicurezza della supply chain dei software, si agisca per creare nuove consapevolezze di igiene digitale tra chi, di quei software, dovrà avvertire la necessità.
Orazio Danilo Russo e Carlo Mauceli
Per approfondire:
https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
Nessun commento:
Posta un commento