Obsolescenza tecnologia e cybersecurity: alle lunghe, non è neanche male.


Autore: Massimiliano Brolli

Data Pubblicazione: 01/06/2021


Molto spesso mi viene chiesto come poter sostituire il software obsoleto presente sulle applicazioni evitando gli elevati impatti economici, le riscritture di codice e soluzioni custom. Purtroppo non c’è una risposta o una soluzione definitiva, in quanto tutte le cose (e anche le applicazioni) hanno un loro ciclo di vita.


È però possibile dare delle indicazioni su come trattare in modo efficace il fenomeno dell’obsolescenza, cosa che tenterò di fare con questo articolo.


Cosa è l’obsolescenza tecnologica?

È un fenomeno derivato dal fatto che una componente software (ad es. un sistema operativo, un framework di sviluppo, ma anche il firmware di uno smartphone o di una stampante) ha un periodo di supporto da parte del fornitore limitato nel tempo, che di solito risulta sufficientemente lungo. Superato questo periodo il fornitore cessa la fornitura di aggiornamenti e bug-fix (comprese le patch di sicurezza) causando l’accumulo e la stratificazione delle vulnerabilità nel tempo e rendendo i nostri sistemi facilmente violabili.


Si tratta di un rischio che consente vettori di attacco molto pervasivi come ad esempio i pericolosi RCE (Remote Code Execution) capaci di compromissioni e impatti di ogni natura e profondità. Purtroppo, spesso, la via più immediata per trattare un sistema obsoleto è riscriverlo o riadattarlo alle più recenti componenti software. Su applicazioni enterprise questo può risultare altamente costoso oltre a non dare vantaggi agli utenti in termini di CX. Ciò costituisce un ostacolo importante, che spesso porta l’utente a dire “sono pienamente soddisfatto del mio sistema e non vedo il motivo di dover spendere dei soldi per riaverlo esattamente come prima”.



Siamo realisti, non è facile trasmettere questi concetti ad utenti non esperti di sicurezza. Per mia esperienza aiuta molto dimostrare ciò che è possibile fare sfruttando l’obsolescenza tecnologica; l’utilizzo di messaggi diretti come: “Sottrazione di tutte le carte di credito degli utenti da rete internet in accesso anonimo a causa dell’obsolescenza tecnologica“, vi assicuro che vale più di altre mille altre parole.


Addentriamoci nel merito, come sempre la sicurezza passa per i soliti due concetti ovvero la “Security by Design” e “Long-Term Security” e questo fenomeno, ovviamente non è da meno.

Security by Design

  • Scegliere il software con attenzione: nei nuovi progetti, porre massima attenzione a tutta la pila software utilizzata, in modo che sia opportunamente aggiornata e garantisca tempistiche di supporto adeguate. Ad esempio, se oggi avviamo un nuovo progetto su tecnologia Microsoft potremmo utilizzare SQL Server 2008 R2 (tuttora a listino) che va in end-of-life a settembre 2019. Una svista di questa natura è “clamorosa” in quanto tra meno di un anno tale release andrà in end-of-life e non verranno più rilasciate patch di sicurezza. Scegliendo invece SQL Server 2017, il problema verrà spostato a dicembre 2027, ben 9 anni di supporto in più, un’eternità nella gestione di un sistema.

  • Non far decidere agli altri, decidete voi: molto spesso i fornitori tendono a creare sistemi su tecnologie datate per evitare costi di formazione su quelle più recenti. Occorre prestare la massima attenzione a questo fenomeno (in particolare su software open-source) in quanto non è raro avere nuovi sistemi con software già in end-of-life non appena questi varcano la soglia dell’esercizio.

  • Componenti Open Source: fate molta attenzione. A parte il software Open riconosciuto a livello internazionale (ad es. MySql, Apache, Tomcat, Java, ecc..) con vendor o community di spessore alle spalle, scegliete le librerie e i framework che notoriamente non hanno problemi di sicurezza ricorrenti (ad es. Drupal, Joomla, Struts2, ecc…). Verificate anche che le relative community risultino attive prima di adottarle nella vostra architettura software, in quanto utilizzare software open-source con community in decommissioning porterà ad una veloce obsolescenza, e questo lo dobbiamo evitare.

  • Framework e librerie open source & buy: come visto in precedenza se l’applicazione è scritta da noi, utilizzare il più possibile codice proprietario e librerie messe a disposizione dai framework di sviluppo (ad es. librerie native di Java, Namespaces Microsoft .NET) evitando di utilizzare componenti di terze parti per effettuare operazioni implementabili in modo “semplice”. Ad esempio, se in ambiente .NET ci occorre una libreria che invia mail, non acquistiamo una DLL di terze parti ma sviluppiamo le nostre classi estendendo il namespace “System.Net.Mail.SmtpClient”. Insomma, più autonomia e controllo abbiamo sul codice da noi prodotto, più facile risulterà agire.

  • Patching automatizzato: per tutte le tecnologie che lo consentono (ad es. Prodotti Microsoft o Red Hat Satellite) abilitare il patching automatizzato e valutare, in caso di tecnologie che non lo consentono, prodotti di terze parti da implementare.


Long-term Security

  • Vulnerability Assessment ricorsivi: Effettuare scansioni cadenzate sulle applicazioni più critiche monitorando lo scostamento nel tempo (recycle) delle vulnerabilità sfruttabili ed effettuare tutte le mitigazioni del caso. Alle volte sono presenti servizi non necessari che introducono vulnerabilità gravi che se correttamente segregati possono mitigare o risolvere completamente il problema.