La spaventosa verità sulla fiducia: perché essere "verificati" non significa essere al sicuro

Parliamo di qualcosa che toglie il sonno agli esperti di sicurezza. Non è l'hacker con la felpa con cappuccio che si vede nei film. Non è un sofisticato exploit zero-day. È qualcosa di molto più semplice e infinitamente più pericoloso: l'assunzione che verificare l'identità equivalga a verificare l'autenticità.

Recentemente mi sono imbattuto in questo caso studio affascinante (e leggermente terrificante) e non riesco a smettere di pensarci. Un'azienda — chiamiamola una tipica media impresa — ha affrontato non uno, non due, ma TRE distinti incidenti di sicurezza nell'arco di quattro mesi. Il punto cruciale è questo: nessuno di essi ha comportato la violazione di reti o lo sfruttamento di bug del software. Ogni singola volta, l'attaccante è semplicemente diventato qualcuno di cui l'azienda si fidava già.

È... in realtà molto inquietante se ci si pensa.

La password era perfetta. La persona no.

Il punto con la sicurezza tradizionale è questo: trattiamo l'autenticazione come un problema di serratura e chiave. Ottieni la password giusta, superi il controllo MFA e boom — sei dentro. Ma cosa succede se la serratura funziona esattamente come previsto, e la persona che la attraversa semplicemente... non è chi dice di essere?

I casi a cui mi riferisco mostravano tre diverse varianti di questo identico problema. Primo, c'è stato un CFO che ha ricevuto una chiamata dal "supporto IT" riguardo a un'attività sospetta sul suo account. L'ID del chiamante mostrava un numero interno. Il chiamante conosceva il provider MFA dell'azienda. Sapevano che il CFO era in viaggio (perché ne aveva postato sui social media, perché ovviamente lo ha fatto — lo facciamo tutti). Avevano persino informazioni provenienti da vecchie violazioni di dati che circolavano nel dark web.

Tutto ciò di cui avevano bisogno era che lui leggesse un codice di verifica. E lo ha fatto.

In venti minuti, qualcuno stava usando la sua email per richiedere pagamenti urgenti. L'unico motivo per cui i soldi non si sono spostati? Un attento specialista della contabilità ha percepito che la richiesta era "strana" e lo ha chiamato direttamente. Quel istinto umano ha salvato la situazione.

Fidarsi è tutto, ma verificare è meglio (tranne quando non lo fai)

Ciò che mi colpisce di più di questi incidenti non è la sofisticazione degli attacchi — è quanto sembrerebbero noiosi per la maggior parte dei sistemi di sicurezza. Le credenziali erano corrette. L'autenticazione era passata. Le sessioni erano valide.

Ma da qualche parte lungo il percorso, abbiamo dimenticato che la verifica non consiste solo nel spuntare delle caselle. Consiste nel confermare che l'essere umano dall'altra parte sia effettivamente chi dice di essere — e che abbia un motivo legittimo per fare ciò che sta facendo.

Il secondo incidente ha coinvolto un dipendente assunto da remoto che sembrava completamente legittimo. Ottimo curriculum. Referenze credibili. Portfolio solido. Ma ecco il punto: nessuna di queste cose è difficile da rubare. La persona si è rivelata utilizzare l'identità di un vero ingegnere, con referenze completamente fabricate, e operava dall'estero utilizzando laptop aziendali spediti in un appartamento in affitto.

L'unico motivo per cui è stato scoperto? Qualcuno ha notato che il laptop era più attivo durante le ore notturne. Tutto qui. Nessuna rilevazione sofisticata. Solo qualcuno che prestava attenzione a qualcosa che sembrava un po' strano.

Il problema della sessione di cui nessuno parla

E poi c'è il terzo incidente, che penso sia la minaccia più trascurata nella sicurezza moderna. L'account di un dirigente è stato accesso dalla Romania. Lei stava dormendo in Ohio in quel momento.

La sua password non era compromessa. Il suo MFA non era stato bypassato. Invece, un malware su un computer di casa condiviso ha raccolto i cookie della sua sessione del browser. L'attaccante è passato proprio attraverso la porta digitale, apparendo come un utente autenticato perfettamente legittimo.

Questo è il segreto sporco dell'autenticazione basata sulla sessione: una volta che sei dentro, spesso ci resti. I token di sessione possono rimanere validi per ore o addirittura giorni. E a differenza delle password, non sono qualcosa che gli utenti possono proteggere o ruotare facilmente.

Quindi, qual è la vera lezione?

Non penso che la lezione qui sia "sii più paranoico" (anche se onestamente, un po' di sana paranoia non guasta mai). Penso che la vera intuizione riguardi il divario tra verifica dell'identità e conferma della fiducia.

La maggior parte delle organizzazioni è diventata molto brava nella prima parte. Verifichiamo le credenziali, applichiamo l'MFA, spuntiamo le caselle. Ma la seconda parte — confermare continuamente che qualcuno sia ancora autorizzato e stia agendo in modo appropriato — è dove falliamo.

I casi di cui sto parlando avevano tutti un'altra cosa in comune: sono stati scoperti da esseri umani o da sistemi progettati da umani che cercavano anomalie comportamentali, non solo fallimenti di autenticazione. Un collega che ha messo in dubbio una richiesta insolita. Un analista che ha notato schemi di lavoro strani. Un sistema automatizzato che ha segnalato un viaggio impossibile.

I controlli tecnici sono necessari. Ma non sono sufficienti. Il vero moltiplicatore di sicurezza è costruire una cultura in cui le persone si sentano autorizzate a mettere in dubbio le cose che sembrano sbagliate — anche quando le credenziali sono corrette.

Perché ecco la verità scomoda: nel panorama delle minacce odierno, il rischio di sicurezza maggiore potrebbe non essere l'attaccante fuori dalle vostre mura. Potrebbe essere l'identità dall'aspetto perfettamente valido già al loro interno.

Restate vigili, amici.

Tag: ['identity-security', 'social-engineering', 'business-security', 'remote-work-security', 'authentication']