Home › Procedura di gestione delle vulnerabilità secondo la NIS 2: come impostarla

Procedura di gestione delle vulnerabilità secondo la NIS 2: come impostarla

La procedura di gestione delle vulnerabilità è il documento che descrive come un'organizzazione individua, valuta, classifica e corregge le debolezze dei propri sistemi informativi, e come ne conserva le evidenze. La direttiva NIS 2 non prescrive un modello unico, ma richiede misure di gestione del rischio che comprendono la gestione e la divulgazione delle vulnerabilità. Una procedura scritta, applicata e documentata è il modo più diretto per dimostrarlo.

Cos'è la gestione delle vulnerabilità e perché la richiede la NIS 2

Una vulnerabilità è una debolezza di un software, di un dispositivo, di una configurazione o di un processo che può essere sfruttata per compromettere riservatezza, integrità o disponibilità dei dati e dei servizi. La gestione delle vulnerabilità è il processo continuo con cui queste debolezze vengono trovate e ridotte entro livelli di rischio accettabili.

La Direttiva (UE) 2022/2555 (NIS 2), all'articolo 21, impone ai soggetti essenziali e importanti di adottare misure tecniche, operative e organizzative adeguate e proporzionate. Tra gli ambiti minimi indicati rientrano la sicurezza nell'acquisizione, sviluppo e manutenzione di reti e sistemi, comprese la gestione e la divulgazione delle vulnerabilità, e le politiche per valutare l'efficacia delle misure adottate. In Italia la direttiva è recepita dal D.Lgs. 138/2024, e l'Agenzia per la Cybersicurezza Nazionale (ACN) definisce gli obblighi e le misure di dettaglio: conviene sempre verificare i requisiti vigenti applicabili alla propria categoria di soggetto.

In pratica, un'autorità di controllo o un auditor si aspetta di vedere non solo strumenti di scansione, ma un processo definito, con responsabilità assegnate e prove di applicazione.

Le fasi della procedura: identificazione, valutazione, priorità, rimedio

1. Identificazione

Non si possono gestire vulnerabilità su asset che non si conoscono. Il punto di partenza è un inventario aggiornato di sistemi, applicazioni, dispositivi di rete, servizi cloud e componenti software di terze parti. Le fonti per individuare le vulnerabilità sono in genere:

• scansioni periodiche e automatiche dell'infrastruttura;
• bollettini dei produttori e avvisi dei CSIRT e delle autorità competenti;
• test di sicurezza, come penetration test e revisioni del codice;
• segnalazioni interne, di clienti, fornitori o ricercatori esterni.

2. Valutazione

Ogni vulnerabilità va analizzata nel contesto. Un punteggio di gravità standard, come il CVSS, è un utile punto di partenza, ma non basta: occorre considerare se il sistema è esposto a Internet, quanto è critico per i servizi, se esiste un exploit noto e se sono presenti controlli compensativi. Va anche verificato che la segnalazione sia reale, escludendo i falsi positivi.

3. Priorità

Le risorse sono limitate, quindi la procedura deve definire criteri di prioritizzazione chiari, per esempio livelli di severità (critica, alta, media, bassa) collegati a tempi di intervento. I fattori tipici sono la gravità tecnica, la criticità dell'asset, l'esposizione e l'evidenza di sfruttamento attivo.

4. Rimedio

Le azioni possibili sono:

• correzione: installazione di patch o aggiornamenti;
• mitigazione: modifica di configurazioni, segmentazione, regole di filtraggio, quando la patch non è disponibile o applicabile subito;
• accettazione del rischio: decisione formale, motivata, approvata e con scadenza di riesame;
• rimozione: dismissione del sistema o del componente vulnerabile.

Dopo l'intervento serve una verifica (nuova scansione o test) che confermi la chiusura. Senza verifica la vulnerabilità non può considerarsi risolta.

Ruoli e responsabilità

La procedura deve attribuire compiti a ruoli, non a persone, così resta valida nel tempo. Un'assegnazione tipica:

• Organo di gestione (direzione): approva la procedura e le politiche, ne supervisiona l'attuazione e decide sulle accettazioni di rischio di maggiore impatto. La NIS 2 attribuisce infatti agli organi di gestione la responsabilità di approvare e sovrintendere le misure di gestione del rischio.
• Responsabile della sicurezza delle informazioni: governa il processo, definisce i criteri, monitora gli indicatori e riferisce alla direzione.
• Team IT e operations: eseguono scansioni, patching e mitigazioni.
• Responsabili degli asset o dei servizi (system owner): confermano la criticità, autorizzano le finestre di manutenzione e concordano le eccezioni.
• Sviluppo software, se presente: corregge le vulnerabilità nel codice proprio e gestisce le dipendenze.
• Acquisti e gestione fornitori: inseriscono nei contratti obblighi di notifica e correzione delle vulnerabilità.

Va inoltre indicato un punto di contatto per ricevere segnalazioni esterne, in linea con la logica di divulgazione coordinata delle vulnerabilità promossa dalla NIS 2.

Tempistiche e registrazione delle evidenze

La NIS 2 non fissa scadenze generali di correzione per ogni vulnerabilità: i tempi li stabilisce l'organizzazione in base al proprio rischio, e devono essere realistici, perché poi vanno rispettati e misurati. Un esempio di schema (da adattare, non un obbligo normativo):

• critica con sfruttamento noto: intervento in emergenza, in giorni molto brevi;
• alta: entro alcune settimane;
• media e bassa: nei cicli ordinari di manutenzione.

Anche la frequenza delle scansioni va definita (ad esempio continua o periodica per i sistemi esposti, più diradata per quelli interni) e rivista quando cambia il contesto.

Le evidenze sono ciò che rende la procedura verificabile. Conviene conservare:

1. un registro delle vulnerabilità con data di rilevazione, asset, severità, responsabile, azione decisa e data di chiusura;
2. i report delle scansioni e delle verifiche successive;
3. le approvazioni delle eccezioni e delle accettazioni di rischio, con motivazione e scadenza;
4. gli indicatori periodici (numero di vulnerabilità aperte, tempi medi di chiusura, scostamenti dai tempi previsti);
5. i verbali dei riesami con la direzione.

Esempio di struttura del documento di procedura

Un documento chiaro e consultabile può seguire questo indice:

1. Scopo e ambito: sistemi, sedi e servizi coperti.
2. Riferimenti: NIS 2, normativa nazionale di recepimento, politiche interne collegate.
3. Definizioni: vulnerabilità, patch, mitigazione, eccezione.
4. Ruoli e responsabilità.
5. Inventario degli asset e criteri di criticità.
6. Identificazione: fonti, strumenti, frequenza.
7. Valutazione e prioritizzazione: criteri e matrice di severità.
8. Rimedio: tempi target, gestione delle patch, mitigazioni, verifica.
9. Gestione delle eccezioni e accettazione del rischio.
10. Divulgazione e segnalazioni esterne: canale di contatto e gestione.
11. Fornitori e terze parti.
12. Registrazione, indicatori e riesame.
13. Versioni e approvazione: data, autore, approvatore.

Come la includiamo nel manuale delle politiche

La procedura non vive isolata: va inserita nel sistema documentale di sicurezza dell'organizzazione. L'impostazione più efficace è a livelli. La politica di sicurezza, approvata dalla direzione, afferma l'impegno a gestire le vulnerabilità. La procedura descrive il processo. Le istruzioni operative e i moduli (registro, modello di richiesta di eccezione) spiegano come eseguire i singoli passaggi.

Nel manuale delle politiche conviene creare collegamenti espliciti con i documenti affini: gestione degli asset, gestione delle modifiche, gestione degli incidenti, sicurezza della catena di fornitura, sviluppo sicuro e continuità operativa. Una vulnerabilità sfruttata può diventare un incidente da notificare, quindi il passaggio tra i due processi deve essere chiaro. Il manuale deve poi prevedere un riesame periodico e dopo eventi rilevanti, con versioni tracciate e approvazione della direzione.

Domande frequenti

La NIS 2 impone tempi precisi per applicare le patch?

La direttiva non indica un termine universale. Richiede misure adeguate e proporzionate al rischio: è l'organizzazione a definire e giustificare i propri tempi, nel rispetto di eventuali indicazioni specifiche dell'autorità nazionale competente.

Basta una scansione automatica per essere conformi?

No. La scansione è solo uno strumento della fase di identificazione. Servono anche valutazione, prioritizzazione, rimedio, verifica, ruoli definiti ed evidenze documentate.

Cosa fare se una patch non può essere installata?

Si adottano misure di mitigazione e si formalizza l'eccezione, con motivazione, approvazione del responsabile competente, controlli compensativi e data di riesame.

Ogni quanto va aggiornata la procedura?

Almeno con cadenza periodica stabilita dall'organizzazione (ad esempio annuale) e ogni volta che cambiano in modo rilevante infrastruttura, normativa, fornitori o a seguito di incidenti significativi.

Le vulnerabilità dei fornitori rientrano nella procedura?

Sì. La NIS 2 pone attenzione alla sicurezza della catena di approvvigionamento: la procedura dovrebbe prevedere come ricevere, valutare e tracciare le vulnerabilità dei prodotti e servizi di terze parti, e i relativi obblighi contrattuali.