CompTIA SY0-701: Gestione delle Vulnerabilità e delle Patch — Guida allo studio

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fa parte della CompTIA Security+ SY0-701 — Guida allo studio. Esercitati con risposte verificate nel centro esami CompTIA, oppure fai test cronometrati su ExamRoll.io.

La gestione delle vulnerabilità (vulnerability management) è il processo continuo di identificazione, classificazione, risanamento e verifica delle debolezze di sicurezza nell’intero patrimonio tecnologico di un’organizzazione. Non è un progetto con una data di fine, ma una disciplina operativa che deve tenere il passo con un panorama delle minacce che produce centinaia di nuove CVE ogni settimana.

Il ciclo di vita della gestione delle vulnerabilità

Il ciclo di vita inizia con l’individuazione degli asset (asset discovery): non è possibile proteggere ciò che non si sa di possedere. La scansione attiva (Nessus, Qualys, Rapid7) sonda la rete alla ricerca di host attivi e servizi aperti. L’individuazione passiva (analisi del traffico di rete, log DHCP, integrazione con CMDB) rileva gli asset che le scansioni attive non colgono. Gli ambienti cloud richiedono un’individuazione basata su API, poiché la scansione di rete tradizionale non è in grado di enumerare funzioni serverless, servizi gestiti o container effimeri.

La scansione segue l’individuazione. Le scansioni autenticate forniscono una visibilità completa su software installato, livelli di patch e debolezze di configurazione. Le scansioni non autenticate sono utili per la valutazione della superficie di attacco esterna, ma non rilevano la maggior parte delle vulnerabilità. La frequenza delle scansioni dovrebbe essere commisurata al rischio: asset esposti a Internet settimanalmente, server interni mensilmente, workstation mensilmente con monitoraggio continuo basato su agent.

La prioritizzazione utilizza il CVSS come base di partenza, ma deve integrare il contesto. Una vulnerabilità con CVSS 9.8 su un server di sviluppo air-gapped è meno urgente di una vulnerabilità con CVSS 7.5 su un endpoint di autenticazione pubblico. I punteggi EPSS, l’appartenenza al catalogo KEV, la criticità degli asset e i controlli di compensazione contribuiscono a modificare la priorità effettiva. L’obiettivo non è applicare tutte le patch, ma applicare prima quelle giuste.

Le opzioni di risanamento (remediation) includono l’applicazione di patch (preferibile), la modifica della configurazione (disabilitando una funzionalità vulnerabile), il patching virtuale (una regola WAF che blocca l’exploit), l’isolamento di rete o l’accettazione formale del rischio con motivazione documentata. Gli SLA per il risanamento devono essere definiti e monitorati; le eccezioni richiedono un’approvazione e un controllo di compensazione.

La verifica conferma l’efficacia del risanamento. Una nuova scansione dopo l’applicazione della patch conferma che la vulnerabilità non è più presente. La verifica viene spesso saltata per mancanza di tempo, portando a situazioni in cui una patch è stata distribuita ma non applicata correttamente, o in cui la vulnerabilità è stata risanata su un’istanza ma non su altre dello stesso livello (tier).

Operazioni di gestione delle patch (Patch Management)

La gestione delle patch (patch management) rende operativa la fase di risanamento. Un programma maturo include una pipeline di test delle patch: le patch vengono applicate prima a un ambiente di non produzione, validate per compatibilità e funzionalità, e poi promosse in produzione attraverso un processo di change management. Le patch di emergenza per vulnerabilità attivamente sfruttate possono saltare il ciclo di test completo con un’approvazione accelerata della modifica.

Windows Server Update Services (WSUS) e Microsoft Endpoint Configuration Manager (MECM/SCCM) sono strumenti comuni per la gestione su larga scala delle patch di Windows. Gli ambienti Linux utilizzano gestori di pacchetti (apt, yum, dnf) combinati con strumenti di automazione (Ansible, Puppet, Chef) per imporre lo stato delle patch. Gli ambienti cloud-native utilizzano AWS Systems Manager Patch Manager, Azure Update Management o servizi equivalenti.

Il reporting sulla conformità delle patch (patch compliance) monitora la percentuale di asset che rispettano gli SLA per ogni livello di gravità. Una dashboard che mostra una conformità del 94% per le patch critiche può sembrare accettabile, finché non ci si rende conto che il 6% di 10.000 endpoint corrisponde a 600 sistemi senza patch, ognuno dei quali è un potenziale punto di ingresso. I numeri assoluti contano tanto quanto le percentuali.

Gestione della configurazione e baseline

La gestione della configurazione (configuration management) mantiene i sistemi in uno stato noto e sicuro. Le baseline di configurazione definiscono lo stato approvato per ogni tipo di sistema; il rilevamento delle deviazioni (drift detection) identifica gli scostamenti da tale baseline. Strumenti come CIS-CAT Pro, OpenSCAP e servizi cloud-native (AWS Config, Azure Policy) valutano continuamente la conformità della configurazione e avvisano in caso di deviazioni.

Il change management (gestione delle modifiche) governa le modifiche ai sistemi di produzione. Ogni modifica dovrebbe avere una motivazione documentata, una valutazione del rischio, un piano di rollback e l’approvazione degli stakeholder appropriati. Le modifiche di emergenza, richieste al di fuori della normale finestra di modifica, seguono un processo accelerato con una revisione post-implementazione. Le modifiche non autorizzate, rilevate dagli strumenti di gestione della configurazione, sono trattate come eventi di sicurezza fino a prova contraria.

Scenario pratico: risposta a Log4Shell sotto pressione

Quando la CVE-2021-44228 (Log4Shell) è stata resa pubblica il 9 dicembre 2021, con un punteggio CVSS di 10.0 e sfruttamento attivo entro poche ore dalla sua divulgazione, le organizzazioni hanno affrontato una crisi che ha messo alla prova ogni aspetto dei loro programmi di gestione delle vulnerabilità. Un’azienda tecnologica con un programma maturo ha risposto come segue: entro due ore, il team di sicurezza ha interrogato il proprio inventario degli asset per tutte le applicazioni Java e ha identificato 847 sistemi potenzialmente interessati. Entro sei ore, tramite scansioni autenticate, avevano confermato che 312 sistemi eseguivano versioni vulnerabili di Log4j. Entro 24 ore, avevano implementato regole WAF per bloccare il pattern di stringa ${jndi: come controllo di compensazione temporaneo su tutti i sistemi esposti a Internet. Entro 72 ore, l'89% dei sistemi critici era stato patchato. Il restante 11% è stato isolato in segmenti di rete ristretti, in attesa dell’approvazione delle finestre di patching da parte dei proprietari delle applicazioni. Il successo del programma dipendeva da tre prerequisiti che a molte organizzazioni mancavano: un inventario degli asset completo e accurato; la capacità di eseguire scansioni autenticate; e procedure di modifica di emergenza pre-approvate che potessero essere invocate senza un ciclo di approvazione di una settimana.

← Sicurezza di Endpoint · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →