La gestione dell’obsolescenza del software da parte delle software house rende concretamente ingestibile la sicurezza informatica
di Andrea Monti – Key4Biz.it del 2 ottobre 2017
High Sierra e IOS11, i due nuovi sistemi operativi di Apple, si portano dietro un pesante carico di incompatibilità con il parco software esistente. Adobe e Microsoft hanno già dichiarato che alcuni loro prodotti devono essere aggiornati, mentre altri (Microsoft Office 2011 per Mac) non verranno resi compatibili con il nuovo sistema operativo. Destino analogo riguarda tantissimi altri programmi che dovranno essere dismessi o acquistati nella loro versione “compatibile” con la “nuova versione”.
Dunque, per gli utenti, la scelta è chiara: continuare ad usare una piattaforma resa artificialmente”vecchia” (e non essere costretti a spendere tempo e soldi per l’upgrade) e trovarsi progressivamente “tagliato fuori”, o mettere mano al portafogli ed “essere protagonista dell’innovazione”.
Fino a quando questa politica – non solo di Apple, per carità – riguarda il mondo della produttività, i danni sono relativamente contenuti. Alla fin fine, si tratta solo di spendere soldi e ore della propria vita dietro download, formattazioni, installazioni, crash, riconfigurazioni e attese per qualche patch.
Ma quando la gestione del ciclo di vita di un software impatta su quello della sicurezza, le cose cambiano drasticamente.
Prendete una struttura minimamente complessa, come potrebbe essere quella di una pubblica amministrazione o a una banca che hanno centinaia di migliaia di apparati, ciascuno con i rispettivi software da configurare, gestire e aggiornare. Vogliamo veramente sostenere che è possibile tenere aggiornata all’ultima patch tutta l’infrastruttura ICT? Al di la del problema delle competenze dei soggetti che si occupano della cosa, è pensabile che in un solo anno si riesca a fare tutto questo? E anche se ci si riuscisse, come si può essere certi che gli aggiornamenti di un sistema operativo o di un software siano più “sicuri” dei predecessori?
La verità è che il “lifecycle management” orientato alla sicurezza ha dei tempi totalmente incompatibili con quelli dell’equivalente gestito da logiche commerciali.
Una gestione orientata alla sicurezza richiederebbe code reviewing, verifica di (in)compatibilità, controllo dell’interazione fra il nuovo “pezzo di codice”, quelli esistenti e lo hardware che li fa funzionare. Ma no ho quasi mai visto nessuno fare sul serio una cosa del genere, anche in contesti industriali.
Mi domando se il Ministero dei trasporti omologherebbe una vettura con una scheda tecnica tipo: “il mezzo ha le ruote e il motore. I freni li aggiungeremo fra qualche mese, mentre cinture di sicurezza e airbag saranno presenti nel prossimo modello. Nel frattempo, potremmo decidere – ma non lo garantiamo – di ritirare questa versione e sostuirla con una nella quale abbiamo inserito il piantone dello sterzo collassabile e un roll-bar. Ma non prendiamo alcun impegno di installare tutto questo – a nostre spese – sui modelli già venduti.”
Possibly Related Posts:
- Chi ci protegge dal dossieraggio tecnologico?
- Perché Apple ha ritirato la causa contro la società israeliana dietro lo spyware Pegasus?
- Le accuse mosse a Pavel Durov mettono in discussione la permanenza in Europa di Big Tech
- Cosa significa l’arresto di Pavel Durov per social media e produttori di smart device
- Chi vince e chi perde nella vicenda di Julian Assange