Sophos Phish Threat: consentire mittenti, domini e IP

Sophos Phish Threat può fornire risultati realistici delle campagne solo se le simulazioni vengono consegnate e gli utenti possono raggiungere le relative pagine di phishing e formazione. A questo scopo, i domini mittente, gli indirizzi IP e le destinazioni web forniti da Sophos devono essere consentiti in tutti i punti di controllo effettivamente attraversati. Tuttavia, non è né necessario né opportuno escludere indiscriminatamente il traffico dai controlli di sicurezza e-mail o web.

Questa procedura è indipendente dal fornitore. Si applica a gateway e-mail a monte, Mail Transfer Agent, Secure Web Gateway, proxy, firewall, filtri DNS e URL, nonché ai prodotti che analizzano automaticamente link o allegati. Le istruzioni specifiche per ciascun prodotto sono riportate nelle guide alla consegna per Microsoft 365 e Google Workspace.

Individuare i valori correnti in Sophos Fusion (in precedenza Sophos Central)

L’elenco vincolante deve essere recuperato dal tenant Sophos Fusion interessato:

1. Fare clic sull’icona Global Settings.
2. Aprire Products and Services > Sophos Phish Threat.
3. Fare clic su Sending domains and IPs.
4. Documentare tutti i domini mittente, gli indirizzi IP e le destinazioni web visualizzati, insieme alla data di recupero.

Gli indirizzi IP Sophos Mailflow regionali non devono essere aggiunti indiscriminatamente all’allowlist di Phish Threat. Vengono utilizzati esclusivamente per i connettori Mailflow di Microsoft 365 configurati automaticamente o per il loro ripristino dopo modifiche alla configurazione. Queste reti devono pertanto essere inserite solo nell’ambito della configurazione documentata dei connettori Mailflow e solo per la regione utilizzata, non preventivamente nei gateway a monte, nei proxy o nei filtri web.

L’elenco può contenere valori destinati a funzioni diverse:

• indirizzi IP e domini per l’invio delle e-mail della campagna,
• domini del mittente o del Return-Path,
• destinazioni di tracciamento e reindirizzamento per la misurazione dei clic,
• domini per pagine simulate di phishing o di accesso,
• pagine di formazione e altre destinazioni web necessarie per lo svolgimento della campagna.

I link di Phish Threat possono effettuare un reindirizzamento tramite la destinazione di tracciamento AWS awstrack.me documentata da Sophos. Tale reindirizzamento è previsto per la misurazione dei clic. Prima dell’invio pilota, confrontare gli host effettivamente necessari con l’elenco Sophos corrente e con le destinazioni della campagna specifica. Non consentire sottodomini aggiuntivi, salvo che la loro necessità sia documentata in tali fonti o nella documentazione del prodotto.

Mappare il flusso di dati prima dell’autorizzazione

L’allowlisting va eseguito in ogni punto di controllo, non solo sull’ultimo server di posta. Per prima cosa, documentare il percorso effettivo di un messaggio e di un clic di test:

1. Sophos Phish Threat invia la simulazione.
2. Un filtro cloud a monte, un Secure Email Gateway o un MTA accetta il messaggio.
3. Ulteriori servizi antispam, antiphishing, sandbox o di analisi dei link lo elaborano.
4. Il sistema di destinazione lo recapita alla casella di posta.
5. Quando l’utente fa clic, la richiesta attraversa filtri DNS, proxy, Secure Web Gateway, firewall ed eventualmente la protezione del browser o dell’endpoint.
6. Le pagine di tracciamento, phishing e formazione restituiscono gli eventi a Phish Threat.

Per ogni passaggio, registrare il prodotto, il responsabile della regola, il valore necessario, l’eccezione desiderata, la data di scadenza o revisione e il percorso di rollback. Se sono presenti più filtri in sequenza, è necessario considerarli tutti. Consentire il traffico solo nella casella di destinazione non risolve un blocco nel gateway a monte.

Implementare un’allowlist con l’ambito più ristretto possibile

La regola deve essere estesa solo quanto tecnicamente necessario per la simulazione. Preferire indirizzi IP o nomi host esatti, l’elenco Phish Threat corrente e i destinatari del test previsti. Utilizzare un intero dominio, un pattern wildcard o un’eccezione globale dello scanner solo se la configurazione della campagna o il prodotto non consentono una regola più restrittiva.

Alcuni prodotti distinguono tra consegna, valutazione dello spam, riscrittura degli URL, controllo Time-of-Click, Attachment Sandboxing e accesso web. Una singola regola “Allow” non copre automaticamente tutte queste funzioni. Viceversa, un’autorizzazione per la consegna delle e-mail non deve escludere involontariamente da ogni controllo tutti i file o gli URL dello stesso mittente.

Consentire host variabili solo in caso di necessità comprovata

Inizialmente, aggiungere singolarmente solo gli host indicati in Sophos Fusion o nella documentazione del prodotto e utilizzati nella campagna. Se è comprovato che una specifica destinazione del prodotto o della campagna usa host variabili e non è tecnicamente possibile limitare l’autorizzazione a nomi host esatti, può essere necessaria una wildcard. In tal caso, applicare controlli aggiuntivi:

• impostare la wildcard solo al di sotto del dominio di base indicato da Sophos,
• non consentire l’intero dominio superiore del provider,
• limitare la regola al traffico Phish Threat e, se possibile, ai destinatari pilota,
• documentare il responsabile e la data di revisione,
• prima di ogni nuovo modello di campagna, verificare se viene utilizzato un host aggiuntivo.

Un’autorizzazione molto ampia, come un’intera piattaforma cloud o di invio condivisa, aumenta il rischio di ammettere traffico estraneo. Se un prodotto non permette di rappresentare l’ambito ristretto necessario, questo rischio residuo deve essere accettato prima della modifica oppure va scelto un altro percorso di consegna.

Evitare falsi clic e l’apertura automatica degli allegati

I prodotti per la sicurezza e-mail spesso esaminano i messaggi richiamando gli URL o aprendo gli allegati in una sandbox. Phish Threat può interpretare tale richiesta come un’azione dell’utente. Ne risultano clic o allegati apparentemente aperti, anche se il destinatario non ha ancora interagito con il messaggio.

Indizi tipici del fatto che l’evento provenga da uno scanner anziché da un utente sono:

• gli eventi si verificano prima o immediatamente al momento della consegna,
• molti destinatari mostrano quasi contemporaneamente la stessa azione,
• gli indirizzi sorgente o gli User-Agent appartengono al servizio di sicurezza,
• diversi link dello stesso messaggio vengono aperti in rapida successione,
• il comportamento è riproducibile con un messaggio pilota appena inviato.

La correzione va effettuata sullo scanner che causa il problema: aggiungere gli indirizzi IP e i domini Phish Threat correnti al relativo elenco per le simulazioni di phishing autorizzate o per le eccezioni di scansione mirate. L’eccezione deve corrispondere sia alla sorgente identificata sia alla funzione di scansione interessata. Consentire solo un indirizzo mittente non è sufficiente se il servizio apre comunque ogni URL in una sandbox.

Gli eventi di clic mancanti hanno spesso la causa opposta. Le destinazioni di tracciamento possono essere bloccate da Secure Web Gateway, filtri DNS o estensioni del browser come gli ad blocker. In caso di telemetria mancante, quindi, non riavviare immediatamente la campagna: controllare prima la catena di reindirizzamento nel browser e i log di proxy, DNS ed endpoint.

Header di bypass di Microsoft 365 solo come eccezione legacy

Le guide meno recenti utilizzano regole di trasporto con gli header X-MS-Exchange-Organization-SkipSafeLinksProcessing o X-MS-Exchange-Organization-SkipSafeAttachmentProcessing. Tali regole non costituiscono la baseline per una nuova configurazione. Per la consegna basata su SMTP attraverso la pipeline di trasporto di Microsoft 365 è prevista l’Advanced Delivery Policy di Microsoft. Per le nuove configurazioni, invece, Sophos consiglia M365 Direct Delivery; questo percorso di consegna evita la pipeline di trasporto, quindi Advanced Delivery non vi si applica. La configurazione specifica di Microsoft 365 deve seguire le istruzioni Sophos correnti per il percorso di consegna scelto e non rientra nell’ambito di questo articolo.

Gli header legacy sono da prendere in considerazione solo se un ambiente esistente ne ha ancora una necessità comprovata, è stato verificato lo stato corrente del supporto ed esiste una modifica approvata con ambito IP/dominio ristretto. Priorità, effetto e conseguenze per la sicurezza della regola devono essere testati separatamente. Le vecchie regole degli header non devono essere mantenute “per precauzione” insieme a un’autorizzazione di simulazione corrente.

Convalidare una campagna pilota

Iniziare con un piccolo gruppo pilota composto da account di test controllati. Deve includere almeno una casella di posta per ogni percorso di consegna, gruppo di policy e sede rilevanti. Il test comprende un messaggio con un link e, se previsto dall’uso operativo, una campagna con allegato e formazione.

Prima dell’invio, documentare timestamp, ID della campagna, destinatari, mittente previsto, dominio utilizzato e ID delle regole modificate. Quindi verificare quanto segue:

1. Il gateway accetta il messaggio e lo consegna una sola volta alla casella di posta prevista.
2. I valori effettivamente utilizzati per la corrispondenza della regola prevista coincidono con l’elenco Sophos corrente: il dominio From visibile appropriato o il dominio Envelope Sender/Return-Path e, se la regola è basata sull’IP, l’IP sorgente del sistema SMTP mittente registrato dal gateway che esegue il controllo come peer della connessione. Controllare questi campi separatamente; l’IP del server ricevente non può essere usato come IP sorgente del mittente.
3. Il messaggio non finisce né in quarantena né, inaspettatamente, nella cartella Posta indesiderata.
4. In Phish Threat non compare alcun evento di clic o allegato prima di un’azione dell’utente.
5. Un clic controllato dell’utente apre la pagina di reindirizzamento, simulazione o formazione prevista.
6. Esattamente tale azione compare nel risultato della campagna a un orario plausibile.
7. I log di proxy, firewall, DNS e scanner mostrano la regola prevista, ma nessun bypass inutilmente ampio.
8. Un normale messaggio di test esterno e una destinazione web non autorizzata continuano a essere controllati secondo le policy di sicurezza esistenti.

Il successo non significa soltanto che “l’e-mail è arrivata”. Devono essere confermati congiuntamente la consegna, l’accuratezza della misurazione della campagna, la raggiungibilità delle destinazioni web e la continua efficacia dei controlli di sicurezza. Solo allora la regola può essere estesa al gruppo di destinatari previsto.

Circoscrivere gli errori in modo sistematico

In caso di mancata consegna, procedere verso l’interno dal primo punto di accettazione: log SMTP, gateway a monte, quarantena, regola di trasporto a valle e casella di destinazione. L’errore SMTP o il verdetto del prodotto indica in quale punto è stato rifiutato il messaggio. Aggiungere eccezioni ampie senza questa prova rende più difficile l’analisi della causa.

In caso di falsi clic, confrontare invece la cronologia dall’invio alla consegna. Utilizzare i log dello scanner, l’IP sorgente e lo User-Agent per attribuire una richiesta automatica riproducibile al prodotto che la causa. Se i clic reali non vengono registrati, controllare la risoluzione DNS, la decisione del proxy, la connessione TLS, i reindirizzamenti e le estensioni del browser.

Se la causa rimane incerta, interrompere la campagna pilota. Un’eccezione non deve essere ampliata gradualmente finché la consegna non funziona per caso.

Annullare le modifiche ed eseguire una manutenzione continua

Prima dell’implementazione, definire un rollback per ogni regola: stato precedente, ID della regola, esportazione o screenshot, persona responsabile e ordine di annullamento. Se vengono consegnati inaspettatamente messaggi estranei, la sicurezza viene esclusa dai controlli in modo troppo ampio, gli accessi proxy risultano sospetti o i dati della campagna restano falsati, disattivare la modifica o ripristinare l’ultimo stato verificato. Quindi controllare nuovamente i log e-mail e web.

Per le attività correnti, applicare almeno i controlli seguenti:

• confrontare i valori correnti con Sophos Fusion prima di ogni campagna importante,
• testare nuovamente le regole dopo un cambio di prodotto, routing o provider,
• verificare regolarmente se è possibile restringere l’ambito di wildcard ed eccezioni globali,
• rimuovere domini, IP e regole legacy non più necessari,
• associare a ogni eccezione una data di revisione, un proprietario e una motivazione tecnica,
• dopo le modifiche, eseguire sempre una campagna pilota senza falsi clic automatici.

FAQ