la guida operativa

Legacy IT: mitigare i rischi dei sistemi obsoleti


Indirizzo copiato

Come individuare, isolare e mettere in sicurezza le tecnologie non più aggiornabili, fino alla dismissione pianificata

Pubblicato il 2 nov 2026

Federica Maria Rita Livelli

Business Continuity & Risk Management Consultant, BCI Cyber Resilience Committee Member, CLUSIT Direttivo



AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti
Legacy IT


Punti chiave

  • I sistemi Legacy IT a EoL accumulano vulnerabilità note (es. CVE), favoriscono il lateral movement e creano rischi normativi.
  • Gestione basata sul rischio: inventario completo (scansioni e CMDB), priorità per criticità, segmentazione di rete con Virtual Patching e monitoraggio centralizzato.
  • Pianificare la dismissione con responsabilità e scadenze; valutare il TCO; migrazione cifrata con rollback, cancellazione sicura (wiping, crypto-erase, distruzione) e documentazione.
Riassunto generato con AI


I sistemi Legacy IT, tecnologie ereditate dal passato che continuano a svolgere funzioni di business, ma non ricevono più gli aggiornamenti necessari a restare sicure. Un server con un sistema operativo di dieci anni fa, un macchinario di produzione non aggiornabile collegato in rete, un’applicazione gestionale sviluppata su misura che il fornitore non supporta più.

Il problema è che gli attaccanti lo sanno dato che le vulnerabilità di questi sistemi sono note, documentate e spesso sfruttabili con strumenti facilmente reperibili; mentre l’azienda non ha più modo di correggerle con una semplice patch. Un sistema obsoleto diventa, quindi, una porta d’ingresso nella rete aziendale: basta una sola compromissione per raggiungere dati e servizi molto più importanti.

Ignorare il tema non è una soluzione, ma neppure sostituire tutto, da un giorno all’altro, è sempre possibile. Serve capire perché questi sistemi sono pericolosi, censirli, ridurne l’esposizione con contromisure mirate e pianificarne la dismissione in modo sicuro.

Come gestire i rischi di sicurezza legati ai sistemi Legacy IT

Gestire il rischio legacy significa, anzitutto, riconoscere che non si tratta di un problema esclusivamente tecnico. Ogni sistema obsoleto ha un ruolo nei processi aziendali, un costo di sostituzione, un livello di criticità diverso.

Pertanto, l’approccio più efficace è quello basato sul rischio (risk-based): si valuta l’esposizione di ciascun sistema, si decide quali contromisure applicare nell’immediato e si definisce una tempistica realistica di superamento.

Perché le infrastrutture End of Life rappresentano una minaccia per la rete

Si parla di EoL (End of Life) quando un vendor dichiara concluso il ciclo di vita di un prodotto e smette di rilasciare aggiornamenti, correzioni di sicurezza e assistenza. Spesso a questa fase si arriva dopo l’EoS (End of Support), il termine ufficiale del supporto tecnico. Da quel momento ogni nuova vulnerabilità scoperta resta senza rimedio ufficiale, e il sistema accumula nel tempo debolezze note a chiunque.

Di fatto, le vulnerabilità sono catalogate pubblicamente, per esempio nei database CVE (Common Vulnerabilities and Exposures) e gli attaccanti possono cercarle in modo automatico su migliaia di sistemi.

Inoltre, i sistemi datati non supportano spesso i moderni meccanismi di autenticazione e cifratura, quindi, trasmettono credenziali o dati in chiaro e le soluzioni EDR (Endpoint Detection and Response), potrebbero non essere installabili. Infine, la scarsa documentazione e la perdita di competenze rendono più difficile capire cosa il sistema faccia davvero e cosa succeda in caso di intervento.

Il rischio maggiore è però laterale: l’attaccante non punta necessariamente al sistema obsoleto, lo usa come punto di appoggio. Una volta dentro, si muove nella rete (lateral movement) verso obiettivi di maggior valore, quali: database, sistemi di produzione o archivi di proprietà intellettuale. Ne consegue che un singolo server dimenticato può compromettere l’intera infrastruttura.

Inoltre, è importante considerare anche l’impatto normativo: direttive come la NIS2 e regolamenti come il GDPR richiedono misure adeguate al rischio e l’uso consapevole di sistemi non più aggiornabili, senza compensazioni è difficile da giustificare in caso di incidente.

Come identificare i software e gli hardware non più supportati dai vendor

Il primo passo è costruire un inventario completo degli asset, che comprenda hardware, sistemi operativi, applicazioni, firmware, librerie e dispositivi connessi, inclusi quelli di tipo OT e IoT spesso dimenticati.

Per ottenere un quadro affidabile si combinano più fonti: gli strumenti di scansione della rete e di discovery rilevano i dispositivi attivi e le versioni installate; mentre la CMDB (Configuration Management Database), il database che raccoglie le informazioni sugli asset e le loro relazioni, consente di collegarli ai servizi di business. A queste si aggiungono i report dei sistemi di gestione delle vulnerabilità e le informazioni dei fornitori.

Inoltre, un’attenzione particolare va dedicata al cosiddetto shadow IT, ossia ai sistemi installati senza il coinvolgimento dell’area informatica.

Dopo aver individuato gli asset, si confronta ciascuno di essi con le date di fine supporto dichiarate dai vendor (i.e. roadmap di ciclo di vita), distinguendo tra ciò che è già scaduto, ciò che scadrà a breve e ciò che è ancora sotto copertura. Inoltre, a ogni sistema, si associano la criticità per il business, l’esposizione (a esempio, se raggiungibile da Internet), le dipendenze e un responsabile.

Il risultato è un elenco ordinato per priorità, che permette di concentrare le risorse dove il rischio è maggiore.

Come applicare le contromisure di sicurezza sui sistemi obsoleti

Generalmente, quando non è possibile sostituire o aggiornare un sistema, si ricorre alle cosiddette misure compensative: controlli alternativi che riducono il rischio, senza modificare direttamente il componente vulnerabile.

Il principio è semplice: se il sistema non può essere reso sicuro, bisogna renderne più difficile l’accesso e più rapida la rilevazione di qualsiasi anomalia.

Come isolare i sistemi legacy mediante la segmentazione di rete e Virtual Patching

È importante evidenziare che l’isolamento è la misura più efficace in termini di gestione dei sistemi obsoleti. In particolare, la segmentazione di rete consiste nel suddividere l’infrastruttura in zone separate, con regole precise su quali comunicazioni sono ammesse tra l’una e l’altra.

I sistemi legacy vengono collocati in segmenti dedicati, protetti da firewall e, quando possibile, resi non raggiungibili da Internet. Si consentono solo i flussi indispensabili, verso pochi sistemi autorizzati e su porte e protocolli definiti, e si accede agli apparati tramite postazioni di amministrazione controllate.

Tale logica, nei contesti industriali, si applica con modelli a livelli e con le cosiddette zone demilitarizzate (DMZ – Demilitarized Zone), i.e. aree intermedie che separano la rete aziendale da quella di produzione.

Di fatto, l’isolamento logico delle componenti tecnologiche non più aggiornabili è una condizione imprescindibile per la protezione del perimetro esteso, evitando che sistemi datati diventino il punto di ingresso per attacchi alla rete.

È importante evidenziare che, oggi, il perimetro non coincide più con i confini fisici dell’ufficio ed è sempre più ampliato. Pertanto, è opportuno implementare altresì un approccio Zero Trust, in cui nessun utente o dispositivo è considerato affidabile per principio e ogni accesso viene verificato.

Inoltre, alla segmentazione si affianca il Virtual Patching, o “patching virtuale” e, quando non esiste una correzione ufficiale, strumenti come i WAF (Web Application Firewall), gli IPS (Intrusion Prevention System)e le regole di filtraggio dei firewall di nuova generazione sono in grado di intercettare il tentativo di sfruttare la vulnerabilità prima che raggiunga il sistema.

Quali procedure di hardening adottare sui server che non possono essere aggiornati

L’hardening è il processo di “indurimento” di un sistema, che consiste nel ridurne la superficie di attacco, eliminando tutto ciò che non serve e si converte, per quanto riguarda i server che non possono essere aggiornati, nella prima linea di difesa e segue una sequenza logica.

Il punto di partenza è sfoltire il sistema. Si disattivano servizi, porte e protocolli non necessari, in particolare quelli obsoleti e insicuri, e si rimuovono software e account inutilizzati, perché ogni componente superfluo è una possibile via d’ingresso.

Una volta ridotta la superficie, si passa a governare chi può accedere a ciò che resta. Si applica il principio del minimo privilegio, si sostituiscono le password predefinite e si introduce, dove tecnicamente possibile, l’MFA (Multi-Factor Authentication), gestendo gli accessi amministrativi attraverso sistemi dedicati. Se il server non supporta nativamente un’autenticazione moderna, si può interporre un sistema intermedio (jump server) che la garantisca al posto suo.

A questo punto occorre proteggere i dati e prepararsi all’eventualità peggiore. Dove possibile si cifrano i collegamenti e si impedisce l’esecuzione di software non autorizzato con l’application allowlisting, ovvero un elenco di applicazioni ammesse al di fuori del quale nulla può essere avviato. Parallelamente si mantengono backup frequenti, isolati dalla rete e verificati con prove di ripristino, definendo obiettivi chiari di RTO (Recovery Time Objective) e RPO (Recovery Point Objective.

Infine, poiché un sistema che non si può proteggere del tutto va almeno osservato con attenzione, si attiva un monitoraggio dedicato: i log vengono inviati a un SIEM (Security Information and Event Management) e si configurano allarmi per i comportamenti anomali.

Tutte queste misure vanno documentate, indicando il rischio residuo e una data di riesame, così che la deroga concessa al sistema obsoleto non diventi permanente.

Come pianificare la dismissione sicura delle tecnologie datate

Le misure compensative guadagnano tempo, ma non risolvono il problema alla radice. L’obiettivo finale resta la sostituzione o il ritiro dei sistemi obsoleti, da realizzare con un piano strutturato che tenga insieme priorità di rischio, vincoli operativi e budget.

Il piano indica, per ogni sistema, la soluzione di destinazione (sostituzione, aggiornamento, migrazione al cloud o semplice spegnimento), i responsabili, le scadenze e le dipendenze da gestire, in modo da evitare blocchi dell’operatività.

Come valutare i costi di mantenimento dei sistemi vecchi rispetto al rinnovo

Mantenere in vita un sistema datato sembra spesso la scelta più economica, ma il confronto va fatto sul costo complessivo, il TCO (Total Cost of Ownership), che comprende tutte le spese lungo il ciclo di vita e non solo l’acquisto.

Per i sistemi legacy, le voci da considerare sono molte: contratti di assistenza straordinaria o con fornitori specializzati, spesso più onerosi; ricambi difficili da reperire; competenze rare e costose; maggiore consumo energetico; misure compensative da gestire e monitorare; e il tempo del personale dedicato a tenere in funzione ciò che non evolve.

A questi costi visibili si sommano quelli del rischio. Occorre stimare la perdita attesa derivante da un incidente, che comprende l’interruzione delle attività, il ripristino, le eventuali sanzioni, il danno reputazionale e le possibili ricadute contrattuali o assicurative.

Una polizza cyber, per esempio, può prevedere condizioni più severe o esclusioni per chi utilizza sistemi non supportati.

Vanno poi considerati i costi dell’inazione: l’impossibilità di integrarsi con nuovi servizi, la perdita di efficienza e il rallentamento dell’innovazione.

Sul fronte opposto si valutano i costi di sostituzione: licenze o abbonamenti, migrazione dei dati, formazione, riprogettazione dei processi e periodo di affiancamento tra vecchio e nuovo sistema. Il confronto più utile è quello su un orizzonte di più anni, accompagnato da scenari alternativi, per esempio una sostituzione graduale per priorità anziché integrale.

In molti casi emerge che il rinnovo, pur richiedendo un investimento iniziale, riduce i costi complessivi e abbassa in modo stabile l’esposizione al rischio.

Come gestire la migrazione dei dati e la cancellazione sicura

La dismissione è un momento delicato, perché in questa fase i dati possono andare persi, essere alterati o finire in mani sbagliate. La migrazione richiede quindi un metodo. Si parte dal censimento dei dati da trasferire, distinguendo quelli necessari da quelli da archiviare per obbligo di legge e quelli da eliminare, con il coinvolgimento dei responsabili dei processi e, per i dati personali, del DPO (Data Protection Officer).

Si prepara poi un ambiente di destinazione già protetto e si esegue la migrazione in modo graduale, con test preliminari, controlli di integrità per verificare che i dati siano completi e non alterati, e un piano di ritorno (rollback) nel caso in cui qualcosa non funzioni.

Durante il trasferimento i dati devono viaggiare cifrati e con accessi tracciati.

Solo dopo la verifica del buon esito, e un adeguato periodo di funzionamento in parallelo, si procede alla cancellazione sicura. Eliminare i file o formattare un disco non basta, perché i contenuti possono essere recuperati.

Le tecniche riconosciute dipendono dal tipo di supporto: la sovrascrittura multipla dei dati (data wiping) per i dischi tradizionali, la cancellazione crittografica (crypto-erase), che rende illeggibili i dati distruggendo le chiavi con cui sono cifrati, e la distruzione fisica quando il supporto è danneggiato o contiene informazioni particolarmente sensibili.

Quando la dismissione è affidata a terzi, si richiedono garanzie contrattuali e certificati di avvenuta distruzione.

Occorre, infine, chiudere il cerchio: revocare account e credenziali associati ai sistemi spenti, rimuovere i dispositivi dagli inventari e dalle regole di rete, aggiornare la documentazione e smaltire le apparecchiature nel rispetto della normativa sui rifiuti elettronici (RAEE, Rifiuti da Apparecchiature Elettriche ed Elettroniche).

Conservare la prova delle operazioni svolte è essenziale per dimostrare, in caso di audit o di controllo, che il ritiro è avvenuto in sicurezza.

Conclusione

I sistemi legacy non scompaiono da soli, e ignorarli significa lasciare aperti dei varchi proprio dove l’azienda è meno in grado di difendersi. Il percorso per gestirli è però chiaro: capire perché i sistemi a fine vita sono pericolosi, censirli con un inventario affidabile, ridurne l’esposizione con segmentazione, Virtual Patching e hardening, e pianificarne la dismissione confrontando con realismo costi e rischi.

Le misure compensative servono a guadagnare tempo, non a rinviare all’infinito la decisione. La vera soluzione è un piano di superamento con scadenze, responsabilità e risorse, sostenuto dalla direzione e verificato nel tempo.

Affrontare oggi il problema dei sistemi obsoleti significa proteggere l’intera infrastruttura, rafforzare la continuità operativa e ridurre l’esposizione a incidenti che, domani, potrebbero costare molto di più.

Partecipa alla community

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x