Quando le organizzazioni pensano a una violazione dei dati, l’attenzione si concentra spesso sugli autori degli attacchi che sfruttano le vulnerabilità, rubano le credenziali o ottengono l’accesso a una rete. Il recente incidente che ha coinvolto Revolut mette in luce un’altra modalità: convincere un’organizzazione a divulgare informazioni tramite una richiesta apparentemente legittima.
Secondo quanto riportato, una terza parte non autorizzata ha ottenuto informazioni sui clienti inviando richieste fraudolente da un indirizzo e-mail associato al dominio di un’agenzia governativa autentica. Revolut ha dichiarato che i propri sistemi e i fondi dei clienti non sono stati compromessi. Le notifiche inviate ai clienti descritte nel rapporto indicavano che tra le informazioni esposte figuravano documenti di identità, selfie di verifica e dati finanziari.
L’incidente illustra perché la protezione dei dati e la sicurezza informatica non possono essere trattate come aspetti completamente separati. La tecnologia potrebbe funzionare esattamente come previsto; la vulnerabilità può comunque risiedere nella decisione presa da qualcuno quando una richiesta sembra legittima.
L’apparente autorevolezza non dovrebbe mai escludere la necessità di una verifica indipendente. Le richieste di informazioni sensibili meritano un’attenta analisi anche quando sembrano provenire da un’agenzia governativa, un’autorità di regolamentazione o una terza parte conosciuta, come sottolineato neicommenti del nostro CTO Richard Ford a Sync NI.
Un indirizzo e-mail credibile è solo un'informazione. Non stabilisce se la persona che lo utilizza abbia il diritto di ricevere determinati dati, se lo scopo sia autentico o se la quantità di informazioni richieste sia appropriata.
La cronaca pubblica non fornisce dettagli sufficienti per valutare ogni fase del processo interno di Revolut. Tuttavia, le organizzazioni possono utilizzare questo incidente per esaminare le proprie procedure. Se domani arrivasse una richiesta dall’aspetto ufficiale, cosa accadrebbe prima che qualcuno divulgasse le informazioni dei clienti? I controlli sarebbero chiari e coerenti, o dipenderebbero dalla decisione di un singolo individuo che percepisce che qualcosa non va?
Questa distinzione è importante perché le richieste convincenti sono progettate proprio per non destare sospetti.
Un dipendente può autenticarsi in modo sicuro, aprire un file a cui è autorizzato ad accedere e condividerlo utilizzando una piattaforma approvata, ma comunque divulgare informazioni alla persona sbagliata.
I controlli di accesso stabiliscono cosa un dipendente può fare all’interno di un sistema. Non stabiliscono necessariamente se una particolare azione aziendale sia giustificata. Ciò richiede un contesto: lo scopo della richiesta, l’autorità del destinatario e le informazioni necessarie per soddisfarla.
È qui che i team di sicurezza, protezione dei dati e operativi hanno bisogno di un processo condiviso. Insieme, dovrebbero definire chi può approvare le divulgazioni, come possono essere condivisi i dati sensibili e quali prove devono essere conservate.
Una politica che stabilisce che le informazioni dei clienti devono essere protette deve tradursi in decisioni pratiche e controlli di sistema. Altrimenti, i dipendenti sono lasciati a interpretare il requisito mentre gestiscono una casella di posta piena di richieste contrastanti.
Le procedure di verifica dovrebbero coprire sia le richieste di dati sensibili sia le transazioni finanziarie. Una fonte apparentemente credibile non dovrebbe essere sufficiente per autorizzare una divulgazione.
In pratica, una verifica indipendente implica l’utilizzo di un canale di contatto stabilito separatamente dal messaggio in arrivo. Rispondere alla stessa e-mail o chiamare un numero fornito al suo interno non costituisce una verifica indipendente.
Il processo dovrebbe rispondere a diverse domande:
Le organizzazioni dovrebbero inoltre rendere visibile l’esito di tali controlli alla persona che divulga i dati. Registrare l’approvazione, la sua portata e il destinatario verificato aiuta a impedire che una richiesta inizialmente valida si trasformi in una divulgazione inappropriata.
Gli aggressori possono sfruttare l’autorità, l’urgenza e il contesto pertinente per rendere convincenti le loro richieste. La formazione sulla consapevolezza deve aiutare i dipendenti a riconoscere tali pressioni e a metterle in discussione, in particolare quando un messaggio sembra inserirsi in un rapporto d’affari già esistente.
Un esercizio utile consiste nell’esaminare una richiesta di divulgazione realistica insieme ai team che se ne occuperebbero. Dove verrebbe inoltrata? Chi la valuterebbe? Cosa succede se il responsabile dell’approvazione abituale non è disponibile? Un dipendente può sospendere la richiesta senza essere criticato per aver ritardato una risposta?
Queste discussioni possono mettere in luce i punti deboli che una politica scritta non rileva. Offrono inoltre al personale l’opportunità di esercitarsi nel prendere decisioni prima di doverle affrontare sotto pressione.
La responsabilità non può ricadere interamente sulla persona che legge il messaggio. I manager devono sostenere il processo di verifica, mentre i flussi di lavoro dovrebbero rendere i controlli facili da completare e difficili da aggirare. Un’ulteriore approvazione per le divulgazioni sensibili, le restrizioni sulle esportazioni in blocco e il monitoraggio delle condivisioni insolite possono fornire un’ulteriore protezione.
Le informazioni personali rubate possono mantenere il proprio valore molto tempo dopo la divulgazione originale, favorendo frodi e tentativi di phishing sempre più convincenti. I dettagli ottenuti in un incidente possono conferire a un approccio successivo credibilità sufficiente per persuadere qualcuno a condividere ulteriori informazioni.
Ciò rende importante la portata di qualsiasi divulgazione. Anche una richiesta verificata non dovrebbe comportare automaticamente la condivisione di un record completo del cliente. Le organizzazioni dovrebbero stabilire con precisione ciò che è necessario e limitare la divulgazione di conseguenza.
La pianificazione degli incidenti dovrebbe inoltre coinvolgere fin dall’inizio i team di sicurezza e di protezione dei dati. I dipendenti hanno bisogno di un percorso di segnalazione chiaro, mentre chi conduce le indagini deve stabilire cosa è stato condiviso, con chi e se sia possibile impedire ulteriori divulgazioni.
Integrity360 affronta la sicurezza informatica considerando persone, processi e tecnologia, poiché la protezione delle informazioni dipende dal funzionamento congiunto di tutti e tre questi elementi.
La lezione pratica consiste nell’esaminare il momento in cui qualcuno decide di fidarsi di una richiesta. Un’autenticazione forte e sistemi sicuri rimangono essenziali, ma devono essere supportati da chiari percorsi di approvazione, verifiche proporzionate e dipendenti che si sentano liberi di porre domande.
Le organizzazioni dovrebbero essere in grado di spiegare perché le informazioni sono state divulgate, chi ne ha autorizzato la divulgazione e come è stato verificato il destinatario. Integrare questi controlli nel lavoro quotidiano unisce la protezione dei dati e la sicurezza informatica proprio dove è più importante: prima che le informazioni sensibili escano dall’organizzazione.
Rivolgetevi a Integrity360 per rafforzare il vostro approccio alla protezione dei dati sensibili e alla gestione dei rischi legati all’ingegneria sociale.