PR23.1 - Gestione delle Vulnerabilità Tecniche
Procedura di Gestione delle Vulnerabilità Tecniche
Revisioni
| Rev. | Data | Descrizione | Redatto | Approvato |
|---|---|---|---|---|
| 0.1 | 16/07/2026 | Prima bozza — documento mancante generato per colmare una lacuna rilevata nella SOA | IA | Da approvare |
1 Introduzione
1.1 Scopo / Campo di applicazione
La presente procedura descrive le modalità operative con cui VECTORLAB identifica, valuta, tratta e verifica la chiusura delle vulnerabilità tecniche che interessano:
-
l'infrastruttura cloud AWS (EC2, ECS, S3, EFS, CloudFront, Parameter Store) e il server Aruba gestito in modalità Infrastructure-as-Code;
-
i sistemi operativi e il software installato sulle postazioni di lavoro aziendali;
-
il codice sorgente, i framework e le librerie/dipendenze di terze parti utilizzate nei progetti software sviluppati da VECTORLAB per conto proprio o dei Clienti (web, mobile, desktop, embedded);
-
i servizi SaaS aziendali (Google Workspace, GitHub, strumenti di ticketing e collaborazione) per la parte di configurazione sotto il controllo di VECTORLAB.
Il documento si applica al reparto IT, al CTO, agli sviluppatori (interni ed esterni in P.IVA) e, più in generale, a chiunque intervenga sui sistemi e sul software oggetto della presente procedura.
1.2 Riferimenti e Allegati
MDPR11.1.C - Piano di Audit Tecnici
MDPR23.1.A - Piano Gestione delle Vulnerabilità [progetto]
PO23 - Gestione delle Minacce e Vulnerabilità
PO25 - Sviluppo Sicuro
PR14.1 - Gestione Asset
PR19.1 - Gestione del Cambiamento
PR22.1 - Gestione delle Patch
PR23.2 - Monitoraggio delle Minacce
PR27.1 - Gestione Incidenti e Data Breach
PR33.1 - Processo Analisi del Rischio e Trattamento
SOA - Statement of Applicability - Dichiarazione di Applicabilità.
1.3 Definizioni, Acronimi, Abbreviazioni
CI/CD - Continuous Integration / Continuous Deployment
CTO - Chief Technology Officer
CVE - Common Vulnerabilities and Exposures
IT - reparto Information Technology di VECTORLAB
RSGI - Responsabile del Sistema di Gestione Integrato
SGI - Sistema di Gestione Integrato
VA - Vulnerability Assessment.
2 Procedura di Gestione delle Vulnerabilità Tecniche
2.1 Identificazione delle vulnerabilità
L'identificazione delle vulnerabilità tecniche avviene attraverso più canali, in ragione della natura eterogenea degli asset coinvolti (infrastruttura cloud, server gestito in IaC, codice applicativo):
-
infrastruttura cloud e server Aruba: IT verifica periodicamente la disponibilità di aggiornamenti di sicurezza per i sistemi operativi e i componenti infrastrutturali, anche attraverso le notifiche dei fornitori (AWS, produttori del software di base) e le dashboard di monitoraggio già in uso (cfr. "PR20.1 - Capacità e Monitoraggio Tecnico");
-
codice sorgente e dipendenze di progetto: in ragione del core business di sviluppo software, particolare attenzione è dedicata all'identificazione di vulnerabilità note nelle librerie e nei framework di terze parti utilizzati nei progetti, verificate in occasione degli interventi di manutenzione e di aggiornamento delle dipendenze nell'ambito della pipeline di sviluppo (GitHub, GitHub Actions);
-
Vulnerability Assessment periodico: IT esegue attività di VA secondo quanto pianificato nel "MDPR11.1.C - Piano di Audit Tecnici", che già prevede una riga dedicata a tale attività;
-
segnalazioni esterne: segnalazioni provenienti da Clienti, fornitori o dalla community tecnica (cfr. "PR23.2 - Monitoraggio delle Minacce") possono anch'esse dare origine all'identificazione di una vulnerabilità da trattare secondo la presente procedura.
[DA CONFERMARE: non è stato individuato nella documentazione esistente uno strumento specifico di vulnerability scanning automatizzato (es. scanner di infrastruttura o analisi statica/SCA del codice) formalmente adottato; ad oggi l'identificazione si basa su verifiche manuali, aggiornamenti dei fornitori e controlli in fase di sviluppo/manutenzione, coerentemente con quanto dichiarato nella SOA per il controllo 8.8]
2.2 Valutazione e prioritizzazione
Ogni vulnerabilità identificata viene valutata da IT, con il supporto del CTO, considerando:
-
la criticità dell'asset coinvolto, secondo la classificazione riportata nell'Asset Inventory (cfr. "PR14.1 - Gestione Asset");
-
la gravità della vulnerabilità, in base alle informazioni rese disponibili dalla fonte che l'ha segnalata (es. CVE pubblicata, bollettino del fornitore, advisory della community);
-
l'esposizione effettiva dell'asset, ovvero se il componente vulnerabile è raggiungibile dall'esterno, se è utilizzato in produzione o solo in ambienti di test, e se esistono già mitigazioni in atto (es. segmentazione di rete, cfr. "PR24.1 - Gestione delle Reti");
-
l'eventuale impatto sui dati personali trattati dal sistema interessato.
[DA CONFERMARE: non è definita una scala di severità formalizzata (es. CVSS a 4 o 5 livelli) né SLA di remediation differenziati per livello di gravità; la prioritizzazione è ad oggi demandata al giudizio tecnico di IT e CTO caso per caso]
Per i progetti software che lo richiedono (in base a complessità, criticità o requisiti contrattuali del Cliente), la valutazione e il trattamento delle vulnerabilità identificate vengono formalizzati nel modulo "MDPR23.1.A - Piano Gestione delle Vulnerabilità [progetto]", che riporta l'elenco delle vulnerabilità rilevate, la relativa severità, l'owner e lo stato di trattamento.
2.3 Trattamento e remediation
A seguito della valutazione, la vulnerabilità viene trattata secondo una delle seguenti modalità:
-
applicazione di patch o aggiornamento: quando disponibile, la patch o la nuova versione del componente vulnerabile viene applicata secondo quanto descritto in "PR22.1 - Gestione delle Patch", con classificazione del cambiamento secondo "PR19.1 - Gestione del Cambiamento" (standard, minor o, nei casi più gravi, emergency change);
-
mitigazione temporanea: quando una patch non è ancora disponibile o non è immediatamente applicabile per motivi operativi, vengono valutate misure di mitigazione compensative (es. restrizione di accesso, disattivazione temporanea di una funzionalità);
-
accettazione del rischio residuo: nei casi in cui l'impatto sia valutato come non significativo e la remediation risulti sproporzionata, la decisione di non intervenire viene motivata e tracciata, con l'approvazione del CISO.
Le vulnerabilità che, per gravità o urgenza, richiedono un intervento immediato sono gestite come emergency change secondo quanto previsto da "PR19.1 - Gestione del Cambiamento".
2.4 Tracciamento e verifica di chiusura
Tutte le attività di identificazione, valutazione e trattamento delle vulnerabilità tecniche sono tracciate sullo strumento aziendale di ticketing, in coerenza con le prassi già adottate per la gestione degli asset e degli incidenti.
La chiusura di una vulnerabilità viene verificata da IT confermando che la patch/aggiornamento è stato correttamente applicato o che la misura di mitigazione è effettivamente in atto. L'esito della verifica viene registrato sul ticket associato e, ove applicabile, riportato nel "MDPR23.1.A - Piano Gestione delle Vulnerabilità [progetto]" relativo al progetto interessato.
2.5 Vulnerability Assessment periodico
L'attività di Vulnerability Assessment è pianificata a livello aziendale nel "MDPR11.1.C - Piano di Audit Tecnici", che ne assegna la responsabilità operativa a IT.
[DA CONFERMARE: la cadenza esatta del Vulnerability Assessment (es. trimestrale) non risulta ad oggi definita in modo esplicito, oltre alla programmazione generica riportata nel Piano di Audit Tecnici]
Gli esiti del Vulnerability Assessment sono valutati secondo i criteri di cui al par. 2.2 e, se necessario, danno origine alle attività di trattamento descritte al par. 2.3.
2.6 Collegamento con l'analisi del rischio
Le vulnerabilità ricorrenti o particolarmente rilevanti, individuate nel corso delle attività descritte nella presente procedura, costituiscono un input per il processo di analisi del rischio per la sicurezza delle informazioni (cfr. "PR33.1 - Processo Analisi del Rischio e Trattamento"), contribuendo all'aggiornamento periodico della valutazione dei rischi associati agli asset aziendali.