Laura Santeusanio
Direttore regionale per l'Europa meridionale
Dirigente internazionale con oltre 20 anni di esperienza nella crescita del business, nell'espansione dei mercati e nella trasformazione in tutta Europa. Direttore generale di comprovata esperienza, capace di scalare le operazioni, costruire team ad alte prestazioni ed eseguire la strategia per ottenere risultati misurabili.
Punti chiave:
Una recente violazione in una fintech, ampiamente riportata dai media, non ha comportato alcuna intrusione tecnica: gli aggressori hanno usato un account email governativo compromesso per richiedere dati dei clienti, e l'azienda li ha consegnati ritenendo legittima la richiesta.
Secondo quanto riportato, lo schema è proseguito per mesi prima che qualcuno se ne accorgesse, non perché una singola email sia sfuggita a un filtro, ma perché il processo di verifica stesso non aveva alcun modo di individuare un falso ben autenticato.
L'autenticazione tecnica delle email (SPF, DKIM, DMARC) conferma che un messaggio proviene da un dominio autentico. Non dice nulla sul fatto che la persona che lo ha inviato fosse autorizzata a farlo, né che la richiesta sia lecita.
Molti dei dettagli più eclatanti che ancora circolano, come l'esatto volume di dati, la cifra del riscatto e la durata della compromissione dell'account governativo, provengono dalle dichiarazioni degli stessi aggressori e non sono confermati da alcun ente ufficiale.
La soluzione non è un filtro antispam migliore, ma un passaggio di verifica documentato e obbligatorio per questa specifica categoria di richieste, che esista sulla carta e venga effettivamente seguito anche sotto pressione.
Cosa è successo davvero
La ricostruzione emersa dalle inchieste giornalistiche è lineare, ed è proprio questo a renderla inquietante. Un aggressore ha preso il controllo di un account email appartenente a un vero ufficio governativo. Da quell'account ha inviato alla fintech richieste di informazioni sui clienti, presentate come richieste delle forze dell'ordine. Le richieste provenivano da un dominio governativo autentico, quindi hanno superato i controlli tecnici che di solito segnalano i tentativi di impersonificazione, e sono state instradate attraverso il normale processo aziendale per la gestione delle richieste governative e delle forze dell'ordine.
L'azienda ha trattato le richieste come legittime e ha divulgato i dati. Successivamente ha descritto l'accaduto come una truffa esterna basata sull'impersonificazione, e non come una violazione dei propri sistemi, e questa impostazione regge a un esame approfondito: non ci sono prove pubbliche di un'intrusione nella rete, e l'azienda ha dichiarato che i fondi dei clienti e i sistemi principali non sono mai stati compromessi. Ciò che è avvenuto è una violazione dei dati personali e, secondo la definizione stessa del GDPR, lo è indipendentemente dal fatto che un solo server sia stato toccato. La divulgazione non autorizzata a un soggetto sbagliato è la violazione, senza eccezioni.
Un mittente verificato non equivale a una richiesta autorizzata
Il punto scomodo che emerge da questo episodio è uno che la maggior parte delle organizzazioni non ha ancora valutato fino in fondo: autenticazione e autorizzazione sono problemi diversi, e la maggior parte dei processi di divulgazione verifica solo il primo.
SPF, DKIM e DMARC servono a rispondere a una sola domanda: questo messaggio proviene davvero dal dominio che dichiara? Svolgono bene questo compito. Non dicono nulla sul fatto che la persona che lo ha inviato fosse autorizzata a presentare quella specifica richiesta, che la base giuridica invocata sia effettivamente applicabile, o che il volume e la natura di ciò che viene richiesto corrispondano a una richiesta legittima. Un account compromesso all'interno di un vero dominio governativo supera tutti e tre i controlli senza difficoltà. Il dominio è autentico. La persona dietro l'account, in quell'occasione, no.
Le richieste governative e delle forze dell'ordine godono di una particolare fiducia istituzionale che peggiora il problema anziché attenuarlo. Una richiesta che appare ufficiale tende a essere elaborata più in fretta e messa in discussione meno, ed è esattamente il presupposto su cui fa leva un aggressore.
L'aspetto che dovrebbe preoccupare i team di conformità più della violazione stessa
Una singola email fraudolenta che passa è una brutta giornata. Quello che sarebbe accaduto qui è diverso: lo stesso schema di richieste è proseguito, non rilevato, per un periodo prolungato. Non è la storia di una email sfuggita a un filtro. È la storia di un processo di verifica privo di qualsiasi meccanismo in grado di individuare un falso ben autenticato, anche dopo che aveva già funzionato più di una volta.
La maggior parte delle organizzazioni può indicare una policy che prevede che le richieste governative siano gestite con attenzione. Molte meno possono dimostrare che la policy includa un passaggio specifico e obbligatorio, come la conferma della richiesta tramite un canale di contatto ottenuto in modo indipendente, e non fornito nella richiesta stessa, prima che venga divulgato qualsiasi dato. Senza questo passaggio scritto e realmente applicato, "gestita con attenzione" diventa silenziosamente "elaborata come qualsiasi altra richiesta", e nessuno se ne accorge finché non è già successo più volte.
Cosa è confermato e cosa è ancora solo una dichiarazione
Scrivere in modo responsabile di un incidente ancora in corso significa essere onesti su quali dettagli siano solidi e quali no. Al momento della stesura:
Accertato con ragionevole certezza: un aggressore ha usato un account email governativo compromesso per inviare richieste fraudolente di dati dei clienti. L'azienda ha divulgato i dati in risposta, ritenendo legittime le richieste. I sistemi dell'azienda e i fondi dei clienti non sono stati violati. Le autorità stanno indagando.
Riportato dai media, non confermato ufficialmente: il numero specifico di clienti coinvolti e quale account di quale ufficio governativo sia stato compromesso.
Dichiarato solo dall'aggressore, non verificato da alcun ente ufficiale: il volume totale di dati che sarebbero stati ottenuti, la durata della presunta compromissione dell'account governativo e la richiesta di riscatto. La prassi di governance è chiara su questo punto: le dichiarazioni di un attore delle minacce su ciò che possiede sono propaganda per il tentativo di estorsione, non prove, finché qualcosa di indipendente non le conferma.
Cosa significa se la propria organizzazione riceve una richiesta governativa
Quasi tutte le organizzazioni regolamentate, dai servizi finanziari alla sanità e alle telecomunicazioni, dispongono di un processo per rispondere alle richieste di dati da parte delle autorità governative e delle forze dell'ordine, perché la legge in genere lo richiede. La domanda che questo episodio solleva non è se tale processo esista, ma se preveda un controllo reale pensato proprio per questo scenario: una richiesta che sembra del tutto legittima e potrebbe non esserlo.
Un controllo ragionevole, in questo caso, è specifico e non generico. Qualcosa di simile a: prima di divulgare dati personali in risposta a una richiesta governativa, giudiziaria o delle forze dell'ordine, verificare in modo indipendente l'identità e l'autorità del richiedente, la base giuridica della richiesta e la sua portata, utilizzando recapiti ottenuti autonomamente e non quelli forniti nella richiesta stessa. Le richieste di grandi volumi o fuori dall'ordinario richiedono un secondo controllo obbligatorio prima che qualsiasi dato venga trasmesso.
Messo per iscritto, sembra ovvio. Il motivo per cui nella pratica fallisce è che raramente si trova in un punto che il team addetto alla ricezione delle richieste vede davvero nel momento in cui serve, e raramente viene testato su una richiesta che appare perfettamente corretta.
Scopri come un passaggio di verifica come questo si inserisce nel tuo programma di conformità
Porta il tuo processo di gestione delle richieste governative o delle forze dell'ordine, per quanto informale sia oggi. Preferiamo mostrarti come strutturare il controllo piuttosto che descriverlo in astratto.
Come Formalize supporta questo aspetto
Prima che un problema tecnologico, questo è un problema di controlli, e il ruolo di Formalize è fare in modo che il controllo esista davvero in un luogo diverso da un documento di policy che nessuno apre quando è sotto pressione. In pratica, significa:
Un controllo documentato per le divulgazioni alle autorità governative e alle forze dell'ordine, collocato accanto agli altri controlli anziché in un raccoglitore di policy separato, con un responsabile designato.
Passaggi di verifica integrati nel flusso di lavoro, in modo che una richiesta venga controllata rispetto a criteri definiti prima della divulgazione, e non dopo.
Una traccia di chi ha approvato una divulgazione e perché, così che, se una richiesta viene messa in discussione in seguito, la motivazione sia già disponibile e non debba essere ricostruita a memoria.
Lo stesso controllo riutilizzato tra più framework, dal momento che questo tipo di rischio di divulgazione riguarda il GDPR e spesso si sovrappone anche agli obblighi previsti da framework come DORA o ISO 27001.
Nulla di tutto ciò sostituisce il giudizio. Fa in modo che il giudizio venga applicato in modo coerente, ogni volta, compresa l'unica volta in cui conta di più.