Perché le e-mail di simulazione di phishing finiscono nello spam (e come risolvere il problema senza compromettere la sicurezza)

Se le tue e-mail di simulazione di phishing finiscono nello spam o in quarantena, i tuoi risultati diventano poco affidabili.

Un tasso di clic del 2% potrebbe significare che i tuoi utenti sono migliorati. Oppure potrebbe significare che gran parte dell'azienda non ha mai visto il messaggio. Non si tratta solo di un problema di reporting. È un problema di progettazione del programma. Questa guida è pensata per ingegneri della sicurezza, amministratori IT, CISO e responsabili della conformità che hanno bisogno di una consegna affidabile per le simulazioni senza creare pericolose falle nella sicurezza della posta.

Nota di sicurezza: questo articolo riguarda le simulazioni difensive e la misurazione della consapevolezza. Non include istruzioni per il phishing vero e proprio, il furto di credenziali o l’aggiramento dei controlli di sicurezza a fini dannosi.

La versione breve

Se le email di simulazione di phishing finiscono nello spam, la soluzione di solito non è “allentare i filtri finché tutto non arriva nella posta in arrivo”.

L'approccio più sicuro è:

• usa un dominio o sottodominio dedicato alla simulazione
• rendi intenzionale l'allineamento di SPF, DKIM e DMARC
• mantieni puliti i contenuti e le catene di reindirizzamento
• distingue la telemetria di consegna dalla telemetria del comportamento degli utenti
• e, se necessario, usa liste di autorizzazione mirate piuttosto che bypass generici

Quest'ultimo punto è importante. Le liste di autorizzazione generiche sono rischiose. Ma regole ristrette e ben documentate, legate a un IP di invio dedicato e a identità di mittenti note, possono essere un controllo a lungo termine perfettamente ragionevole.

Perché la deliverability della simulazione di phishing fallisce

I fallimenti di deliverability sono raramente casuali. Di solito sono il risultato prevedibile di come è stato configurato il programma.

1) SPF, DKIM o DMARC non sono allineati con il mittente visibile

Questa è la causa più comune.

Se il dominio che gli utenti vedono nel campo Da non corrisponde al dominio autorizzato da SPF o firmato da DKIM, i sistemi di posta hanno un buon motivo per essere sospettosi. Sia Microsoft che Google trattano SPF, DKIM e DMARC come segnali fondamentali di affidabilità del mittente, ed entrambi sottolineano l'allineamento con il dominio del mittente visibile.

Modelli di errore comuni:

• il dominio Da visibile non è il dominio che hai effettivamente autenticato
• la firma DKIM manca o è associata al dominio sbagliato
• DMARC esiste, ma l'allineamento con il mittente visibile non è mai stato testato correttamente
• sono state apportate modifiche al DNS, ma non sono state completamente propagate o convalidate prima del lancio della campagna

2) La simulazione utilizza il dominio aziendale principale

L'uso del dominio aziendale principale può sembrare realistico, ma spesso crea collisioni inutili.

Finisci per testare gli stessi controlli anti-spoofing, anti-impersonificazione e anti-abuso che esistono per proteggere quel dominio in produzione. Questo può essere appropriato in alcuni programmi maturi, ma raramente è il punto di partenza più pulito.

Per la maggior parte dei team, un sottodominio dedicato alla simulazione è l’impostazione predefinita più sicura.

3) È stato utilizzato il tipo sbagliato di whitelist

L'allowlisting può diventare un problema di sicurezza, specialmente quando i team fanno cose come:

• bypassare la protezione anti-phishing a livello globale
• inserire in allowlisting enormi intervalli di IP di provider cloud
• esentare intere infrastrutture di mittenti che non controllano
• saltare la scansione per ampie categorie di posta

Ma questo non è l'unico modello.

C'è una grande differenza tra bypass generici e regole di consegna mirate. Se il tuo provider invia da un IP dedicato e da un insieme ristretto e noto di indirizzi o domini mittenti, un'allowlist con ambito ristretto può essere accettabile e può persino rimanere in vigore come parte della configurazione standard. I documenti di guida alla configurazione di AutoPhish descrivono esattamente questo modello: le campagne vengono inviate da un server SMTP/IP dedicato e da un insieme definito di indirizzi mittenti, il che rende possibili eccezioni di filtraggio precise senza ricorrere a bypass eccessivi che creano una reale esposizione.

4) I contenuti e i link attivano gli stessi controlli di cui ti aspetti che gli utenti si fidino

Le email di simulazione spesso contengono:

• link di tracciamento
• reindirizzamenti
• linguaggio che trasmette urgenza
• frasi tipiche del brand
• inviti all'azione in stile login

Questo non è automaticamente sbagliato. Ma significa che l'email verrà ispezionata come se fosse sospetta. Se la simulazione si basa sull'apparire abbastanza sospetta da aggirare i tuoi stessi controlli, non stai più testando gli utenti. Stai testando se il tuo sistema di sicurezza rileva contenuti palesemente rischiosi.

5) I dati di consegna e quelli comportamentali sono mescolati insieme

Se non riesci a separare chiaramente:

• inviato
• consegnato
• aperto
• cliccato
• segnalato

allora i tuoi report ti fuorvieranno. Una metrica debole della campagna potrebbe riflettere un problema dell’utente. Oppure un problema di instradamento. O una politica di quarantena. O un problema di filtraggio specifico del provider di posta. Si tratta di percorsi di risoluzione molto diversi.

Un modo più sicuro per migliorare la deliverability delle simulazioni di phishing

Passo 1: Separa l’invio delle simulazioni dalle normali email aziendali

Per la maggior parte delle organizzazioni, il miglior punto di partenza è:

• un dominio o sottodominio dedicato alle simulazioni
• record di autenticazione dedicati
• un percorso di invio pulito, facile da spiegare e da verificare
• nessuna impersonificazione di persone interne reali, a meno che non ci sia una ragione valida e verificata

Questo riduce il raggio d'azione, riduce la confusione e rende la risoluzione dei problemi molto più semplice.

Passo 2: Verifica l'autenticazione prima della prima campagna

Prima di concludere che "Microsoft ci sta bloccando" o "Google è troppo aggressivo", verifica le basi:

• L'SPF include solo l'infrastruttura che dovrebbe inviare le email di simulazione
• Il DKIM è abilitato e firma in modo affidabile
• Il DMARC è pubblicato e allineato con il dominio del mittente visibile
• i messaggi di prova mostrano effettivamente i risultati di autenticazione che ti aspettavi

Per un ripasso indipendente dal fornitore, la panoramica di Microsoft sull'autenticazione delle email è un utile punto di riferimento, e la guida di Google per i mittenti sottolinea lo stesso concetto fondamentale: una consegna affidabile inizia con un'autenticazione pulita e l'allineamento del dominio.

Se utilizzi AutoPhish, l’articolo della guida sulla consegna delle email delle campagne e il controllo DNS sono ottimi punti di partenza durante la configurazione.

Passo 3: Usa un’allowlist mirata quando serve, non bypass generici

Questa è la parte di cui molti team hanno davvero bisogno.

Un’eccezione valida è:

• specifica
• documentata
• verificabile
• facile da spiegare ai revisori
• legata a un’identità del mittente nota o a un IP di invio dedicato
• abbastanza ristretta da non fidarsi accidentalmente di traffico non correlato

Un’eccezione sbagliata è “va bene qualsiasi cosa da questo provider”. Un'eccezione migliore è “le email di simulazione provenienti da questo IP dedicato e da questo gruppo definito di mittenti devono essere consegnate in modo coerente per questo programma di sensibilizzazione”. Questa distinzione è importante.

In pratica, l'approccio più difendibile è spesso:

• mantenere la scansione normale dove possibile
• evitare regole globali di “esclusione dal filtraggio”
• preferire regole ristrette basate su mittente/IP piuttosto che un’affidabilità a livello di infrastruttura
• documentare esattamente perché la regola esiste e cosa copre
• rivedila periodicamente, ma non dare per scontato che debba essere temporanea se rimane ben circoscritta e si adatta ancora al tuo modello di controllo

Con AutoPhish, quel modello è realizzabile perché le campagne vengono inviate da un IP dedicato e da un’impronta del mittente nota, piuttosto che da un enorme pool di posta condiviso.

Passo 4: Progetta simulazioni per insegnare il riconoscimento, non per combattere il gateway

Le migliori simulazioni di phishing non devono necessariamente “vincere” contro ogni controllo di sicurezza.

Devono aiutarti a valutare se le persone:

• notano segnali sospetti
• evitano azioni rischiose
• segnalano rapidamente i messaggi sospetti
• migliorano nel tempo

Questo è un obiettivo di progettazione più sano rispetto al tentativo di rendere ogni email indistinguibile da un attacco reale a livello di filtraggio.

Passo 5: Crea report in grado di distinguere i problemi di posta da quelli delle persone

Un programma maturo dovrebbe essere in grado di rispondere a:

• Quanti messaggi sono stati effettivamente consegnati?
• Quale provider o politica li ha filtrati?
• Quali reparti hanno avuto una visibilità inferiore?
• Gli utenti hanno segnalato il messaggio?
• Gli stessi utenti sono migliorati nel tempo?

È questo che trasforma le simulazioni da “un mucchio di email false” in qualcosa di utile dal punto di vista operativo.

Se vuoi quel tipo di struttura, i report sono importanti tanto quanto i contenuti. Vedi: Reportistica sulla simulazione di phishing: 12 caratteristiche che i team di sicurezza dovrebbero confrontare.

Come dovrebbe essere una "buona" lista di autorizzazioni

Una buona regola dovrebbe essere abbastanza restrittiva da essere accettabile per il tuo team di sicurezza e comprensibile per i tuoi revisori.

Questo di solito significa:

• è limitata all'infrastruttura di invio delle simulazioni
• è legata a domini noti, identità dei mittenti o a un IP dedicato
• non si fida delle email non correlate provenienti dallo stesso provider più ampio
• non crea una condizione generica del tipo "consegna sempre, non scansionare mai" a meno che non ci sia un motivo molto valido
• viene monitorata come parte della progettazione del programma di sensibilizzazione, non come una soluzione alternativa nascosta

È qui che conta anche l'architettura del provider. Se una piattaforma invia da un pool condiviso utilizzato da molti clienti, l’inserimento in una lista di autorizzazioni a lungo termine diventa più difficile da giustificare. Se invia da un IP dedicato con una superficie di mittenti piccola e documentata, l’inserimento in una lista di autorizzazioni ristretta diventa molto più facile da difendere.

Una breve checklist quando le email di simulazione di phishing finiscono nello spam

Usa questa checklist quando i tuoi risultati sembrano sospetti.

Autenticazione e identità del mittente

• Il dominio “Da” visibile è quello che intendevi usare?
• SPF, DKIM e DMARC sono allineati con quel dominio?
• È cambiato qualcosa di recente nel DNS o nella configurazione di invio?
• Le intestazioni di test mostrano i risultati che ti aspettavi?

Architettura di invio

• Stai usando un sottodominio di simulazione dedicato?
• L'infrastruttura di invio è isolata dalla posta di produzione?
• La cronologia della reputazione del mittente è stabile?
• Ti affidi a un pool di mittenti condiviso o a un IP dedicato?

Regole ed eccezioni

• Qualcuno ha creato un bypass generico per "farlo funzionare e basta"?
• La regola potrebbe essere ristretta a identità precise dei mittenti o a un IP dedicato?
• L'eccezione è documentata e verificabile?
• Stai ancora effettuando scansioni ovunque sia possibile?

Contenuto e misurazione

• Gli URL sono puliti e prevedibili?
• Ci sono catene di reindirizzamenti inutili?
• Stai misurando la consegna separatamente dal coinvolgimento?
• Stai monitorando il tasso di segnalazione e il tempo di segnalazione, non solo i clic?

Domande frequenti

Dovremmo inserire nella whitelist le email di simulazione di phishing?

A volte sì.

Quello che devi evitare è una fiducia generica. Ciò che spesso è accettabile è una fiducia limitata: un IP di invio dedicato, identità dei mittenti note, uno scopo chiaramente documentato e nessuna deroga eccessiva che indebolisca il resto della tua sicurezza della posta.

Queste regole dovrebbero essere temporanee?

Non necessariamente.

Le eccezioni di emergenza di ampia portata dovrebbero essere temporanee. Ma le regole mirate e ben definite possono rimanere in vigore se fanno parte del modello operativo approvato, sono ancora adeguatamente limitate e vengono riviste periodicamente.

Possiamo eseguire simulazioni dal nostro dominio aziendale principale?

Puoi farlo, ma di solito comporta maggiori attriti e rischi più elevati.

Un sottodominio dedicato alle simulazioni è più facile da autenticare, più facile da spiegare e meno soggetto a interferire con i tuoi controlli anti-spoofing e anti-impersonificazione in produzione.

Una migliore deliverability riduce il realismo?

No.

Le simulazioni efficaci misurano il comportamento di riconoscimento e segnalazione. Non hanno bisogno di infrastrutture approssimative o bypass non sicuri per essere utili.

Come dimostriamo che i risultati sono affidabili?

Documenta entrambi i lati del sistema:

1. cosa avrebbe dovuto essere consegnato
2. cosa hanno effettivamente fatto gli utenti dopo la consegna

Questo è molto più difendibile che mostrare un grafico del tasso di clic senza il contesto della consegna.

Pronto a eseguire simulazioni che misurano la resilienza invece degli incidenti nel flusso di posta?

AutoPhish è pensato per i team che vogliono simulazioni sicure, report attenti alla privacy e prove facilmente verificabili senza un carico operativo eccessivo.

Se hai bisogno di una guida precisa per la configurazione, consulta il nostro articolo di aiuto su come assicurarti che le e-mail della campagna vengano ricevute correttamente.

Iscriviti

Crediti immagine: Foto di Krsto Jevtic su Unsplash.