Cosa deve essere configurato prima di fidarsi del tasso di click

Una simulazione di phishing è stata inviata a diecimila persone. Il report si è chiuso con novemilacinquecento aperture e novemila click. Un 95% di apertura e un 90% di click non sono cifre che produce un gruppo di persone.

Quel risultato è comparso più di una volta nei primi anni di SMARTFENSE, quando le simulazioni partivano senza preparare l’ambiente. Quello che mostrava era uno strumento di email security che apriva e visitava i messaggi prima che arrivassero al destinatario. Quel report misurava le difese di posta dell’organizzazione.

Quando un risultato non torna, la conversazione arriva al mio team. E la prima domanda che facciamo riguarda la consegna delle simulazioni di phishing in quell’organizzazione prima che le persone, da dove è entrato il messaggio, chi lo ha toccato prima della casella e cosa ha potuto caricare il client di posta quando il collaboratore lo ha aperto. La spiegazione sta quasi sempre lì.

Cosa misura davvero una simulazione di phishing?

Ogni metrica di una simulazione è una misura congiunta di due cose, la decisione della persona e lo stato dell’ambiente attraversato dal messaggio. Poterle separare è la condizione per interpretare il risultato.

Un tasso di click del 4% può significare che l’organizzazione ha imparato a diffidare. Può anche significare che metà dei messaggi non è mai arrivata a destinazione. I due scenari producono lo stesso numero e chiedono decisioni opposte.

Conviene chiarire cosa si sta mettendo alla prova. Gli strumenti di email security hanno una loro valutazione e un team dedicato che li controlla. La simulazione serve a misurare il livello che resta quando quegli strumenti non bastano, cioè la persona davanti al messaggio. Se le barriere fermano la trappola, l’esercizio smette di dire qualcosa su ciò che era andato a cercare, e vale la pena ricordare che una campagna si progetta per cambiare il comportamento e non per verificare l’email security.

Perché la simulazione non arriva in casella di posta?

Tra la piattaforma e la casella del collaboratore ci sono diversi livelli di controllo, e ognuno di essi può fermare il messaggio. Prepararli è ciò che si chiama whitelist, e c’è un dettaglio che quasi nessuno ricorda: si divide in due metà.

La prima metà è la consegna della posta, che si risolve dichiarando gli indirizzi IP e i domini di invio negli strumenti che analizzano la posta in entrata. La seconda è la navigazione, perché il collaboratore che clicca finisce su un sito di phishing simulato che può essere bloccato a sua volta. Quella metà richiede di abilitare i domini di navigazione nel browser, nelle sue estensioni e negli strumenti di cybersecurity della postazione di lavoro. Una campagna con la prima metà risolta e la seconda in sospeso consegna i messaggi e perde tutti i click.

Ci sono tre modi per dichiararlo, per indirizzo IP, per dominio e per header del messaggio. Il terzo entra in gioco quando davanti al server di posta c’è uno strumento di sicurezza che riscrive l’IP di origine. In quello scenario dichiarare i nostri indirizzi non basta, perché quello che arriva al server è già un altro, e il messaggio va identificato dal suo header.

L’elenco aggiornato di IP e domini vive dentro la piattaforma, in Configurazione › Sicurezza › Whitelist, ed è anche nei requisiti minimi pubblicati. Conviene consultarlo il giorno della campagna e non quello di avvio del progetto, perché cambia quando cambiano i server di invio.

La consegna diretta sostituisce la whitelist?

Direct Message Injection è un metodo di consegna alternativo. Invece di viaggiare via SMTP e attraversare tutti i livelli, il messaggio viene inserito direttamente nella casella di posta tramite una connessione sicura via API con il provider di posta, disponibile per le organizzazioni che lavorano con Microsoft o con Google.

Risolve tre cose. La prima è la consegna, al punto che in alcuni casi elimina la necessità della whitelist di posta. La seconda sono gli avvisi che alcuni client aggiungono in automatico sopra il messaggio e che allertano il collaboratore prima che abbia modo di decidere. La terza è la fragilità della configurazione, perché l’aggiornamento di uno strumento di sicurezza può invalidare una whitelist che funzionava.

Quello che non risolve è la seconda metà. Il sito di phishing simulato resta dall’altra parte degli strumenti di navigazione, e il filtraggio successivo alla consegna può spostare il messaggio una volta depositato. È la conclusione a cui arrivava già l’articolo che ha presentato DMI su questo blog, e resta valida. La consegna diretta riduce la superficie di configurazione senza farla sparire.

Perché l’apertura è la metrica più fragile?

La piattaforma conta un’apertura quando il client di posta del destinatario mostra il messaggio e carica un pixel trasparente che porta un riferimento univoco a quella persona. Da quel pixel dipendono le statistiche di apertura nelle campagne di newsletter, phishing, ransomware e momenti educativi.

In una nuova implementazione il sintomo si presenta sempre uguale. I messaggi arrivano correttamente in casella di posta, i collaboratori li aprono, e la statistica di apertura non viene registrata. La causa sta nel client di posta, che non ha il permesso di mostrare le immagini, e poiché il pixel è un’immagine non viene mai caricato. La nostra guida ai requisiti minimi lo dice senza giri di parole, se il client blocca le immagini le statistiche di apertura saranno inferiori a quelle reali.

La correzione si applica a livello di tutta l’organizzazione, con l’elenco dei mittenti attendibili applicato tramite policy centrale o da riga di comando, invece di chiedere a ogni persona di abilitare le immagini nel proprio account.

La deviazione avviene anche nella direzione opposta. Le protezioni della privacy della posta caricano il contenuto remoto per conto proprio. Apple documenta che, con quella protezione attiva, il contenuto remoto viene scaricato in background quando si riceve il messaggio e non quando lo si apre. Il pixel si carica senza che nessuno abbia letto niente, e l’apertura risulta contata comunque.

Con entrambe le deviazioni in gioco, l’apertura basta soltanto a confermare che la consegna ha funzionato. Le metriche che sostengono una decisione sono quelle che richiedono un’azione deliberata della persona, il click sul link, l’inserimento di dati nel sito simulato e la segnalazione del messaggio. Sono quelle da portare in dashboard quando si definisce cosa sta misurando il programma.

Quando il numero che sale non è una persona?

Un falso positivo è una statistica generata da un software e registrata a nome di un utente. È ciò che stava dietro al caso del primo paragrafo, e arriva per tre vie, gli strumenti aziendali che analizzano la posta dell’organizzazione, gli strumenti personali installati sui dispositivi che accedono a quella posta e altro software che interviene sul messaggio, come le estensioni del browser o l’anteprima dei link.

Chi amministra la posta di un’organizzazione conosce l’elenco dei sospetti: filtri antispam, antivirus, DLP, gateway di sicurezza, IDS/IPS, analisi continua dei link e componenti aggiuntivi della casella di posta. Nessuno di loro sta facendo qualcosa di improprio. Stanno facendo il loro lavoro su un messaggio che sembra un attacco, perché è stato costruito per sembrarlo.

La piattaforma rileva e filtra questi casi con un algoritmo che evidenzia le campagne interessate, segnala l’origine delle statistiche generate da software e permette di adattare i suoi parametri agli strumenti di ogni organizzazione. Le interazioni rilevate restano fuori dai risultati finali, così le statistiche e i registri di audit contengono solo ciò che hanno fatto le persone. Origine e soluzioni dei falsi positivi sono trattati su questo blog.

Il punto conta a valle. Quello stesso dato alimenta il punteggio di rischio per persona. Un falso positivo non filtrato non resta dentro il report mensile. Muove il punteggio di qualcuno che non ha fatto niente, e quel punteggio poi decide chi riceve formazione aggiuntiva.

Cosa verificare prima della prima campagna?

Sono sei punti, nell’ordine in cui conviene risolverli.

1. Consegna dichiarata negli strumenti che analizzano la posta in entrata, per indirizzo IP, per dominio o per header a seconda di cosa si trovi davanti al server di posta.
2. Navigazione abilitata per i domini della piattaforma nel browser, nelle sue estensioni e negli strumenti di sicurezza della postazione di lavoro.
3. Elenco aggiornato consultato in Configurazione › Sicurezza › Whitelist il giorno della campagna, non quello di avvio del progetto.
4. Immagini visibili nel client di posta, applicato con policy centrale a tutta l’organizzazione invece che utente per utente.
5. Rilevamento dei falsi positivi attivo, con i parametri adattati agli strumenti che l’organizzazione ha installato.
6. Una campagna pilota su un gruppo ridotto prima della prima misurazione generale, verificando i messaggi consegnati, le aperture e i click in cerca di coincidenze sospette.

La verifica non si fa una volta sola. Ogni aggiornamento dello stack di sicurezza può invalidare una configurazione che funzionava, e il momento migliore per scoprirlo è un pilota su cinquanta persone, non la campagna i cui risultati vanno al comitato.

Domande frequenti

Perché le simulazioni di phishing non arrivano in casella di posta?
Perché tra la piattaforma che le invia e la casella del collaboratore ci sono diversi livelli di controllo che analizzano la posta in entrata e possono fermare il messaggio. Prepararli richiede di dichiarare gli indirizzi IP e i domini di invio, e di farlo per indirizzo IP, per dominio o per header del messaggio a seconda di quale strumento si trovi davanti al server di posta.

Serve configurare la whitelist se uso la consegna diretta dei messaggi?
Sì, ma di meno. La consegna diretta risolve la consegna della posta e in alcuni casi elimina la necessità della whitelist per quella metà. La navigazione verso il sito di phishing simulato richiede comunque che i domini siano abilitati nel browser, nelle sue estensioni e negli strumenti di cybersecurity della postazione di lavoro.

Perché l’apertura non viene registrata se il collaboratore ha aperto il messaggio?
Perché l’apertura viene contata quando il client di posta carica un pixel trasparente, e quel pixel è un’immagine. Se il client non mostra le immagini, il messaggio viene letto ma l’apertura non risulta registrata. Si risolve abilitando la visualizzazione delle immagini con una policy centrale su tutta l’organizzazione.

Che cos’è un falso positivo in una simulazione di phishing?
È una statistica generata da un software e registrata a nome di un utente. La producono gli strumenti aziendali che analizzano la posta dell’organizzazione, gli strumenti personali installati sui dispositivi che accedono a quella posta e altro software che interviene sul messaggio, come le estensioni del browser o l’anteprima dei link.

Quali metriche di una simulazione servono per prendere decisioni?
Quelle che richiedono un’azione deliberata della persona, il click sul link, l’inserimento di dati nel sito simulato e la segnalazione del messaggio. L’apertura basta soltanto a confermare che la consegna ha funzionato.

Se stai per lanciare la prima campagna, i requisiti minimi sono pubblicati e l’elenco aggiornato di IP e domini vive dentro la piattaforma. Mezz’ora di verifica prima dell’invio evita la conversazione scomoda su quanto ci si possa fidare del numero nel report.