Il percorso di una email segnalata, dalle 11:23 alle 11:27

Mercoledì, 11:23. A Lucía arriva una email che sembra venire dall’area IT e le chiede di aggiornare le sue credenziali VPN prima di mezzogiorno. Qualcosa non le torna. Preme il pulsante di segnalazione e torna a quello che stava facendo.

Questo è tutto quello che fa lei. Il pezzo precedente di questa serie lasciava aperto un punto. L’abitudine a segnalare regge solo se segnalare ha una conseguenza che la persona può percepire, e quella conseguenza dipende da quanto tempo impiega una email reale per avere una risposta. L’analisi automatica delle email segnalate è ciò che comprime quell’attesa, ed ecco il suo percorso passo per passo, senza tecnicismi. Gli orari e i numeri sono quelli di un’organizzazione concreta, la stessa dei pezzi precedenti, e non medie di settore.

Qual è la prima cosa che viene verificata quando arriva una email segnalata?

La prima cosa è se l’email l’ha inviata il tuo programma. È l’unica domanda alla quale la piattaforma può rispondere senza indagare niente, perché ha il registro di ogni simulazione di phishing che ha inviato, e per questo va per prima.

Quando la risposta è sì, il caso si chiude subito. La piattaforma riconosce alla persona di averla individuata, lo somma al suo punteggio e non resta niente da analizzare. L’email di Lucía non è una simulazione, quindi il percorso continua.

Cosa verifica l’analisi di una email segnalata?

11:24. Da qui l’email viene analizzata in modo automatico, con lo stesso livello di dettaglio con cui la esaminerebbe una persona del team di sicurezza, ma senza che nessuno debba aprirla.

Si verifica se l’email arriva da dove dice di arrivare o se qualcuno si sta spacciando per un’azienda conosciuta. Si segue ogni link fino alla sua destinazione finale, perché un link può mostrare un indirizzo e portare a un altro. Si esaminano gli allegati, compreso il classico che finge di essere una fattura e non lo è.

E si guardano le immagini del messaggio. È lì che oggi si nasconde buona parte di quello che l’email security non riesce a vedere. Un codice QR prende il posto del link e una schermata prende il posto del testo, quindi un’analisi che legge soltanto il testo passa accanto a entrambi i casi senza vederli.

Un’analisi che legge soltanto il testo di una email non vede l’attacco che arriva dentro un’immagine.

Come simulare quell’attacco per addestrare le tue persone è già trattato in l’articolo sul qrishing di questo blog. Qui il codice QR arriva in una email che qualcuno ha già segnalato, e quello che serve è decidere cosa sia.

E quando l’evidenza tecnica non basta?

Ci sono email che l’evidenza non risolve. Il mittente è legittimo, i link non figurano in nessuna lista, non ci sono allegati, ma il messaggio chiede qualcosa che non torna, con un’urgenza che non torna nemmeno. È la zona grigia dove finora serviva il giudizio di una persona.

Per quei casi c’è un agente di intelligenza artificiale che analizza cosa dice l’email e come lo dice, dall’urgenza e dalla pressione fino al pretesto che usa per giustificare la richiesta. Non sostituisce la verifica tecnica. Entra quando quella verifica si ferma, che è esattamente il punto in cui si accumulavano le segnalazioni difficili.

Nell’email di Lucía l’evidenza basta e avanza. Il dominio del mittente è stato registrato 48 ore fa, i link puntano a un server in un paese dove l’azienda non opera e l’autenticazione del mittente fallisce.

Verdetto: phishing. Punteggio di rischio: 92 su 100.

Cosa riceve il team di sicurezza quando l’analisi è finita?

11:25. Al team di sicurezza arriva un risultato invece dell’email da aprire. Sono tre cose.

• Un verdetto. Phishing reale o falso allarme.
• Un punteggio di rischio da 0 a 100. La priorità, senza bisogno di leggere altro.
• Una spiegazione del perché, scritta nella lingua di chi la legge.

La terza è quella che cambia chi può lavorare con la segnalazione. La spiegazione non arriva nel linguaggio di un header di posta, arriva in frasi come «l’allegato nasconde il suo vero tipo di file» o «le risposte a questa email andrebbero a un indirizzo diverso da quello del mittente». Non serve saper leggere una email dall’interno per capirle, e questo significa che la segnalazione smette di aspettare l’unica persona del team che lo sa fare.

Cosa succede alle email segnalate che risultano innocue?

L’email di Lucía era phishing, ma la maggior parte non lo è. Nel mese di cui stiamo parlando, 160 delle 183 email segnalate sono risultate innocue. Una fattura reale che sembrava strana, una promozione, l’email di un fornitore nuovo che nessuno aveva in agenda.

È quello che accade quando le persone stanno attente. Un’organizzazione che tratta il falso allarme come un costo finisce per insegnare alle sue persone a non segnalare. Chi ha avuto un dubbio davanti a una email legittima ha fatto esattamente quello che era stato chiesto.

Quello che cambia con l’analisi automatica è che anche quelle 160 email ricevono il loro verdetto e si chiudono senza consumare il tempo di nessuno. Smettono di essere la pila sotto la quale aspettano le 23 che erano davvero attacchi.

Quanto dura il percorso completo?

11:27. Chi è di turno apre la segnalazione, trova l’analisi già fatta, conferma il verdetto e avvia il protocollo di risposta. La decisione resta sua. Quello che è cambiato è che non deve più costruire l’evidenza per poterla prendere.

E il protocollo non deve aspettare quella conferma. Un Playbook è un insieme di azioni che si eseguono da sole quando si verifica un evento determinato, quindi il verdetto può concatenare le prime senza che nessuno le lanci.

Può essere un avviso al team via email, via Slack o via Microsoft Teams, più una chiamata ai sistemi che hai integrato, così il contenimento parte mentre la persona di turno esamina il caso. Dove mettere quel limite lo decide ogni organizzazione, perché ci sono risposte che conviene far partire da sole e altre che non si muovono finché qualcuno non guarda.

Tra il momento in cui Lucía ha premuto il pulsante e il momento in cui il team di sicurezza ha iniziato ad agire sono passati quattro minuti. Con la coda di 47 segnalazioni di cui abbiamo parlato in il primo pezzo della serie, sarebbero stati tre giorni.

Quella differenza ha un costo che la coda non mostra. Una email di phishing che aspetta tre giorni per essere classificata resta tre giorni nelle caselle di posta del resto dell’organizzazione, e nessuno può avvisare, bloccare o contenere un attacco che non è ancora stato guardato. Il tempo di classificazione è il tempo che l’attacco ha per continuare a lavorare.

Quello che Lucía nota, senza che nessuno glielo spieghi

C’è una seconda lettura di quei quattro minuti, e non sta su nessun dashboard di sicurezza. Lucía ha avvisato ed è successo qualcosa.

Il verdetto e il punteggio non arriveranno mai al suo schermo, e non le servono. Le basta percepire che il suo avviso è entrato in un circuito che si è mosso, perché è questo che peserà la prossima volta che avrà un dubbio davanti a una email. Quando il percorso si misura in giorni, la risposta arriva tardi per lei e tardi per l’organizzazione. Quando si misura in minuti, il circuito si chiude da solo.

Quel percorso è quello che fa Smart Triage dentro la console delle segnalazioni di SMARTFENSE, sulle email che le tue persone segnalano con il pulsante. Se vuoi vederlo sulle tue segnalazioni, nella console c’è il dettaglio di ogni analisi e lo storico di quello che è stato classificato.

Nel prossimo pezzo della serie cambieremo di nuovo punto di vista e guarderemo il mese dell’analista SOC che apriva quelle 183 segnalazioni una per una, e le ore che il triage automatico restituisce al team.