Verifica della gestione delle patch: quali report vogliono effettivamente vedere i revisori e i principali clienti

Gli aggiornamenti vengono eseguiti automaticamente, ma nessuno è in grado di dimostrarlo

La domanda del questionario sembra innocua: «Entro quale lasso di tempo vengono installati gli aggiornamenti di sicurezza critici e come lo verificate?» La risposta onesta in molte aziende è: Windows si aggiorna da solo, il resto avviene prima o poi e non c’è modo di dimostrarlo. È proprio qui che gli audit dei fornitori falliscono più spesso che a causa di una mancanza di tecnologia.

La cosa spiacevole è che spesso l’azienda è più preparata di quanto riesca a dimostrare. I sistemi sono aggiornati, ma nessuno è in grado di dire quanto siano aggiornati, da quando, su quanti dispositivi o quali vulnerabilità siano state corrette. Questo articolo spiega cosa vogliono effettivamente vedere i revisori e i principali clienti, quali report forniscono tali informazioni, in che modo differiscono i moduli di applicazione delle patch dei principali fornitori e quali limitazioni è necessario conoscere prima dell’acquisto.

Perché i revisori chiedono proprio lo stato delle patch, prima di ogni altra cosa?

Perché le vulnerabilità note al pubblico e non corrette sono tra i punti di accesso più comuni in assoluto — e perché, a differenza di molti altri fattori, questo aspetto può essere verificato oggettivamente. Un revisore non può valutare quanto il personale sia in grado di riconoscere il phishing. Tuttavia, può chiedere da quanto tempo risale la vulnerabilità critica più vecchia non corretta presente nel vostro inventario — e quel dato la dice lunga sull’organizzazione nel suo complesso.

Inoltre, questo argomento compare praticamente in ogni insieme di normative. La versione 2022 della norma ISO 27001 elenca la gestione delle vulnerabilità tecniche come un punto di controllo separato nella sezione 8.8. La Direttiva NIS 2 indica esplicitamente la gestione e la divulgazione delle vulnerabilità come una delle categorie di misure richieste. E lo Standard minimo svizzero per le TIC include la gestione delle vulnerabilità all’interno delle funzioni «Identificare» e «Proteggere». Chiunque elabori un questionario attinge a queste fonti: ecco perché le domande sono così simili.

È richiesto l’aggiornamento o è richiesta la prova?

Entrambe, ma è la prova che viene verificata. Questo è il punto in cui la maggior parte delle organizzazioni sottovaluta la questione. Un revisore non può verificare se i vostri dispositivi siano aggiornati: può solo vedere ciò che gli presentate.

In genere, sono richiesti quattro elementi. Primo, una politica scritta che specifichi le responsabilità e le scadenze in base alla gravità: ad esempio, le vulnerabilità critiche devono essere risolte entro quattordici giorni. Secondo, rapporti che dimostrino che le scansioni delle vulnerabilità vengono condotte regolarmente, con una tempistica chiara. In terzo luogo, un sistema di tracciamento dall’individuazione alla risoluzione che indichi chi ha fatto cosa e quando. In quarto luogo, una politica documentata sulle eccezioni per tutto ciò che non può essere corretto con una patch.

La lamentela più comune è di natura specifica: l’organizzazione contrassegna una vulnerabilità come risolta senza aver verificato tecnicamente che la patch sia stata effettivamente applicata. Un segno di spunta su un elenco non costituisce una prova; lo è invece una scansione ripetuta che non rilevi più la vulnerabilità.

Rispondere correttamente ai questionari sulla sicurezza dei principali clienti
mostra quali voci di tali questionari possono essere comprovate con il software degli endpoint e quali devono essere verificate tramite misure organizzative.

Gli aggiornamenti automatici di Windows non sono sufficienti?

Per il sistema operativo, sì; per il resto, no — e il resto costituisce la superficie di attacco più ampia. Gli aggiornamenti automatici di Microsoft coprono Windows e le applicazioni Microsoft. Non coprono tutto il resto che viene tipicamente installato su una workstation: programmi per PDF, browser diversi da Edge, strumenti di archiviazione, ambienti di runtime, software di manutenzione remota e applicazioni specifiche del settore.

Sono proprio questi programmi ad essere elencati nel questionario sotto la voce “applicazioni di terze parti”, ed è proprio di questi che, nella pratica, sono più spesso obsoleti perché nessuno se ne occupa individualmente. Un modulo di patch li gestisce a livello centrale e, così facendo, offre l’effetto collaterale che conta davvero: un elenco preciso di quali software siano effettivamente in uso. Questo inventario è il primo allegato richiesto per la maggior parte degli audit.

C’è un secondo punto da considerare: gli aggiornamenti automatici non possono essere controllati. Chiunque debba dimostrare che una patch è stata installata entro un determinato periodo di tempo ha bisogno di una pianificazione e di un report, non di un meccanismo che si avvia da solo in un momento qualsiasi.

Qual è la differenza tra gestione delle vulnerabilità e gestione delle patch?

La gestione delle vulnerabilità identifica e valuta le vulnerabilità; la gestione delle patch le risolve. Questa distinzione non è solo semantica: è il motivo per cui ad alcune domande del questionario non è possibile rispondere utilizzando solo un modulo di gestione delle patch.

Il processo si articola in quattro fasi: identificare quale software è installato e quali vulnerabilità note presenta; valutare quanto siano gravi e sfruttabili queste vulnerabilità all’interno del proprio ambiente; risolverle, solitamente tramite una patch; e verificare che la risoluzione sia stata efficace. La maggior parte dei prodotti di questa categoria copre tutte e quattro le fasi, motivo per cui vengono spesso definiti «Gestione delle vulnerabilità e delle patch».

La distinzione diventa importante quando non è disponibile alcuna patch, sia perché il fornitore non ne ha ancora rilasciata una, sia perché il software è giunto al termine del proprio ciclo di vita. In tali casi, ogni serie di linee guida richiede una misura alternativa e una decisione, non semplicemente l’inazione. Questo è proprio il motivo per cui la fase di valutazione è necessaria.

Quali scadenze dovrei fissare per le vulnerabilità critiche?

Una che si possa rispettare. Sembra ovvio, ma è l’unica regola sensata: una scadenza di sette giorni che viene regolarmente disattesa fa una peggiore impressione in un audit rispetto a una scadenza di trenta giorni che viene rispettata. Si è preso un impegno e non lo si è mantenuto.

È comune classificare le scadenze in base alla gravità, con scadenze diverse per le vulnerabilità critiche, ad alta e a media gravità. Tuttavia, la gravità da sola è un parametro debole. La classificazione diventa più significativa quando si tengono in considerazione due fattori aggiuntivi: se la vulnerabilità è già oggetto di sfruttamento attivo e se il sistema interessato è accessibile da Internet. Una vulnerabilità di gravità media su un server connesso a Internet — per la quale esistono già strumenti di attacco — è più urgente di una vulnerabilità critica su un sistema di test isolato.

Incorporate questa logica nella vostra politica. Un revisore che constati che stabilite le priorità in base alla possibilità di sfruttamento e all’esposizione piuttosto che rigorosamente in base al punteggio, considererà questo approccio come un processo maturo e accetterà scadenze più lunghe per la parte non critica.

Di quali report specifici ho bisogno?

Cinque report coprono la stragrande maggioranza di tutti i questionari e gli audit, e tutti e cinque provengono dalla console di gestione, non da un foglio di calcolo gestito autonomamente.

In primo luogo, l’elenco di inventario: quali dispositivi vengono gestiti e quale software è installato su di essi. In secondo luogo, il rapporto sulle patch mancanti, suddiviso per gravità: questo rapporto risponde alla domanda sullo stato attuale. In terzo luogo, lo stesso rapporto con informazioni sull’anzianità, ovvero da quanto tempo una vulnerabilità è rimasta aperta; questa è la metrica che un revisore utilizza per valutare la vostra conformità alle scadenze. In quarto luogo, l’elenco delle installazioni non riuscite, poiché una patch che non è stata installata correttamente non verrebbe mai individuata senza questo rapporto. In quinto luogo, la panoramica delle patch escluse intenzionalmente, insieme alle ragioni della loro esclusione.

Tutti questi report presentano due caratteristiche che mancano a una tabella gestita manualmente: una data e un ambito di applicazione. Il report non si limita a indicare che novantadue dispositivi sono aggiornati, ma precisa anche che il numero totale di dispositivi gestiti è novantaquattro. Questa differenza è esattamente ciò che serve.

Cosa devo fare con i sistemi su cui non è possibile applicare le patch?

Li si documenta come eccezioni, includendo il motivo, una soluzione alternativa, un limite di tempo e l’approvazione. Si tratta di una procedura riconosciuta e non di un’ammissione di debolezza. Ciò che non è riconosciuto è omettere del tutto di menzionare i sistemi interessati.

Esempi tipici includono un sistema di controllo macchine il cui produttore non concede l’approvazione per le versioni più recenti, un’applicazione specifica del settore che richiede un ambiente di esecuzione obsoleto o un sistema legacy che deve rimanere in funzione per motivi contrattuali. Le possibili misure correttive includono l’isolamento dalla rete, la limitazione dei diritti di accesso, il blocco dell’applicazione sul sistema interessato o un monitoraggio rafforzato.

È importante fissare un termine. Un’eccezione senza data di scadenza verrà segnalata durante il prossimo audit perché indica che nessuno sta più monitorando la situazione. Fissate una data entro la quale la decisione dovrà essere riesaminata, anche se è prevedibile che l’esito sarà lo stesso.

In che modo si differenziano i moduli di patch dei fornitori?

I moduli che aggiornano centralmente i sistemi operativi e le applicazioni di terze parti e forniscono report su tali aggiornamenti sono simili tra loro. Kaspersky offre la sua soluzione "Vulnerability and Patch Management" sia come prodotto autonomo sia come modulo aggiuntivo ai pacchetti esistenti e viene quindi trattata separatamente di seguito.

Funzionalità	Bitdefender GravityZone Patch Management	ESET Vulnerability & Patch Management	Gestione delle patch per aziende di Avast e AVG
Windows e applicazioni di terze parti	✓	✓	✓
macOS	✓	✓	✕
Linux	Limitata	✓	✕
La console può essere eseguita localmente	✓	✕	✕
Cache delle patch locale	✓	Vedi nota	✓
Informazioni CVE per ogni patch	✓	Vedi nota	Vedi nota
Patch ESU di Microsoft	Vedi nota	Vedi nota	✕
Disponibilità	Modulo aggiuntivo	Incluso a partire dalla versione Complete	Prodotto autonomo

Per quanto riguarda i campi aperti e quelli con restrizioni: su Linux, Bitdefender non aggiorna le applicazioni installate al di fuori del gestore di pacchetti e installa automaticamente solo le patch firmate digitalmente; per tutte le altre è necessario un intervento manuale, di cui occorre tenere conto nel processo. Per ESET, le informazioni relative agli identificatori CVE per ciascuna patch e alla cache locale non sono disponibili con lo stesso livello di dettaglio e dovrebbero quindi essere incluse nella proposta. Per Avast e AVG, è esplicitamente documentato che gli aggiornamenti di sicurezza estesi di Microsoft non sono supportati: un aspetto da considerare per qualsiasi organizzazione che utilizzi un sistema oltre la normale scadenza del supporto.

Qual è il prodotto giusto per ogni ambiente?

Per gli ambienti esclusivamente Windows che non utilizzano ancora un pacchetto aziendale di uno dei principali fornitori, i prodotti autonomi rappresentano l’opzione più rapida: Avast Business Patch Management ⧉ e AVG Patch Management Business Edition ⧉. Entrambi consentono di pianificare scansioni giornaliere, settimanali o mensili, visualizzare le patch mancanti insieme al loro livello di gravità e alla data di rilascio, ed escludere specifici fornitori o applicazioni. Per risparmiare larghezza di banda, la distribuzione viene gestita da un dispositivo selezionato sulla rete. Il limite è chiaro: solo Windows; nessun altro sistema operativo.

Se state già utilizzando GravityZone, potete aggiungere Bitdefender GravityZone Patch Management ⧉ come modulo aggiuntivo. Supporta Windows, Linux e macOS, mostra l’identificatore CVE per ogni patch, può bloccare singole patch se interferiscono con un flusso di lavoro e può posticipare il riavvio richiesto. Per la distribuzione all’interno della propria rete, è possibile configurare come cache anche un dispositivo con ruolo di relay.

Con ESET, il modulo fa parte del livello del pacchetto. È incluso a partire da ESET PROTECT Complete ⧉ e in ESET PROTECT Elite ⧉, che comprende anche il componente Detection and Response. Per i livelli Entry e Advanced, può essere aggiunto come funzionalità separata. Copre Windows, Linux e macOS, comprese le applicazioni di terze parti, e la funzionalità può essere estesa anche ai server, a condizione che questi utilizzino le versioni più recenti dei corrispondenti prodotti server ESET.

Kaspersky offre entrambe le opzioni: Kaspersky Vulnerability and Patch Management ⧉ come prodotto autonomo e Kaspersky Vulnerability and Patch Management come componente aggiuntivo ⧉ a integrazione di un pacchetto Kaspersky esistente. L’opzione disponibile dipende dal prodotto di base e deve essere chiarita prima di effettuare l’ordine.

Base, Base Plus, Add-On o Rinnovo: cosa significano questi termini
Spiega come interpretare i nomi dei pacchetti disponibili sul mercato e quali di essi richiedono una licenza esistente.

È possibile che io disponga già del modulo di gestione delle patch?

È possibile, e vale la pena verificarlo prima di effettuare qualsiasi ordine. Diversi fornitori hanno incluso la gestione delle patch nei loro pacchetti di livello superiore invece di venderla separatamente.

Con Kaspersky, la gestione delle patch è inclusa nel livello Next EDR Optimum; con ESET, è inclusa a partire da PROTECT Complete; e anche ThreatDown Advanced ⧉ la include come parte del pacchetto. Chiunque possieda già una licenza per uno di questi livelli non ha bisogno di un prodotto aggiuntivo; deve semplicemente attivare e configurare la funzionalità — cosa che, in pratica, viene sorprendentemente spesso trascurata perché nessuno si rende conto che sia inclusa.

Al contrario, con Bitdefender la gestione delle patch non è inclusa in nessun livello di pacchetto, ma è sempre un modulo aggiuntivo a pagamento. Un’offerta per GravityZone che non includa questa voce non soddisfa i requisiti del questionario.

Quali sono le insidie da tenere d’occhio al momento dell’acquisto?

Tre, che spesso si notano solo dopo aver effettuato l’ordine.

La prima riguarda ESET: secondo il produttore, la gestione delle vulnerabilità e delle patch non è disponibile nella versione della console di gestione gestita localmente, ma richiede la console cloud. Le organizzazioni che gestiscono deliberatamente i propri sistemi internamente — ad esempio, a causa di requisiti specifici legati alla sede — non possono utilizzare questa funzionalità in tale contesto. Non si tratta di un dettaglio di poco conto, ma di una decisione fondamentale che deve essere presa prima dell’acquisto.

La seconda questione riguarda l’elenco dei software. Ogni modulo aggiorna solo ciò che è elencato nel proprio catalogo. Questi cataloghi sono ampi e vengono continuamente ampliati, ma non coprono mai tutto. Bitdefender pubblica un elenco scaricabile dei fornitori e dei prodotti supportati, aggiornato mensilmente. Prima dell’acquisto, verificate se le vostre applicazioni più importanti siano incluse: il software specifico di settore, in particolare, è raramente elencato e deve quindi essere gestito manualmente, operazione che dovrete documentare separatamente.

Il terzo punto riguarda i server. Un modulo di patch che copre solo le workstation risponde solo parzialmente alla domanda del questionario, poiché la domanda si riferisce all’intera infrastruttura. È necessario chiarire se le licenze per i server includono le stesse funzionalità e se per essi sono richiesti elementi separati.

Protezione dei server, Exchange e server di file: perché le licenze per endpoint non sono sufficienti
Spiega perché i server richiedono licenze e prodotti dedicati e quali ruoli aggiuntivi devono essere coperti.

Come gestire i riavvii?

Utilizzate finestre di manutenzione programmate anziché richieste ad hoc. I riavvii sono il motivo per cui la gestione delle patch fallisce in molte organizzazioni: nessuno vuole riavviare il server durante l’orario di lavoro e la sera non c’è nessuno in sede.

I moduli risolvono questo problema attraverso due meccanismi. Innanzitutto, la scansione può essere separata dall’installazione: le scansioni vengono eseguite quotidianamente, mentre le installazioni avvengono a un orario programmato. In secondo luogo, il riavvio può essere posticipato in modo che la patch venga installata ma non diventi effettiva fino al successivo riavvio regolare.

Per quanto riguarda la verifica, c’è un aspetto cruciale ma facilmente trascurato: una patch che è stata installata ma non è ancora attiva non risolve la vulnerabilità. Se il vostro report considera tali casi come risolti, state verificando uno stato che non esiste. Pertanto, definite per quanto tempo un riavvio in sospeso possa rimanere aperto e trattate eventuali casi che superino tale limite come una vulnerabilità aperta.

In che modo la gestione delle patch aiuta ad adempiere agli obblighi di segnalazione in Svizzera?

A partire dal 1° aprile 2025, i gestori di infrastrutture critiche devono segnalare gli attacchi informatici all’Ufficio federale per la sicurezza informatica entro 24 ore dalla scoperta, in conformità con la legge sulla sicurezza dell’informazione (ISG) e l’ordinanza sulla sicurezza informatica; le informazioni mancanti possono essere fornite entro 14 giorni. Ciò si applica alle agenzie governative e alle organizzazioni definite nell’art. 74b della Legge sulla sicurezza dell’informazione (ISG); sono previste eccezioni per le organizzazioni di dimensioni più ridotte e per gli incidenti con impatti minori.

Lo stato delle patch non ha un ruolo diretto nella segnalazione stessa. Tuttavia, diventa importante immediatamente dopo, in particolare per determinare in che modo l’autore dell’attacco abbia ottenuto l’accesso. Se si scopre che è stata sfruttata una vulnerabilità nota da mesi e per la quale era disponibile una patch, lo scenario è diverso rispetto a un attacco tramite una vulnerabilità sconosciuta al momento dell’incidente. Un rapporto che documenti lo stato delle patch del sistema interessato al momento dell’incidente è quindi uno dei documenti più preziosi in assoluto, a condizione che sia stato generato e conservato prima dell’incidente.

Cosa non fa la gestione delle patch: non determina se la vostra organizzazione sia soggetta a obblighi di segnalazione, non rileva un attacco in corso e non sostituisce una responsabilità designata in materia di segnalazione.

Cosa richiede la direttiva NIS 2 in merito alle vulnerabilità?

La direttiva elenca la gestione e la divulgazione delle vulnerabilità come una delle categorie di misure che le organizzazioni interessate devono attuare. Non prescrive alcun software specifico né una scadenza concreta: ciò che è richiesto è una procedura che venga applicata in modo dimostrabile.

Ciò è supportato dalle scansioni, dalla definizione delle priorità e dai rapporti generati da un modulo di gestione delle patch. Gli aspetti organizzativi non sono coperti: la definizione scritta delle scadenze, le responsabilità designate, la gestione delle segnalazioni esterne relative alle vulnerabilità scoperte e la verifica periodica dell’effettiva efficacia della procedura. Nessun prodotto può occuparsi di questi punti.

Le organizzazioni che devono conformarsi sia ai requisiti svizzeri che a quelli europei si trovano di fronte a due serie di normative che differiscono in termini di scadenze e terminologia.

Un confronto tra gli obblighi di sicurezza informatica in Svizzera e nell’UE
mette a confronto gli obblighi di segnalazione svizzeri con quelli della direttiva NIS 2 ed evidenzia i punti di divergenza.

Cosa non copre un modulo di patch?

Tutto ciò che non è un sistema operativo o un’applicazione installata — e si tratta di più di quanto si possa pensare.

Non sono coperti il firmware dei dispositivi di rete, i firewall, gli access point, le stampanti e i sistemi NAS. Eppure sono proprio questi dispositivi ad essere direttamente connessi a Internet e le cui vulnerabilità vengono sfruttate con particolare frequenza. Sono esclusi anche i sistemi di controllo delle macchine, i servizi cloud in cui è il provider a gestire gli aggiornamenti e il software che ha raggiunto la fine del proprio ciclo di vita e per il quale semplicemente non sono più disponibili patch.

Per queste aree, è necessario un secondo processo, solitamente manuale, con un proprio elenco e una propria pianificazione. Chiunque spunti la casella nel questionario indicando che tutti i sistemi sono integrati nella gestione delle patch — mentre i firewall e i dispositivi NAS sono gestiti separatamente — sta fornendo informazioni che non reggerebbero a un esame approfondito.

Come posso iniziare in trenta giorni?

Nella prima settimana, assicuratevi la visibilità: attivate o procuratevi il modulo, integrate tutti i dispositivi ed eseguite una scansione completa iniziale. L’esperienza dimostra che i risultati sono spesso inquietanti – ed è proprio per questo che sono preziosi – perché rivelano per la prima volta l’inventario effettivo.

Nella seconda e terza settimana, smaltite l’arretrato, iniziando da tutto ciò che è accessibile da Internet, e contemporaneamente documentate le linee guida: chi è responsabile, quali scadenze si applicano in base alla gravità, quando eseguire la scansione, quando installare e come vengono approvate le eccezioni. È sufficiente una pagina; deve solo essere datata e approvata.

Nella quarta settimana, si genera la prima serie di report e li si archivia. È proprio questo report archiviato e datato che funge da prova richiesta dalle persone — e dal momento in cui si inizia a ripetere questo processo mensilmente, un’istantanea si trasforma in una cronologia verificabile. Questa è la vera differenza tra un’azienda che applica le patch alle vulnerabilità e una che è in grado di dimostrarlo.

 

 

---