Una politica di rifiuto può essere una parte utile della protezione di un dominio di invio. Non può stabilire che ogni messaggio ricevuto da una persona sia sicuro, che ogni destinatario intraprenda la stessa azione o che un mittente autenticato agisca onestamente.
La questione pratica non è se un dominio abbia raggiunto una particolare etichetta politica. Riguarda quale percorso di rappresentazione viene indirizzato al controllo e quali prove supportano la decisione successiva. Un programma di sicurezza ha bisogno che tale limite venga dichiarato chiaramente prima che una percentuale del dashboard diventi una richiesta di gestione.
Descrivere l'identità controllata
Sotto RFC 9989 §5.3.5, DMARC valuta l'utilizzo del dominio nell'indirizzo Da visibile contro passaggio, allineato SPF O DKIM prova. Una policy si applica a quella relazione di dominio. Non autentica un nome visualizzato, non approva una richiesta di pagamento né giudica un sito Web collegato; RFC 9989 §5.4 chiarisce che l'uso del dominio convalidato non è un'asserzione di valore su un messaggio.
Una politica di rifiuto esprime la valutazione richiesta dal proprietario del dominio per i messaggi che non superano la convalida. La gestione finale del ricevente dipende anche dalla sua stessa analisi. RFC 9989 RFC 9989 §7.4 richiede specificamente ai destinatari di considerare qualcosa di più di una politica di rifiuto pubblicata, in particolare quando è coinvolta la posta indiretta legittima.
Questi limiti non rendono il controllo irrilevante. Rendono misurabile la sua copertura. Utilizzo la guida alla selezione delle politiche per collegare la policy allo scopo effettivo del dominio.
Prova quattro diverse storie di attacco
Gli scenari seguenti sono illustrativi. Non si tratta di incidenti dei clienti o di risultati di attacchi misurati.
- Scenario: un mittente utilizza il dominio del mittente esatto di un'organizzazione senza un'identità allineata di passaggio; Cosa può mostrare l'evidenza del dominio: il fallimento DMARC può informare la gestione secondo la policy applicabile; Il controllo è ancora necessario: analisi del destinatario, monitoraggio e risposta agli incidenti
- Scenario: un mittente utilizza un dominio diverso con un nome visualizzato esecutivo convincente; Cosa può mostrare l'evidenza del dominio: quel dominio diverso può autenticarsi con successo; È ancora necessario il controllo: rilevamento della rappresentazione e segnalazione degli utenti
- Scenario: un account legittimo viene preso in consegna e inviato tramite un percorso approvato; Cosa può mostrare l'evidenza del dominio: il messaggio potrebbe avere un'autenticazione allineata valida; Il controllo è ancora necessario: sicurezza e indagini sull'account
- Scenario: un fornitore invia un messaggio autenticato richiedendo una modifica fraudolenta del conto bancario; Cosa può dimostrare l'evidenza del dominio: l'utilizzo del dominio da parte del fornitore può essere convalidato; Il controllo è ancora necessario: verifica indipendente della modifica dei pagamenti
Un solo”phishing Il numero bloccato" nasconderebbe queste differenze. Etichettare i test per identità, percorso e controllo previsto. Per un esercizio sicuro, utilizzare account di prova autorizzati e contenuto sintetico; non è necessario esporre un destinatario reale a un'istruzione fraudolenta per stabilire il limite del protocollo.
Controlla la posta legittima prima di modificare la politica
Una politica restrittiva può influenzare la comunicazione legittima la cui autenticazione è mancante o le cui identità sono disallineate. Inventaria ogni servizio aziendale, il suo proprietario e l'account o il percorso che lo invia. Aggiungi la prova del messaggio ricevuto insieme allo stato DNS .
Una matrice di preparazione sintetica potrebbe mostrare la fatturazione verificata, il supporto verificato e un avviso fiscale trimestrale ancora in attesa di un test di invio. La decisione di rilascio corretta è quella di risolvere il flusso critico mancante, non di mediarlo perché la fatturazione rappresenta la maggior parte del volume.
Tratta le fonti sconosciute come irrisolte finché le prove non le identificano. Un fornitore di servizi cloud familiare non dimostra l'approvazione e una riga di report non riuscita non dimostra un attacco. Un inventario del mittente gestito dà a quelle indagini un posto dove approdare.
Account per inoltro e mailing list
Un messaggio può lasciare il suo percorso originale attraverso un alias, un forwarder o una mailing list. L'inoltro cambia la fonte di connessione vista dal ricevitore finale sotto RFC 7208 §10.3; le modifiche ai contenuti coperti possono influire sulla verifica DKIM ai sensi RFC 6376 §3.7. L'errore risultante potrebbe riguardare un messaggio legittimo.
Attuale RFC 9989 §7.4 mette in guardia contro il rifiuto di domini generici i cui utenti possono postare su mailing list Internet. Richiede inoltre che il rifiuto di pubblicazione dei domini applichi firme DKIM valide anziché affidarsi esclusivamente a SPF . Un dominio transazionale e un dominio di corrispondenza del personale possono quindi richiedere decisioni politiche diverse.
Un test consegnato tramite uno spedizioniere è la prova di quel percorso e di quel tempo. Non stabilisce che ogni elenco, ricevitore o modifica futura si comporti in modo identico. Registrare sia il percorso di lavoro che l'incertezza.
Mantieni il record della modifica legato al reclamo
Prima di una modifica alla policy approvata, conserva il record precedente, la differenza proposta, l'ambito del dominio, il proprietario, le prove esaminate e l'azione di ripristino. Successivamente, confronta i flussi legittimi osservati, gli errori restituiti e i report disponibili. Registrare i risultati effettivi anziché dare per scontato che una pubblicazione DNS riuscita dimostri una comunicazione riuscita.
Per un esercizio sintetico, la nota di modifica potrebbe dire che un dominio di ricezione dedicato è stato preso in considerazione per una valutazione più approfondita dopo che i suoi servizi noti e le rotte indirette sono stati esaminati. Non si dovrebbe dire che tutto il phishing sia stato eliminato. Le prove supportano una decisione su quel dominio e sui suoi flussi di posta documentati.
Riportare il rischio residuo in un linguaggio utile
Una chiara dichiarazione di gestione nomina il dominio, la popolazione monitorata, i servizi legittimi verificati, la politica attuale e i restanti punti deboli. Mantiene i risultati dei domini contraffatti separati dalla compromissione dell'account, domini simili e frode nelle transazioni.
Utili azioni di follow-up includono la rimozione di permessi di invio obsoleti, il miglioramento della protezione dell'account, la convalida di richieste sensibili attraverso un canale indipendente noto e il mantenimento di un processo di segnalazione per la posta sospetta. Tali azioni affrontano diversi percorsi di fallimento; il loro valore non dovrebbe essere attribuito al Registro DMARC solo.
Il risultato a cui mirare è preciso: l'uso legittimo del dominio Da scelto viene compreso e mantenuto, vengono indagati i guasti e la politica si adatta all'uso del dominio. Mantieni visibili gli scenari di frode rimanenti in modo che una politica di dominio più forte non diventi una falsa promessa su ogni messaggio.
Registrare una decisione che può essere rivista
Per i quattro scenari, mantenere risultati separati per errore del dominio esatto, dominio autenticato diverso, presa in carico del conto e una richiesta di modifica del pagamento autenticata. Non sommarli in una richiesta di successo DMARC non qualificata. I controlli di follow-up proposti sono raccomandazioni operative, non garanzie o requisiti del protocollo DMARC . Non è stato eseguito alcun incidente, simulazione di attacco o implementazione di policy.