Un incidente che mette in discussione i tradizionali controlli di sicurezza

Un’e-mail proveniente da un dominio istituzionale, correttamente autenticata, può essere considerata automaticamente affidabile? Il caso che avrebbe coinvolto Revolut dimostra perché la risposta debba essere negativa. Secondo le informazioni disponibili, un soggetto non autorizzato sarebbe riuscito a utilizzare un account appartenente a un dominio governativo legittimo per inviare richieste di informazioni sui clienti. La società ha confermato che le comunicazioni provenivano da un dominio autentico e disponevano delle relative autenticazioni tecniche. Non si sarebbe quindi trattato del classico caso di spoofing, nel quale l’attaccante imita o falsifica l’indirizzo del mittente. L’ipotesi, ancora in attesa di conferme indipendenti su alcuni aspetti, è che sia stata utilizzata direttamente una casella istituzionale compromessa.  L'incidente richiama l’attenzione su un rischio spesso sottovalutato: l’autenticità tecnica del canale non dimostra necessariamente l’identità della persona che lo sta utilizzando.

La possibile esposizione dei dati personali

Secondo quanto riportato nel documento di partenza, l’incidente sarebbe stato notificato a circa 680 clienti. Tra i dati potenzialmente comunicati figurerebbero documenti d’identità, indirizzi, numeri di conto e altre informazioni personali e finanziarie. Alcune notifiche avrebbero indicato anche la possibile esposizione di selfie utilizzati per la verifica dell’identità, IBAN, estratti conto e cronologie delle transazioni. Revolut ha dichiarato che i propri sistemi informatici non sarebbero stati violati e che i fondi dei clienti non sarebbero stati coinvolti. Il punto critico, pertanto, non riguarderebbe necessariamente la sicurezza del database, ma il processo attraverso il quale una richiesta esterna viene riconosciuta come legittima e autorizzata. Secondo la ricostruzione citata, le richieste potrebbero essere proseguite per diversi mesi. Anche questa circostanza necessita tuttavia di una verifica indipendente.

Che cosa insegna il caso dal punto di vista privacy

Il Regolamento generale sulla protezione dei dati non richiede soltanto di impedire accessi abusivi ai sistemi. Il titolare del trattamento deve adottare misure tecniche e organizzative adeguate al rischio e deve essere in grado di dimostrarne l’efficacia.In particolare, risultano rilevanti:

• Articolo 5 del GDPR, con riferimento ai principi di integrità, riservatezza e responsabilizzazione;
• articolo 24, relativo alla responsabilità del titolare del trattamento;
• articolo 25, sulla protezione dei dati fin dalla progettazione e per impostazione predefinita;
• articolo 32, sulla sicurezza del trattamento;
• articoli 33 e 34, riguardanti la gestione delle violazioni di dati personali e l’eventuale comunicazione agli interessati.

Una comunicazione di dati a un soggetto non autorizzato può costituire una violazione dei dati personali anche quando non vi sia stata un’intrusione tecnica nei sistemi del titolare. La nozione di data breach comprende infatti anche la divulgazione o l’accesso non autorizzati a dati trasmessi, conservati o comunque trattati.

Una PEC autentica non basta

La PEC certifica alcuni elementi della trasmissione, ma non garantisce in modo assoluto che la casella sia utilizzata in quel momento dal suo legittimo titolare.Se un account autentico viene compromesso, il dominio, l’infrastruttura e le autenticazioni possono risultare perfettamente validi. Proprio questa apparente affidabilità può trasformare il canale istituzionale in uno strumento di social engineering particolarmente efficace. Il problema riguarda soprattutto banche, assicurazioni, fintech, operatori telefonici e, più in generale, organizzazioni abituate a ricevere richieste di informazioni da autorità e amministrazioni pubbliche. L’attaccante può cercare di sfruttare l’autorevolezza dell’interlocutore per ottenere dati, documenti o informazioni sulle procedure interne senza dover violare direttamente i sistemi dell’azienda destinataria. 

Quali controlli dovrebbero adottare le organizzazioni

Il caso offre alcune indicazioni operative applicabili a tutte le organizzazioni che gestiscono richieste esterne di dati personali.

1. Non affidarsi esclusivamente all’indirizzo del mittente

La provenienza da un dominio istituzionale deve rappresentare soltanto uno degli elementi della verifica. Le richieste più delicate devono essere sottoposte a controlli ulteriori.

2. Verificare l’identità attraverso un canale indipendente

Quando vengono richiesti dati particolarmente sensibili o finanziari, è opportuno effettuare una verifica utilizzando recapiti ufficiali già conosciuti o pubblicati sui siti istituzionali. Non si dovrebbero utilizzare esclusivamente i contatti indicati nella stessa richiesta ricevuta.

3. Applicare il principio del doppio controllo

Le richieste provenienti da autorità pubbliche dovrebbero essere approvate da almeno due soggetti competenti, per esempio dalle funzioni legale, privacy o compliance. Il controllo deve riguardare sia l’identità del richiedente sia la validità giuridica e la proporzionalità della richiesta.

4. Limitare i dati comunicati

Anche in presenza di una richiesta legittima, devono essere trasmessi soltanto i dati strettamente necessari. Occorre verificare con attenzione il periodo temporale, i soggetti interessati e le categorie di informazioni richieste.

5. Conservare una traccia completa delle verifiche

La procedura dovrebbe documentare la richiesta ricevuta, le verifiche effettuate, le autorizzazioni interne e i dati effettivamente comunicati. Questa documentazione è essenziale anche per dimostrare il rispetto del principio di accountability.

6. Prevedere indicatori di anomalia

Richieste ripetute, numerose, urgenti, riferite a soggetti noti oppure accompagnate da documenti incompleti o modificati dovrebbero determinare un livello di controllo più elevato.

7. Aggiornare la procedura di gestione dei data breach

L’organizzazione deve sapere come bloccare rapidamente ulteriori comunicazioni, ricostruire i dati trasmessi, valutare il rischio per gli interessati e stabilire se ricorrano gli obblighi previsti dagli articoli 33 e 34 del GDPR.

Dalla sicurezza dei sistemi alla sicurezza della fiducia

La principale lezione è chiara: proteggere il database non è più sufficiente.È necessario proteggere anche i processi autorizzativi e le relazioni di fiducia attraverso le quali i dati vengono legittimamente richiesti. Un’identità digitale autentica può essere utilizzata in modo illecito e un canale tecnicamente valido può trasportare una richiesta fraudolenta.Per questo motivo, le organizzazioni dovrebbero riesaminare periodicamente le procedure dedicate alle richieste delle autorità, combinando controlli tecnici, verifiche umane, segregazione dei compiti e tracciabilità delle decisioni.La domanda da porre non è più soltanto: “Da quale indirizzo arriva questa richiesta?”. La domanda corretta è:“Abbiamo verificato, con elementi indipendenti, chi sta realmente chiedendo questi dati e con quale titolo?”