DORA: quello che il tuo RSSI non ti ha detto.

La maggior parte delle entità finanziarie non ha iniziato DORA da zero. Avevano un ISMS, un piano di continuità operativa, una politica di esternalizzazione e un inventario dei terzi che era per lo più costituito da contratti di approvvigionamento. DORA non butta via tutto questo. Lo riformula, alza l'asticella su due pilastri in particolare, e sposta la conversazione da "hai un controllo" a "puoi dimostrare che il tuo servizio continua a funzionare quando un fornitore ICT viene meno". Questa pagina parla proprio di quel divario: come i cinque pilastri si concretizzano nelle operazioni, cosa apre per primo un supervisore, e dove i team perdono tempo.

I cinque pilastri, e chi viene sottoposto ad audit su ciascuno

Il regolamento si basa su cinque pilastri. Nella pratica non hanno tutti lo stesso peso. Il Pilastro 1 è fondamentale ma familiare a chiunque gestisca un ISMS. I Pilastri 3 e 4 sono quelli su cui si concentra l'attenzione della vigilanza, perché producono prove difficili da falsificare e facili da verificare. La tabella seguente è la versione che usiamo per informare un consiglio di amministrazione: cosa richiede ciascun pilastro, e chi all'interno dell'entità risulta più esposto quando il regolatore chiede le prove.

Cosa fare per primo

L'errore è iniziare dall'aggiornamento delle policy, perché è il lavoro più comodo. Inizia invece dai due artefatti che un supervisore può richiedere per iscritto e che richiedono più tempo per essere costruiti correttamente: il registro dei terzi ICT e la mappatura delle funzioni critiche o importanti rispetto agli asset e ai fornitori ICT che le sostengono. Tutto il resto dipende da quella mappatura. Non puoi definire l'ambito dei test di resilienza, non puoi classificare la gravità degli incidenti, e non puoi ragionare sul rischio di concentrazione finché non sai quali funzioni sono critiche e da cosa dipendono.

Una sequenza praticabile per i primi 90 giorni:

1. Definisci le tue funzioni critiche o importanti. Questa è una decisione di business, non di sicurezza. Determina l'ambito di quasi ogni altro obbligo.
2. Mappa ogni funzione critica rispetto ai servizi ICT, interni ed esternalizzati, da cui dipende. Questo è il tuo grafo delle dipendenze.
3. Costruisci il registro dei terzi a partire da quel grafo, non dal foglio di calcolo dell'approvvigionamento. Il registro deve descrivere gli accordi che sostengono le funzioni, compresi i subappaltatori nella catena.
4. Colma le lacune contrattuali richieste da DORA (diritti di audit, strategie di uscita, trasparenza del subappalto, cooperazione in caso di incidenti) prima di tutto sugli accordi che sostengono le funzioni critiche.
5. Solo allora formalizza il quadro di gestione del rischio ICT e il programma di test, perché entrambi ora hanno un ambito definito su cui lavorare.

Il registro dei terzi ICT (Pilastro 4) nella pratica

Il registro non è un elenco di fornitori. È un insieme strutturato di registri delle informazioni che l'entità mantiene e che le autorità competenti raccolgono, secondo un modello definito, per osservare la concentrazione ICT nell'intero settore finanziario. Questo cambia il modo in cui lo costruisci. Un campo "abbastanza buono" per uso interno diventa un problema di qualità dei dati quando viene aggregato a livello nazionale e UE. Tre cose causano la maggior parte dei problemi.

Primo, l'unità è l'accordo contrattuale, non il fornitore. Un singolo fornitore può stare dietro a più accordi, e un singolo accordo può sostenere più funzioni. Stai descrivendo un grafo molti-a-molti, e appiattirlo in una riga per fornitore non sopravviverà alla revisione.

Secondo, devi seguire la catena. Il registro deve catturare i subappaltatori che di fatto sostengono una funzione critica o importante, il che significa che la tua visibilità sul fornitore deve spingersi oltre la tua controparte diretta. Se il tuo contratto non ti dà il diritto di sapere chi è la quarta parte, quella è una lacuna contrattuale da colmare, non un campo da lasciare in bianco.

Terzo, il flag di criticità della funzione su ciascun accordo è il campo da cui dipende tutto il resto. Contrassegna troppe cose come critiche e affoghi i tuoi stessi test e la tua remediation contrattuale; contrassegnane troppo poche e sottostimi il rischio di concentrazione e inganni il supervisore. Fai bene la valutazione della criticità una volta sola, a livello di funzione, e lascia che si propaghi.

Test di penetrazione guidati dalla minaccia (Pilastro 3): com'è davvero la sala

Il TLPT è il pilastro che sorprende, perché non assomiglia a un test di penetrazione di routine. È guidato dall'intelligence, eseguito su sistemi di produzione live, circoscritto alle funzioni critiche o importanti, e condotto secondo la metodologia TIBER-EU con il coinvolgimento dell'autorità nazionale. Le entità significative lo eseguono con un ciclo di almeno tre anni. È più vicino a un'esercitazione di red team supervisionata che a una scansione delle vulnerabilità, e il deliverable che conta non è l'elenco delle non conformità; è la prova che il rilevamento e la risposta hanno funzionato, oppure il resoconto onesto del perché non hanno funzionato.

Tre realtà che i team sottovalutano:

• L'ambito è determinato dalle funzioni critiche, non da ciò che è comodo testare. Se una funzione si estende a un fornitore esternalizzato, quel fornitore potrebbe dover rientrare nell'ambito, il che significa che la cooperazione del fornitore deve essere garantita contrattualmente in anticipo.
• Il blue team in genere non viene informato. Il valore sta nel testare il rilevamento e la risposta reali, quindi un TLPT di cui i difensori erano stati avvisati ha perso gran parte del suo senso. Questo ha conseguenze organizzative che si pianificano, non si scoprono a metà esercitazione.
• I tester e i fornitori di threat intelligence devono soddisfare requisiti di competenza e indipendenza, e l'autorità esamina il processo. Non puoi semplicemente rietichettare il pentest annuale dell'anno scorso come TLPT.

Se la tua entità è al di sotto della soglia di significatività, non esegui il TLPT, ma devi comunque un programma di test basato sul rischio: valutazioni delle vulnerabilità, test basati su scenari, e test di resilienza del percorso di ripristino. Il corso Lead Operational Resilience Manager è costruito proprio attorno a questo livello di test ed evidenze rivolto al regolatore, e il corso DORA Lead Manager copre come l'intero programma è governato dall'inizio alla fine.

DORA come lex specialis rispetto a NIS 2 per le banche

Le banche, e la maggior parte delle altre entità finanziarie, rientrano nell'ambito sia di NIS 2 sia di DORA. I due si sovrappongono fortemente su rischio ICT, segnalazione degli incidenti e sicurezza della catena di fornitura, il che solleva l'ovvio timore di fare tutto due volte. DORA risolve la questione: sulle materie ICT che disciplina, DORA è lex specialis. La regola specifica prevale su quella generale. Laddove DORA fissa l'obbligo di gestione del rischio ICT e di segnalazione degli incidenti, un'entità finanziaria segue DORA, e le autorità competenti non dovrebbero applicare in aggiunta l'equivalente requisito NIS 2 per lo stesso tema ICT.

Cosa questo non significa: non disattiva del tutto NIS 2 per un'entità finanziaria, e non cambia chi è la tua autorità competente per le materie non ICT. La decisione pratica per una banca è mappare ogni obbligo allo strumento che lo disciplina: resilienza operativa ICT, segnalazione degli incidenti e rischio ICT di terze parti rientrano in DORA; tutto ciò che è al di fuori di DORA è ambito che valuti separatamente. Documenta quella mappatura. È la risposta alla domanda "stai contando due volte o sotto-contando" che esaminatori e auditor pongono entrambi.

Errori comuni e dove costruire la competenza

Gli insuccessi ricorrenti non sono esotici. Il registro è costruito per fornitore invece che per accordo e si rompe nel momento in cui il subappalto conta. La criticità delle funzioni critiche è valutata dall'IT invece che dal business, quindi l'ambito di tutto ciò che ne discende è sbagliato. Le soglie di classificazione degli incidenti sono scritte ma mai testate rispetto a un incidente reale, quindi il primo evento grave diventa la prima prova generale della tempistica di segnalazione. E la continuità operativa è trattata come un progetto ISO 22301 separato anziché come il muscolo di ripristino che i test DORA dovrebbero esercitare.

Quest'ultimo punto conta: DORA non sostituisce un sistema di gestione della continuità operativa, ne presuppone uno. Gli obiettivi di ripristino e il percorso di ripristino testato che un BCMS ti offre sono ciò che i test di resilienza convalidano. Costruisci il BCMS correttamente con il corso ISO 22301 Lead Implementer, e diventa il substrato su cui poggiano gli obblighi di resilienza operativa anziché un raccoglitore parallelo che nessuno apre.

Se parti dal regolamento stesso, il corso DORA Foundation offre a tutto il team una lettura condivisa e accurata dei cinque pilastri e dell'ambito prima che chiunque tocchi il registro o il programma di test. Da lì, il corso DORA Lead Manager è il livello di attuazione e governance per le persone che saranno titolari del quadro, e il corso Lead Operational Resilience Manager è per la funzione che deve presentarsi davanti al supervisore e dimostrare che la resilienza è reale, non documentata.