Un messaggio in entrata può superare l'autenticazione del dominio e chiedere comunque al destinatario di fare qualcosa di pericoloso. Può anche fallire l'autenticazione perché un percorso legittimo si è interrotto. Tratta l'autenticazione come una proprietà misurata di un messaggio, quindi applica gli altri controlli del sistema ricevente e il processo di verifica aziendale dell'organizzazione. Il fallimento di questi passaggi produce sia false rassicurazioni che inutili interruzioni.
Identificare le tre decisioni
La prima decisione è tecnica: un identificatore autenticato è allineato con il dominio dell'autore nell'applicabile DMARC regole? Il secondo è operativo: come dovrebbe questo ambiente ricevente gestire il messaggio, considerando la politica e altri segnali? Il terzo è specifico dell'azienda: l'azione richiesta è legittima e autorizzata? RFC 9989 definisce l'autenticazione e la politica basata sul dominio; non trasforma un messaggio di passaggio in approvazione al pagamento di una fattura. Specifica DMARC.
Registra queste decisioni in campi separati. Per una richiesta di modifica della fattura, il campo di autenticazione potrebbe essere superato, il campo di gestione messo in quarantena in attesa di revisione e il campo aziendale non verificato. Questi valori sono compatibili. Un destinatario può utilizzare segnali esterni DMARC e un dipendente deve seguire il flusso di lavoro di approvazione indipendente anche quando la posta è stata autenticata.
Utilizza i risultati di un confine attendibile
UN Intestazione Authentication-Results è utile solo quando se ne comprende la provenienza. Gli aggressori possono inserire il testo dell'intestazione in un messaggio. L'organizzazione ricevente deve distinguere i risultati prodotti dal proprio servizio di autenticazione affidabile dalle asserzioni non attendibili. RFC 8601 descrive quel confine di fiducia. Risultati dell'autenticazione.
Conserva il messaggio non elaborato e i registri del sistema ricevente attendibile. Confronta il dominio Da visibile con ciascuno verificato DKIM dominio di firma e il file SPF identità effettivamente valutata. Evita di considerare il nome visualizzato, il campo Rispondi a o uno screenshot inoltrato come dominio dell'autore autenticato. Se il messaggio è stato inoltrato, registrare il punto di valutazione originale e le successive trasformazioni prima di decidere quale prova applicare.
Confronta tre richieste sintetiche
Consideriamo tre ipotetici messaggi di modifica del pagamento. Il primo dichiara brand.test ma ha solo una firma evil.test superabile e nessun pass SPF ; il presunto unico identificatore autenticato non è rigoroso allineamento. Il secondo utilizza brand-pay.test sia in From che nella sua identità DKIM di passaggio, quindi la sua autenticazione modellata supera nonostante il problema della somiglianza. Il terzo utilizza brand.test in modo coerente e lo supera, rendendo possibile un abuso dell'account o una richiesta non autorizzata.
L'azione aziendale proposta per ciascun caso è: trattenere la modifica e verificarla in modo indipendente. Si tratta di input di autenticazione inventati, non di risultati crittografici o del ricevitore. I casi scritti presuppongono che le identità dichiarate siano gli unici identificatori autenticati disponibili, isolano la rigorosa corrispondenza esatta del dominio e non implementano il rilevamento DMARC completo. Non è stato eseguito alcun messaggio, firma o test del destinatario. Dimostra perché l'azione aziendale non può essere calcolata solo dal valore booleano di autenticazione.
Gestione della progettazione senza bypassare la revisione
Scegli i messaggi di test autorizzati per ciascun percorso di controllo e registra se il sistema li ha rifiutati, messi in quarantena, consegnati o successivamente corretti. L'etichetta della funzionalità di un fornitore non è una prova del comportamento configurato. Includi eccezioni e consenti regole nel test perché possono modificare il risultato effettivo. Evitare un'ampia lista di consentiti semplicemente per far passare un percorso legittimo interrotto.
Per richieste finanziarie utilizzare un canale di contatto precedentemente stabilito. L'FBI consiglia di verificare in modo indipendente le richieste di pagamento e le modifiche ai dettagli dell'account. Non utilizzare i dettagli di contatto introdotti dal messaggio sospetto come canale indipendente. Guida alla compromissione delle e-mail aziendali dell'FBI.
Chiudi una revisione con tutte e tre le decisioni, le prove per ogni questione irrisolta. Ciò consente al team di posta di riparare l'autenticazione mentre il dipartimento finanziario mantiene la sospensione del pagamento o la sicurezza di indagare su un messaggio sospetto ma di passaggio senza dichiarare che DMARC è difettoso.
Confine di origine e di esecuzione
RFC 9989 Sezioni 4.4, 5.3.5 e 5.4 distinguere autenticazione, allineamento e gestione; un passaggio non approva il contenuto del messaggio. Le decisioni operative qui sono raccomandazioni mirate ed esempi esplicitamente ipotetici, non nuovi test di un cliente, fornitore o appuntamento storico. Qualsiasi cambiamento reale richiede un proprio ambito autorizzato, prove conservate e una decisione responsabile.