skip to Main Content

I dilemmi della cybersecurity erano già stati predetti nel 1999 in un editoriale inedito

I Dilemmi Della Cybersecurity Erano Già Stati Predetti Nel 1999 In Un Editoriale Inedito

In “Fattore Critico” Giustozzi si preoccupava della “proliferazione di automatismi intelligenti basati su microprocessori embedded”

I problemi attuali della cybersecurity e del settore IoT erano stati già predetti nel 1999. Nell’editoriale inedito “Fattore Critico” su Byte Italia, che si è rivelato profetico. Il commento non uscì mai, in quanto l’editore sospese le pubblicazioni prima dell’uscita del numero 17 della rivista. La firma è del suo fondatore e direttore Corrado Giustozzi, una delle massime autorità cybersecurity in Italia e – tra le altre cose tra i responsabili del Computer Emergency Response Team della Pubblica Amministrazione (CERT-PA) di AgID, nonché membro del Permanent Stakeholders’ Group ENISA. “Una volta mi fidavo dei computer. In realtà mi fido abbastanza di loro anche oggi, almeno in determinate situazioni – scriveva il giornalista -; tuttavia l’idea che ormai vi siano microcomputer in quasi tutti i dispositivi elettronici, e che questa proliferazione di automatismi ‘intelligenti’ basati su microprocessori embedded non sia destinata a diminuire ma, anzi, ad estendersi, inizia a preoccuparmi un po’”.

Il cyber esperto: Il problema vero è nei modelli e paradigmi dello sviluppo del software

“’Uffa’, dirà qualcuno, ‘la solita tiritera contro l’inaffidabilità dei PC, le solite rievocazioni nostalgiche di quanto si stava meglio col DOS o l’Apple II e 64K di RAM’ – aveva proseguito Giustozzi -. No, tranquilli. Questa volta non me la prendo coi PC, che oramai è diventato come sparare sulla Croce Rossa. Me la prendo invece con un fenomeno decisamente più ampio e fondamentale ma stranamente meno dibattuto, e quindi a mio avviso più preoccupante. Il problema vero è nel software, o meglio nei modelli e nei paradigmi dello sviluppo del software, che ancora oggi mi sembrano drammaticamente primitivi. Diciamocelo francamente: in cinquant’anni di informatica il modo di fare il software non è poi cambiato così tanto. La programmazione strutturata è invenzione degli anni ’80, e ancora quindici anni fa si dibatteva se il GOTO fosse un’istruzione accettabile o no”.

Le verifiche, il testing e il controllo di qualità sul software si svolgono in modo “artigianale”

“La successiva programmazione ad oggetti, che sembrava finalmente in grado di allineare lo sviluppo del software agli stessi standard industriali utilizzati per la produzione di componenti fisici, dopo dieci anni ha sconsolantemente dimostrato tutti i suoi limiti – aveva proseguito il cyber esperto -. Così fare software è ancora largamente un’arte, non un processo industriale. E cose quali il rispetto delle specifiche, l’effettuazione delle procedure di verifica ed il testing, l’applicazione dei controlli di qualità, si svolgono spesso in maniera artigianale o comunque senza il rigoroso ricorso a metodologie formali ed automatiche, per il semplice motivo che queste di fatto non esistono. D’accordo, forse esagero – si leggeva su Byte Italia -: diciamo allora che esistono alcune metodologie a livello essenzialmente accademico, la cui attuazione pratica lascia spesso a desiderare, e che comunque non eliminano del tutto i soliti vecchi problemi che affliggono lo sviluppo del software sin dall’era di Von Neumann”.

Giustozzi su Byte Italia ricorda che il software invece fallisce per colpa di errori sistematici, non di fluttuazioni casuali

“In tutto ciò vedo una serie di problemi concettuali – aveva sottolineato Giustozzi -. Ad esempio, forse è proprio sbagliato considerare il software come un oggetto industriale. Il software tutto sommato non è e non si comporta come un meccanismo fisico, e quindi dovrebbe essere progettato e verificato in modo diverso. Ma di questo nessuno sembra rendersi conto a fondo. I meccanismi di autoprotezione di ogni dispositivo fisico, ad esempio, sono fatti per salvaguardare la funzionalità e la stabilità del dispositivo stesso in seguito ad errori casuali provocati durante il suo funzionamento da eventi esterni accidentali ed imprevedibili. Il software invece fallisce per colpa di errori sistematici, non di fluttuazioni casuali (il valore di una variabile non cambia da solo!) e dunque i meccanismi di verifica e correzione, così come quelli di gestione delle eccezioni, dovrebbero essere fondamentalmente diversi da quelli impiegati nell’hardware”.

Il fallimento della prima missione di Ariane 5 si è verificato per un errore di software

“Tanto per dirne una, non basta duplicare un sottosistema nella speranza di migliorarne l’affidabilità, se nelle due copie gira esattamente lo stesso software! – aveva precisato il cyber esperto -. La ridondanza protegge infatti contro malfunzionamenti casuali, ma un errore sistematico nel software stesso metterà certamente fuori uso entrambe le copie del sottosistema, con buona pace della duplicazione. Dico cose banali? Forse. Tuttavia il fallimento nel 1996 della prima missione dell’allora nuovo vettore europeo Ariane 5, che esplose in aria a 37 secondi dal decollo con il suo preziosissimo carico di satelliti scientifici, si è verificato proprio per un banale errore nel software di controllo delle piattaforme inerziali – si suggeriva su Byte Italia -; scritto in Ada, che nessuna procedura di verifica e controllo aveva rilevato. E la ridondanza delle piattaforme non ha potuto fare nulla per evitare il disastro”.

Come facciamo a essere sicuri che non ci si bloccherà l’ABS in curva o non ci esploderà in faccia l’airbag in galleria per un ‘banale’ errore di programma?

“E proprio poche settimane fa la sonda Mars Climate Orbiter della NASA si è probabilmente schiantata sul pianeta rosso – aggiungeva Giustozzi -. Perché nessun software di verifica e nessuna procedura di controllo si erano accorti che i due team di controllo della missione avevano usato l’uno le unità di misure metriche e l’altro quelle anglosassoni. Ciò nel calcolare i dati relativi all’orbita, col risultato di inviare al veicolo delle istruzioni d’assetto completamente assurde nella fase critica di avvicinamento al pianeta. A questo punto mi domando: ma il software che gestisce la centralina elettronica delle nostre autovetture, come è stato scritto? – concludeva il cyber esperto -. Come facciamo ad essere sicuri che un giorno o l’altro non ci si bloccherà l’ABS in curva o non ci esploderà in faccia l’airbag in galleria per un ‘banale’ errore di programma?”.

L’editoriale “Fattore Critico” di Giustozzi, che sarebbe dovuto uscire su Byte Italia a novembre del 1999

Back To Top