Un aggiornamento rimandato non è una dimenticanza. Nella maggior parte dei casi è una decisione: c’è un applicativo che potrebbe non funzionare più, una finestra di fermo da concordare, un fornitore da coinvolgere. Chi rimanda lo fa perché aggiornare costa qualcosa, e in quel momento sembra costare più del rischio.
Il problema è che quel calcolo viene fatto una volta e poi non si rifà. L’aggiornamento resta in sospeso, il sistema continua a funzionare, e sei mesi dopo nessuno ricorda che c’era una decisione da riprendere.
Vediamo cosa contiene davvero un aggiornamento di sicurezza, perché in azienda si accumula ritardo, e cosa sfrutta chi attacca nella finestra fra la correzione disponibile e la correzione applicata.
Cosa contiene un aggiornamento di sicurezza
Non tutti gli aggiornamenti sono la stessa cosa, e la distinzione conta perché cambia l’urgenza.
Un aggiornamento di funzionalità aggiunge cose nuove o cambia l’interfaccia. Si può pianificare, si può rimandare, e se crea problemi si torna indietro. Un aggiornamento di sicurezza fa un’altra cosa: chiude una vulnerabilità che è già stata scoperta, e nel momento in cui esce diventa pubblica anche la vulnerabilità che corregge.
Questo è il punto che sfugge più spesso. La pubblicazione di una correzione non riduce il rischio: nell’immediato lo aumenta. Prima del rilascio la vulnerabilità la conosceva chi l’ha trovata. Dopo, la conosce chiunque legga il bollettino del produttore, insieme all’informazione su quali versioni sono esposte.
Chi attacca legge quei bollettini. Non per curiosità: per sapere cosa cercare.
Perché in azienda si rimanda
Le ragioni sono concrete e quasi mai pretestuose. Vale la pena elencarle, perché nessuna si risolve dicendo alle persone di aggiornare più spesso.
| Ostacolo | Perché blocca |
|---|---|
| Compatibilità applicativa | Il gestionale su cui gira l’azienda è certificato per una versione precisa. Aggiornare il sistema può farlo smettere di funzionare, e nessuno lo scopre prima di provarci |
| Finestra di fermo | Un server di produzione si riavvia quando il reparto operativo lo concede. Su alcuni sistemi quella finestra arriva una volta al trimestre |
| Vincolo del fornitore | Su apparati e macchinari l’aggiornamento passa dal produttore, e una modifica autonoma può invalidare garanzia o certificazione |
| Nessun ambiente di prova | Senza un ambiente dove testare, ogni aggiornamento è una scommessa fatta in produzione. Chi decide preferisce non farla |
| Sistemi che nessuno rivendica | Un server acceso da anni, di cui non si sa più chi lo usa, non si aggiorna e non si spegne. Resta lì |
L’ultima riga è quella che pesa più delle altre. Un aggiornamento rimandato per un motivo valido almeno è tracciato: c’è un ticket, una data, qualcuno che se ne occupa. Un sistema che nessuno rivendica non compare in nessun elenco, quindi non viene rimandato: viene ignorato.
La finestra che chi attacca sfrutta
Fra il rilascio di una correzione e la sua applicazione passa del tempo. In quella finestra la vulnerabilità è pubblica, documentata, e sfruttabile su tutti i sistemi che non hanno aggiornato.
Il caso più noto resta WannaCry, nel 2017. La vulnerabilità che ha sfruttato era stata corretta da Microsoft **due mesi prima** della campagna, con un bollettino pubblico. I sistemi colpiti non erano privi di difese: erano privi di un aggiornamento disponibile da otto settimane.
Lo stesso schema si ripete ogni volta, e la finestra non si chiude mai del tutto. Su Log4Shell la correzione è del dicembre 2021, e nei rilievi la vulnerabilità compare ancora. Non perché sia irrisolvibile: perché in molti casi nessuno sa dove si trovi quella libreria.
Per questo l’urgenza di un aggiornamento non si misura sulla gravità dichiarata nel bollettino, ma su due domande diverse: quel sistema è raggiungibile dall’esterno, e cosa può raggiungere lui. Una vulnerabilità con punteggio massimo su una macchina isolata conta meno di una vulnerabilità media su un servizio esposto.
Il Vulnerability Assessment rileva le versioni installate su sistemi, servizi esposti e componenti di terze parti, e restituisce le vulnerabilità in ordine di priorità reale.
Quando aggiornare non si può
Esiste una categoria di sistemi per cui l’aggiornamento non è rimandato: è impossibile. Un applicativo su misura il cui fornitore non esiste più. Un macchinario il cui produttore ha chiuso la linea. Un sistema operativo che ha superato la fine del supporto e per cui non usciranno più correzioni.
In questi casi la domanda cambia. Non è più quando aggiornare, ma cosa quel sistema riesce a raggiungere se qualcuno ci entra. La risposta si costruisce con la segmentazione della rete, con la restrizione degli accessi, e con la decisione documentata di accettare quel rischio.
Il tema è affrontato per esteso nell’articolo sulle vulnerabilità che non si possono correggere. Qui basta il principio: un sistema non aggiornabile non è un problema tecnico irrisolto, è una scelta che qualcuno deve prendere e mettere per iscritto.
Come si tiene traccia di cosa manca
Il presupposto di tutto è sapere cosa c’è. E questa è la parte che in genere non torna.
L’inventario aziendale contiene i sistemi che l’IT ha installato e censito. Non contiene il server messo su per un progetto e mai dismesso, la stampante di reparto con il pannello di gestione raggiungibile, il dispositivo che un fornitore ha collegato durante un intervento di manutenzione. Nessuna di queste cose è nell’elenco, e tutte hanno una versione software che invecchia.
Da qui la differenza tra la lista di quello che dovreste aggiornare e la lista di quello che è effettivamente esposto. La prima si legge nell’inventario, la seconda si scopre andando a guardare in rete.
Per i soggetti che rientrano nel perimetro della direttiva NIS 2 questo passaggio non è più solo buona pratica: la gestione delle vulnerabilità è una delle misure di sicurezza di base che devono essere operative e dimostrabili con evidenze entro il 31 ottobre 2026.
E dimostrabile significa con un documento che riporti una data, un perimetro e un esito. Non con la dichiarazione che gli aggiornamenti si fanno.
Il Penetration Test verifica fino a dove porta davvero una vulnerabilità: quali sistemi diventano raggiungibili e dove la segmentazione della rete tiene.
- Autore articolo
- Gli ultimi articoli
Responsabile Marketing per due aziende leader nel settore della Sicurezza Informatica: organizzo e progetto iniziative di diffusione della cultura cybersecurity e dei rischi cyber-crime attraverso contenuti web, eventi on e off line e materiale info-grafico. Ho una naturale propensione per far coesistere il lato metodico e preciso del mio carattere con la parte più creativa, visionaria e ambiziosa di me. Sono curiosa, riflessiva e non metto freni alla mia fame di conoscenza.