Identifica ciò che afferma il messaggio
Un messaggio può imitare un'azienda in molti modi diversi. Potrebbe inserire il dominio esatto dell'azienda nell'indirizzo del mittente visibile, utilizzare il nome visualizzato di una persona familiare con un indirizzo non correlato o inviare messaggi da un dominio diverso scelto per assomigliare all'azienda. Questi non sono meccanismi intercambiabili. Richiedono prove diverse ed espongono confini di controllo diversi. Chiamare tutti e tre i casi a DMARC un errore incoraggia la riparazione sbagliata e può nascondere un incidente che necessita di una verifica aziendale anziché di una modifica DNS .
RFC 9989 ambito DMARC al RFC5322 .Da dominio e autenticazione allineata. Esclude esplicitamente gli attacchi ai nomi visualizzati, l'analisi dei contenuti e l'autenticazione di entità diverse dai domini. Un destinatario può comunque applicare protezioni aggiuntive, ma tali protezioni non dovrebbero essere attribuite a DMARC stesso. Questo articolo offre un metodo di classificazione per il triage difensivo, senza una reale ispezione dei messaggi o accuse su un mittente nominato.
L'uso del dominio esatto richiede un confronto preciso
Inizia con il dominio effettivo nell'indirizzo del mittente analizzato, non con il testo visualizzato dall'applicazione di posta. Confrontalo con il dominio aziendale rilevante per la richiesta. Conservare l'ortografia esatta e la fonte della prova in un registro di indagine riservato. Se i domini sono identici, la domanda successiva è se le prove del destinatario fidato mostrano un’autenticazione allineata, un fallimento, un’assenza di policy o un risultato indeterminato. L'aspetto del dominio esatto da solo non ti dice cosa si è verificato.
Un mittente non autorizzato che utilizza il dominio esatto potrebbe non riuscire allineamento, ma un account o un servizio autorizzato compromesso può produrre posta allineata. Lo stesso dominio visibile può quindi verificarsi in incidenti molto diversi. Un passaggio DMARC non dimostra che il messaggio sia stato approvato da una persona e un errore non dimostra di per sé un intento dannoso. Inoltri, errori di configurazione e prove incomplete possono complicare l'interpretazione. Enunciare il fatto osservato prima di attribuire una causa.
I nomi visualizzati rappresentano una superficie di identità separata
RFC 5322, sezione 3.4, distingue il nome visualizzato facoltativo di una casella di posta dal suo indirizzo. Un nome visualizzato può identificare una persona o un ruolo per un lettore senza essere il dominio valutato da DMARC . Ad esempio, un messaggio fittizio può visualizzare "Account Team" mentre il suo indirizzo appartiene a un dominio di esempio non correlato. L’etichetta familiare non è una prova della proprietà organizzativa.
Una visualizzazione a schermo piccolo o compressa potrebbe non esporre a prima vista tutti i campi di identità. L'azione difensiva consiste nell'esaminare l'indirizzo completo utilizzando l'interfaccia attendibile dell'applicazione ricevente e quindi valutare la richiesta commerciale in modo indipendente. Non inventare una regola universale dell'interfaccia utente né promettere che ogni client evidenzi una mancata corrispondenza. La distinzione dello standard tra etichetta e indirizzo è stabile; la presentazione e gli avvertimenti protettivi dipendono dal cliente e dal ricevente.
I domini simili possono autenticarsi con successo
Un dominio diverso può essere visivamente simile a un dominio attendibile a causa dell'ortografia, della punteggiatura o delle scelte dei caratteri. Se il suo operatore controlla legittimamente la sua configurazione di invio, la posta da quel dominio può passare SPF, DKIM e DMARC per quel dominio. L'autenticazione non ha necessariamente funzionato male. Il riconoscimento dell'organizzazione prevista da parte del destinatario è fallito o è stato manipolato a un livello diverso.
Confronta il dominio effettivo con un record aziendale attendibile ottenuto al di fuori del messaggio discutibile. Non visitare un sito Web fornito o rispondere all'indirizzo discutibile solo per stabilirne la proprietà. Una parola familiare incorporata in un nome più lungo non è sufficiente. Conservare attentamente l'interpretazione dei nomi internazionalizzati e cercare un'analisi qualificata se i moduli visualizzati e quelli sottostanti differiscono; questa bozza non fornisce un algoritmo di classificazione Unicode o suffisso pubblico completo.
Utilizzare prove di autenticazione attendibili
UN Authentication-Results il campo è utile solo all'interno del limite di fiducia del destinatario. RFC 8601 spiega perché i consumatori devono distinguere le asserzioni di autenticazione attendibili dai campi arbitrari contenuti in un messaggio. Copiare una riga che dice "pass out" da un messaggio inoltrato o da uno screenshot non stabilisce che il destinatario in questione lo abbia prodotto. Registra quale destinatario ha valutato il messaggio e come l'investigatore ha ottenuto il risultato.
Mantieni il dominio Da visibile, mittente della busta dominio, dominio di firma DKIM e identità di risposta distinti. Le loro differenze possono avere spiegazioni legittime e non dovrebbero essere automaticamente ridotte a una constatazione di frode. Per DMARC , identifica il percorso di autenticazione allineato anziché considerare sufficiente ogni passaggio SPF o DKIM . Per la richiesta commerciale, esaminare l'azione richiesta e l'autorità della persona che si suppone la compia.
Un foglio di lavoro per il confronto delle identità
Preparare una riga contenente il dominio aziendale attendibile, l'etichetta di visualizzazione visibile, l'indirizzo del mittente analizzato, l'indirizzo di risposta se presente, i domini autenticati, il risultato del destinatario, la provenienza delle prove e la classificazione proposta. Aggiungi colonne per ciò che rimane sconosciuto e quale canale indipendente può verificare la richiesta. Riduci al minimo gli identificatori personali in qualsiasi versione condivisa preservando se due domini erano identici o diversi. La modifica di tutti i valori in un segnaposto distrugge la relazione che il foglio di lavoro dovrebbe mostrare.
Utilizza tre categorie provvisorie: uso del dominio esatto, imitazione del nome visualizzato e somiglianza con domini diversi. Combinazioni di permessi e una categoria non risolta. Un messaggio può utilizzare sia un nome visualizzato fuorviante che un file dominio simile. Il foglio di lavoro dovrebbe inoltre consentire la compromissione degli account autorizzati come ipotesi quando la posta allineata sembra provenire dall'organizzazione reale. La classificazione è un modo per indirizzare l'indagine, non una determinazione finale di intenti o responsabilità.
Confronto immaginario con tre messaggi
Immagina che un team finanziario immaginario riceva tre richieste insolite associate all'esempio di Northbridge. Il primo ha il dominio esatto di Northbridge, ma le prove attendibili del ricevitore indicano che non è stato effettuato alcun passaggio allineato. Il secondo utilizza il nome visualizzato del direttore finanziario con un indirizzo non correlato che autentica il proprio dominio. Il terzo utilizza un dominio dall'aspetto simile ma diverso e si autentica anche per quel dominio. Queste sono osservazioni inventate, non messaggi raccolti durante questo lavoro.
Il primo caso porta ad un'autenticazione e ad un'indagine sul percorso di invio. Il secondo porta alla verifica del nome visualizzato e dell'autorità aziendale. Il terzo porta al confronto dei domini e alla gestione della rappresentazione. Nessuno garantisce il pagamento esclusivamente perché appare un nome familiare e nessuno dovrebbe essere "risolto" aggiungendo il mittente non correlato all'indirizzo di Northbridge. Registro SPF. Se un quarto messaggio supera l'allineamento utilizzando il dominio effettivo di Northbridge, la compromissione dell'account o del servizio rimane possibile e richiede prove proprie.
Verificare la richiesta oltre il messaggio
IL Avviso BEC di posta elettronica cloud IC3, pubblicato nel 2020, raccomanda la verifica tramite metodi di contatto noti per le richieste commerciali sospette. La sua età è esplicita: supporta il controllo generale, non un'affermazione su un incidente attuale o sull'interfaccia attuale di un particolare destinatario. Utilizza un numero o un flusso di lavoro già registrato in autonomia e verifica la specifica modifica richiesta anziché limitarsi a chiedere se qualcuno ha inviato un'e-mail.
Lo scenario di abuso redatto e richiesto con prove di identità, limiti di controllo e verifica aziendale indipendente rimane insoddisfatto. Il confronto fittizio di questo manoscritto non lo soddisfa. Nessun account è stato interrogato, nessun dominio sospetto è stato visitato e nessuna parte è stata contattata. Prima del rilascio, conservare prove reali autorizzate, chiedere a un revisore qualificato di convalidare la classificazione, confermare l'applicabilità della fonte e i percorsi di produzione, completare la revisione dell'accessibilità e ottenere l'approvazione del proprietario. Il risultato dovrebbe essere una spiegazione difendibile di quale identità è stata affermata e di cosa hanno effettivamente stabilito i controlli.