Sono stati versati fiumi di inchiostro sull’incidente di sicurezza che ha coinvolto Crowdstrike e che ha causato un grande fragore mediatico.
Tuttavia, già in passato l’attacco avvenuto a dicembre 2020 a FireEye aveva sollevato preoccupazioni significative nel settore della cybersecurity, dimostrando che anche le aziende meglio attrezzate nel campo della sicurezza possono diventare bersagli di attacchi sofisticati.
Anche l’incidente che ha coinvolto la piattaforma Orion di Solarwinds nel 2020 che, seppur non strettamente di sicurezza viene utilizzata per la gestione e il monitoraggio delle reti, ha permesso di sfruttare una vulnerabilità conosciuta per inserire un malware durante il processo di aggiornamento del software per accedere alle reti infettate, spiare le comunicazioni interne e potenzialmente rubare dati sensibili. Tali prodotti accentrano una mole di informazioni e utilizzano permessi di alto livello, rendendoli particolarmente sensibili e vulnerabili per le infrastrutture critiche che li utilizzano.
Indice degli argomenti
L’urgenza del “time-to-delivery”
Secondo la root cause analysis della stessa Crowdstrike, l’incidente che ha coinvolto Crowdstrike è stato principalmente causato dalle urgenze determinate dal “time-to-delivery” degli aggiornamenti, distribuiti contemporaneamente a tutti i clienti senza roll-out, con realizzazione di test di regressione parziali e, in generale, con una incompletezza dei test.
Anche gli stessi clienti, in particolare quelli che gestiscono infrastrutture critiche, avrebbero dovuto effettuare dei test prima di applicare l’aggiornamento, ma presumibilmente non sono stati realizzati.
È come se i sistemi di sicurezza possedessero delle (in)sicurezze intrinseche: come dice il sociologo Ulrich Beck, “dobbiamo accettare l’insicurezza come un elemento della nostra libertà e [..] nello sforzo di incrementare la produttività, i rischi sono sempre stati trascurati»
Le recenti normative NIS2, CER e DORA (Digital Operational Resilience Act) sono in grado di regolamentare queste situazioni per cercare in maniera efficace di aiutare a mitigarle, se non di risolverle?
Gli aspetti “ambigui” di DORA
In particolare, DORA introduce una serie di regole e buone pratiche volte a garantire, sul piano cyber, la resilienza operativa del settore finanziario nell’Unione Europea, ma lascia aperti alcuni dubbi e incertezze sulla interpretazione.
Non analizzeremo in questo articolo gli aspetti innovativi e di grande opportunità e miglioramento offerti dalla normativa, ma cercheremo di illustrare alcuni aspetti che presentano delle ambiguità e delle difficoltà di applicazione e adattamento, in relazione alla domanda che ci siamo posti.
Sembrerebbe banale, ma innanzitutto il suo perimetro di applicazione e le modalità di identificazione. Il perimetro di applicazione di DORA fa riferimento a servizi ICT a supporto delle “Funzioni Essenziali” o “Importanti”, ovvero a quelle funzioni che, laddove sottoposte ad un’anomalia o un pregiudizio, potrebbero andare a compromettere la continuità operativa della banca o a impedirne la sua capacità di adempiere agli obblighi normativi.
Come Funzioni Essenziali o Importanti, le entità finanziarie devono considerare quelle facenti parte del proprio business e dei propri processi interni, non più solo referenziate alle funzioni esternalizzate.
L’interpretazione della normativa lascia ampia discrezionalità alla entità finanziaria su questo ambito, e l’identificazione delle FEI (Funzioni Essenziali o Importanti) comporta un processo piuttosto complesso e può variare sensibilmente da banca a banca, proprio in relazione ai relativi processi interni e alle attività core business.
Per questa ragione, il perimetro di applicazione dovrebbe essere definito e attenzionato fin dall’inizio del programma di implementazione di DORA, non commettendo l’errore di pensare che le soluzioni suggerite dalle previsioni di DORA siano prettamente tecnologiche e quindi invarianti rispetto al perimetro di applicazione.
Oltre ai processi legati alle linee principali di business definite da Basilea II, ai processi afferenti alle funzioni critiche impattate dalla normativa OCIR per la continuità operativa in caso di risoluzione delle banche, alle funzioni di controllo, anche i processi trasversali di controllo, seppur non connessi a FEI, dovrebbero essere integrati nel perimetro DORA ed essere anche oggetto di considerazioni nell’ambito dei test di resilienza digitale.
Inoltre, il perimetro di applicazione di DORA viene esteso anche agli istituti di pagamento esentati a norma della direttiva (UE) 2015/2366, ai prestatori di servizi di informazione sui conti, agli istituti di moneta elettronica, alle entità non tradizionali, come fornitori di asset legati a criptovalute e piattaforme di crowdfunding, rendendo per i gruppi finanziari internazionali anche l’identificazione del perimetro societario di applicazione non di facile determinazione.
Conformemente a tutta la normativa degli ultimi anni, come ad esempio il GDPR, DORA soggiace al principio di proporzionalità, in cui le entità finanziarie devono tenere conto delle loro dimensioni e del loro profilo di rischio complessivo, nonché della natura, della portata e della complessità dei loro servizi, delle loro attività e della loro operatività.
Ciò si traduce nella implementazione di una serie di processi risk based, tra cui uno per la raccolta delle informazioni rilevanti basato sulla attività BIA (Business Impact Analysis), che però dovrebbe essere integrata con un processo complementare di arricchimento dei dati raccolti, con una estensione sia in termini di profondità di analisi che in termini di perimetro, dato che la BIA si occupa annualmente solo di una porzione dei processi di interesse per DORA e solo di alcune tipologie di informazioni inerenti i servizi ICT.
In tal senso, DORA introduce un nuovo concetto di “sensitiveness of the data” che è dichiaratamente diverso da quello espresso dal GDPR. I più lo interpretano come un attributo determinato dalla potenziale gravità delle conseguenze di un accesso non autorizzato, o relativo alla compromissione dell’integrità o indisponibilità di tali dati, ovvero come una espressione della RID.
Come si è evoluto il concetto di RID
Il concetto di RID (Riservatezza, Integrità, Disponibilità) nel tempo si è arricchito di diversi significati ed è un concetto “dinamico”, che inizialmente definito negli anni ’70, si è evoluto nel tempo. Negli anni ’80 sono state aggiunte due dimensioni (Autenticità e non Repudio), che poi sono stati riassorbite nel concetto di Integrità, a cui si è aggiunto poi il concetto di “Correttezza nelle specifiche”, riassorbito in Integrità e Disponibilità, e poi dagli anni Duemila in avanti si è cercato di integrare la RID con i concetti di Responsabilità, Integrità delle persone, Trust e Ethicality (Dhillon and Kolkowska, Backhouse ed altri). Questo perché la definizione di RID cambia e si evolve in funzione dell’aumento della complessità nel trattamento dei dati e delle necessità organizzative.
L’applicazione pedissequa della logica RID nel processo di raccolta dei dati sui servizi ICT richiesto da DORA, potrebbe non intercettare le categoria di dati che presentassero delle “singolarità” degne di attenzione, ad esempio per macro categorie di dati che, seppur con RID eventualmente bassa, contengono informazioni che possono essere considerate rilevanti per l’organizzazione, come quelle legate al brand (immagini, loghi), oppure legate a brevetti, marchi o altre informazioni coperti da diritto d’autore, oppure informazioni con alto valore di unicità ed integrità come i Non Fungible Token.
Anche le macrocategorie di dati che contengono informazioni che riguardano temi come l’integrità delle persone, la responsabilità sociale, l’etica aziendale che, seppur con RID eventualmente bassa, sono considerate importanti per l’organizzazione (ad es. concorsi aziendali, iniziative ambientali o sociali, certificazioni aziendali, ecc.) potrebbero non essere intercettate se non venisse implementato un processo integrativo e più granulare di analisi e raccolta dei dati, come suggerito in ultima analisi da DORA.
Questo processo dovrebbe essere rivolto non solo al process owner in ambito BIA, ma anche al service manager o al fornitore o in genere a chiunque nell’organizzazione o al di fuori di essa abbia una adeguata conoscenza delle macrocategorie dei dati trattati per il suo ambito di competenza.
Cambio di ruolo: da fornitore IT a partner
Il cambiamento paradigmatico introdotto da DORA, trasforma il fornitore IT da entità esterna in un partner coinvolto in tutta la catena di gestione del rischio, con particolare riferimento alle diverse fasi di interazione, partendo dalla analisi preliminare, dalla qualifica della società, dalla qualifica del servizio fornito e l’aggiornamento e riesamina nell’Albo Fornitori, fino all’introduzione di nuove clausole contrattuali introdotte, nonché alle (nuove) modalità di test del servizio che devono essere concordate con il fornitore.
Tutto ciò comporta un effort enorme per l’organizzazione, se non venisse mutuato da un processo di risk assessment strutturato, con ruoli e responsabilità chiare e definite ed analisi dei razionali utilizzati il più automatizzabile possibile.
Perseguendo il principio di proporzionalità, ad eccezione di alcune disposizioni che rende obbligatorie (ad esempio i test di penetrazione basati su minacce o TLPT) DORA non impone specifiche misure di sicurezza, come quelle che suggeriscono di porre i sistemi critici in grado di bloccare tutta una infrastruttura in reti dedicate e separate.
Molte organizzazioni dovrebbero prendere in considerazione il fatto che, prima o poi, in un futuro non troppo lontano potrebbero cadere vittima di un attacco informatico o di un errore operativo o di un sabotaggio interno che potrebbe creare anche danni maggiori.
Queste strutture dovrebbero spostare il loro focus dalla prevenzione alla resilienza, con l’obiettivo di ripristinare i sistemi business-critical nel modo più rapido ed efficiente possibile dopo un incidente informatico.
L’approccio “vault” con air gap
Le soluzioni esistenti sul mercato che promuovono un approccio “vault” con air gap isolano l’ambiente in termini fisici e logici da sistemi esterni, tranne durante l’effettivo processo di ingestione dei dati per un breve intervallo di tempo. L’acquisizione dei dati e la gestione del processo sono automatizzate e basate su policy ed escludono l’intervento manuale, minimizzando errori o manomissioni.
Una volta replicati i dati nel cyber vault ed applicato un blocco di conservazione, viene effettuata la scansione dei dati di backup, creando osservazioni point-in-time di file e database. L’esecuzione di analisi sui dati presenti nel vault è una componente importante per mantenere l’integrità di questi dati e intervenire con un ripristino rapido dopo un attacco. Grazie all’analisi si determina se un insieme di dati è valido e utilizzabile per il ripristino o se è stato alterato o danneggiato in un qualche modo da renderlo “sospetto” e potenzialmente inutilizzabile. Un esempio di soluzione implementata da Kyndryl:
Queste soluzioni necessitano di investimenti importanti, che prima della identificazione delle infrastrutture e delle applicazioni e della definizione delle misure di sicurezza, richiedono la revisione dei requisiti e dei ruoli delle strutture organizzative e delle responsabilità da attribuire formalmente all’interno dell’entità, oltre che alla definizione dei requisiti relativi a informazioni dei dati da identificare, classificare, utilizzare e conservare. È forse questa la vera sfida lanciata da DORA.
