Evidenze DORA TLPT con i controlli ISO 27001

Sono le 07:40 di un lunedì mattina e il CISO di un istituto di pagamento di medie dimensioni sta esaminando tre versioni della stessa domanda scomoda.

Il Consiglio di amministrazione vuole sapere se l’organizzazione può resistere all’indisponibilità del portale di pagamento clienti causata da ransomware. L’autorità di vigilanza vuole la prova che i test di resilienza operativa digitale non siano un esercizio su PowerPoint. L’Audit interno vuole una traccia chiara dagli obblighi DORA al rischio ICT, ai controlli ISO 27001, ai risultati dei test, ai piani di remediation, alle evidenze dei fornitori e all’approvazione della direzione.

Il CISO dispone di un rapporto del red team. Il SOC ha screenshot degli alert. Il team infrastrutturale ha un log di ripristino dei backup. La funzione legale ha un registro di preparazione a DORA. L’ufficio acquisti ha attestazioni del cloud provider.

Nulla è collegato.

È qui che molti programmi DORA TLPT e di test di resilienza falliscono. Non perché il test sia debole, ma perché le evidenze sono frammentate. Quando un auditor chiede: “Mostratemi in che modo questo test dimostra la resilienza di una funzione critica o importante”, la risposta non può essere una cartella piena di screenshot. Deve essere una catena di evidenze sostenibile.

Quella catena è il punto in cui un SGSI allineato a ISO/IEC 27001:2022 ISO/IEC 27001:2022 diventa potente. ISO 27001 fornisce una struttura per campo di applicazione, valutazione del rischio, selezione dei controlli, Dichiarazione di Applicabilità, controllo operativo, audit interno, riesame della direzione e miglioramento continuo. DORA fornisce la pressione settoriale. La metodologia Clarysec e gli strumenti di conformità trasversale collegano entrambi in un unico modello di evidenze pronto per l’audit.

DORA TLPT è un test di governance, non solo una simulazione di attacco

Il threat-led penetration testing, o TLPT, è facile da fraintendere. Dal punto di vista tecnico può sembrare un’esercitazione red team sofisticata: threat intelligence, percorsi di attacco realistici, stealth, tentativi di exploit, scenari di movimento laterale e convalida della risposta del blue team.

Per DORA, il tema più profondo è la resilienza operativa digitale. L’ente finanziario è in grado di resistere, rispondere e ripristinare l’operatività a fronte di una grave interruzione ICT che interessa i processi aziendali? Può dimostrare che le funzioni critiche o importanti restano entro le tolleranze d’impatto? La direzione può dimostrare che il rischio ICT è governato, finanziato, testato, corretto e migliorato?

DORA Article 1 istituisce un quadro uniforme dell’UE per la sicurezza delle reti e dei sistemi informativi a supporto dei processi aziendali degli enti finanziari. Copre gestione del rischio ICT, segnalazione degli incidenti rilevanti connessi all’ICT, test di resilienza operativa digitale, gestione del rischio ICT di terze parti, requisiti contrattuali obbligatori per i fornitori ICT, vigilanza sui fornitori terzi critici di servizi ICT e cooperazione tra autorità di vigilanza. DORA si applica dal 17 gennaio 2025.

Per le organizzazioni soggette anche a NIS2, DORA opera come atto giuridico dell’Unione specifico di settore per i requisiti di cybersecurity sovrapposti. In pratica, gli enti finanziari dovrebbero dare priorità a DORA per gestione del rischio ICT, segnalazione degli incidenti, test e rischio ICT di terze parti quando i regimi si sovrappongono, pur comprendendo le aspettative NIS2 relative a strutture di gruppo, fornitori e servizi digitali non finanziari.

DORA colloca inoltre la responsabilità al vertice. Article 5 richiede all’organo di gestione di definire, approvare, vigilare e attuare le disposizioni in materia di rischio ICT. Ciò include la strategia di resilienza operativa digitale, la politica di continuità operativa ICT, i piani di risposta e ripristino, i piani di audit, i budget, le politiche ICT di terze parti, i canali di reporting e adeguate conoscenze sul rischio ICT attraverso formazione regolare.

La domanda di audit, quindi, non è semplicemente: “Avete eseguito un TLPT?”

È:

• Il TLPT era collegato a funzioni critiche o importanti?
• Era autorizzato, delimitato nell’ambito, sicuro e sottoposto a valutazione del rischio?
• Sono stati inclusi, ove rilevante, fornitori, dipendenze cloud e servizi ICT esternalizzati?
• Il test ha prodotto evidenze di rilevazione, risposta, ripristino e lezioni apprese?
• Le risultanze sono state convertite in trattamento del rischio, remediation tracciata, retest e reporting alla direzione?
• La Dichiarazione di Applicabilità spiegava quali controlli dell’Annex A di ISO 27001 sono stati selezionati per gestire il rischio?

Per questo Clarysec tratta le evidenze DORA TLPT come un problema di evidenze del SGSI, non solo come un deliverable di penetration testing.

Costruire la spina dorsale delle evidenze ISO 27001 prima dell’inizio del test

ISO 27001 richiede a un’organizzazione di stabilire, attuare, mantenere e migliorare continuamente un SGSI che preservi riservatezza, integrità e disponibilità attraverso un processo di gestione del rischio. Le Clauses 4.1 to 4.4 richiedono all’organizzazione di comprendere questioni interne ed esterne, parti interessate, obblighi legali e normativi, interfacce, dipendenze e quindi documentare il campo di applicazione del SGSI.

Per un’entità regolamentata da DORA, questa fase di definizione del campo di applicazione dovrebbe rilevare esplicitamente funzioni critiche o importanti, asset ICT, piattaforme cloud, operazioni esternalizzate, sistemi di pagamento, portali clienti, servizi di identità, piattaforme di logging, ambienti di ripristino e fornitori terzi di servizi ICT. Se l’ambito del TLPT non si ricollega al campo di applicazione del SGSI, la traccia di audit è già debole.

ISO 27001 Clauses 6.1.1, 6.1.2 and 6.1.3, insieme alle Clauses 8.2 and 8.3, richiedono un processo di valutazione e trattamento del rischio. I rischi devono essere identificati rispetto a riservatezza, integrità e disponibilità. Devono essere assegnati i Titolari del rischio. Devono essere valutate probabilità e conseguenze. I controlli devono essere selezionati e confrontati con l’Annex A. Il rischio residuo deve essere accettato dai Titolari del rischio.

Questo è il ponte tra DORA e test pronti per l’audit.

Il Zenith Blueprint: roadmap in 30 passi per auditor Zenith Blueprint di Clarysec, nella fase di Gestione del rischio, Step 13, descrive chiaramente questo ruolo di tracciabilità:

La SoA è di fatto un documento ponte: collega la valutazione/trattamento del rischio ai controlli effettivamente presenti. Completandola, si verifica anche se sono stati omessi controlli.

Per DORA TLPT, la Dichiarazione di Applicabilità non dovrebbe essere un artefatto statico di certificazione. Dovrebbe spiegare perché controlli come sicurezza dei fornitori, gestione degli incidenti, prontezza ICT per la continuità operativa, logging, monitoraggio, gestione tecnica delle vulnerabilità, backup, sviluppo sicuro e test di sicurezza sono applicabili allo scenario di resilienza.

Uno scenario pratico di rischio potrebbe essere:

“La compromissione delle credenziali privilegiate del provider di identità consente a un attaccante di accedere ai sistemi di amministrazione del processamento dei pagamenti, modificare le configurazioni di instradamento e interrompere una funzione critica di pagamento, causando indisponibilità del servizio, obblighi di segnalazione regolamentare, danni ai clienti e danno reputazionale.”

Questo singolo scenario può guidare l’ambito del TLPT, i casi d’uso di rilevazione, il coinvolgimento dei fornitori, l’esercitazione di ripristino, il reporting al Consiglio di amministrazione e il set di evidenze.

Il Zenith Blueprint raccomanda inoltre di rendere esplicita la tracciabilità normativa:

Creare riferimenti incrociati con le normative: se determinati controlli sono attuati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile indicarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.

Il consiglio è semplice, ma cambia il confronto in audit. Invece di dire a un auditor che DORA è stata presa in considerazione, l’organizzazione può mostrare dove DORA compare nel Registro dei rischi, nella SoA, nel programma di test, nell’insieme delle politiche e nel riesame della direzione.

Mappare i test DORA sui controlli ISO 27001 riconosciuti dagli auditor

DORA Article 6 si aspetta un quadro di gestione del rischio ICT documentato e integrato nella gestione complessiva del rischio. L’Annex A di ISO 27001 fornisce il catalogo dei controlli che rende operativo tale quadro.

Per DORA TLPT e i test di resilienza, questi controlli dell’Annex A di ISO/IEC 27001:2022 sono particolarmente importanti:

Zenith Controls: la guida alla conformità trasversale Zenith Controls di Clarysec aiuta le organizzazioni a evitare di trattare questi controlli come elementi isolati di una checklist. Mappa i controlli ISO/IEC 27002:2022 su attributi, domini, capacità operative, aspettative di audit e schemi di cross-framework.

Ad esempio, Zenith Controls classifica il controllo ISO/IEC 27002:2022 5.30, Prontezza ICT per la continuità operativa, come “Correttivo”, allineato alla “Disponibilità”, associato al concetto di cybersecurity “Respond” e collocato nel dominio “Resilience”. Questa classificazione è utile per spiegare agli auditor perché un’esercitazione di ripristino non è solo un’operazione IT, ma un controllo di resilienza con un ruolo definito nell’ambiente di controllo.

Zenith Controls classifica inoltre il controllo 8.29, Test di sicurezza nello sviluppo e nell’accettazione, come controllo preventivo a supporto di riservatezza, integrità e disponibilità, con capacità operative nella sicurezza delle applicazioni, assurance della sicurezza delle informazioni e sicurezza di sistemi e reti. Per le risultanze TLPT riconducibili a una debolezza di progettazione applicativa, comportamento API non sicuro, flusso di autenticazione debole o validazione inadeguata, questo è il percorso di controllo verso la governance dello sviluppo sicuro.

Anche il controllo 5.35, Riesame indipendente della sicurezza delle informazioni, è importante. Supporta challenge indipendente, assurance di governance e miglioramento correttivo. I team interni possono coordinare i test, ma evidenze pronte per l’audit richiedono riesame, escalation e supervisione oltre le persone che hanno costruito o gestito i sistemi testati.

Proteggere il sistema mentre lo si testa

Un presupposto pericoloso nei test di resilienza è che testare sia automaticamente positivo. In realtà, i test intrusivi possono causare indisponibilità, esporre dati sensibili, inquinare i log, attivare difese automatizzate, interrompere sessioni dei clienti o indurre i fornitori ad attivare procedure di emergenza.

La Politica di security testing e red teaming Politica di security testing e red teaming di Clarysec fornisce alle organizzazioni un modello di governance per l’esecuzione sicura. La Clause 6.1 stabilisce:

Tipi di test: il programma di test di sicurezza deve includere, come minimo: (a) scansioni di vulnerabilità, consistenti in scansioni automatizzate settimanali o mensili di reti e applicazioni per identificare vulnerabilità note; (b) penetration testing, consistente in test manuali approfonditi di specifici sistemi o applicazioni da parte di tester qualificati per identificare debolezze complesse; e (c) esercitazioni red team, consistenti in simulazioni basate su scenari di attacchi reali, inclusa l’ingegneria sociale e altre tattiche, per testare nel complesso le capacità di rilevazione e risposta dell’organizzazione.

Per TLPT, l’elemento red teaming è evidente, ma il valore in audit deriva dalla progettazione del programma. Scansioni di vulnerabilità, penetration testing, esercitazioni red team, esercitazioni di resilienza e retest dovrebbero formare un ciclo, non una raccolta di test scollegati.

La Clause 6.2 della stessa politica affronta l’esecuzione sicura:

Ambito e regole di ingaggio: per ciascun test o esercitazione, lo STC deve definire l’ambito, inclusi sistemi e intervalli IP in ambito, metodi di test consentiti, obiettivi, tempistiche e durata. Le regole di ingaggio devono essere documentate. Ad esempio, i sistemi operativamente sensibili possono essere designati come solo monitoraggio per evitare interruzioni, e qualsiasi test in produzione deve includere procedure di rollback e arresto. Devono essere stabilite misure di sicurezza, quali finestre temporali definite e canali di comunicazione, per prevenire indisponibilità non intenzionali del servizio.

Questo si mappa direttamente sul Zenith Blueprint, fase Controls in Action, Step 21, che si concentra sul controllo 8.34 dell’Annex A di ISO 27001, Protezione dei sistemi informativi durante i test di audit. Il Zenith Blueprint avverte che audit, penetration test, riesami forensi e valutazioni operative possono comportare accessi elevati, strumenti intrusivi o modifiche temporanee al comportamento dei sistemi. Sottolinea autorizzazione, ambito, finestre temporali, approvazione del proprietario del sistema, rollback, monitoraggio e gestione sicura dei dati di test.

Il pacchetto di evidenze pronto per l’audit dovrebbe includere:

• Mandato e obiettivi TLPT
• Sintesi delle informazioni sulle minacce e razionale dello scenario
• Funzioni critiche o importanti in ambito
• Sistemi, intervalli IP, identità, fornitori e ambienti in ambito
• Esclusioni e sistemi in solo monitoraggio
• Regole di ingaggio
• Valutazione del rischio dei test in produzione
• Procedure di rollback e arresto
• Modello di notifica al SOC, incluso ciò che viene comunicato e trattenuto
• Approvazioni legali, privacy e dei fornitori
• Evidenze di creazione e revoca degli account di test
• Posizione di archiviazione sicura per artefatti di test e log

Un DORA TLPT che non possa dimostrare autorizzazione sicura e controllo dell’attività di test può rivelare lacune di resilienza, ma crea anche lacune di governance.

Trasformare l’output TLPT in trattamento del rischio

Il fallimento post-test più comune è il problema del rapporto red team lasciato sullo scaffale. Un rapporto di alta qualità viene consegnato, distribuito, discusso e poi perde progressivamente slancio. Le risultanze restano aperte. I controlli compensativi non sono documentati. I rischi accettati sono informali. Il retest non avviene mai.

La Politica di security testing e red teaming rende questo inaccettabile. La Clause 6.6 stabilisce:

Remediation delle risultanze: tutte le vulnerabilità o debolezze identificate devono essere documentate in un rapporto delle risultanze con classificazione di gravità. Al ricevimento del rapporto, i proprietari dei sistemi sono responsabili della predisposizione di un piano di remediation con date di scadenza; ad esempio, le risultanze critiche devono essere corrette entro 30 giorni e le risultanze ad alta gravità entro 60 giorni, in conformità alla Politica di gestione delle vulnerabilità e delle patch dell’organizzazione. Lo STC deve monitorare l’avanzamento della remediation. Devono essere eseguiti retest per confermare che le problematiche critiche siano state risolte o adeguatamente mitigate.

La Clause 6.7 aggiunge il livello di governance:

Reporting: al termine di ciascun test deve essere emesso un rapporto formale. Per il penetration testing, il rapporto deve includere una sintesi esecutiva, la metodologia e risultanze dettagliate con evidenze di supporto e raccomandazioni. Per le esercitazioni red team, il rapporto deve dettagliare gli scenari, quali percorsi di attacco hanno avuto successo, cosa è stato rilevato dal Blue Team e le lezioni apprese in merito alle lacune di rilevazione e risposta. Il CISO deve presentare i risultati sintetizzati e lo stato della remediation all’alta direzione e, ove rilevante, includerli nel rapporto annuale sulla sicurezza al Consiglio di amministrazione.

Questo è allineato alla guida ISO/IEC 27005:2022 sul trattamento del rischio: selezionare le opzioni di trattamento, determinare i controlli dall’Annex A di ISO 27001 e dai requisiti settoriali, costruire un piano di trattamento del rischio, assegnare persone responsabili, definire tempistiche, tracciare lo stato, ottenere l’approvazione del Titolare del rischio e documentare l’accettazione del rischio residuo.

Ogni risultanza TLPT significativa dovrebbe diventare una di quattro cose: un’azione di remediation, un miglioramento del controllo, un’accettazione formale del rischio o un requisito di retest.

L’obiettivo non è produrre più documenti. L’obiettivo è fare in modo che ogni documento spieghi la decisione successiva.

I test di resilienza devono provare il ripristino, non solo la rilevazione

Un TLPT riuscito può mostrare che il SOC ha rilevato traffico command-and-control, bloccato il movimento laterale ed eseguito correttamente l’escalation. È un valore importante, ma i test di resilienza DORA vanno oltre. Chiedono se l’organizzazione può continuare o ripristinare i servizi aziendali.

Il Zenith Blueprint, fase Controls in Action, Step 23, spiega il controllo 5.30, Prontezza ICT per la continuità operativa, con un linguaggio che ogni CISO dovrebbe usare con il Consiglio di amministrazione:

Dal punto di vista dell’audit, questo controllo viene spesso testato con una sola frase: Mostratemelo. Mostratemi l’ultimo risultato del test. Mostratemi la documentazione di ripristino. Mostratemi quanto tempo è servito per eseguire failover e failback. Mostratemi l’evidenza che quanto promesso può essere effettivamente erogato.

Questo standard del “Mostratemelo” è la differenza tra maturità delle politiche e resilienza operativa.

La Politica di continuità operativa e disaster recovery - SME di Clarysec Politica di continuità operativa e disaster recovery - SME, dalla sezione “Requisiti di applicazione della politica”, Clause 6.4.1, stabilisce:

L’organizzazione deve testare almeno annualmente sia le proprie capacità BCP sia le capacità DR. I test devono includere:

La sezione di applicazione della stessa politica, Clause 8.5.1, rende esplicita la responsabilità sulle evidenze:

Il GM deve garantire che quanto segue sia mantenuto e pronto per l’audit:

Per un ente finanziario regolamentato da DORA, il test annuale può essere il livello minimo, non l’ambizione. Le funzioni critiche o importanti a rischio più elevato dovrebbero essere testate con maggiore frequenza, soprattutto dopo modifiche architetturali, migrazioni cloud, incidenti rilevanti, nuovi fornitori ICT, rilasci applicativi significativi o cambiamenti nell’esposizione alle minacce.

Un solido pacchetto di evidenze per i test di resilienza dovrebbe includere:

• Business Impact Analysis che mappa la funzione critica o importante
• RTO e RPO approvati dai titolari dell’attività
• Mappa delle dipendenze del sistema, incluse identità, DNS, rete, cloud, database, monitoraggio, backup e servizi di terze parti
• Risultati dei test di backup e ripristino
• Marcature temporali di failover e failback
• Evidenze dei controlli di sicurezza operativi durante l’interruzione
• Template di comunicazione verso clienti, autorità di vigilanza e funzioni interne
• Log di partecipazione dell’Incident Commander e del team di crisi
• Lezioni apprese e azioni di miglioramento
• Evidenze di retest per precedenti lacune di ripristino

È qui che entra in gioco anche GDPR. GDPR Articles 2 and 3 portano nell’ambito la maggior parte dei trattamenti SaaS e fintech di dati personali dell’UE. Article 4 definisce dati personali, trattamento, titolare del trattamento, responsabile del trattamento e violazione dei dati personali. Article 5 richiede integrità, riservatezza e accountability, il che significa che l’organizzazione deve essere in grado di dimostrare la conformità. Se TLPT o i test di ripristino utilizzano dati personali di produzione, copiano log contenenti identificativi o convalidano la risposta a una violazione, le misure di tutela della privacy devono essere documentate.

Le evidenze dei fornitori sono il punto cieco DORA che gli auditor non ignoreranno

I moderni servizi finanziari sono assemblati da piattaforme cloud, applicazioni SaaS, fornitori di sicurezza gestita, processori di pagamento, piattaforme dati, provider di identità, strumenti di osservabilità, team di sviluppo esternalizzati e fornitori di backup.

DORA Article 28 richiede agli enti finanziari di gestire il rischio ICT di terze parti come parte del quadro di gestione del rischio ICT e di rimanere pienamente responsabili anche quando i servizi ICT sono esternalizzati. Article 30 richiede contratti scritti per i servizi ICT con descrizioni dei servizi, condizioni di subappalto, luoghi di trattamento, protezione dei dati, accesso e ripristino, livelli di servizio, assistenza sugli incidenti, cooperazione con le autorità, diritti di risoluzione, condizioni più robuste per le funzioni critiche o importanti, diritto di audit, misure di sicurezza, partecipazione al TLPT ove rilevante e accordi di uscita.

Ciò significa che uno scenario TLPT non può fermarsi al firewall dell’organizzazione se la funzione critica dipende da un fornitore.

La Politica di sicurezza delle terze parti e dei fornitori - SME di Clarysec Politica di sicurezza delle terze parti e dei fornitori - SME, dalla sezione “Requisiti di applicazione della politica”, Clause 6.3.1, stabilisce:

I fornitori critici o ad alto rischio devono essere riesaminati almeno annualmente. Il riesame deve verificare:

La Politica di security testing e red teaming aggiunge un requisito specifico sui fornitori per i test nella Clause 6.9:

Coordinamento dei test con terze parti: quando un fornitore critico o prestatore di servizi rientra nell’ambito della sicurezza complessiva dell’organizzazione, in conformità alla Politica di sicurezza delle terze parti e dei fornitori, l’organizzazione deve, ove possibile, ottenere assurance sulle loro pratiche di test di sicurezza o coordinare test congiunti. Ad esempio, quando viene utilizzato un fornitore di servizi cloud (CSP), l’organizzazione può fare affidamento sui suoi rapporti di penetration testing o includerlo in scenari red team collaborativi, subordinatamente alle disposizioni contrattuali.

Per evidenze DORA pronte per l’audit, l’assurance sui fornitori dovrebbe essere collegata allo stesso scenario di rischio del TLPT. Se il provider di identità è essenziale per il ripristino dei pagamenti, il pacchetto di evidenze dovrebbe includere due diligence sui fornitori, requisiti contrattuali di sicurezza, condizioni di supporto agli incidenti, coordinamento dei test, rapporti di assurance, evidenze sui livelli di servizio, strategia di uscita e vincoli sui test.

NIS2 Article 21 è rilevante anche per fornitori SaaS, cloud, servizi gestiti, sicurezza gestita, data center, CDN, servizi fiduciari, DNS, TLD, marketplace online, motori di ricerca e social network. Richiede un approccio all-hazards che copra analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, valutazione dell’efficacia, formazione, crittografia, controllo degli accessi, gestione degli asset, MFA e comunicazioni sicure.

Il risultato pratico è semplice: gli enti finanziari dovrebbero costruire un unico modello di evidenze che soddisfi prima DORA, quindi creare riferimenti incrociati con le aspettative NIS2 dove sono coinvolti fornitori, entità di gruppo o servizi digitali non finanziari.

Un registro pratico delle evidenze Clarysec per TLPT

Si assuma il seguente scenario:

“Un attore della minaccia compromette un account amministratore presso una piattaforma di supporto SaaS, si sposta nell’ambiente operativo dei pagamenti, modifica la configurazione e interrompe il processamento delle transazioni.”

Creare un registro delle evidenze con una riga per ciascun oggetto di evidenza. Non attendere la fine del test. Alimentarlo durante pianificazione, esecuzione, remediation e chiusura.

Usare quindi lo Step 13 del Zenith Blueprint per aggiungere tracciabilità nel Registro dei rischi e nella Dichiarazione di Applicabilità. Ogni elemento di evidenza dovrebbe collegarsi a uno scenario di rischio, a un Titolare del rischio, a un controllo selezionato, a un piano di trattamento e a una decisione sul rischio residuo.

Se una risultanza riguarda una debolezza software, citare i controlli di sviluppo sicuro e test. La Politica di sviluppo sicuro - SME di Clarysec Politica di sviluppo sicuro - SME, dalla sezione “Requisiti di applicazione della politica”, Clause 6.5.2, richiede:

I test devono essere documentati con:

Se una risultanza produce materiale forense, preservare la catena di custodia. La Politica per la raccolta delle evidenze e l’analisi forense - SME di Clarysec Politica per la raccolta delle evidenze e l’analisi forense - SME, dalla sezione “Requisiti di governance”, Clause 5.2.1, stabilisce:

Ogni elemento di evidenza digitale deve essere registrato con:

Questo è il punto che molti team non colgono. Le evidenze non sono solo i rapporti finali. Sono la registrazione controllata di chi ha approvato, chi ha eseguito, cosa è accaduto, cosa è stato rilevato, cosa è stato ripristinato, cosa è stato modificato, cosa resta esposto e chi ha accettato tale esposizione.

Come gli auditor esaminano le stesse evidenze TLPT

Le evidenze DORA TLPT saranno lette in modo diverso a seconda del background dell’auditor. Clarysec progetta pacchetti di evidenze affinché ciascuna prospettiva trovi ciò di cui ha bisogno senza costringere i team a duplicare il lavoro.

COBIT 2019 compare nel riferimento di conformità trasversale del Zenith Blueprint per l’esecuzione sicura di audit e test, inclusi DSS05.03 e MEA03.04. La rilevanza non è che COBIT sostituisca DORA o ISO 27001, ma che i professionisti dell’assurance di matrice ISACA cercheranno esecuzione controllata, monitoraggio, valutazione ed evidenze di conformità.

La narrazione per il Consiglio di amministrazione: cosa deve approvare la direzione

Il reporting al Consiglio di amministrazione dovrebbe evitare il teatro tecnico. Il Consiglio non ha bisogno di payload di exploit. Ha bisogno di evidenze utili alle decisioni:

• Quale funzione critica o importante è stata testata?
• Quale scenario di minaccia è stato simulato e perché?
• La rilevazione ha funzionato?
• L’escalation della risposta ha funzionato?
• Il ripristino ha rispettato RTO e RPO?
• Quali fornitori sono stati coinvolti o hanno posto vincoli?
• Quali debolezze significative restano?
• Quali sono costo, titolare e tempistica della remediation?
• Quali rischi residui richiedono accettazione formale?
• Cosa sarà sottoposto a retest?

È qui che ISO 27001 Clause 5 diventa importante. L’alta direzione deve garantire che la politica e gli obiettivi per la sicurezza delle informazioni siano stabiliti, allineati con l’indirizzo strategico, integrati nei processi aziendali, dotati di risorse, comunicati e migliorati continuamente. Ruoli e responsabilità devono essere assegnati. Gli obiettivi devono essere misurabili ove praticabile e tenere conto dei requisiti applicabili e dei risultati del trattamento del rischio.

Se il TLPT identifica che il tempo di ripristino è di sei ore rispetto a una tolleranza aziendale di quattro ore, non si tratta semplicemente di un elemento nel backlog dell’infrastruttura. È una decisione della direzione che coinvolge propensione al rischio, budget, impegni verso i clienti, esposizione regolamentare, contratti, architettura e capacità operativa.

Errori comuni nelle evidenze dei test di resilienza DORA

I riesami Clarysec rilevano spesso le stesse lacune evidenziali negli enti finanziari e nei fornitori di servizi ICT che si preparano a DORA.

Primo, l’ambito del TLPT non si mappa su funzioni critiche o importanti. Il test può essere tecnicamente impressionante, ma non dimostra la resilienza del processo aziendale a cui le autorità di vigilanza prestano attenzione.

Secondo, le dipendenze dai fornitori sono riconosciute ma non supportate da evidenze. I team affermano che il cloud provider, il SOC gestito o la piattaforma SaaS sono in ambito, ma mancano contratti, diritto di audit, autorizzazioni ai test, condizioni di supporto agli incidenti e piani di uscita.

Terzo, i test creano evidenze ma non trattamento. Le risultanze restano in un rapporto red team invece di essere convertite in aggiornamenti del Registro dei rischi, modifiche ai controlli, titolari, date, retest e decisioni sul rischio residuo.

Quarto, il ripristino viene presunto anziché dimostrato. Esistono politiche di backup, ma nessuno può mostrare marcature temporali di failover, controlli di integrità del ripristino, validazione degli accessi o conferma da parte del titolare dell’attività.

Quinto, le evidenze privacy e forensi non sono controllate. Log e screenshot contengono dati personali, gli artefatti di test sono archiviati in unità condivise, gli account temporanei restano attivi e la catena di custodia delle evidenze è incompleta.

Sesto, il reporting alla direzione è troppo tecnico. L’alta direzione non riesce a capire se la resilienza sia migliorata, se il rischio rientri nella propensione al rischio o quali decisioni di investimento siano necessarie.

Ciascuna di queste lacune può essere risolta trattando DORA TLPT come un flusso di lavoro strutturato di evidenze ISO 27001.

L’approccio integrato di Clarysec alla resilienza pronta per l’audit

L’approccio di Clarysec combina tre livelli.

Il primo livello è la roadmap di implementazione in 30 passi Zenith Blueprint. Per questo tema, lo Step 13 costruisce tracciabilità del trattamento del rischio e della SoA, lo Step 21 protegge i sistemi durante i test di audit e lo Step 23 convalida la prontezza ICT per la continuità operativa. Questi passaggi trasformano TLPT da evento tecnico a ciclo di governance documentato.

Il secondo livello è la libreria di politiche Clarysec. La Politica di security testing e red teaming definisce tipi di test, ambito, regole di ingaggio, remediation, reporting e coordinamento con i fornitori. La Politica di continuità operativa e disaster recovery - SME stabilisce le aspettative per test annuali di BCP e DR ed evidenze di continuità pronte per l’audit. La Politica di sicurezza delle terze parti e dei fornitori - SME supporta l’assurance sui fornitori. La Politica di sviluppo sicuro - SME garantisce che i test di sicurezza siano documentati. La Politica per la raccolta delle evidenze e l’analisi forense - SME supporta la registrazione delle evidenze e la disciplina della catena di custodia.

Il terzo livello è Zenith Controls, la guida di conformità trasversale di Clarysec. Aiuta a mappare i controlli ISO/IEC 27002:2022 su attributi, domini, capacità operative e aspettative cross-framework. Per DORA TLPT, lo schema più importante non è un singolo controllo. È la relazione tra test, continuità, gestione degli incidenti, gestione dei fornitori, logging, monitoraggio, sviluppo sicuro, riesame indipendente e governance.

Quando questi livelli funzionano insieme, il problema del lunedì mattina del CISO cambia. Invece di tre domande scollegate da Consiglio di amministrazione, autorità di vigilanza e Audit interno, l’organizzazione dispone di un’unica narrazione evidenziale:

“Abbiamo identificato la funzione critica. Abbiamo valutato il rischio ICT. Abbiamo selezionato e giustificato i controlli. Abbiamo autorizzato ed eseguito in sicurezza il TLPT. Abbiamo rilevato, risposto e ripristinato. Abbiamo coinvolto i fornitori ove richiesto. Abbiamo documentato le evidenze. Abbiamo corretto le risultanze. Abbiamo effettuato il retest. La direzione ha riesaminato e accettato il rischio residuo.”

Questa è resilienza pronta per l’audit.

Prossimi passi

Se il tuo programma DORA TLPT è ancora organizzato attorno ai rapporti anziché alle catene di evidenze, inizia con un walkthrough delle evidenze Clarysec.

Usa Zenith Blueprint Zenith Blueprint Step 13 per collegare gli scenari TLPT a rischi, controlli e Dichiarazione di Applicabilità. Usa lo Step 21 per verificare autorizzazione sicura, regole di ingaggio, rollback, monitoraggio e cleanup. Usa lo Step 23 per dimostrare la prontezza ICT per la continuità operativa con evidenze di ripristino.

Allinea poi i tuoi documenti operativi con la Politica di security testing e red teaming di Clarysec Politica di security testing e red teaming, la Politica di continuità operativa e disaster recovery - SME Politica di continuità operativa e disaster recovery - SME, la Politica di sicurezza delle terze parti e dei fornitori - SME Politica di sicurezza delle terze parti e dei fornitori - SME, la Politica di sviluppo sicuro - SME Politica di sviluppo sicuro - SME e la Politica per la raccolta delle evidenze e l’analisi forense - SME Politica per la raccolta delle evidenze e l’analisi forense - SME.

Infine, usa Zenith Controls Zenith Controls per creare una mappatura incrociata delle tue evidenze DORA TLPT sui controlli ISO 27001, NIS2, GDPR, COBIT 2019 e sulle aspettative degli auditor.

Se vuoi che il tuo prossimo test di resilienza produca più di semplici risultanze, usa Clarysec per trasformarlo in una catena di evidenze sostenibile. Scarica i toolkit, pianifica una valutazione della preparazione delle evidenze o richiedi un walkthrough di come Clarysec mappa DORA TLPT sui controlli ISO 27001:2022 dalla pianificazione all’approvazione del Consiglio di amministrazione.