Vulnerabilità che non si possono correggere: cosa fare

Un macchinario da centoventimila euro comprato nel 2014 funziona perfettamente e ha davanti altri dieci anni di vita utile. Il PC che lo pilota gira su un sistema operativo fuori supporto da anni, il software di controllo non è certificato su nulla di più recente, e il produttore del macchinario ha chiuso.

La patch non esiste. Non esisterà. E il macchinario non si butta.

Questa situazione non è un’anomalia da sanare: è la condizione ordinaria di gran parte della manifattura italiana, della sanità e delle utility. Un report di vulnerability assessment la fotografa come rilievo critico non risolvibile, e a quel punto la domanda smette di essere tecnica e diventa una decisione da prendere e da giustificare. Vediamo su quali criteri.

1. Quando una vulnerabilità non si corregge
2. Le tre decisioni possibili
3. I controlli compensativi che funzionano
4. Isolare senza fermare la produzione
5. Come si documenta una scelta di questo tipo
6. Gli errori che vediamo più spesso

Quando una vulnerabilità non si corregge

Conviene distinguere subito i casi, perché vengono confusi e richiedono risposte diverse.

Le prime cinque righe sono impossibilità reali. L’ultima è una scelta economica travestita da impossibilità tecnica, e va trattata diversamente: lì una finestra di manutenzione esiste, va solo pianificata e negoziata con chi governa la produzione.

Un chiarimento sulla quarta riga, perché genera confusione. Un difetto hardware non è una vulnerabilità zero-day: lo zero-day è sconosciuto o non ancora corretto e prima o poi una patch arriva. Qui la patch non arriverà mai, perché il difetto sta nella fisica del componente. Sono due problemi con due gestioni opposte: il primo si aspetta, il secondo si aggira.

Le tre decisioni possibili

Davanti a un rilievo non correggibile le strade sono tre, e vanno valutate in quest’ordine — non nell’ordine in cui costano meno.

**Sostituire.** È l’unica che elimina il problema invece di gestirlo. Va valutata seriamente anche quando sembra fuori discussione, perché il confronto onesto non è fra il costo del nuovo sistema e zero: è fra quel costo e il costo di gestire il rischio per tutti gli anni residui, che include controlli, verifiche periodiche e la probabilità di un fermo. Su un orizzonte di cinque anni il calcolo si ribalta più spesso di quanto le aziende si aspettino.

**Isolare.** Il sistema resta dov’è, ma si riduce drasticamente ciò che può raggiungere e da dove può essere raggiunto. È la scelta prevalente nei contesti industriali e sanitari, e funziona: una vulnerabilità raggiungibile solo da due indirizzi interni ha un profilo di rischio incomparabile con la stessa vulnerabilità esposta in rete. Non elimina il difetto, elimina quasi tutti i modi di arrivarci.

**Accettare.** È legittimo, purché sia una decisione presa da chi ha l’autorità per prenderla e messa per iscritto. L’accettazione informale — nessuno decide, nessuno firma, il rilievo resta aperto per anni — non è accettazione del rischio: è assenza di governo, e in caso di incidente la differenza fra le due cose è esattamente ciò che verrà esaminato.

I controlli compensativi che funzionano

Quando si sceglie di isolare, la domanda diventa quali misure sostituiscono la patch mancante. Il criterio è semplice: un controllo compensativo vale nella misura in cui rende la vulnerabilità irraggiungibile o inutile, non nella misura in cui è sofisticato.

La prima riga fa da sola più della metà del lavoro, e resta la misura meno applicata: nei rilievi sui sistemi fuori supporto capita regolarmente di trovare interfacce di gestione raggiungibili da internet senza che nessuno sappia perché. Il quarto controllo merita una nota, perché costa poco e viene ignorato: separare la postazione con cui l’operatore legge la posta da quella che pilota il macchinario elimina il vettore più probabile, cioè il documento aperto sulla macchina sbagliata.

L’ultima riga è l’unica che non riduce il rischio. Serve a sapere che qualcosa sta succedendo, e il modo di leggerla è quello descritto nell’articolo sugli indicatori di compromissione.

Isolare senza fermare la produzione

L’obiezione che arriva sempre, e non è pretestuosa, è che quel sistema deve comunicare con qualcosa: il gestionale, il server di raccolta dati, il tecnico del fornitore che si collega per l’assistenza. Isolarlo del tutto significa spegnerlo.

Il punto è che l’isolamento non è binario. Si parte dalla domanda opposta a quella che si fa di solito: non “da cosa lo tagliamo fuori”, ma con quali sistemi ha bisogno di parlare, per fare cosa, e in quale direzione. Quasi sempre l’elenco è cortissimo — due o tre destinazioni — e quello che rimane fuori è tutto il resto della rete, cioè la parte che conta.

Da questa mappatura escono regole precise: quali indirizzi, quali servizi, quale verso. Un macchinario che invia dati di produzione a un server non ha bisogno di ricevere connessioni da nessuno; un accesso di assistenza del fornitore può esistere solo su richiesta e per una finestra definita, invece di restare permanentemente aperto. Su quest’ultimo punto vale la pena tenere presente che un accesso permanente di terze parti è esattamente il meccanismo che rende praticabile l’island hopping, e va inquadrato con gli stessi criteri usati per valutare la sicurezza di un fornitore.

Sulle utenze vale il privilegio minimo applicato con più severità che altrove: su un sistema che non si può correggere, un’utenza con privilegi eccessivi è l’unica cosa che ancora dipende da voi.

Come si documenta una scelta di questo tipo

Questa è la parte che distingue una gestione difendibile da un rischio subito, ed è anche quella che serve quando un cliente enterprise vi manda un questionario o un auditor apre il registro dei rilievi.

Un rilievo non correggibile gestito correttamente ha cinque elementi scritti: il sistema e la vulnerabilità identificata, il motivo tecnico per cui la correzione non è applicabile, i controlli compensativi adottati con la data, chi ha approvato la decisione, e la scadenza per rivalutarla. Manca uno di questi e la documentazione non regge: senza un’approvazione nominale e una data di riesame non è una decisione, è un rilievo dimenticato.

La direttiva NIS2 non vieta di convivere con sistemi obsoleti — sarebbe irrealistico. Richiede che la gestione del rischio sia basata su valutazioni tracciabili e aggiornate, e un’accettazione motivata, approvata e periodicamente riesaminata soddisfa quel requisito. Un rilievo aperto da tre anni senza nessuna annotazione, no.

Sul come si struttura questa documentazione, il formato dei rilievi e delle raccomandazioni è quello descritto nell’articolo sul report di vulnerability assessment, e il riesame periodico è la ragione per cui il monitoraggio continuo conta più della singola verifica.

Gli errori che vediamo più spesso

Quattro, in ordine di frequenza.

Il primo è considerare l’isolamento un lavoro chiuso. Le reti cambiano: si aggiunge un apparato, si modifica una regola per risolvere un problema urgente, e mesi dopo il sistema che era isolato è tornato raggiungibile senza che nessuno l’abbia deciso. È un decadimento silenzioso, e si rileva solo verificando periodicamente.

Il secondo è confondere l’antivirus con un controllo compensativo. Su un sistema fuori supporto la protezione dell’endpoint non copre la vulnerabilità che non si può correggere: copre altri vettori. Sono cose diverse e non si sostituiscono.

Il terzo è dimenticare i sistemi che nessuno rivendica. Il PC di collaudo, il vecchio server rimasto accanto al nuovo, il pannello di un impianto dismesso e mai scollegato. Non hanno un responsabile, quindi non hanno controlli, e in un inventario tramite scansione compaiono regolarmente con vulnerabilità di anni.

Il quarto è dare per buono l’isolamento senza provarlo. Una regola scritta in una configurazione dice quale era l’intenzione; non dice se funziona. Da questo punto in poi la differenza fra vulnerability assessment e penetration test diventa concreta: il primo vi dice che il sistema è vulnerabile e non correggibile, il secondo vi dice se, partendo da un punto qualsiasi della rete, ci si arriva davvero. Su una vulnerabilità che resterà aperta per anni, quella seconda risposta è l’unica che vi dice se la mitigazione tiene.