// Glossario IT

Patch Management

Il processo (non l'evento) che tiene aggiornati sistemi e software prima che una falla nota diventi un incidente.

Cos'è

Il patch management è il processo organizzato con cui un'azienda identifica, testa e distribuisce gli aggiornamenti di sicurezza per sistemi operativi, applicazioni, driver e firmware. Non è "cliccare aggiorna quando compare la notifica": è un ciclo con priorità (le vulnerabilità critiche già sfruttate attivamente in the wild vanno prima di quelle solo teoriche), una fase di test in un ambiente di staging prima del rilascio in produzione — perché un aggiornamento mal digerito può rompere un gestionale critico quanto una vulnerabilità può essere sfruttata da un attaccante — e una verifica finale che la patch sia stata effettivamente applicata ovunque serva, non solo dove il tool di deployment ha riportato successo. Nella pratica gestisco superfici diverse con logiche diverse: i sistemi operativi hanno cicli di rilascio prevedibili (il Patch Tuesday di Windows, per dire), i firmware di rete e i dispositivi IoT molto meno, e vanno tracciati a parte perché è lì che l'inventario si perde più facilmente.

Perché conta

Una parte enorme degli incidenti che finiscono sui giornali sfrutta vulnerabilità note da mesi o anni, per cui la patch esisteva già ed era rimasta applicata solo su parte del parco macchine — quasi mai per scelta, quasi sempre per mancanza di un processo che tenesse traccia di cosa fosse rimasto indietro. La gestione delle patch è una delle misure esplicitamente richieste dalle specifiche di base ACN per la NIS2, ed è probabilmente la più economica da implementare rispetto al danno che previene: costa ore di lavoro pianificato, non un incident response nel weekend. Quello che ho imparato gestendo parchi macchine reali è che il collo di bottiglia non è quasi mai la disponibilità della patch, ma la finestra di manutenzione concordata con il business: un sistema che non si può mai fermare diventa, quasi sempre, il sistema più vecchio e più vulnerabile del parco.

Le priorità che applico in pratica

Nella pratica lavoro con fasce di priorità concordate a monte, non decise caso per caso quando arriva l'allerta: le vulnerabilità critiche già note come sfruttate attivamente (quelle che finiscono nel catalogo KEV) hanno una finestra di 72 ore, le vulnerabilità critiche non ancora sfruttate una settimana, tutto il resto rientra nel ciclo mensile ordinario. Per i sistemi che non posso permettermi di rompere — un ERP, un gestionale di produzione — il passaggio in staging non è negoziabile, anche quando la pressione a chiudere subito è alta. Le linee guida CISA su patch e vulnerability management sono un buon punto di partenza per strutturare queste fasce, se si parte da zero.

// Nota pratica

Il punto dove le aziende si perdono di più non è decidere se aggiornare, ma sapere con certezza *cosa* hanno da aggiornare: un inventario di asset aggiornato è il prerequisito reale di un patch management efficace, più della velocità con cui si applicano le patch stesse.