Un messaggio autenticato può comunque contenere una richiesta fraudolenta. Questa affermazione non regge SPF, DKIM O DMARC non importante. Definisce il loro confine.
L'autenticazione della posta elettronica fornisce prove sulle identità del dominio e sulla gestione dei messaggi. L'autorizzazione aziendale risponde a una domanda diversa: questa persona o sistema aveva il diritto di presentare questa richiesta e l'organizzazione dovrebbe agire di conseguenza? Un processo sicuro ha bisogno di entrambi.
Chiedi cosa dimostra effettivamente il pass
Sotto RFC 9989 §5.3.5 E RFC 9989 §5.4, un passaggio DMARC a livello di messaggio significa che il destinatario ha trovato almeno un percorso SPF o DKIM di passaggio il cui dominio autenticato è allineato al dominio in Da. Non dimostra:
- quale individuo controllava il conto;
- che l'account non è stato compromesso;
- che una fattura o un cambio bancario siano legittimi;
- che un collegamento o un allegato è innocuo;
- che il dominio è il brand che il destinatario aveva in mente.
È utile l'affermazione precisa: il messaggio presentava un dominio Da e produceva prove di autenticazione qualificanti relative a quel dominio. Evitare di convertirlo nell'affermazione più ampia che il mittente o il messaggio sono sicuri.
Classificare l'abuso di identità prima di scegliere una risposta
Attacchi diversi possono sembrare simili in una casella di posta ma posizionarsi su lati diversi del confine di autenticazione.
- Modello: falsificazione del dominio esatto; Cosa può mostrare l'autenticazione: Nessun percorso di passaggio allineato, soggetto all'evidenza e alla gestione del destinatario; Focus su controllo e risposta: politica DMARC , copertura del mittente, controlli e indagine del destinatario
- Modello: Dominio simile; Cosa può mostrare l'autenticazione: il sosia può autenticare con successo il proprio dominio; Focus di controllo e risposta: monitoraggio del dominio, segnali degli utenti, filtraggio, segnalazione e azione proporzionata in caso di abuso
- Modello: inganno del nome visualizzato; Cosa può mostrare l'autenticazione: un dominio non correlato può autenticarsi presentando un nome familiare; Focus su controllo e risposta: analisi del nome visualizzato, contesto, reporting utente e verifica indipendente
- Modello: account autorizzato compromesso; Cosa può mostrare l'autenticazione: il dominio reale può superare l'autenticazione; Focus su controllo e risposta: sicurezza dell'account, indagine su sessioni e accessi, contenimento e verifica aziendale
- Modello: Fornitore compromesso; Cosa può mostrare l'autenticazione: può passare il dominio reale del fornitore; Focus su controllo e risposta: coordinamento degli incidenti dei fornitori, controlli delle transazioni e conferma del canale alternativo
DMARC è più efficace contro l'uso non autorizzato dell'identità del dominio che copre. Non crea la proprietà di domini visivamente simili, non verifica la veridicità di un nome visualizzato né decide se un account reale è stato utilizzato con la dovuta autorizzazione.
Segui un episodio immaginario di modifica del pagamento
Lo scenario seguente è sintetico. È progettato per mostrare la catena delle prove senza implicare un incidente del cliente.
Un impiegato finanziario riceve una richiesta da accounts@supplier.example chiedendo di modificare le coordinate bancarie. Supponendo una policy applicabile, i risultati del destinatario attendibile mostrano un pass DKIM allineato per supplier.example, quindi il messaggio passa DMARC . Anche la storia del thread e lo stile di scrittura appaiono familiari.
Il dipendente non approva la modifica sulla base di tali segnali. Chiamano un numero di fornitore precedentemente verificato e scoprono che la casella di posta è stata compromessa. L'organizzazione congela la modifica richiesta, conserva il messaggio originale e fornisce al fornitore timestamp e relative intestazioni.
L'autenticazione ha funzionato come previsto: ha dimostrato che il messaggio utilizzava il dominio autenticato del fornitore. Il controllo di verifica indipendente ha bloccato una transazione non autorizzata che l'autenticazione del dominio non ha potuto giudicare.
Conservare le prove del protocollo e le prove aziendali
Per un incidente consequenziale, conservare un messaggio originale ad accesso controllato prima di produrre una copia oscurata. RFC 8601 §7.1 definisce i limiti dei risultati attendibili; le modifiche al materiale firmato possono influire sulla nuova verifica ai sensi RFC 6376 §3.7. Prove tecniche utili possono includere l'attendibilità Authentication-Results, campi ricevuti pertinenti, Da, Rispondi a, Return-Path, firme DKIM , identificatori di messaggi, timestamp e registri di ricezione.
Prove aziendali utili includono la richiesta, l'azione prevista, le regole di approvazione stabilite, il metodo di contatto utilizzato per la verifica e l'esito. Mantieni i fatti separati dalle inferenze. Un primo passaggio non è una prova di compromissione e un fallimento DMARC non è una prova che si sia verificato un danno.
Sotto RFC 9990 §3.1, i report DMARC aggregati possono aiutare i proprietari di domini a comprendere i modelli di autenticazione e disposizione osservati. Non costituiscono una registrazione completa dei singoli messaggi e solitamente non forniscono il contenuto necessario per decidere se una particolare richiesta è stata autorizzata. Sotto RFC 9989 §5.3.9, segnalazioni di guasti, quando generati, richiedono un'attenta gestione della privacy e degli accessi e non sono universalmente disponibili.
Integra una verifica indipendente nei flussi di lavoro sensibili
Le azioni ad alto impatto dovrebbero utilizzare controlli che non dipendano esclusivamente dal messaggio in arrivo. Gli esempi includono:
- verificare le modifiche dei dati bancari attraverso un canale precedentemente approvato;
- richiedere la doppia approvazione per i pagamenti superiori alle soglie definite;
- impedire a un thread di posta elettronica di fornire sia la richiesta che il contatto di verifica;
- utilizzo di portali autenticati per lo scambio di dati sensibili;
- trattare la segretezza urgente, i tempi inusuali o l’aggiramento del controllo come segnali di rischio.
Si tratta di controlli aziendali, non di sostituti dell'autenticazione. L'autenticazione riduce l'ambiguità sull'uso del dominio, mentre i controlli delle transazioni riducono le conseguenze di una richiesta autenticata ma non autorizzata.
Comunicare i confini senza indebolire il programma
Dicendo che DMARC non si ferma tutti phishing la tecnica è accurata. Dire che sia quindi inefficace non lo è. Una policy applicata può ridurre l'uso non autorizzato di un dominio protetto, migliorare le prove del destinatario e rendere esplicita la proprietà dei percorsi di invio legittimi.
Il messaggio giusto è stratificato: proteggere il dominio, proteggere gli account, rilevare sosia e presentazioni ingannevoli e verificare in modo indipendente le azioni sensibili. Usa il Guida all'identità DMARC per il risultato a livello di dominio e il inventario del mittente per la titolarità del servizio autorizzato.
Mantieni la conclusione all'interno delle prove
Il caso immaginario di modifica del pagamento mantiene due risultati indipendenti: autenticazione del dominio superata; l'operazione proposta non è stata approvata dopo separata verifica. Non segnalare la compromissione derivante da un solo passaggio. Conserva solo le divulgazioni di incidenti autorizzati e mantieni un contatto di verifica affidabile al di fuori della richiesta in arrivo. Nessun fornitore è stato contattato e non è stata fornita alcuna risposta a transazioni o incidenti.