SPONSORED STORY

Regolamento DORA: come adeguarsi ai nuovi obblighi per la gestione del rischio ICT

Il Regolamento europeo richiede che tutte le entità finanziarie, inclusi i loro fornitori, rispettino precisi criteri di resilienza operativa digitale. Horizon Security spiega come ottenere la conformità e chiarisce la correlazione con il framework TIBER per l’esecuzione dei Threat-Led Penetration Test

Pubblicato il 24 Mag 2023

Arianna Leonardi

Immagine di JLStock da Shutterstock

Con le minacce informatiche che crescono in numero e sofisticazione, le aziende, soprattutto se operanti in settori strategici come il Finance, devono offrire ulteriori garanzie di continuità operativa.

In quest’ottica, il Digital Operational Resilience Act (DORA) sancisce nuove regole per le entità finanziarie, definendo un approccio end-to-end alla gestione del rischio ICT.

Marco Sotterra, Head of Information Security Business Unit di Horizon Security, spiega come ottenere la conformità, mentre il collega Ruggero Strabla, Head of Offensive Security Business Unit di Horizon Security descrive il framework TIBER, uno strumento che potrebbe supportare le attività di testing prescritte dal DORA.

Le principali caratteristiche del DORA

«Il DORA – esordisce Sotterra – è un regolamento attuativo europeo, con effetto dal 16 gennaio 2023, che impatta il settore finanziario non soltanto circoscritto a Banche e Assicurazioni, ma allargato ad attori collaterali come, ad esempio, i fornitori che si occupano di servizi critici ICT o di criptovaluta. L’obiettivo è armonizzare la regolamentazione in materia di security e resilienza, per l’intero comparto, all’interno dell’Unione».

Il Regolamento sarà vincolante a partire dal 17 gennaio 2025 (decorsi 24 mesi dalla sua pubblicazione nella Gazzetta Ufficiale dell’Unione Europea). «Entro due anni – prosegue Sotterra – le entità finanziarie e relativi fornitori dovranno adeguarsi ai requisiti tecnici. Lo scopo è rendere le aziende del settore resilienti, ovvero capaci di sopportare momenti di crisi prolungata per i servizi di business su base digitale».

La Regulation, come dettaglia Sotterra, si basa su cinque pillar fondamentali: l’ICT Risk Management; la gestione degli incidenti informatici soprattutto in termini di reporting e notifica; l’esecuzione di test di resilienza; la gestione del rischio di terza parte; l’information sharing per condividere le conoscenze sui rischi cyber in tutto il perimetro UE.

«Tra gli aspetti innovativi del Regolamento – precisa Sotterra -, bisogna citare la varietà delle entità coinvolte, che appartengono almeno a una ventina di tipologie differenti. Inoltre, il DORA conferisce ampi poteri alle ESA ovvero le Autorità Europee di Supervisione, che possono richiedere informazioni molto dettagliate e verticali, effettuare visite ispettive e addirittura comminare sanzioni. Un altro nodo distintivo e cruciale del DORA è il monitoraggio del rischio di terze parti, ovvero sui fornitori critici di servizi tecnologici».

Il regolamento DORA punto per punto

A fronte di tante novità, come si devono direzionare gli operatori per ottenere la compliance?

Allo scopo di fornire una risposta esaustiva, Sotterra passa in rassegna i punti salienti del DORA.

Gestione del rischio ICT

«Il primo pillar – spiega – invita le aziende a strutturare l’ICT Risk Management, correlando anche le informazioni relative alle interdipendenze tra fornitori. Le entità finanziarie, pertanto, sono chiamate a definire strategie, documenti procedurali e strumenti per gestire il rischio in maniera misurabile, scalabile e ripetibile. Inoltre, devono implementare un sistema di gestione per la sicurezza delle informazioni e procedere al riesame continuo degli scenari di rischio, che cambiano in funzione degli eventi e delle tecnologie. Infine, è necessario sviluppare piani per la resilienza».

Incident management

Il secondo pilastro relativo all’incident management insiste sul monitoraggio degli eventi e spinge ad adottare un approccio preventivo alla sicurezza. «Subire un attacco – afferma Sotterra – ormai non è un’eventualità, ma una certezza, pertanto le aziende devono essere adeguatamente preparate». Per adempiere correttamente al secondo pillar è importante anche avere capacità di classificazione, ovvero stabilire delle soglie di impatto e tolleranza, anche in base alla tipologia e all’entità di eventuali ripercussioni. Inoltre, bisogna sviluppare un sistema di notifica capillare, più efficiente rispetto al passato.

Test di resilienza

«Il terzo pillar – afferma Sotterra – incentrato sulle attività di test, rappresenta il cuore del Regolamento. Per verificare l’efficacia dell’impianto tecnologico e organizzativo in caso di incidente, bisogna effettuare delle prove».

Come nota Sotterra, il DORA contribuisce ulteriormente ad armonizzare il quadro della cybersecurity: se prima i test di resilienza potevano essere eseguiti con qualsiasi metodologia, il nuovo Regolamento fornisce indicazioni precise in merito, unificando il sistema di testing.

Secondo le prescrizioni, ci sono due tipologie di test: i Basic Test vanno condotti annualmente e coinvolgono tutte le organizzazioni assoggettate, mentre gli Advanced Test vengono richiesti su base triennale e riguardano solo gli attori più rilevanti e critici.

Per la conduzione dei test avanzati, Il DORA fa riferimento alla metodologia di Threat-Led Penetration Testing, anche nota come Red Teaming Testing, per cui l’azienda target viene bersagliata con azioni malevole controllate, simulando il comportamento reale di un hacker e cercando di sfruttare tutti gli eventuali percorsi di attacco. Per capire la differenza, i classici penetration test invece sottopongono le singole risorse IT a un elenco di prove per scovare quante più vulnerabilità possibile.

«Il terzo pillar – asserisce Sotterra – spinge le aziende ad abbandonare la logica della sicurezza incentrata sul singolo asset per ragionare in ottica di rischio complessivo per l’azienda. Ormai infatti bisognerebbe dare per scontato che, secondo l’applicazione dei principi di continuità, qualsiasi risorsa IT critica è comunque ridondata su più siti e il rischio va considerato in una più ampia prospettiva di business».

Risk management di terze parti

«Con il quarto pillar – suggerisce Sotterra – la gestione del rischio viene allargata alle terze parti, pertanto la normativa assume un impatto trasversale sul settore. Le aziende sono pertanto obbligate a rivedere la propria strategia di scelta e gestione dei fornitori, adeguandola nel tempo, in funzione degli scenari di rischio estesi a tutta la catena. Sarà necessario effettuare un’attività di due diligence, ovvero un processo di indagine preliminare sui fornitori per verificare quanto siano robusti e conformi a specifiche norme di sicurezza. I contratti dovranno contemplare clausole specifiche con livelli di servizio definiti, perché la continuità aziendale dipende anche dalla capacità dei subfornitori. Importante è sottolineare che le Autorità di Supervisione potranno indagare anche sulle terze parti».

Information sharing

Il quinto pillar, infine, impone l’obbligo di information sharing, una caratteristica che già era propria dei CERT, ovvero i Computer Emergency Response Team, governativi o di altra entità. «La creazione di una rete di scambio informativo – commenta Sotterra – è assolutamente strategica in un’ottica di prevenzione, poiché permette alle aziende di agire più rapidamente contro una minaccia nota. La condivisione deve avvenire chiaramente nel rispetto delle informazioni confidenziali di ciascuna organizzazione, garantendo tuttavia la formazione di una comunità trusted all’interno del Financial Services, che riunisce solo operatori riconosciuti dal punto di vista della sicurezza e della continuità».

I principali impatti del Regolamento

Il Regolamento così formulato ha importanti ripercussioni su diversi fronti.

«Come primo impatto importante – sostiene Sotterra -, la concezione della sicurezza non è più orientata a singolo asset informativo, ma viene allargata al rischio legato al business. Si abbandona quindi la tradizionale logica a silos, per cui l’azienda viene considerata per compartimenti stagni e la sicurezza è pensata relativamente a una specifica funzione. Si passa invece alla convergenza cross function, quindi la sicurezza diventa un fattore che riguarda tutte le divisioni trasversalmente, un obiettivo da perseguire congiuntamente».

Il DORA impatta anche su altri aspetti, come la formazione dei dipendenti. Come spiega Sotterra, con riferimento al cosiddetto Human Firewall, avanza il concetto che alcune figure, in virtù del ruolo aziendale, diventano sensibili per la sicurezza delle informazioni e possono contribuire a ridurre il rischio di incidente. Pertanto, si rende necessaria un’adeguata sensibilizzazione e formazione delle persone perché adottino dei comportamenti corretti.

«Un’altra novità portata dal Regolamento – prosegue Sotterra – riguarda il passaggio dal concetto di resilienza a breve termine, basata sulle metriche RTO e RPO, alla logica di resilienza a medio-lungo termine, che non considera soltanto il tempo e il punto di ripristino per un determinato processo, ma valuta la capacità complessiva dell’azienda di resistere a una situazione di crisi prolungata».

L’ultimo elemento innovativo del DORA concerne l’approccio alla sicurezza, non più solamente reattivo ma anche preventivo, con un impulso a irrobustire le funzioni di detection.

Il supporto di Horizon Security alla compliance

«Diversi clienti di Horizon Security – dichiara Sotterra – si stanno muovendo con il nostro supporto per ottenere la conformità al DORA. Molte aziende arrivano da un periodo di stress dovuto allo sforzo di adeguarsi alle precedenti regolamentazioni e oggi sono chiamate nuovamente a reindirizzare le strategie di compliance. Il nostro contributo consiste quindi nell’aiutare le imprese a definire correttamente i modelli organizzativi e funzionali per governare tutti i processi che soggiacciono alla continuità operativa. Chiaramente la revisione viene tarata sulle specificità dell’azienda, come le dimensioni, il settore o il contesto interno, così da implementare una effettiva capacità di cyber resiliency».

Tipicamente, come descrive Sotterra, gli specialisti di Horizon Security vengono ingaggiati per condurre le analisi sui processi business critical, definendo le soglie di tolleranza e valutando i tempi di sopportazione della crisi, così da sviluppare piani di ripristino adeguati.

«Tra le attività più importanti – precisa Sotterra – rientrano le simulazioni e le esercitazioni: riproduciamo insomma uno scenario di crisi o attacco per mettere alla prova la business continuity dell’azienda a fronte di eventi impattanti. Da qui interveniamo per migliorare la compliance aziendale, dal punto di vista organizzativo e tecnico. Operiamo in sinergia con più specialisti multidisciplinari per lavorare su più fronti».

Attualmente, in attesa che vengano pubblicate le regolamentazioni tecniche del DORA e sfruttando il biennio che separa dall’obbligo di adempimento, Horizon Security sta supportando i clienti nella revisione dei processi organizzativi perché siano predisposti alla compliance. «Ad esempio – puntualizza Sotterra -, si preoccupa che, durante la gestione di un incidente, le attività di classificazione, notifica e così via vengano implementate correttamente. Inoltre, si occupa di effettuare i test di resilienza e le attività di risk management rispetto alle terze parti. In alcuni casi, siamo noi a svolgere direttamente per conto dei clienti l’assessment sui fornitori critici. Infine, spesso siamo chiamati a disegnare i modelli di information sharing, implementando se necessario le relative soluzioni tecniche e predisponendo la relativa documentazione».

TIBER, cos’è e perché è connesso al DORA

Strettamente correlato al Regolamento DORA, il TIBER (Threat Intelligence Based Ethical Red-Teaming) è un framework che definisce in dettaglio le metodologie per testare la resilienza del settore finanziario agli attacchi informatici. «Sostanzialmente – interviene Strabla – specifica le modalità operative, gli stakeholder da coinvolgere e come definire gli obiettivi da raggiungere, sulla base di dati di threat intelligence, quando si effettua un’attività di Red Teaming».

Il Red Teaming, come precisa Strabla, è la simulazione di un attacco informatico diretto verso un’organizzazione, finalizzata a capire quali violazioni riuscirebbe a compiere un attaccante e quali target potrebbe conquistare a fronte delle misure difensive attualmente implementate.

«Il TIBER – prosegue Strabla – è stato redatto prima a livello europeo (TIBER-EU) per essere calato successivamente in ambito nazionale. In Italia (TIBER-IT), è stato recepito lo scorso anno, con rappresentanti di Banca d’Italia, Ivass (Istituto per la vigilanza sulle assicurazioni) e Consob (Commissione nazionale per le società e la Borsa) che rappresentano il gruppo di coordinamento (Steering Committee) e detengono l’ownership di gestione del documento. Attualmente non esiste l’obbligo per le aziende del settore finanziario di effettuare attività di Red Teaming. Il DORA, tuttavia, contiene delle indicazioni vincolanti per la conduzione dei test e in particolare fa riferimento al Threat-Led Penetration Testing, che sostanzialmente significa sviluppare il Red Teaming».

Come effettuare il Red Teaming Testing

Ma come si sviluppa in termini operativi un’attività di Red Teaming?

Strabla chiarisce innanzitutto i principali attori che intervengono nel processo di testing definito dal TIBER:

  • gli stakeholder che compongono lo Steering Committee e definiscono la tipologia di minacce attualmente più ricorrenti e rilevanti per il mercato Finance;
  • il White Team ovvero il gruppo di specialisti scelti dall’entità finanziaria sottoposta a test, con il compito di coordinare le attività e scegliere i fornitori di Threat Intelligence e Red Teaming;
  • il Blue Team cioè tutto il personale dell’entità finanziaria, incluse le terze parti e specialmente coloro che gestiscono la difesa dei sistemi;
  • i provider che offrono servizi di Threat Intelligence o Red Teaming e che possono essere rappresentati da un unico operatore se ha entrambe le competenze.

Il processo descritto dal TIBER si svolge quindi in tre fasi.

Durante la fase iniziale, tra le diverse attività, il fornitore di Threat Intelligence analizza il contesto aziendale dell’entità finanziaria sottoposta a test, considerando gli input sulle minacce dettati dagli stakeholder. L’obiettivo è identificare tutti i percorsi e tutte le modalità di attacco che gli hacker potrebbero effettivamente sfruttare, in relazione al caso specifico. Viene quindi definito il perimetro di applicazione del test (scoping).

Nella seconda fase, in base alle informazioni raccolte, il provider di Red Teaming effettua le attività di testing vere e proprie, con la simulazione degli attacchi.

L’ultimo step concerne il reporting: si analizza quanto emerso durante la simulazione, quindi si elencano i percorsi di attacco e le vulnerabilità che gli ipotetici hacker sono stati in grado di sfruttare. A chiusura dell’intero processo, viene stilato un Remediation Plan e si rilascia l’attestazione dell’avvenuto svolgimento del test.

«Oggi – conclude Strabla – molti clienti ci chiedono un supporto per effettuare test e migliorare le difese e i processi di sicurezza in modalità propedeutica ad attacchi informatici, al TIBER o altre certificazioni, anche in ottica di eventuali futuri obblighi di compliance. Insomma, arrivare impreparati, non conviene».

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

L
Arianna Leonardi

Articoli correlati

Articolo 1 di 4