CVD per NIS2 e DORA: mappa delle evidenze ISO 27001

Alle 08:17 di un martedì, la casella di posta della sicurezza riceve un messaggio da un ricercatore indipendente. L’oggetto è pacato, quasi cortese: “Potenziale compromissione dell’account nel vostro portale clienti”. Il contenuto è meno rassicurante. Il ricercatore sostiene che una vulnerabilità concatenata nella vostra applicazione SaaS consenta a un tenant di accedere ai record delle fatture di un altro tenant. È allegato un proof of concept, cifrato con la vostra chiave PGP pubblicata.

Per Maria, la nuova CISO di FinanTechSaaS, il momento non potrebbe essere peggiore. La sua azienda ha appena firmato un contratto importante con una banca UE di primario livello. Il team di due diligence del cliente ha già richiesto una “Politica di divulgazione coordinata delle vulnerabilità” e le evidenze della sua applicazione, citando esplicitamente NIS2 e DORA. L’azienda dispone di un indirizzo e-mail security@, ma è monitorato da un solo sviluppatore. Non esiste un registro formale di ricezione, non è definito alcuno SLA di validazione, non esiste un percorso di escalation verso la direzione e manca una traccia di audit.

Tre orologi partono contemporaneamente.

Il primo è operativo. La vulnerabilità è reale? È sfruttabile in produzione? Qualcuno la sta già sfruttando attivamente?

Il secondo è regolatorio. Se i dati dei clienti sono esposti, inizia la valutazione della violazione ai sensi del GDPR. Se l’erogazione del servizio è interessata per un soggetto essenziale o importante ai sensi di NIS2, possono attivarsi le soglie di segnalazione degli incidenti. Se l’azienda è un’entità finanziaria o un fornitore ICT a supporto di servizi finanziari, possono diventare rilevanti le regole DORA su gestione degli incidenti, classificazione, escalation e comunicazione ai clienti.

Il terzo è probatorio. Sei mesi dopo, un auditor ISO/IEC 27001:2022, un’autorità di vigilanza del settore finanziario, un team di assurance del cliente o un comitato di audit interno potrebbero chiedere: “Mostrateci come è stata gestita questa vulnerabilità”.

È su questa domanda che molte organizzazioni scoprono che la divulgazione coordinata delle vulnerabilità non è soltanto una casella e-mail della sicurezza. È un sistema di governance. Richiede titolarità della politica, un canale pubblico di segnalazione, un flusso di triage, SLA di remediation, escalation verso i fornitori, criteri decisionali sugli incidenti, riesame privacy, reportistica alla direzione ed evidenze difendibili.

Clarysec tratta la CVD come un modello di controllo integrato, non come una casella di posta isolata. In Zenith Blueprint: la roadmap in 30 passi per auditor Zenith Blueprint, il trattamento delle vulnerabilità compare nella fase Controls in Action, Step 19: Controlli tecnologici I, dove l’indicazione è chiara: le organizzazioni non devono archiviare passivamente le risultanze sulle vulnerabilità, ma sottoporle a triage, assegnarle e seguirle fino alla chiusura. Lo stesso standard si applica alle segnalazioni esterne. Se qualcuno vi indica come il vostro servizio può fallire, la vera domanda diventa: potete dimostrare di aver ricevuto, valutato, prioritizzato, corretto, comunicato e appreso?

Perché la CVD è oggi una questione da consiglio di amministrazione ai sensi di NIS2 e DORA

Per anni, le organizzazioni attente alla sicurezza hanno invitato gli hacker etici a segnalare vulnerabilità perché era una buona pratica. Con NIS2 e DORA, questa pratica è diventata parte della resilienza digitale regolamentata.

NIS2 si applica a molte entità medie e grandi in settori ad alta criticità e in altri settori critici, inclusi fornitori di infrastrutture digitali, fornitori di servizi di cloud computing, fornitori di servizi di data centre, prestatori di servizi gestiti, prestatori di servizi di sicurezza gestiti e determinati fornitori digitali quali marketplace online, motori di ricerca e piattaforme di social networking. Può applicarsi anche indipendentemente dalle dimensioni a categorie quali prestatori di servizi fiduciari, fornitori di servizi DNS, registri dei nomi di dominio di primo livello e fornitori di reti o servizi pubblici di comunicazione elettronica.

NIS2 Article 21 richiede ai soggetti essenziali e importanti di applicare misure tecniche, operative e organizzative adeguate e proporzionate per la gestione dei rischi di cibersicurezza, adottando un approccio multirischio. Uno degli ambiti minimi riguarda la sicurezza nell’acquisizione, nello sviluppo e nella manutenzione dei sistemi informativi e di rete, inclusi il trattamento e la divulgazione delle vulnerabilità. La stessa baseline copre anche il trattamento degli incidenti, la sicurezza della catena di fornitura, la continuità operativa, il controllo degli accessi, la gestione degli asset, la formazione, la crittografia e le procedure per valutare l’efficacia dei controlli.

NIS2 Article 20 rende inoltre esplicita la responsabilità della direzione. Gli organi di gestione devono approvare le misure di gestione dei rischi di cibersicurezza, vigilare sulla loro attuazione e seguire attività formative. Per un programma CVD, ciò significa che il consiglio di amministrazione o l’alta direzione devono comprendere il canale di segnalazione, il gruppo di risposta alle vulnerabilità, le scadenze di validazione, le aspettative di remediation, le dipendenze dai fornitori e gli elementi che attivano la segnalazione degli incidenti.

DORA introduce, dal 17 gennaio 2025, un regime settoriale specifico per le entità finanziarie. Copre la gestione del rischio ICT, la segnalazione degli incidenti connessi alle ICT, i test di resilienza operativa digitale, la condivisione di informazioni, il rischio ICT di terze parti, i requisiti contrattuali, la vigilanza sui fornitori terzi critici di servizi ICT e la cooperazione tra autorità di vigilanza. Per le entità finanziarie coperte da DORA, DORA prevale generalmente su NIS2 per la gestione del rischio ICT e la segnalazione degli incidenti, in quanto atto giuridico dell’Unione specifico di settore. Il requisito pratico rimane tuttavia lo stesso: le entità finanziarie e i fornitori ICT che le servono devono gestire un processo strutturato, documentato e verificabile per identificare, analizzare, classificare, effettuare l’escalation, correggere e trarre apprendimento dalle debolezze ICT.

Una segnalazione di vulnerabilità può nascere come risultanza tecnica, diventare un evento di sicurezza, evolvere in un incidente, attivare una valutazione di violazione dei dati personali ai sensi del GDPR, richiedere azioni da parte di un fornitore e comparire in seguito nella Dichiarazione di Applicabilità ISO/IEC 27001:2022. Per questo la CVD deve essere progettata come un unico modello operativo che coinvolge sicurezza, conformità, sviluppo, funzione legale, privacy, approvvigionamento e direzione.

La base ISO 27001: dalla divulgazione alle evidenze del SGSI

ISO/IEC 27001:2022 fornisce ai CISO e ai responsabili della conformità il sistema di gestione che rende la CVD verificabile in sede di audit.

Le clausole 4.1-4.4 richiedono all’organizzazione di comprendere le questioni interne ed esterne, i requisiti delle parti interessate, i confini del SGSI e le dipendenze con altre organizzazioni. È qui che NIS2, DORA, GDPR, i contratti con i clienti, gli obblighi dei fornitori e gli impegni di divulgazione delle vulnerabilità entrano nel SGSI.

Le clausole 5.1-5.3 definiscono la responsabilità della leadership. L’alta direzione deve allineare la sicurezza delle informazioni alla direzione strategica, fornire risorse, assegnare responsabilità e assicurare che il SGSI consegua i risultati attesi. Per la CVD, ciò significa nominare un gruppo di risposta alle vulnerabilità, definire l’autorità per accettare il rischio residuo ed effettuare l’escalation verso la direzione delle vulnerabilità ad alto impatto.

Le clausole 6.1.1-6.1.3 forniscono il motore di gestione del rischio. L’organizzazione deve definire i criteri di rischio, valutare i rischi per la sicurezza delle informazioni, assegnare i titolari del rischio, selezionare le opzioni di trattamento del rischio, confrontare i controlli con l’Appendice A, produrre una Dichiarazione di Applicabilità e ottenere l’approvazione del rischio residuo. Le clausole 8.1-8.3 richiedono poi il controllo operativo, le modifiche pianificate, il controllo dei processi forniti esternamente, valutazioni del rischio a intervalli pianificati o dopo modifiche significative ed evidenze dei risultati del trattamento.

In Zenith Blueprint, fase Gestione del rischio, Step 13, la Dichiarazione di Applicabilità è descritta come più di un foglio di calcolo per la conformità:

“La SoA è di fatto un documento ponte: collega la valutazione/trattamento del rischio ai controlli effettivi di cui disponete.”
Fonte: Zenith Blueprint: la roadmap in 30 passi per auditor, fase Gestione del rischio, Step 13: pianificazione del trattamento del rischio e Dichiarazione di Applicabilità (SoA) Zenith Blueprint

Per la divulgazione coordinata delle vulnerabilità, la SoA deve collegare obblighi normativi, rischio aziendale, controlli dell’Appendice A, clausole di politica ed evidenze operative.

L’obiettivo non è creare silos paralleli di conformità. La politica CVD deve essere un processo controllato del SGSI che supporta contemporaneamente la certificazione ISO/IEC 27001:2022, la conformità NIS2, la preparazione a DORA, l’assurance dei clienti e le operazioni di sicurezza.

La baseline della politica: cosa deve prevedere la vostra politica CVD

Il primo controllo visibile è il canale pubblico di divulgazione. Ricercatori, clienti, fornitori e partner devono sapere dove segnalare le vulnerabilità e come proteggere le evidenze sensibili.

La Politica di divulgazione coordinata delle vulnerabilità di Clarysec Politica di divulgazione coordinata delle vulnerabilità fornisce la baseline aziendale:

“Canali pubblici di divulgazione: l’organizzazione deve mantenere un canale chiaro per la segnalazione delle vulnerabilità, ad esempio un indirizzo e-mail dedicato di contatto per la sicurezza (per esempio, security@company.com) o un modulo web. Queste informazioni devono essere pubblicate nella pagina sulla sicurezza del sito web aziendale insieme alla chiave pubblica PGP dell’organizzazione, per consentire invii cifrati.”
Fonte: Politica di divulgazione coordinata delle vulnerabilità, requisiti di attuazione, clausola 6.1

Questa clausola risolve un fallimento comune negli audit. Molte organizzazioni affermano di accettare segnalazioni, ma il percorso di segnalazione è nascosto, non cifrato o assegnato al team sbagliato. Un canale maturo è pubblico, sicuro, monitorato e assegnato a una funzione responsabile.

Il controllo successivo è la disciplina di risposta. Una segnalazione critica seguita dal silenzio crea rischio di divulgazione, rischio reputazionale e rischio di exploit. La Politica di divulgazione coordinata delle vulnerabilità definisce un’aspettativa concreta di presa d’atto e validazione:

“Triage e presa d’atto: al ricevimento di una segnalazione, il VRT deve registrarla e inviare una presa d’atto al segnalante entro 2 giorni lavorativi, assegnando un riferimento di tracciamento. Il VRT deve svolgere una valutazione preliminare della gravità, ad esempio utilizzando il punteggio CVSS, e validare il problema, anche con il supporto dei team IT e di sviluppo ove necessario, entro un termine obiettivo di 5 giorni lavorativi. Le vulnerabilità critiche, ad esempio quelle che consentono l’esecuzione di codice da remoto o una grave violazione dei dati, devono essere gestite con priorità accelerata.”
Fonte: Politica di divulgazione coordinata delle vulnerabilità, requisiti di attuazione, clausola 6.4

Questa formulazione crea punti di evidenza immediati: ora di ricezione, ora della presa d’atto, riferimento di tracciamento, gravità preliminare, esito della validazione e decisione di trattamento accelerato.

Per le PMI, Clarysec applica la stessa logica con un’attuazione proporzionata. La Politica sui requisiti di sicurezza delle applicazioni-sme Politica sui requisiti di sicurezza delle applicazioni - PMI richiede alle organizzazioni di:

“specificare gli obblighi relativi alla divulgazione delle vulnerabilità, ai tempi di risposta e all’applicazione delle patch.”
Fonte: Politica sui requisiti di sicurezza delle applicazioni-sme, requisiti di governance, clausola 5.3.2

Non serve un grande team di sicurezza del prodotto per essere responsabili. Servono obblighi espliciti, tempistiche realistiche, titolari nominati ed evidenze che il processo funzioni.

Il flusso di ricezione CVD: dall’e-mail del ricercatore alla registrazione della decisione

Un buon flusso di ricezione è abbastanza semplice da funzionare sotto pressione e abbastanza completo da soddisfare un auditor. Deve iniziare con un canale dedicato, ad esempio security@[company], un modulo web o un file security.txt pubblicato. Il percorso di invio deve consentire evidenze cifrate, indicazione del prodotto o dell’endpoint interessato, passaggi per la riproduzione, recapiti del segnalante, tempistiche preferite di divulgazione e qualsiasi indicazione di esposizione dei dati o sfruttamento attivo.

Una volta ricevuta la segnalazione, il gruppo di risposta alle vulnerabilità deve creare una registrazione in uno strumento GRC, in una piattaforma di ticketing, in un sistema di gestione delle vulnerabilità o in un registro controllato. Lo strumento conta meno della coerenza e della qualità delle evidenze.

Il flusso operativo deve poi svilupparsi attraverso sette passaggi operativi.

1. Ricezione: la segnalazione viene ricevuta attraverso il canale pubblico e registrata automaticamente o manualmente.
2. Presa d’atto: il VRT risponde entro 2 giorni lavorativi e assegna un riferimento di tracciamento.
3. Validazione: il team tecnico riproduce il problema, conferma i sistemi interessati ed effettua una valutazione preliminare della gravità.
4. Valutazione dell’evento: il VRT determina se la vulnerabilità è soltanto una debolezza, un evento di sicurezza delle informazioni o un incidente.
5. Escalation: le problematiche alte o critiche sono inviate ai responsabili dei sistemi, al CISO, alle funzioni privacy e legale, ai fornitori e alla direzione, secondo necessità.
6. Remediation: il team responsabile applica una correzione, una mitigazione, un controllo compensativo o una restrizione temporanea.
7. Chiusura: il VRT verifica la correzione, comunica con il segnalante, aggiorna il fascicolo delle evidenze e registra le lezioni apprese.

Clarysec mappa questo passaggio operativo al controllo ISO/IEC 27002:2022 A.5.25, Valutazione e decisione sugli eventi di sicurezza delle informazioni, e al controllo A.8.8, Gestione delle vulnerabilità tecniche, attraverso Zenith Controls: la guida alla cross-compliance Zenith Controls. Per A.5.25, Zenith Controls spiega che la valutazione degli eventi è la funzione di triage tra allarmi grezzi di monitoraggio e trattamento formale dell’incidente, usando log, soglie e criteri decisionali per determinare l’escalation. Per A.8.8, Zenith Controls collega la gestione delle vulnerabilità tecniche alla protezione antimalware, alla gestione della configurazione, alla gestione delle modifiche, alla sicurezza degli endpoint, alle informazioni sulle minacce, al monitoraggio, allo sviluppo sicuro, alla valutazione degli eventi e alla risposta agli incidenti.

Un passaggio di Zenith Controls è particolarmente utile quando si sospetta sfruttamento attivo:

“Le informazioni sulle minacce indicano quali vulnerabilità sono sfruttate attivamente, guidando la prioritizzazione delle patch.”
Fonte: Zenith Controls: la guida alla cross-compliance, controllo ISO/IEC 27002:2022 8.8, collegamento al controllo 5.7 Threat Intelligence Zenith Controls

Questo è un punto di governance importante. La gravità non è solo CVSS. Una vulnerabilità con punteggio medio sfruttata attivamente contro il vostro settore può avere priorità su una criticità teorica in un sistema di test non esposto.

Quando una vulnerabilità diventa un incidente

Non ogni segnalazione di vulnerabilità è un incidente. Un header di sicurezza mancante in un ambiente di staging non equivale a un bypass di autorizzazione sfruttato che espone fatture dei clienti. Tuttavia, ogni segnalazione di vulnerabilità credibile deve passare attraverso un punto decisionale sugli incidenti.

NIS2 Article 23 richiede ai soggetti essenziali e importanti di notificare senza indebito ritardo al proprio CSIRT o all’autorità competente gli incidenti che incidono in modo significativo sulla prestazione dei servizi. Un incidente significativo è quello che ha causato o è in grado di causare gravi perturbazioni operative o perdite finanziarie, oppure che ha colpito o è in grado di colpire altre persone causando danni materiali o immateriali considerevoli. La sequenza di segnalazione comprende un preallarme entro 24 ore dalla conoscenza dell’incidente, una notifica dell’incidente entro 72 ore, relazioni intermedie se richieste e una relazione finale entro un mese dalla notifica delle 72 ore.

DORA Articles 17 to 20 richiedono alle entità finanziarie di rilevare, gestire, registrare, classificare, effettuare l’escalation, notificare e comunicare incidenti connessi alle ICT e minacce informatiche significative. Gli incidenti gravi connessi alle ICT devono essere portati all’attenzione dell’alta direzione e dell’organo di gestione. La comunicazione ai clienti può essere richiesta quando sono interessati interessi finanziari.

Per le PMI, la cultura di segnalazione deve essere altrettanto chiara. La Politica di risposta agli incidenti-sme di Clarysec Politica di risposta agli incidenti - PMI stabilisce:

“Il personale deve segnalare qualsiasi attività sospetta o incidente confermato a incident@[company] oppure verbalmente al Direttore generale o al fornitore IT.”
Fonte: Politica di risposta agli incidenti-sme, requisiti di applicazione della politica, clausola 6.2.1

In Zenith Blueprint, fase Controls in Action, Step 16: controlli relativi al personale II, il principio è ancora più semplice:

“Nel dubbio, segnala.”
Fonte: Zenith Blueprint: la roadmap in 30 passi per auditor, fase Controls in Action, Step 16: controlli relativi al personale II (A.6.5-A.6.8)

Questa frase deve applicarsi a sviluppatori, team di supporto, responsabili dei fornitori, referenti privacy, dirigenti e prestatori in outsourcing. Una vulnerabilità che può incidere su riservatezza, integrità, disponibilità, fiducia dei clienti, segnalazioni regolatorie o operazioni finanziarie deve essere registrata e valutata, non gestita informalmente in chat.

Remediation, applicazione delle patch e controlli compensativi

Una volta validata, una vulnerabilità deve essere trattata. Il trattamento deve essere basato sul rischio, supportato da evidenze e limitato nel tempo.

La Politica di divulgazione coordinata delle vulnerabilità definisce l’aspettativa aziendale:

“Piano di remediation: per tutte le vulnerabilità confermate deve essere sviluppato un piano di remediation o mitigazione. L’attuazione della correzione deve essere prioritizzata in base alla gravità. Ad esempio, le vulnerabilità critiche devono essere corrette o mitigate entro 14 giorni ove fattibile, o prima se viene rilevato sfruttamento attivo, mentre le problematiche di gravità inferiore devono essere affrontate entro un termine ragionevole. Quando una correzione completa è ritardata, devono essere applicati controlli compensativi o misure temporanee di mitigazione, quali la disabilitazione della funzionalità vulnerabile o l’aumento del monitoraggio.”
Fonte: Politica di divulgazione coordinata delle vulnerabilità, requisiti di attuazione, clausola 6.6

Per la disciplina di applicazione delle patch nelle PMI, la Politica di gestione delle vulnerabilità e delle patch-sme Politica di gestione delle vulnerabilità e delle patch - PMI stabilisce:

“Le patch critiche devono essere applicate entro 3 giorni dal rilascio, in particolare per i sistemi esposti a Internet”
Fonte: Politica di gestione delle vulnerabilità e delle patch-sme, requisiti di applicazione della politica, clausola 6.1.1

Queste tempistiche non sono contraddittorie. Una patch di fornitore per un sistema esposto a Internet può richiedere una distribuzione molto rapida. Una vulnerabilità di prodotto che richiede modifiche al codice, test di regressione, coordinamento con i clienti e rilascio graduale può richiedere un piano di remediation con mitigazioni intermedie. L’aspetto essenziale è che la decisione sia documentata, attribuita a un titolare del rischio e approvata quando permane rischio residuo.

Un caso pratico può svolgersi così:

1. Un ricercatore segnala un bypass di autorizzazione nell’API di fatturazione clienti.
2. Il VRT registra CVD-2026-014 con marcatura temporale e invia presa d’atto entro 2 giorni lavorativi.
3. La sicurezza del prodotto valida il difetto entro 24 ore e assegna gravità alta per accesso ai dati tra tenant.
4. La funzione privacy effettua una valutazione di violazione GDPR perché i record delle fatture possono contenere dati personali.
5. L’incident manager apre una valutazione dell’evento ai sensi del controllo ISO/IEC 27002:2022 A.5.25.
6. Il responsabile del sistema disabilita l’endpoint vulnerabile tramite un feature flag temporaneo.
7. Il team di sviluppo crea una correzione urgente ai sensi del controllo ISO/IEC 27002:2022 A.8.32, Gestione delle modifiche.
8. Vengono aggiunte regole di monitoraggio per gli indicatori di exploit, collegate ad A.8.15, Registrazione, e A.8.16, Attività di monitoraggio.
9. Il CISO informa l’alta direzione perché il problema è ad alto rischio.
10. Il VRT si coordina con il ricercatore per riverifica e tempistiche di divulgazione.
11. Il titolare del rischio approva la chiusura solo dopo i test di verifica e il riesame dell’impatto sui clienti.
12. La SoA, il registro dei rischi, il ticket, i log, la notifica alla direzione e le lezioni apprese vengono aggiornati.

Questa è la differenza tra “abbiamo applicato la patch” e “possiamo dimostrare di aver governato il processo”.

Dipendenze da fornitori e cloud: il punto di fallimento nascosto

Molti fallimenti CVD sono in realtà fallimenti dei fornitori. La vulnerabilità può interessare un componente SaaS, un servizio cloud, un fornitore di sicurezza gestita, un gateway di pagamento, un broker di autenticazione, una libreria open source, un team di sviluppo esternalizzato o un subappaltatore.

NIS2 Article 21 richiede la sicurezza della catena di fornitura, compresi i rapporti con fornitori diretti e prestatori di servizi. Le misure relative alla catena di fornitura devono considerare vulnerabilità dei fornitori, qualità dei prodotti, pratiche di cibersicurezza e procedure di sviluppo sicuro.

DORA Articles 28 to 30 vanno oltre per le entità finanziarie. Richiedono che il rischio ICT di terze parti sia gestito come parte del quadro di riferimento del rischio ICT, con registri dei contratti di servizi ICT, distinzione delle funzioni critiche o importanti, due diligence precontrattuale, requisiti contrattuali di sicurezza, assistenza sugli incidenti, cooperazione con le autorità, diritto di audit, diritti di risoluzione e strategie di uscita. Le entità finanziarie restano pienamente responsabili della conformità DORA anche quando utilizzano fornitori terzi di servizi ICT.

La Politica di sicurezza delle terze parti e dei fornitori-sme di Clarysec Politica di sicurezza delle terze parti e dei fornitori - PMI include una semplice regola di escalation:

“Deve notificare immediatamente al GM qualsiasi violazione della sicurezza, modifica o incidente”
Fonte: Politica di sicurezza delle terze parti e dei fornitori-sme, ruoli e responsabilità, clausola 4.4.3

Per i contratti con fornitori enterprise, Zenith Blueprint, fase Controls in Action, Step 23, raccomanda di includere obblighi di riservatezza, responsabilità di controllo degli accessi, misure tecniche e organizzative, tempistiche di segnalazione degli incidenti, diritto di audit, controlli sui subappaltatori e disposizioni di fine contratto. Afferma:

“Ciò che conta è che esistano e che siano comprese e accettate da entrambe le parti.”
Fonte: Zenith Blueprint: la roadmap in 30 passi per auditor, fase Controls in Action, Step 23: controlli organizzativi (5.19-5.37)

La preparazione dei fornitori alla CVD deve rispondere a queste domande:

• Il fornitore pubblica un canale di segnalazione delle vulnerabilità?
• Le tempistiche di notifica delle vulnerabilità sono definite nel contratto?
• Le vulnerabilità critiche del fornitore sono segnalate senza indebito ritardo?
• Le debolezze che impattano sui clienti sono collegate agli obblighi di assistenza sugli incidenti?
• Il fornitore può fornire evidenze di remediation o avvisi di sicurezza?
• Gli obblighi relativi alle vulnerabilità sono trasferiti ai subappaltatori?
• Esiste una strategia di uscita se la remediation è inadeguata?

È qui che NIS2, DORA e ISO/IEC 27001:2022 convergono. La gestione delle vulnerabilità dei fornitori non è una casella da spuntare nell’approvvigionamento. È parte della resilienza operativa.

Mappatura delle evidenze per ISO 27001, NIS2, DORA, GDPR e COBIT

I programmi CVD più solidi sono progettati a partire dalle evidenze. Presuppongono che qualsiasi segnalazione significativa possa essere successivamente riesaminata da audit interno, auditor di certificazione, autorità di regolamentazione, clienti, assicuratori o comitati rischi del consiglio di amministrazione.

La Politica di audit e monitoraggio della conformità-sme di Clarysec Politica di audit e monitoraggio della conformità - PMI evidenzia un dettaglio che molti team trascurano:

“I metadati (ad esempio chi li ha raccolti, quando e da quale sistema) devono essere documentati.”
Fonte: Politica di audit e monitoraggio della conformità-sme, requisiti di applicazione della politica, clausola 6.2.3

Uno screenshot di un server patchato è debole se nessuno sa chi lo ha acquisito, quando, da quale sistema e come si mappa alla vulnerabilità. Un ticket con marcature temporali, output dello scanner, pull request, approvazione della modifica, log di distribuzione, query di monitoraggio, conferma della riverifica e metadati è molto più solido.

Una matrice di tracciabilità più dettagliata aiuta durante la due diligence dei clienti e l’audit interno.

Auditor diversi testeranno lo stesso processo attraverso prospettive diverse.

Un auditor ISO/IEC 27001:2022 partirà dal SGSI. Chiederà se gli obblighi di divulgazione delle vulnerabilità sono inclusi nei requisiti delle parti interessate, se i rischi sono valutati in modo coerente, se i controlli compaiono nella SoA, se esistono evidenze operative e se la direzione riesamina tendenze ed elementi scaduti.

Un revisore DORA o dei servizi finanziari si concentrerà sulla resilienza operativa. Esaminerà integrazione del rischio ICT, classificazione degli incidenti, escalation all’alta direzione, comunicazione ai clienti, dipendenze da terze parti, test e lezioni apprese. Se la vulnerabilità interessa una funzione critica o importante, si aspetterà un collegamento stretto tra ticket tecnico, impatto sul business, implicazioni di continuità e obblighi del fornitore.

Un revisore GDPR si concentrerà sui dati personali. Sono stati coinvolti dati personali? Vi è stato accesso non autorizzato, perdita, alterazione o divulgazione? I ruoli di titolare e responsabile del trattamento erano chiari? È stata valutata la soglia di violazione? Erano rilevanti misure di sicurezza quali cifratura, controllo degli accessi, registrazione e minimizzazione?

Un auditor COBIT 2019 o ISACA si concentrerà su governance, responsabilità, prestazione e assurance. Cercherà titolarità definita, metriche, escalation, obiettivi di controllo, supervisione della direzione e tracciamento delle eccezioni. Una vulnerabilità critica scaduta non è solo un problema tecnico. È una questione di governance, salvo escalation formale e accettazione del rischio.

Un valutatore orientato a NIST ragionerà in termini di Identify, Protect, Detect, Respond e Recover. Vorrà titolarità degli asset, identificazione delle vulnerabilità, prioritizzazione, modifica protettiva, rilevamento degli exploit, coordinamento della risposta e convalida del ripristino.

Il vantaggio di un modello CVD integrato è che la stessa dorsale di evidenze può supportare tutti questi riesami.

Il ciclo mensile di controllo: metriche utilizzabili dalla direzione

La CVD non termina quando il ticket viene chiuso. La Politica di divulgazione coordinata delle vulnerabilità richiede il riesame continuo dei registri:

“Il VRT deve mantenere un log di divulgazione delle vulnerabilità che tracci ogni segnalazione dalla ricezione alla chiusura. Il log deve essere riesaminato mensilmente per garantire l’avanzamento tempestivo degli elementi aperti. Gli elementi scaduti devono essere oggetto di escalation.”
Fonte: Politica di divulgazione coordinata delle vulnerabilità, Monitoraggio e audit, clausola 9.1

Questo riesame mensile trasforma la divulgazione delle vulnerabilità in una governance presentabile al consiglio di amministrazione. La direzione non ha bisogno di ogni dettaglio tecnico. Ha bisogno di tendenze, esposizione, responsabilità e rischio scaduto.

In un’implementazione Clarysec matura, questo riesame mensile dei registri alimenta il registro dei rischi, la Dichiarazione di Applicabilità, il backlog di sviluppo sicuro, i riesami dei fornitori, le lezioni apprese dagli incidenti, il piano di audit interno e il pacchetto di reportistica alla direzione.

Costruire il processo prima che arrivi la segnalazione grave

Il momento peggiore per progettare la divulgazione coordinata delle vulnerabilità è dopo che un ricercatore ha pubblicato la vostra debolezza o un cliente bancario critico ha bloccato l’onboarding. NIS2, DORA, GDPR, ISO/IEC 27001:2022, le aspettative di resilienza in stile NIST e la governance COBIT 2019 indicano tutte la stessa direzione: la divulgazione delle vulnerabilità deve essere pianificata, assegnata, testata, comprovata da evidenze e migliorata.

Iniziate con queste cinque azioni:

1. Adottate o adattate la Politica di divulgazione coordinata delle vulnerabilità.
2. Costruite il flusso di ricezione e triage utilizzando Zenith Blueprint, in particolare Step 13 per la tracciabilità della SoA, Step 16 per la cultura di segnalazione, Step 19 per la gestione delle vulnerabilità tecniche e Step 23 per gli accordi con i fornitori.
3. Mappate il flusso attraverso Zenith Controls, concentrandovi sui controlli ISO/IEC 27002:2022 A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 e A.8.32.
4. Aggiungete clausole adatte alle PMI da Politica di risposta agli incidenti-sme, Politica di gestione delle vulnerabilità e delle patch-sme, Politica di sicurezza delle terze parti e dei fornitori-sme, Politica sui requisiti di sicurezza delle applicazioni-sme e Politica di audit e monitoraggio della conformità-sme dove è richiesta proporzionalità.
5. Eseguite un’esercitazione tabletop che simuli una segnalazione di un ricercatore con impatto su dati personali e su un componente ospitato da un fornitore, quindi testate presa d’atto, triage, classificazione dell’incidente, applicazione delle patch, comunicazione ai clienti, acquisizione delle evidenze ed escalation verso la direzione.

Clarysec può aiutarvi a trasformare tutto questo in una politica CVD operativa, un registro di ricezione, una mappa delle evidenze ISO/IEC 27001:2022, un albero decisionale NIS2 e DORA, un modello di escalation verso i fornitori e un pacchetto di controlli pronto per l’audit. L’obiettivo è semplice: quando arriverà la prossima segnalazione di vulnerabilità, il vostro team non dovrà improvvisare. Dovrà eseguire con fiducia, evidenze e controllo.