DORA Pentest Italia: Obblighi di Test di Penetrazione secondo gli Art. 24 e 26
Dal 17 gennaio 2025, il regolamento Digital Operational Resilience Act (DORA, regolamento (UE) 2022/2554) si applica direttamente in tutti gli Stati membri dell'Unione europea. L'articolo 24 obbliga gli enti finanziari a effettuare test di penetrazione regolari dei propri sistemi TIC; l'articolo 26 impone agli istituti di rilevanza sistemica i Threat-Led Penetration Test (TLPT) aggiuntivi. In Italia, Banca d'Italia e IVASS svolgono un ruolo centrale nella supervisione di questi obblighi. La presente guida illustra quali enti rientrano nel perimetro, cosa richiede concretamente il regolamento e quale approccio soddisfa le esigenze normative.
Perché DORA rende il test di penetrazione un obbligo regolamentare
DORA non è una guida alle buone pratiche: è un regolamento europeo di applicazione diretta. A differenza delle precedenti linee guida EBA sui rischi TIC (EBA/GL/2019/04), DORA ha forza vincolante: Banca d'Italia e IVASS possono infliggere sanzioni pecuniarie fino all'1% del fatturato giornaliero mondiale e coinvolgere personalmente la responsabilità dei dirigenti. L'articolo 24, paragrafo 1 del regolamento DORA richiede che gli enti finanziari sottopongano i propri sistemi, applicazioni e infrastrutture TIC a un «programma di test della resilienza operativa digitale» regolare. L'articolo 24, paragrafo 2, cita esplicitamente i «test di penetrazione, compresi i test di penetrazione basati sulla minaccia». Banca d'Italia ha precisato nelle proprie comunicazioni del gennaio 2025 che una semplice scansione delle vulnerabilità non soddisfa questo requisito: è richiesto un test di penetrazione completo con un perimetro documentato, una metodologia e una prova di sfruttamento. Per gli istituti significativi e di rilevanza sistemica (art. 26 DORA), il framework TLPT (Threat-Led Penetration Testing, riferimento TIBER-EU / TIBER-IT) si applica in aggiunta, e solo i fornitori accreditati da Banca d'Italia possono condurre tali test.
- DORA Art. 24 §1 e §2: obbligo di test di sicurezza TIC regolari, comprensivi di test di penetrazione per tutti gli enti finanziari di cui all'Art. 2 DORA — istituti di credito, imprese di investimento, assicuratori, istituti di pagamento, prestatori di servizi per le cripto-attività (MiCA), agenzie di rating, depositari centrali di titoli.
- DORA Art. 26 §1: obbligo TLPT per gli istituti di rilevanza sistemica — almeno ogni tre anni, un test di penetrazione basato sulla minaccia completo condotto da un fornitore accreditato, coordinato con l'autorità competente (Banca d'Italia / IVASS).
- DORA Art. 24 §7 e §8: i test devono essere condotti da parti indipendenti (interne o esterne); per i servizi TIC critici, da tester esterni; documentazione completa comprendente perimetro, metodologia e vulnerabilità rilevate.
- RTS DORA (Regolamento delegato (UE) 2024/1774): le norme tecniche di regolamentazione precisano i requisiti relativi ai test di sicurezza TIC — copertura minima, frequenza, obblighi di reporting.
- TIBER-IT (framework Banca d'Italia): declinazione italiana del riferimento TIBER-EU, che definisce i criteri di accreditamento dei fornitori Red Team operanti sul mercato italiano e le procedure di coordinamento con Banca d'Italia.
- Responsabilità personale dei dirigenti (Art. 5 DORA): il consiglio di amministrazione e la direzione generale sono direttamente responsabili della resilienza operativa digitale — l'assenza di prove di test di penetrazione costituisce un rischio di governance diretto.
- Coordinamento transfrontaliero (Art. 26 §8 DORA): per gli istituti operanti in più Stati membri, la BCE coordina i test TLPT comuni — il riferimento TIBER-EU definisce il quadro applicabile.
Cosa deve coprire un test di penetrazione conforme a DORA
- Sistemi TIC delle funzioni essenziali (Art. 24 §3 DORA): sistemi bancari core, API di pagamento, piattaforme di trading, archivi dati clienti — inventario completo degli asset come prerequisito.
- Autenticazione e controllo degli accessi: implementazioni MFA (requisiti PSD2 SCA), flussi OAuth2/OIDC, gestione degli accessi privilegiati (PAM), autorizzazioni degli account di servizio.
- Sicurezza delle API secondo OWASP API Top 10 (2023): API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Property Level Authorization — particolarmente critico per le API Open Banking (PSD2, Berlin Group NextGenPSD2).
- Segmentazione di rete e configurazione dei firewall: separazione degli ambienti TIC (produzione / collaudo / sviluppo), movimento laterale tra segmenti, isolamento della rete SWIFT (SWIFT CSP CSCF v2024).
- Cifratura dei dati a riposo e in transito: TLS 1.3 (RFC 8446), integrazione HSM per il materiale crittografico, suite di cifratura obsolete (CVE-2016-2107 POODLE, CVE-2023-0215 OpenSSL), CVE-2022-0778 (loop infinito OpenSSL).
- Dipendenze TIC di terze parti (Art. 28 DORA): componenti SaaS, fornitori di infrastruttura cloud, processori di pagamento — rischi della supply chain, CVE noti nelle librerie di terze parti.
- Continuità operativa e ripristino dopo un incidente: test della capacità di un attaccante di compromettere i processi di backup; simulazione ransomware sui sistemi di backup; verifica dei tempi di ripristino.
- Simulazioni di ingegneria sociale e phishing (per gli engagement TLPT più completi): sensibilizzazione del personale, controlli tecnici di rilevamento del phishing, tempi di risposta del team di incident response.
- Infrastruttura cloud (rischi di terze parti Art. 28 DORA): errori di configurazione IAM in AWS/Azure/GCP, autorizzazioni S3 Bucket, account di storage esposti, funzioni serverless non sicure.
- Logging e monitoraggio (Art. 10 DORA): verifica che le attività di attacco vengano rilevate dal SIEM/SOAR — principio «rilevare ciò che facciamo» come prova DORA.
Esempio di finding
Flusso OAuth2 non sicuro sul gateway API Open Banking (violazione FAPI)
Il gateway API Open Banking implementa il flusso OAuth2 Authorization Code senza PKCE (Proof Key for Code Exchange, RFC 7636). Un attaccante in posizione di man-in-the-middle può intercettare il codice di autorizzazione dall'URL di reindirizzamento del browser e scambiarlo con un token di accesso senza possedere il code_verifier. Inoltre, il gateway non convalida il parametro «state», il che consente un attacco di tipo Cross-Site Request Forgery durante l'inizializzazione OAuth. Il gateway elabora oltre 50.000 transazioni PSD2 al giorno; un token compromesso consente l'accesso completo in lettura ai dati di conto e ai pagamenti avviati.
Correzione: Implementare PKCE (RFC 7636) come requisito obbligatorio per tutti i flussi OAuth2 (incluso lato server, in difesa in profondità). Convalidare il parametro «state» ad ogni richiesta di autorizzazione. Migrare verso il profilo di sicurezza Financial-grade API (FAPI 2.0, OpenID Foundation) come best practice per l'Open Banking. Rotazione dei token dopo ogni utilizzo, durata breve dei token di accesso (5 minuti massimo), token di aggiornamento solo con rotazione. Documentare il protocollo di test di penetrazione conformemente a DORA Art. 24 §7.
Riferimento: CVE-2022-21449 (ECDSA Psychic Signatures, Java) · OWASP API2:2023 Broken Authentication · RFC 7636 PKCE · DORA Art. 24 §2 · PSD2 RTS sull'AFS (UE) 2018/389 Art. 9
Pentest DORA: confronto delle opzioni
| — | Scan gratuito | Matproof Sentinel | Consulenza tradizionale |
|---|---|---|---|
| Motore di scansione automatizzato | ✓ (anteprima 3 min) | ✓ Scansione completa | ✗ Solo manuale |
| Copertura OWASP Top 10 | Parziale | ✓ Completa | ✓ Completa |
| Prova di exploit | ✗ | ✓ Per finding | ✓ Per finding |
| Mapping normativo (DORA/NIS2/ISO 27001) | ✗ | ✓ Automatizzato | ✓ Manuale |
| Report PDF pronto per l'audit | ✗ | ✓ Immediato | ✓ Consegna 2–4 settimane |
| Scansioni continue / ricorrenti | ✗ | ✓ Per deploy | ✗ Impegno annuale |
| Tempo al primo risultato | ~3 min | ~30 min scansione completa | 2–4 settimane |
| Prezzo | €0 | Da €149 | €8.000–€25.000 |
| Revisione codice sorgente (SAST) | ✗ | ✓ Piano Growth | ✓ In scope |
| Test API (REST/GraphQL) | ✗ | ✓ Automatizzato | ✓ Manuale |
Offerte di pentest conformi a DORA
- 1 scansione pentest completa
- Risultati prioritizzati da AI con CVSS 3.1
- Proof-of-exploit per ogni finding
- Report PDF (pronto per l'audit)
- Mapping normativo (DORA, NIS2, ISO 27001)
- Scansioni illimitate (fino a 3 domini)
- Monitoraggio continuo
- Integrazione CI/CD (GitHub, GitLab)
- Tutti i mapping normativi
- Supporto prioritario
- Scansioni + domini illimitati
- Test autenticati / White-Box
- Test API e infrastruttura cloud
- Account manager dedicato
- SLA risposta 24h
Domande frequenti sul test di penetrazione DORA in Italia
Quali enti sono soggetti all'obbligo di test di penetrazione DORA Art. 24 in Italia?
L'Art. 2 DORA definisce il campo di applicazione: istituti di credito, istituti di pagamento, istituti di moneta elettronica, imprese di investimento, imprese di assicurazione, agenzie di rating, repertori di dati sulle negoziazioni, piattaforme di negoziazione, prestatori di servizi per le cripto-attività (MiCA), servizi di reporting e fornitori terzi critici di servizi TIC. In Italia, la supervisione è esercitata da Banca d'Italia per gli istituti di credito e gli istituti di pagamento, da IVASS per le imprese di assicurazione e da Consob per le imprese di investimento. Le PMI (Art. 3 DORA) sono soggette a requisiti semplificati, ma il principio di test tecnici regolari si applica anche a esse.
Qual è la differenza tra il pentest DORA Art. 24 e il TLPT dell'Art. 26?
L'Art. 24 prescrive test di penetrazione generali per tutti gli enti finanziari interessati — la frequenza, il perimetro e la profondità sono basati sul rischio, ma deve esistere un report di test di penetrazione documentato. L'Art. 26 TLPT è un requisito aggiuntivo riservato agli istituti «significativi» (banche sistemiche, assicuratori importanti): almeno ogni tre anni, un test Red Team completo in cui un fornitore accreditato deriva la propria metodologia da una reale analisi della minaccia e attacca senza preavviso. Un TLPT costa generalmente tra 80.000 € e 250.000 €; un pentest DORA standard è realizzabile con una piattaforma di pentest AI come Matproof Sentinel o un fornitore specializzato (8.000 € – 25.000 €).
Con quale frequenza deve essere effettuato un pentest DORA?
DORA non impone una frequenza fissa — l'Art. 24 §1 parla di «regolarmente». L'interpretazione di Banca d'Italia e le linee guida EBA prevedono generalmente test almeno annuali per i sistemi critici e dopo modifiche sostanziali. L'Art. 26 TLPT impone esplicitamente almeno ogni tre anni per gli istituti interessati. Raccomandazione: pentest annuale completo + scanning continuo (tramite Matproof Sentinel) dopo ogni versione principale.
Cosa deve contenere il report di pentest DORA?
L'Art. 24 §7 DORA richiede: documentazione del perimetro (quali sistemi sono stati testati), metodologia utilizzata, vulnerabilità identificate con livello di gravità, raccomandazioni di remediation e stato (corretto / in corso / accettato). Banca d'Italia raccomanda inoltre: qualifica del tester (OSCP/CREST o equivalente), riferimento metodologico utilizzato (PTES, OWASP Testing Guide), prova di sfruttamento per i rilievi critici e alti. Matproof Sentinel genera automaticamente tutti questi elementi nel report PDF.
Matproof Sentinel può sostituire il test TLPT DORA Art. 26?
No — il TLPT DORA Art. 26 richiede, per gli istituti di rilevanza sistemica, un fornitore Red Team accreditato da Banca d'Italia / BCE. Matproof Sentinel è una piattaforma di pentest assistita dall'IA perfettamente adatta al pentest DORA Art. 24 standard, alla preparazione al TLPT (analisi dei gap, baseline delle vulnerabilità) e ai test di sicurezza continui tra i cicli TLPT. Per il TLPT, orientiamo volentieri verso partner accreditati.
Quali sanzioni rischia un ente finanziario che non riesce a dimostrare un pentest DORA?
Banca d'Italia, IVASS e la BCE possono infliggere sanzioni fino all'1% del fatturato giornaliero mondiale in caso di inosservanza dei requisiti DORA (Art. 50 DORA). In caso di violazioni ripetute o gravi, è possibile anche la sospensione dell'attività. Inoltre, la direzione risponde personalmente (Art. 5 DORA). In pratica, l'assenza di prove di test di penetrazione durante i controlli prudenziali viene qualificata come inadempienza significativa, con conseguenti obblighi di conformità e giustificazione.
I fornitori TIC terzi (cloud, SaaS) devono anch'essi effettuare pentest DORA?
Direttamente: sì, se sono designati «fornitori terzi critici di servizi TIC» ai sensi dell'Art. 31 DORA (designazione da parte di EBA/ESMA/EIOPA). In tal caso, sono direttamente soggetti alla supervisione DORA. Indirettamente: tutti gli altri fornitori TIC terzi devono soddisfare requisiti minimi di sicurezza tramite clausole contrattuali (Art. 30 DORA) che possono includere test di penetrazione. L'ente finanziario deve assicurarsi ai sensi dell'Art. 28 DORA che i propri fornitori terzi critici effettuino test di sicurezza adeguati.
Come si articolano DORA e NIS2 per gli enti finanziari italiani?
DORA è una norma settoriale speciale per gli enti finanziari e prevale su NIS2 come lex specialis. In Italia, NIS2 è stata recepita con il D.Lgs. 138/2024, che si applica in generale agli enti essenziali e importanti nei settori critici, ma l'Art. 4 della direttiva NIS2 precisa che il diritto settoriale europeo (come DORA) prevale. Le imprese soggette sia a DORA sia a NIS2 devono conformarsi solo a DORA — il regolatore ritiene che la conformità DORA copra integralmente NIS2.
Approfondisci — articoli correlati dal blog
Avvii subito il Suo pentest conforme a DORA
Ottenga una prima valutazione della Sua postura di sicurezza TIC in 3 minuti — senza registrazione, senza impegno. Il pentest completo Matproof Sentinel produce un report audit-ready che soddisfa i requisiti dell'Art. 24 §7 DORA. Per il TLPT Art. 26, La mettiamo in contatto con partner accreditati da Banca d'Italia.
Avvia il pentest DORA