Patch Management: l’importanza di una corretta gestione delle patch

Capita con una regolarità che ha smesso di sorprenderci.
Consegniamo un report di vulnerability assessment, l’azienda lo legge, concorda sulle priorità. Sei mesi dopo, alla verifica successiva, metà di quelle patch non è stata applicata.

Non per negligenza. O almeno, quasi mai per negligenza.

Il patch management viene raccontato come un problema di processo e di strumenti e tutta la letteratura sull’argomento spiega come dovrebbe funzionare.
Molto meno si dice sul perché, nelle aziende reali, è un’attività che passa in secondo piano.

1. Il report non è l’intervento
2. Il sistema che non si può fermare
3. Il fornitore che non autorizza
4. Quando nessuno sa cosa gira davvero
5. Le priorità costruite sul numero sbagliato
6. Che fare quando la patch non si può applicare
7. Come si costruisce un processo che tiene

Il report non è l’intervento

Vale la pena dirlo subito, anche se non ci conviene: un report di vulnerability assessment non mette in sicurezza niente da solo.

Il documento riporta per iscritto quali vulnerabilità sono presenti nella struttura oggetto dell’analisi, su quali sistemi e con quale priorità di intervento.
È il punto di partenza, non l’arrivo. Quello che succede dopo dipende da decisioni che stanno fuori dal perimetro tecnico: budget, fermi produzione, rapporti con i fornitori, responsabilità.

Il caso limite l’abbiamo raccontato parlando di BlueKeep.
Una vulnerabilità con punteggio 9,8, corretta da Microsoft nel 2019 anche per sistemi fuori supporto e sette anni dopo ancora presente in reti aziendali italiane. La patch esiste da sempre. Nessuno (o quasi) l’ha mai applicata.

Quindi la domanda utile non è come si fa patch management.
È che cosa blocca l’applicazione di una patch quando tutti sanno che andrebbe applicata.

Il sistema che non si può fermare

È la ragione numero uno e non si risolve con uno strumento.

L’applicazione di una patch richiede quasi sempre un riavvio e eseguire un riavvio del sistema comporta (in alcuni casi) il fermo.

• Su un server di posta significa attendere dieci minuti, in quel lasso di tempo nessuno riceve o invia e-mail.
• Su un gestionale di produzione sono dieci minuti in cui la linea non registra.
• Su una macchina che pilota significa programmare il fermo affinché l’impianto possa fermarsi per dieci minuti.

In alcuni settori, e con alcuni dispositivivi quei dieci minuti costano: economicamente, organizzativamente e infine, responsabilmente.

Il problema si complica quando la finestra di manutenzione non esiste affatto.
Un’azienda che lavora su tre turni non ha una notte libera. Un magazzino automatizzato che movimenta anche il sabato non ha un fine settimana libero.
La finestra va negoziata con chi risponde della produzione e solitamente, chi risponde della produzione ha obiettivi che non coincidono con quelli di chi risponde della sicurezza della rete.

C’è poi il timore concreto che installando patch, si rompa qualcosa.
Non è una paura irrazionale: può succedere e quando succede, il responsabile IT che ha autorizzato l’aggiornamento è la persona a cui viene chiesto conto.
La verifica preventiva su un ambiente di prova riduce questo rischio, ma un ambiente fedele alla produzione ce l’hanno poche organizzazioni: ne abbiamo spiegato i motivi parlando di verifiche in ambiente isolato.

Il risultato di questi tre vincoli sommati è sempre lo stesso.
La patch non viene rifiutata.
Viene rinviata la sua installazione e il rinvio si rinnova ogni mese perché le condizioni che lo hanno causato non cambiano da sole.

Il fornitore che non autorizza

Questa è la ragione che nella nostra esperienza blocca più interventi di quanto si immagini e raramente compare negli articoli sul tema.

Molti sistemi aziendali non sono gestiti da chi li usa.
Il gestionale, il sistema di controllo della produzione, l’applicativo verticale di settore: li ha installati un fornitore e li mantiene lui, sulla base di un contratto di assistenza.

Quel contratto copre una configurazione precisa, che nel gergo commerciale si chiama configurazione certificata. Uscire da quella configurazione, e aggiornare il sistema operativo sottostante significa uscirne, fa decadere il supporto.

Il risultato è paradossale ma frequente.
Un’azienda che sa di avere una vulnerabilità critica, che ha il budget per correggerla e che non può farlo perché perderebbe l’assistenza sul sistema che manda avanti l’attività. La scelta non è fra sicuro e insicuro. È fra una vulnerabilità aperta e un gestionale senza nessuno che lo assista.

Nel caso dei macchinari il vincolo è ancora più rigido.
Un impianto sotto garanzia arriva con una configurazione stabilita dal costruttore, e toccarla significa assumersi la responsabilità di tutto quello che succede dopo: se la linea si ferma per un problema software, la garanzia non copre più niente.

Sono le stesse macchine di cui parliamo affrontando le vulnerabilità dei dispositivi IoT aziendali. In funzione per quindici anni, con il supporto software esaurito da dieci, e con un fornitore che per quel modello non rilascia più nulla.

C’è però una cosa che l’azienda può fare, e riguarda i contratti futuri.
La previsione di tempi massimi di aggiornamento dopo la pubblicazione di una vulnerabilità critica è una clausola che si negozia alla firma, quando il fornitore ha interesse a chiudere. A contratto già in essere il potere contrattuale è quasi nullo, e il tema si affronta come abbiamo descritto parlando di segnalazioni a un fornitore che non risponde.

Quando nessuno sa cosa gira davvero

C’è un ostacolo che precede tutti gli altri e li rende invisibili: non si aggiorna quello che non si sa di avere.

Un processo di patch management si applica a un elenco.
Se l’elenco è incompleto, il processo funziona perfettamente su quello che contiene e ignora tutto il resto. È il motivo per cui un inventario degli asset aggiornato non è un adempimento burocratico ma la precondizione tecnica di qualunque cosa venga dopo.

Il problema si estende ai componenti dentro i sistemi.
Un’applicazione web moderna include decine di librerie di terze parti, ciascuna con la propria versione e le proprie vulnerabilità, e nessuno le censisce. La vicenda di Log4Shell ha reso questa domanda famosa: quando esce una falla critica in una libreria diffusissima, sapere se la si ha installata richiede giorni di ricerca in molte organizzazioni.

E poi ci sono le installazioni che non compaiono da nessuna parte.
Il software messo su da un collega per una necessità temporanea, l’ambiente di prova dimenticato acceso, la macchina virtuale creata per una migrazione e mai spenta. Rientrano nella stessa famiglia delle configurazioni fuori controllo.

Le priorità costruite sul numero sbagliato

Anche dove il processo esiste, l’ordine con cui si interviene è spesso sbagliato. La causa è un fraintendimento su cosa misura il punteggio di gravità.

Il Common Vulnerability Scoring System dice quanto sarebbe grave una compromissione, non quanto è probabile che riguardi voi.
Un punteggio di 9,8 su un servizio che non avete esposto vale zero. Un 6,5 su un sistema raggiungibile da internet, con credenziali deboli e nessun secondo fattore, vale molto più di quanto quel numero suggerisca.

Ordinare le patch per gravità decrescente è quindi l’errore più comune.
L’ordine che riduce davvero il rischio tiene conto di tre cose insieme: se il sistema è raggiungibile, se esiste un codice di sfruttamento funzionante in circolazione, e cosa consegna quel sistema a chi lo compromette.

Il secondo punto merita attenzione perché è verificabile.
Esistono elenchi pubblici delle vulnerabilità per cui è documentato uno sfruttamento reale, e una vulnerabilità su quegli elenchi conta più di una con punteggio superiore su cui nessuno ha mai scritto un exploit. È un criterio che sposta le priorità in modo radicale, e lo abbiamo approfondito parlando di severity e rischio effettivo.

Che fare quando la patch non si può applicare

Questa è la parte che manca in tutti gli articoli sull’argomento, perché l’ipotesi di partenza è sempre che la patch si possa applicare.

Quando non si può, e per le ragioni viste sopra capita spesso, esiste un ventaglio di misure che riducono il rischio senza toccare il sistema.
Nessuna risolve il difetto. Tutte rendono più difficile raggiungerlo.

La prima è togliere il sistema dal perimetro raggiungibile.
Se quel servizio non deve rispondere da internet, va reso accessibile solo attraverso un canale di accesso controllato. Chiude la maggior parte degli scenari senza riavviare niente.

La seconda è la segmentazione.
Confinare il sistema vulnerabile in un’area separata con regole strette non impedisce la compromissione, ma limita quello che la compromissione consegna. È la differenza fra un incidente circoscritto e uno che si propaga a tutta la rete aziendale.

La terza sono le misure di contenimento specifiche della vulnerabilità: disattivare la funzione interessata, irrigidire una configurazione, imporre l’autenticazione prima del punto vulnerabile. I produttori le pubblicano spesso insieme all’avviso di sicurezza, proprio perché fra la divulgazione e la correzione passa tempo.

Su queste va detta una cosa che nessuno dice.
Sono provvisorie e vanno tracciate come tali, con una scadenza e un responsabile. Le misure temporanee che nessuno rimuove diventano configurazioni permanenti di cui a distanza di due anni nessuno ricorda la ragione.

Come si costruisce un processo che tiene

Le cose che fanno la differenza sono organizzative prima che tecniche, e sono poche.

Serve un titolare per ogni sistema.
Non un reparto, una persona: chi decide quando quel sistema si aggiorna e chi risponde se non viene aggiornato. Dove questa attribuzione manca, le patch restano in sospeso non perché qualcuno le rifiuti ma perché nessuno le approva.

Servono finestre di manutenzione concordate in anticipo con chi risponde della produzione, non negoziate ogni volta di corsa quando esce una vulnerabilità critica. Una finestra mensile stabilita a inizio anno costa una discussione sola.

Servono clausole nei contratti con i fornitori che stabiliscano entro quanto tempo una configurazione certificata viene aggiornata dopo la pubblicazione di una vulnerabilità critica.
È il punto su cui le aziende hanno meno potere e per questo va affrontato al momento della firma, non dopo.

E serve una verifica periodica che dica se il processo sta funzionando davvero, perché l’unico modo di saperlo è guardare i sistemi e non i registri di chi li amministra.
Un penetration test risponde alla domanda successiva: fra le vulnerabilità rimaste aperte, quali sono realmente sfruttabili e fin dove portano.