Patch management: cos'è e come si organizza

La risposta breve: il patch management è il processo con cui un'organizzazione individua, mette in ordine di priorità, recupera e installa patch, aggiornamenti e upgrade del software, e ne verifica l'installazione, su tutti i suoi asset: postazioni, server, apparati di rete, cloud, dispositivi OT e IoT. Non coincide con l'installare gli aggiornamenti. È decidere in anticipo cosa si aggiorna, in che ordine, entro quando, e cosa si fa quando una patch non c'è.

Qui vediamo come lo imposta il NIST, come si decidono le priorità con il catalogo KEV della CISA e cosa chiedono le misure NIS2 dell'ACN e la ISO 27001.

Cos'è il patch management

La definizione della risposta breve è quella della NIST SP 800-40 Rev. 4 (aprile 2022), la guida alla pianificazione del patch management in azienda. La patch, nella stessa guida, è una modifica al software installato (firmware, sistema operativo o applicazione) che corregge problemi di sicurezza o di funzionamento, oppure aggiunge funzioni.

Il punto della Rev. 4 non è tecnologico. NIST parte da una frattura nota a chi lavora in IT: il business vede nel patching fermi e rischio di rompere qualcosa, la sicurezza una riduzione del rischio. La guida propone di trattarlo come manutenzione preventiva, come quella di una flotta aziendale: un costo normale di esercizio, da seguire e misurare. E ricorda che i fermi causati da una patch sono in gran parte controllabili, quelli causati da un incidente no.

Patch management e vulnerability management

La gestione delle vulnerabilità è il ciclo più ampio: sapere quali vulnerabilità toccano i propri asset, decidere come rispondere, eseguire e verificare. La patch è una delle risposte possibili. La SP 800-40 ne elenca quattro:

• Accettare il rischio, per esempio perché i controlli esistenti bastano o perché l'impatto è basso.
• Mitigare, eliminando la vulnerabilità (patch, upgrade, disattivazione della funzione vulnerabile) o aggiungendo controlli come la segmentazione di rete.
• Trasferire una parte delle conseguenze, con una polizza cyber o passando a un servizio SaaS in cui le patch le applica il fornitore.
• Evitare, togliendo il software vulnerabile o dismettendo l'asset.

Secondo NIST, patch e upgrade sono le uniche risposte che eliminano la vulnerabilità senza togliere funzioni. Non sempre sono subito praticabili: la patch può non esistere ancora, il prodotto può essere a fine vita, il produttore può imporre tempi lunghi di certificazione, come succede in settori regolati su apparati da cui dipende la sicurezza delle persone. Per questo il processo prevede anche le alternative.

Per trovare le vulnerabilità da correggere servono le scansioni, che spieghiamo nell'articolo sul vulnerability assessment. Qui ci concentriamo su cosa succede dopo.

Il ciclo di vita di una patch

La SP 800-40 Rev. 4 scompone l'esecuzione in quattro fasi:

1. Preparare. Si assegna la priorità, si pianifica dentro il change management, si recupera la patch e se ne verificano autenticità e integrità prima di provarla o installarla: può arrivare da una fonte malevola o essere alterata lungo la strada.
2. Distribuire e installare. Spesso la patch fa effetto solo dopo un riavvio o un cambio di configurazione. NIST avverte che può modificare per errore impostazioni di sicurezza esistenti e a volte costringe a tornare alla versione precedente o al backup.
3. Verificare. Si controlla che la patch sia installata e attiva; su numeri reali, osserva la guida, servono strumenti automatici.
4. Monitorare nel tempo. Una patch può sparire: un utente o un attaccante la disinstalla, una versione vecchia rientra da un backup, il dispositivo torna alle impostazioni di fabbrica.

Come si organizza: le raccomandazioni NIST

La sezione 3 della Rev. 4 dice come pianificare prima che arrivi la prossima vulnerabilità critica. Il principio: valutare da zero ogni nuova vulnerabilità non è sostenibile, quindi le decisioni si preparano in anticipo.

Un inventario che si aggiorna da solo

Senza sapere quale software gira su quale asset, fino a pacchetti e librerie, non si sa cosa aggiornare. NIST scrive che il vecchio modello, l'inventario aggiornato una volta al mese o al trimestre con una scansione, non va più usato: serve una scoperta continua, con scansioni autenticate. Per ogni asset si registrano anche quanto conta per il business, chi lo amministra, i vincoli contrattuali o normativi sul suo aggiornamento e quando può essere riavviato.

Quattro scenari

• Patching ordinario: le patch a cadenza regolare, la maggior parte del lavoro.
• Patching d'emergenza: una vulnerabilità grave o già sfruttata attivamente.
• Mitigazione d'emergenza: la patch non c'è ancora o è difettosa, quindi si interviene in via temporanea, isolando l'asset o disattivando una funzione.
• Asset non aggiornabili: sistemi a fine vita o che devono girare senza interruzioni, da isolare con misure di lungo periodo.

Gruppi di manutenzione e piani per ciascuno

Ogni asset va in un gruppo di manutenzione, un insieme di asset con esigenze simili: per esempio i portatili degli utenti, tolleranti al fermo; il datacenter, vincolato alle finestre di manutenzione; gli apparati OT legacy, che non ricevono più patch e restano isolati in rete. Per ogni gruppo e per ogni scenario si scrive un piano con le azioni e i tempi di inizio e fine.

Anche un asset che non si può aggiornare ha esigenze di manutenzione, quindi NIST lo mette in un gruppo con il suo piano invece di chiamarlo eccezione. Le eccezioni che restano si tracciano e si rivedono.

Rilascio graduale e scadenza obbligata

Per il patching ordinario la guida consiglia il rilascio a fasi: la patch va prima a un piccolo gruppo di asset sentinella, poi si allarga, ed è così che viene testata. Agli utenti si lascia un periodo di tolleranza, scaduto il quale l'installazione si forza, anche negando l'accesso alla rete a chi non è aggiornato. In emergenza lo schema è lo stesso, con il passaggio sulle sentinelle ridotto a minuti o ore.

Come decidere le priorità: il catalogo KEV della CISA

Il punteggio CVSS dice quanto è grave una vulnerabilità in astratto, non se qualcuno la sta usando. Il catalogo KEV (Known Exploited Vulnerabilities) della CISA, l'agenzia statunitense per la cybersecurity, risponde a questa seconda domanda. Una vulnerabilità entra nel catalogo se soddisfa tre criteri: ha un identificativo CVE, ci sono prove affidabili che sia sfruttata attivamente, esiste un'azione di rimedio chiara, come un aggiornamento del produttore.

Nella versione del 30 settembre 2026 il catalogo conta 1.730 vulnerabilità; per 361 di queste CISA indica un uso noto in campagne ransomware. CISA raccomanda a tutte le organizzazioni, non solo a quelle federali, di monitorare il catalogo e di usarlo come input del proprio schema di priorità, accanto agli altri criteri.

Dalla BOD 22-01 alla BOD 26-04

Il 10 giugno 2026 CISA ha emesso la Binding Operational Directive 26-04, che revoca la BOD 22-01 del 2021 e cambia il modello. La 22-01 fissava due settimane per le vulnerabilità del catalogo (sei mesi per i CVE assegnati prima del 2021), ed è il termine che cita ancora la SP 800-40 Rev. 4. La 26-04 fa dipendere i tempi da quattro domande:

• l'asset è esposto pubblicamente?
• la vulnerabilità è nel catalogo KEV?
• un attaccante può automatizzare tutti i passi dello sfruttamento?
• dopo lo sfruttamento ottiene il controllo totale o parziale dell'asset?

Le risposte portano a quattro fasce in giorni di calendario: 3 giorni nei casi più gravi, a cui si aggiunge un'analisi forense per capire se il sistema è già compromesso quando, per esempio, un asset esposto ha una vulnerabilità del catalogo che dà il controllo totale; 14 o 60 giorni nei casi intermedi; correzione al prossimo upgrade programmato per un asset interno con una vulnerabilità fuori dal catalogo e non automatizzabile. La direttiva vincola solo le agenzie civili federali statunitensi, ma la sua tabella è un buon modello per la propria matrice dei tempi: incrocia esposizione, sfruttamento reale e impatto, invece di guardare solo il punteggio.

Cosa chiedono NIS2 e ISO 27001

NIS2 in Italia

Il D.Lgs. 138/2024, all'art. 24 comma 2 lettera e), mette tra gli elementi che le misure di gestione del rischio devono comprendere almeno la "sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità". Il dettaglio operativo sta nelle misure di sicurezza di base della determinazione ACN 379907/2025, che si applica dal 15 gennaio 2026. La pagina ACN sulle modalità e specifiche di base fissa l'adozione entro 18 mesi dalla comunicazione di inserimento nell'elenco nazionale NIS, e indica ottobre 2026.

Per soggetti importanti (allegato 1) ed essenziali (allegato 2) le misure sul patching sono le stesse nella sostanza:

• PR.PS-02, punto 1: si installa solo software, sistemi operativi compresi, per cui è garantita la disponibilità di aggiornamenti di sicurezza.
• PR.PS-02, punto 2: gli ultimi aggiornamenti di sicurezza del produttore si installano "senza ingiustificato ritardo", in coerenza con il piano di gestione delle vulnerabilità.
• ID.RA-08, punti 1 e 2: si monitorano almeno i canali del CSIRT Italia e degli eventuali CERT e ISAC di settore, e le vulnerabilità sono "prontamente risolte" con aggiornamenti o mitigazioni, oppure accettando e documentando il rischio nel piano di trattamento dei rischi.
• ID.RA-08, punti 3 e 4: serve un piano di gestione delle vulnerabilità documentato, con modalità, ruoli e responsabilità, approvato dagli organi di amministrazione e direttivi.

Ai soggetti essenziali l'allegato 2 chiede due cose in più: verificare in ambiente di test l'aggiornamento del software ritenuto critico prima di portarlo in produzione (PR.PS-02, punto 4) e monitorare anche i canali dei fornitori di quel software (ID.RA-08, punto 5). In entrambi gli allegati, se per ragioni normative o tecniche motivate e documentate non si applicano i punti della PR.PS-02 elencati nella tabella 2, il piano di trattamento dei rischi (ID.RA-06) deve descrivere le misure compensative adottate e il rischio residuo.

Il quadro completo degli obblighi è nella nostra guida completa alla NIS2.

ISO/IEC 27001:2022

Nell'Annex A il tema corrisponde al controllo 8.8, gestione delle vulnerabilità tecniche; in audit servono inventario, piano, tempi, prove di installazione ed eccezioni motivate. Il dettaglio dei controlli è nell'articolo sui requisiti dell'Annex A.

Gli errori più comuni

• Rimandare il patching ordinario. NIST lo dice in chiaro: ogni rinvio lascia una finestra in più agli attaccanti e rende più lenta l'emergenza successiva, perché prima di installare la patch urgente bisogna recuperare quelle da cui dipende.
• Misurare solo la percentuale di sistemi aggiornati. Per la SP 800-40 non porta a nessuna decisione: un 10% di asset non aggiornati è grave se sono i più importanti, ragionevole se sono i meno importanti. Meglio misurare, per importanza dell'asset e gravità della vulnerabilità, la quota corretta entro la scadenza del piano e i tempi medi e mediani.
• Mitigazioni temporanee che diventano permanenti. Un workaround serve finché non arriva la patch. NIST chiede di fissare e far rispettare una scadenza sia per installare la patch sia per rimuovere la mitigazione.
• Sistemi fuori perimetro. OT, apparati di rete e macchine legacy restano fuori dal ciclo perché il processo è stato pensato per le postazioni. Per quelli contano isolamento e configurazione, di cui parliamo nell'articolo sull'hardening dei sistemi.

In sintesi

Il patch management è manutenzione preventiva pianificata: inventario continuo, gruppi di asset con un piano per ogni scenario, priorità decise su esposizione, sfruttamento reale e impatto, verifica che la patch resti installata. Il catalogo KEV della CISA è un input concreto per le priorità; per i soggetti NIS le misure ACN PR.PS-02 e ID.RA-08 chiedono aggiornamenti senza ingiustificato ritardo, un piano approvato dai vertici ed eccezioni documentate.

Se vuoi capire quanto tempo restano aperte le vulnerabilità sui tuoi sistemi e come portare il processo in linea con le misure ACN, puoi partire dai nostri servizi di cybersecurity.