Come pianificare i test di resilienza DORA utilizzando l'AI

Panoramica

Imparerai come progettare e implementare un programma di test di resilienza operativa digitale che soddisfa gli Articoli 24-27 del DORA utilizzando l'AI. Questa guida copre il programma di test generale (valutazioni delle vulnerabilità, penetration testing, test basati su scenari), i requisiti avanzati di Threat-Led Penetration Testing (TLPT), la portata e la frequenza dei test, la comunicazione dei risultati al tuo organo di gestione e l'integrazione dei test con il tuo framework di gestione del rischio ICT, con prompt specifici di ISMS Copilot per generare ogni componente.

A chi è rivolto

Questa guida è per:

• CISO e security manager responsabili della progettazione e supervisione dei programmi di test di resilienza
• IT risk manager che integrano i risultati dei test nelle valutazioni del rischio ICT
• Coordinatori di penetration testing che gestiscono attività di test interne ed esterne
• Responsabili della conformità che assicurano che i programmi di test soddisfino le aspettative normative
• Consulenti che aiutano le entità finanziarie a prepararsi per il TLPT o i test di resilienza generale

Prima di iniziare

Avrai bisogno di:

• Un account ISMS Copilot (prova gratuita disponibile)
• Il tuo framework di gestione del rischio ICT e l'inventario degli asset ICT da Come costruire un framework di gestione del rischio ICT DORA utilizzando l'AI
• Le tue procedure di classificazione e risposta agli incidenti da Come implementare la segnalazione degli incidenti DORA utilizzando l'AI
• Una comprensione delle tue attuali attività di test (scansioni delle vulnerabilità, penetration test, test di disaster recovery)
• La conoscenza se la tua entità è stata designata per il TLPT dalla tua autorità competente
• L'autorizzazione di budget per i servizi di test esterni (in particolare per il TLPT)

Comprendere i requisiti di test di resilienza del DORA

Analisi articolo per articolo

Il Capitolo IV del DORA (Articoli 24-27) stabilisce un approccio strutturato ai test di resilienza operativa digitale:

Article

Title

Key requirements

Applicability

Art 24

Requisiti generali per i test di resilienza operativa digitale

Stabilire un programma di test come parte della gestione del rischio ICT, approccio basato sul rischio

Tutte le entità finanziarie (proporzionato)

Art 25

Test degli strumenti e dei sistemi ICT

Tipi di test specifici: valutazioni delle vulnerabilità, penetration testing, test basati su scenari, test di compatibilità, test di performance, revisioni del codice sorgente

Tutte le entità finanziarie (proporzionato)

Art 26

Test avanzati tramite TLPT

Threat-led penetration testing basato sul framework TIBER-EU, ogni 3 anni

Solo entità designate

Art 27

Requisiti per i tester

Qualifiche, indipendenza e standard per i tester (interni ed esterni)

Tutte le entità che conducono test

Test generali vs. TLPT

Comprendere la distinzione tra test generali e TLPT è fondamentale per definire la portata del tuo programma:

Aspect

Test generali (Art 24-25)

TLPT (Art 26-27)

Key difference

Chi

Tutte le entità finanziarie

Solo entità designate

L'autorità competente designa le entità TLPT

Frequenza

Basata sul rischio; sistemi critici almeno annualmente

Almeno ogni 3 anni

Il TLPT è meno frequente ma molto più intensivo

Portata

Tutti i sistemi ICT (proporzionato)

Funzioni critiche e importanti, sistemi di produzione live

Il TLPT testa i sistemi live, non solo gli ambienti di test

Metodologia

Varie (scansioni delle vulnerabilità, penetration test, test su scenari)

Framework TIBER-EU, guidato da threat intelligence

Il TLPT simula tattiche di avversari reali

Tester

Interni o esterni (con requisiti di indipendenza)

Tester esterni richiesti (con limitate eccezioni)

Il TLPT richiede un red team esterno certificato

Reporting

Interno (organo di gestione, funzione di rischio ICT)

All'autorità competente, con attestazione

I risultati del TLPT vanno al regolatore

Passo 1: Progetta il tuo programma di test generale (Articoli 24-25)

Framework del programma di test

L'Articolo 24 richiede un programma di test che sia parte integrante del tuo framework di gestione del rischio ICT, segua un approccio basato sul rischio e sia proporzionato alle dimensioni e al profilo di rischio della tua entità.

1. Apri il tuo spazio di lavoro DORA in ISMS Copilot

2. Genera il documento del programma di test:

   "Crea un Programma di Test di Resilienza Operativa Digitale per un [tipo di entità] che soddisfi gli Articoli 24-25 del DORA. Includi: scopo e obiettivi del programma, governance (supervisione dell'organo di gestione, responsabile del programma, ruoli e responsabilità), approccio basato sul rischio alla pianificazione dei test (come i rischi determinano cosa testare e con quale frequenza), portata dei test (mappata all'inventario degli asset ICT e alle funzioni critiche/importanti), tipi di test da condurre (valutazioni delle vulnerabilità, test di sicurezza della rete, penetration testing, test basati su scenari, test di compatibilità, test di performance, revisioni del codice sorgente, test del software open source, test end-to-end), frequenza dei test per criticità degli asset e tipo di test, requisiti per tester interni vs esterni, requisiti di indipendenza secondo l'Articolo 27, reporting dei risultati e comunicazione all'organo di gestione, processo di tracciamento delle remediation, integrazione con gli aggiornamenti del framework di gestione del rischio ICT, modello di calendario dei test annuale e pianificazione del budget e delle risorse. Applica la proporzionalità per un'organizzazione di [dimensione entità]."

3. Definisci la metodologia di test basata sul rischio:

   "Crea una metodologia di test basata sul rischio per i test di resilienza DORA. Definisci come determiniamo: quali sistemi e funzioni testare (in base alla criticità degli asset ICT, all'impatto aziendale, al panorama delle minacce, agli incidenti precedenti), quale tipo di test applicare (scansione delle vulnerabilità vs penetration test vs test basato su scenari), profondità e intensità del test (base, standard, avanzato), frequenza dei test (trimestrale, semestrale, annuale) e priorità dei test in caso di risorse limitate. Fornisci una matrice di priorità dei test che mappa la criticità degli asset e il livello di minaccia al tipo e alla frequenza dei test. Includi esempi per un [tipo di entità]."

Tipi di test e loro applicazione

L'Articolo 25 specifica più tipi di test. Usa ISMS Copilot per sviluppare piani dettagliati per ciascuno:

1. Programma di valutazione delle vulnerabilità:

   "Crea un programma di valutazione delle vulnerabilità per la conformità all'Articolo 25 del DORA. Includi: portata delle scansioni (tutti gli asset ICT per livello di criticità), strumenti e metodologia di scansione, frequenza delle scansioni (almeno trimestrale per gli asset critici, mensile consigliato), classificazione delle vulnerabilità allineata al punteggio CVSS, tempistiche di remediation per gravità (critiche: 48 ore, alte: 7 giorni, medie: 30 giorni, basse: 90 giorni), processo di gestione delle eccezioni per le vulnerabilità che non possono essere risolte immediatamente, formato di reporting (report tecnico e sintesi per la direzione), metodologia di analisi delle tendenze e integrazione con le procedure di gestione delle patch. Fornisci un flusso di lavoro per la gestione delle vulnerabilità."

2. Programma di penetration testing:

   "Crea un programma di penetration testing per la conformità all'Articolo 25 del DORA. Includi: portata dei test (perimetro esterno, rete interna, applicazioni web, applicazioni mobili, sicurezza delle API, ingegneria sociale), frequenza dei test (almeno annuale per i sistemi critici, più frequente per le aree ad alto rischio), metodologia di test (OWASP, PTES o equivalente), modello di regole di ingaggio (portata, tempistiche, escalation, azioni vietate), requisiti di qualificazione dei tester secondo l'Articolo 27 del DORA (indipendenza, competenza, assicurazione), procedure pre-test (autorizzazione, conferma della portata, comunicazione), requisiti di reporting (sintesi esecutiva, risultati tecnici, valutazioni del rischio, raccomandazioni di remediation), procedure post-test (verifica della remediation, ri-test), e formato di reporting per l'organo di gestione. Fornisci un modello di esempio delle regole di ingaggio."

3. Programma di test basati su scenari:

   "Progetta un programma di test di resilienza basati su scenari per l'Articolo 25 del DORA. Crea scenari di test che coprano: attacco ransomware ai sistemi bancari/core di pagamento, interruzione di un importante provider cloud che influisce sui servizi critici, attacco DDoS durante i periodi di picco delle transazioni, minaccia interna che compromette dati sensibili, attacco alla supply chain tramite un fornitore ICT critico di terze parti, guasto simultaneo dei sistemi primari e di backup, perdita di personale ICT chiave durante un incidente, violazione dei dati normativi che richiede la notifica ai clienti. Per ogni scenario, definisci: obiettivi del test, portata e sistemi coinvolti, narrativa dello scenario e timeline degli eventi, criteri di successo, partecipanti e ruoli, procedure di esecuzione del test, risultati attesi, criteri di valutazione e modello di reporting. Includi sia formati di esercitazione tabletop che simulati."

Passo 2: Stabilisci i requisiti per i tester (Articolo 27)

Indipendenza e qualifiche dei tester

L'Articolo 27 stabilisce i requisiti per i tester che conducono test di resilienza. Questi si applicano sia ai tester interni che esterni:

"Crea una politica di requisiti e qualifiche per i tester secondo l'Articolo 27 del DORA. Affronta: tester interni (indipendenza dalle aree testate, certificazioni rilevanti come OSCP/CREST/GPEN, competenza mantenuta, requisiti di rotazione), tester esterni (certificazioni professionali e accreditamenti, esperienza rilevante nei test del settore finanziario, assicurazione di responsabilità civile professionale, verifica dell'indipendenza, controllo delle referenze), gestione dei conflitti di interesse, procedure di verifica e autorizzazione di sicurezza dei tester, requisiti di riservatezza e non divulgazione, e criteri di valutazione delle prestazioni dei tester. Fornisci una checklist di qualificazione dei tester sia per i tester interni che esterni, e un esempio di statement of work per gli incarichi di test esterni."

Passo 3: Pianifica il TLPT (Articoli 26-27)

Comprendere i requisiti del TLPT

Il Threat-Led Penetration Testing (TLPT) secondo il DORA si basa sul framework TIBER-EU e rappresenta il requisito di test più intensivo. Anche se non sei stato designato per il TLPT, comprendere i requisiti è utile per la preparazione.

1. Valuta l'applicabilità del TLPT:

   "Valuta se la nostra [tipo di entità] con [dimensione, importanza sistemica, profilo di rischio ICT] è probabile che venga designata per il TLPT del DORA secondo l'Articolo 26. Considera: la nostra importanza sistemica nel settore finanziario, la criticità dei servizi che forniamo, il nostro profilo di rischio e complessità ICT, i criteri di designazione dell'autorità competente dalle linee guida pubblicate. Se è probabile la designazione, fornisci una valutazione della preparazione al TLPT e una timeline di preparazione. Se è improbabile, raccomanda le misure preparatorie che dovremmo adottare comunque."

2. Genera il framework TLPT:

   "Crea un framework di preparazione ed esecuzione del TLPT per l'Articolo 26 del DORA, allineato alla metodologia TIBER-EU. Includi: Fase 1 - Preparazione: definizione della portata (funzioni critiche e importanti da testare sui sistemi di produzione live), coinvolgimento e notifica all'autorità competente, selezione del fornitore di threat intelligence, selezione del fornitore del red team, formazione del white team (squadra interna a conoscenza del test), approvazioni della governance interna. Fase 2 - Threat Intelligence: report di threat intelligence (analisi del panorama delle minacce mirato), scenari di minaccia basati su attori e tecniche di minaccia attuali, analisi della superficie di attacco e revisione degli scenari di minaccia da parte dell'autorità competente. Fase 3 - Red Team Testing: ingaggio del red team (attacchi simulati sui sistemi di produzione live), esecuzione del test su [durata tipica: 8-12 settimane], meccanismi di sicurezza per il testing controllato, attività di purple team (se concordate) e documentazione dei risultati. Fase 4 - Chiusura: report del red team con risultati ed evidenze, valutazione della risposta del blue team, sviluppo del piano di remediation, briefing all'organo di gestione, processo di attestazione all'autorità competente. Fornisci stime di tempistiche e requisiti di risorse per ogni fase."

Selezione del fornitore TLPT

Il TLPT richiede sia un fornitore di threat intelligence che un fornitore di red team. Usa ISMS Copilot per sviluppare criteri di selezione:

"Crea un framework di selezione dei fornitori TLPT per gli Articoli 26-27 del DORA. Per il Fornitore di Threat Intelligence: qualifiche richieste (esperienza specifica sulle minacce nel settore finanziario, certificazioni riconosciute), criteri di valutazione (qualità dei precedenti report sulle minacce, comprensione delle minacce nel settore finanziario UE, fonti di dati e capacità di raccolta), e checklist di selezione. Per il Fornitore di Red Team: qualifiche richieste (accreditamento CREST, CBEST o equivalente, esperienza con i test TIBER-EU, esperienza nel settore finanziario), criteri di valutazione (capacità tecniche, metodologia, composizione del team, track record di sicurezza), verifica dell'indipendenza (nessun rapporto di consulenza attuale con l'entità), requisiti assicurativi e checklist di selezione. Fornisci un modello di RFP per entrambi i tipi di fornitori."

Definizione della portata del TLPT

Una corretta definizione della portata è fondamentale per un TLPT di successo. Usa ISMS Copilot per definire la portata dei test:

"Aiutaci a definire la portata per il nostro esercizio TLPT del DORA. Le nostre funzioni critiche e importanti includono: [elenco funzioni]. Per ogni funzione critica, identifica: i sistemi e l'infrastruttura ICT di supporto che dovrebbero essere inclusi nella portata, i flussi di dati e le integrazioni che potrebbero essere percorsi di attacco, i fornitori ICT di terze parti che supportano la funzione (e se dovrebbero essere inclusi nei test secondo l'Articolo 26(3)), le potenziali superfici di attacco (esterne, interne, fisiche, ingegneria sociale), e i sistemi che dovrebbero essere esplicitamente esclusi per motivi di sicurezza. Produci un documento di portata TLPT adatto per la revisione da parte dell'autorità competente."

Passo 4: Reporting dei risultati e tracciamento delle remediation

Comunicazione dei risultati dei test alla direzione

Il DORA richiede che i risultati dei test siano comunicati all'organo di gestione e utilizzati per aggiornare il framework di gestione del rischio ICT:

1. Genera modelli di report dei risultati dei test:

   "Crea un modello di report dei risultati dei test di resilienza per la comunicazione all'organo di gestione secondo l'Articolo 24 del DORA. Includi: sintesi esecutiva (postura generale di resilienza, risultati chiave, confronto delle tendenze), sintesi dell'esecuzione del programma di test (test condotti, portata, tempistiche), risultati per gravità (critici, alti, medi, bassi) con contesto di impatto aziendale, confronto con i cicli di test precedenti (miglioramento o peggioramento), stato delle remediation per le vulnerabilità precedentemente identificate, nuove raccomandazioni di remediation con priorità basata sul rischio, valutazione dell'efficacia del programma di test, utilizzo del budget e delle risorse, e raccomandazioni per gli aggiustamenti del programma di test. Il report dovrebbe essere adatto ai membri del consiglio non tecnici, mantenendo al contempo dettagli sufficienti per la supervisione del rischio."

2. Crea la documentazione di attestazione TLPT:

   "Crea un pacchetto di documentazione di attestazione TLPT per la presentazione alla nostra autorità competente secondo l'Articolo 26(6) del DORA. Includi: report di sintesi del TLPT (portata, metodologia, tempistiche), risultati del red team in forma anonima (severità critica e alta), piano di remediation con tempistiche e stato, riconoscimento e approvazione dell'organo di gestione, lezioni apprese dall'organizzazione, e eventuali richieste di riconoscimento reciproco con altre autorità competenti. Segui le linee guida sul formato dell'[autorità competente] e del framework TIBER-EU."

Tracciamento delle remediation

I test sono utili solo se i risultati portano a miglioramenti. Stabilisci un solido tracciamento delle remediation:

"Crea una procedura di tracciamento delle remediation dei test di resilienza per la conformità al DORA. Includi: come i risultati vengono tradotti in azioni di remediation, metodologia di prioritizzazione (critiche: remediation entro 30 giorni, alte: 60 giorni, medie: 90 giorni, basse: prossimo ciclo di test), assegnazione e responsabilità del proprietario della remediation, tracciamento dei progressi e escalation per le remediation in ritardo, test di verifica (conferma dell'efficacia delle correzioni), processo di eccezione per i risultati che non possono essere risolti (controlli compensativi, accettazione del rischio con approvazione dell'organo di gestione), integrazione con il registro dei rischi ICT (aggiornamento delle valutazioni dei rischi basate sui risultati dei test), e cadenza di reporting all'organo di gestione. Fornisci un modello di registro di tracciamento delle remediation."

Passo 5: Integra i test con il tuo framework di gestione del rischio ICT

Inserimento dei risultati nella gestione del rischio

Il DORA richiede che i risultati dei test informino e aggiornino il tuo framework di gestione del rischio ICT. Usa ISMS Copilot per formalizzare questa integrazione:

"Definisci come i risultati dei test di resilienza si integrano con il nostro framework di gestione del rischio ICT del DORA. Includi: come i risultati dei test aggiornano il registro dei rischi ICT (nuovi rischi identificati, valutazioni dei rischi aggiornate, rivalutazione dell'efficacia dei controlli), come i risultati dei test informano la revisione annuale del framework di gestione del rischio ICT secondo l'Articolo 6(5), come i risultati del TLPT influenzano la nostra strategia di rischio ICT e l'appetito per il rischio, come i risultati dei test basati su scenari aggiornano i nostri piani di continuità operativa e disaster recovery, come le tendenze delle valutazioni delle vulnerabilità informano le nostre misure di protezione e prevenzione secondo l'Articolo 9, e come i risultati delle simulazioni di incidenti convalidano o mettono in discussione le nostre procedure di classificazione e reporting degli incidenti. Fornisci un flusso di processo che mostri il ciclo di feedback tra i test e la gestione del rischio."

Miglioramento continuo dei test

Il tuo programma di test stesso dovrebbe evolversi in base ai risultati e alle minacce in cambiamento:

"Crea un processo di revisione annuale del programma di test per la conformità al DORA. La revisione dovrebbe valutare: copertura dei test (abbiamo testato tutti i sistemi e le funzioni critiche come pianificato?), efficacia dei test (i test hanno identificato vulnerabilità reali? come si confrontano i risultati con gli incidenti effettivi?), efficienza dei test (stiamo utilizzando le risorse in modo efficace? ci sono test sovrapposti o ridondanti?), cambiamenti nel panorama delle minacce (i nostri scenari di test riflettono le minacce attuali?), nuovi sistemi o servizi aggiunti dall'ultima revisione (sono inclusi nella portata dei test?), feedback normativi o linee guida sulle aspettative di test, e aggiustamenti raccomandati per il programma nel ciclo successivo. Produci un modello di report di revisione annuale del programma di test per l'approvazione dell'organo di gestione."

Passo 6: Gestisci la logistica e la governance dei test

Calendario e coordinamento dei test

Stabilisci un calendario annuale strutturato dei test per assicurarti che tutte le attività di test siano pianificate, dotate di risorse e coordinate:

"Crea un calendario annuale dei test di resilienza per la nostra [tipo di entità]. Mappa tutte le attività di test richieste durante l'anno: scansioni delle vulnerabilità (trimestrali per i sistemi critici, mensili per quelli esposti su internet), penetration test (annuale esterno, annuale interno, annuale applicativo), esercitazioni basate su scenari (semestrale tabletop, annuale simulato), test di continuità operativa (annuale failover, annuale ripristino backup), e attività di preparazione TLPT (se applicabile). Includi: requisiti di risorse per ogni attività, requisiti di coordinamento (finestre di freeze delle modifiche, coinvolgimento delle unità aziendali), dipendenze tra le attività di test, allocazione del budget per trimestre e milestone di reporting all'organo di gestione. Formatta come vista calendario con struttura a diagramma di Gantt."

Test dei fornitori ICT di terze parti

L'Articolo 26(3) affronta i test che coinvolgono i fornitori di servizi ICT di terze parti. Coordina i requisiti di test con i tuoi fornitori:

"Crea procedure per il coordinamento dei test di resilienza con i fornitori ICT di terze parti secondo il DORA. Includi: requisiti contrattuali per la partecipazione del fornitore ai test (collegamento alle clausole contrattuali dell'Articolo 28), procedure di notifica e coordinamento con il fornitore, test di responsabilità condivisa (cosa testiamo noi vs cosa testa il fornitore), gestione del rifiuto del fornitore a partecipare ai test, approcci alternativi di test quando il test diretto del fornitore non è possibile (test sintetici, report di test forniti dal fornitore), TLPT che coinvolge i sistemi del fornitore di terze parti (accordi di test aggregati secondo l'Articolo 26(3)), e raccolta di prove dalle attività di test del fornitore. Affronta scenari per fornitori cloud, fornitori di servizi gestiti e fornitori di infrastrutture critiche."

Prossimi passi

Ora disponi di un programma completo di test di resilienza operativa digitale:

• Framework del programma di test con metodologia basata sul rischio
• Piani dettagliati per valutazioni delle vulnerabilità, penetration testing e test basati su scenari
• Requisiti di qualificazione e indipendenza dei tester
• Framework di preparazione TLPT (se designato o probabile che lo sia)
• Modelli di reporting dei risultati per l'organo di gestione e l'autorità competente
• Procedure di tracciamento delle remediation
• Integrazione con il framework di gestione del rischio ICT

Continua con l'ultima guida di questa serie DORA:

• Come gestire il rischio ICT di terze parti DORA utilizzando l'AI -- Assicurati che i tuoi fornitori di terze parti siano inclusi nel tuo programma di test e che i contratti supportino i tuoi obblighi di test

Per la configurazione di base, consulta Come iniziare con l'implementazione del DORA utilizzando l'AI. Per il framework di rischio ICT, consulta Come costruire un framework di gestione del rischio ICT DORA utilizzando l'AI. Per l'integrazione della segnalazione degli incidenti, consulta Come implementare la segnalazione degli incidenti DORA utilizzando l'AI.

Per prompt pronti all'uso, consulta la DORA Compliance Prompt Library. Per la panoramica normativa completa, fai riferimento alla Guida alla conformità DORA per le entità finanziarie.

Ottenere aiuto

Per ulteriore supporto nella pianificazione del tuo programma di test di resilienza:

• Chiedi a ISMS Copilot: Usa il tuo spazio di lavoro DORA per generare scenari di test specifici per il tipo di entità e l'ambiente ICT
• Carica report di test esistenti: Ottieni un'analisi delle lacune caricando report precedenti di penetration test o valutazioni delle vulnerabilità per il confronto con i requisiti DORA
• Preparazione TLPT: Usa ISMS Copilot per sviluppare il documento di portata del TLPT e i criteri di selezione dei fornitori prima di coinvolgere la tua autorità competente
• Convalida degli output: Rivedi tutti i piani di test rispetto agli Articoli 24-27 del DORA, agli RTS pertinenti e al framework TIBER-EU prima dell'approvazione dell'organo di gestione