Un addetto del reparto IT riceve una telefonata da un manager che si presenta come un membro del board. Conosce il suo nome, il ruolo e il contesto lavorativo, e chiede di approvare una richiesta di autenticazione per risolvere un problema urgente di accesso a un sistema aziendale. In una situazione di questo tipo, un dipendente saprebbe distinguere un collega da un attaccante? Come anche recenti, ed eclatanti, casi in Italia hanno dimostrato, la risposta è no.
Il social engineering si basa infatti da tempo sulla manipolazione delle persone più che sullo sfruttamento diretto della tecnologia, ma quello che gioca sempre di più a favore dei cyber criminali è la capacità di rendere questi attacchi sempre più convincenti. Da una parte c’è l’AI che consente loro di creare messaggi e impersonificazioni molto credibili, mentre dall’altra, le informazioni disponibili online o ottenute attraverso dati compromessi forniscono il contesto necessario per rendere una richiesta ancora più legittima.
In questo contesto, la sfida per le organizzazioni è intervenire su due fronti: da un lato, fornire agli utenti strumenti e procedure per identificare, verificare e segnalare le interazioni sospette; dall’altro, introdurre controlli sull’identità e sugli accessi che limitino le conseguenze di un’eventuale manipolazione umana riuscita, impedendo che si traduca in un accesso non autorizzato ai sistemi aziendali o processi critici.
Per le organizzazioni, la risposta deve quindi agire su due fronti: da un lato, fornire agli utenti strumenti e procedure per identificare, verificare e segnalare le interazioni sospette; dall’altro, progettare autenticazione, recupero degli account e autorizzazione in modo che una manipolazione riuscita non dia automaticamente accesso ai sistemi o ai processi critici.
Aiutare a riconoscere le interazioni sospette
Il primo aspetto da tenere presente è che la formazione sulla sicurezza deve concentrarsi sui comportamenti e sulle richieste, non soltanto sulla forma delle comunicazioni. Un messaggio con il tono usuale, una voce familiare o una richiesta coerente con determinate attività aziendali non costituiscono prove sufficienti dell’identità dell’interlocutore. Allo stesso modo, conoscere il nome del dipendente a cui ci si rivolge, alcuni suoi dati personali o alcuni dettagli organizzativi non significa essere autorizzati a impartire istruzioni.
In questa prospettiva, gli utenti devono imparare a riconoscere soprattutto le situazioni che richiedono una verifica aggiuntiva. In particolare, dovrebbero essere considerati segnali di allarme:
· richieste inattese accompagnate da un senso di urgenza
· pressioni a derogare procedure
· domande di credenziali o codici di autenticazione
· richieste di reimpostazione di un account
· notifiche MFA che non corrispondono a un’operazione avviata dall’utente
· resistenza a una verifica “esterna” dell’identità di chi pone la richiesta
Questi elementi non dimostrano da soli che sia in corso un attacco, ma indicano che la richiesta non dovrebbe essere approvata senza ulteriori verifiche.
Questi criteri devono, nello stesso tempo, essere tradotti in indicazioni operative semplici. Di fronte a una richiesta sospetta, la regola può essere riassunta in tre semplici azioni: “stop, verify, report” ovvero occorre interrompere l’interazione prima di fornire informazioni o autorizzare operazioni, verificare l’identità attraverso un canale ufficiale già conosciuto e segnalare il tentativo al team di sicurezza o al proprio referente.
La formazione deve essere periodica e accompagnata da simulazioni realistiche, procedure di segnalazione accessibili e indicazioni chiare su come comportarsi, ma è ancora più importante anche che i dipendenti sappiano che segnalare un dubbio è preferibile a prendere una decisione sotto pressione e quindi che l’organizzazione metta le persone nelle condizioni di fermarsi e controllare senza essere criticate per aver ostacolato inutilmente il lavoro.
In un contesto in cui la pressione e l’urgenza fanno parte della tecnica di attacco, la possibilità di interrompere il processo è a sua volta una pre-condizione per il controllo di sicurezza.
Limitare le conseguenze di una manipolazione riuscita
La consapevolezza degli utenti è necessaria, ma non può costituire l’unica linea di difesa. Un attacco può andare a buon fine anche se un dipendente è formato e sospettoso. Per questo, i processi di autenticazione, recupero degli account e concessione degli accessi devono essere progettati in modo da ridurre la dipendenza dal giudizio umano e rendere più difficile sfruttare un’identità legittima per entrare nei sistemi.
Un primo ambito da “mettere in sicurezza” è quello della verifica delle identità in carico ai service desk, dal momento che le procedure di reimpostazione delle password e di recupero degli account possono diventare un punto di accesso alternativo quando prevedono verifiche deboli o affidate alla valutazione del singolo operatore. In questo contesto, l’attaccante, sfruttando semplicemente informazioni facilmente reperibili o ottenibili attraverso tecniche di social engineering, può limitarsi a convincere qualcuno a superare il meccanismo di autenticazione.
Le organizzazioni dovrebbero quindi applicare verifiche dell’identità solide e coerenti prima di autorizzare operazioni sensibili, in particolare reset delle credenziali, sblocco degli account e modifica dei metodi di autenticazione. Dove possibile, i processi di recupero devono essere automatizzati attraverso soluzioni self-service basate su fattori di autenticazione robusti e regole definite dall’organizzazione. L’automazione riduce la variabilità delle verifiche manuali, purché non riproduca le stesse debolezze in un nuovo flusso.
Un secondo livello riguarda l’autenticazione. L’adozione di metodi resistenti al phishing e di soluzioni passwordless può ridurre la dipendenza da credenziali che possono essere rubate o condivise. È inoltre importante che le richieste MFA siano legate a un’operazione effettivamente avviata dall’utente e che le notifiche inattese non diventino un mezzo per ottenere approvazioni sotto pressione. Nessun singolo controllo elimina ogni rischio e l’efficacia di un attacco dipende anche da come sono gestite le eccezioni, il recupero degli account e gli altri percorsi di accesso.
Autenticazione e autorizzazione devono inoltre essere considerate separatamente. La prima serve a verificare che un soggetto controlli l’autenticatore associato a un’identità; la seconda determina quali risorse e operazioni quell’identità può utilizzare, e questo vale anche quando l’autenticazione è stata superata correttamente, cosicché il principio del minimo privilegio possa limitare ciò che un account compromesso è in grado di fare. Inoltre, controlli basati sul rischio possono introdurre verifiche aggiuntive quando una richiesta presenta elementi anomali ed il monitoraggio delle attività di accesso aiuta a individuare comportamenti che non corrispondono alle abitudini o alle autorizzazioni dell’utente, consentendo di approfondire possibili compromissioni.
Queste verifiche devono coprire l’intero ciclo di vita dell’identità, dalla sua verifica iniziale alla gestione delle credenziali, dal recupero dell’account alla concessione o revoca dei privilegi, includendo ovviamente gli accessi di terze parti e quelli privilegiati. Rafforzare soltanto il momento del login non è sufficiente se un’identità può essere compromessa attraverso un processo di assistenza meno protetto.
