Gestione delle patch e SLA

La prioritizzazione indica cosa correggere; la gestione delle patch è il processo disciplinato che porta effettivamente a completare queste correzioni, nei tempi previsti e sull'intero parco di sistemi.

SLA (accordi sui livelli di servizio) definiscono la rapidità con cui devono essere corrette le diverse gravità. Senza di essi, le correzioni urgenti vengono rimandate e la responsabilità si perde.

Un ciclo ripetibile mantiene aggiornati i sistemi:

• Identificare le patch disponibili (avvisi dei fornitori, risultati delle scansioni).
• Valutare la pertinenza e il rischio dell'applicazione.
• Testare in un ambiente non di produzione.
• Distribuire in ondate controllate.
• Verificare che la patch sia stata applicata e che il sistema sia integro.

Ogni passaggio ha responsabili ed evidenze, rispecchiando il più ampio ciclo di vita della VM.

Un SLA trasforma l'intenzione in una scadenza. Stabilisce il tempo massimo consentito dalla scoperta alla correzione, graduato in base alla gravità. Esempi di obiettivi:

• Critica / KEV: 7-15 giorni (o meno per i sistemi esposti a Internet).
• Alta: 30 giorni.
• Media: 90 giorni.
• Bassa: secondo disponibilità / ciclo successivo.

Gli SLA rendono misurabile il tempo di permanenza e creano pressione per chiudere le rilevazioni, non solo per prenderne atto.

Colleghi la scadenza al rischio reale, non solo a CVSS. Una vulnerabilità critica presente in KEV o esposta a Internet dovrebbe avere uno SLA più stringente di una vulnerabilità di gravità media interna.

I framework di riferimento sono utili: CISA impone alle agenzie federali di correggere le vulnerabilità KEV entro scadenze stabilite e molte aziende adottano tempistiche accelerate analoghe per le vulnerabilità sfruttate attivamente, indipendentemente dal punteggio CVSS.

Le patch possono causare problemi. I test in staging rilevano le regressioni prima che raggiungano la produzione:

• Applichi prima la patch a un gruppo di test rappresentativo.
• Convalidi le funzionalità critiche e le prestazioni.
• Verifichi che non vi siano conflitti con il software esistente.

Bilanci velocità e sicurezza: per una vulnerabilità KEV sfruttata attivamente, accetti un rischio maggiore e applichi la patch più rapidamente rispetto a un aggiornamento ordinario.

Distribuisca in ondate (ring deployment): prima il gruppo pilota, poi anelli più ampi e infine tutti i sistemi. Monitori l'integrità a ogni livello prima di procedere.

Disponga sempre di un piano di rollback: snapshot, downgrade del pacchetto o ripristino della configurazione. Se una patch causa un'interruzione, deve essere possibile ripristinarla rapidamente mentre si svolgono le verifiche.

La gestione manuale delle patch non è scalabile. Utilizzi strumenti centralizzati:

• WSUS / SCCM / Intune per Windows.
• Gestione della configurazione (Ansible, Puppet, Chef) per i parchi Linux.
• Immagini golden/base ricreate con le patch per il cloud e i container.

L'automazione garantisce la coerenza e riduce l'intervallo tra il rilascio della patch e la sua distribuzione.

A volte non è possibile applicare subito una patch: a causa di ritardi del fornitore, di un sistema legacy fragile o di requisiti di disponibilità continua. Applichi controlli compensativi per ridurre nel frattempo il rischio:

• Segmentazione della rete / regole firewall.
• Virtual patching tramite firme WAF o IPS.
• Disabilitazione della funzionalità o del servizio vulnerabile.

Queste misure offrono tempo, ma non sostituiscono permanentemente la correzione effettiva.

I sistemi fuori supporto possono non avere alcuna patch. Le opzioni includono:

• Isolarli su un segmento di rete limitato.
• Proteggerli con rigidi controlli di accesso e monitoraggio.
• Pianificare migrazione/dismissione con una scadenza.
• Accettare formalmente il rischio residuo con una data di scadenza.

Documenti tutto: un sistema non aggiornabile lasciato senza documentazione rappresenta un rischio per gli audit e per le violazioni.

Monitori se il programma rispetta effettivamente i propri impegni:

• MTTR per gravità rispetto all'obiettivo SLA.
• Tasso di conformità agli SLA (percentuale chiusa entro la scadenza).
• Rilevazioni oltre la scadenza / più datate per team e asset.
• Copertura delle patch (percentuale del parco aggiornato).

Crei report per il team responsabile, così la responsabilità è visibile e le aree più lente ricevono l'attenzione necessaria.

Dopo la distribuzione, verifichi: esegua una nuova scansione per confermare che la CVE non sia più presente e che il sistema sia integro, quindi chiuda la rilevazione con le relative evidenze. Riporti i problemi ricorrenti (una libreria che ricompare continuamente, un team cronicamente in ritardo) nel processo di miglioramento.

Una gestione delle patch efficace trasforma il rischio prioritizzato in una riduzione del rischio misurabile e puntuale.

Confermi il ruolo degli SLA di correzione.

La gestione delle patch porta a completamento le rilevazioni prioritarie attraverso identificazione, valutazione, test, distribuzione graduale e verifica, con il supporto di piani di rollback e automazione. Gli SLA stabiliscono scadenze differenziate per gravità e rischio (più stringenti per KEV e sistemi esposti a Internet), così le correzioni vengono completate nei tempi previsti.

Quando non è possibile applicare patch, utilizzi controlli compensativi e un'accettazione del rischio documentata e a tempo. Misuri MTTR, conformità agli SLA e copertura, quindi riporti gli insegnamenti nel ciclo di vita.