DORA vulnerability assessment e scanning per entità finanziarie

Il Digital Operational Resilience Act (DORA) e il Regolamento Delegato (UE) 2024/1774 hanno elevato il vulnerability assessment a requisito normativo imprescindibile per tutte le entità finanziarie. Implementare un programma di DORA vulnerability assessment e scanning risulta essenziale per convalidare la resilienza dei sistemi ICT rispetto a minacce dinamiche e in evoluzione.

Definizione DORA di vulnerability assessment

La valutazione delle vulnerabilità, secondo DORA, costituisce una componente fondamentale di un quadro di gestione ICT trasparente, coerente e responsabile. Tale attività comprende procedure per identificare, convalidare e registrare le debolezze degli asset ICT che potrebbero essere sfruttate da attori malevoli. L’attenzione non si limita al rilevamento, ma si estende all’analisi dell’impatto potenziale sulla resilienza operativa dell’entità.

Differenza tra assessment e scanning

• Vulnerability Scanning: attività automatizzata tramite software specializzati per coprire sistematicamente la più ampia gamma di asset ICT.
• Vulnerability Assessment: processo più esteso che integra lo scanning, la valutazione critica dei risultati, l’analisi delle cause profonde e la definizione delle migliori misure di mitigazione.

Scope corretto: sistemi, app, cloud, endpoint e librerie terze

• Asset ICT totali: tutti gli asset devono essere sottoposti a verifica secondo la loro classificazione e profilo di rischio.
• Librerie di terze parti: è obbligatorio monitorare versioni e aggiornamenti di sicurezza, anche per componenti open source.
• Applicazioni e software: analisi e test sul codice sorgente e software proprietario fornito da terzi.
• Endpoint e infrastruttura: controllo su endpoint portatili e configurazioni di rete per ridurre l’esposizione alle minacce.

Frequenze: quando settimanale, quando risk-based

• Frequenza settimanale: scansioni automatizzate almeno una volta a settimana per asset ICT che supportano funzioni critiche o importanti.
• Frequenza risk-based: per asset non critici, la frequenza è determinata da classificazione e profilo di rischio.
• Situazioni di emergenza: la frequenza deve aumentare in presenza di minacce elevate o vulnerabilità appena rilevate.

Evidenze documentali: finding, severity, owner, remediation, retest

• Identificazione e Severity: ogni vulnerabilità deve essere registrata con valori quantitativi o qualitativi su impatto e probabilità di occorrenza.
• Prioritizzazione della remediation: i piani di rimedio devono dare priorità alle patch in base alla criticità rilevata e al profilo di rischio.
• Verifica e monitoraggio: controllo e verifica dell’effettiva risoluzione delle vulnerabilità emerse.
• Controllo delle terze parti: obbligo per i fornitori ICT di gestire e segnalare prontamente vulnerabilità critiche relative ai propri servizi.

KPI utili per audit e management

• Tempo medio di rilevamento e risoluzione delle vulnerabilità (MTTR).
• Percentuale di asset critici scansionati entro i termini settimanali.
• Numero di vulnerabilità aperte oltre i tempi di tolleranza definiti nel piano di mitigazione.
• Statistiche e trend sulle vulnerabilità gestite dai fornitori terzi.

FAQ

• La vulnerability scan è sufficiente? No. Lo scanning è solo una componente automatizzata. DORA richiede un framework di gestione complessivo che includa analisi delle cause profonde, prioritizzazione del rischio e verifica della remediation.
• La scansione settimanale vale per tutti gli asset? No. L’obbligo settimanale riguarda solo asset che supportano funzioni critiche o importanti. Per gli altri, si applica un approccio risk-based.
• Come documentare l’attività? È necessario adottare procedure scritte per la registrazione dei rilevamenti, l’attribuzione dei responsabili (owner), il tracciamento delle patch e la conservazione sicura dei report per le autorità competenti.

Evita sanzioni e interruzioni: richiedi oggi una Gap Analysis completa sul tuo processo di vulnerability management per allinearlo ai requisiti tecnici del DORA.