Un incidente di autenticazione spesso contiene diversi orologi: l'intervallo coperto da un report, l'arrivo del report, una modifica DNS , la distribuzione dell'applicazione e un test controllato. Metterli su una sequenza temporale è utile solo se ogni evento mantiene il suo significato originale. Un quotidiano rapporto aggregato di solito non è in grado di dirti il minuto esatto in cui ciascun messaggio incluso ha avuto esito negativo.
Stabilire una base temporale comune
Riferimenti: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Normalizza i timestamp visualizzati in un fuso orario dichiarato mantenendo i valori e la precisione originali. Registrare le sorgenti dell'orologio e l'incertezza nota. Distinguere l'intervallo del report dai timestamp di arrivo e di acquisizione. La consegna tardiva del rapporto non dovrebbe essere tracciata come una nuova raffica di invii nel momento in cui è arrivato l'allegato.
Limita l'indagine a un dominio dell'autore e a un servizio verificato, ove possibile. Mantieni separate le fonti non classificate. Conserva l'identità del segnalatore e dei report, i conteggi dei messaggi, i gruppi di origine e le identità valutate, insieme alle decisioni duplicate e sovrapposte. Questi dettagli determinano quali osservazioni possono essere legittimamente confrontate.
Aggiungi prove DNS senza riscrivere la cronologia
Riferimenti: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
Registrare la modifica approvata, l'ora di pubblicazione prevista, le osservazioni autorevoli e tutti i campioni del risolutore, inclusi l'ora di ricerca e il TTL restituito. Una risposta DNS attuale stabilisce cosa ha osservato ora quella ricerca; non è una storia completa di ciò che ogni ricevitore ha visto in precedenza.
La memorizzazione nella cache DNS è importante sotto RFC 1034 §3.6; comportamento qualificante di servizio stantio sotto RFC 8767 §4 può estendere l'utilizzo della cache oltre la normale freschezza. Non affermare che tutti i ricevitori siano stati commutati al momento della pubblicazione o che esattamente uno abbia visualizzato TTL successivamente. Conserva la configurazione precedente, il registro delle modifiche e i limiti delle prove. Laddove l’intervallo di un rapporto abbraccia un cambiamento di politica, etichettatelo come misto o potenzialmente misto invece di assegnare ogni osservazione alla politica finale.
Aggiungere prove della domanda e del destinatario
Riferimenti: RFC 5321 §4.2.5.
Posiziona le distribuzioni delle applicazioni, le modifiche al gateway e le modifiche alla firma accanto agli eventi DNS . Mantieni i test controllati come osservazioni individuali con il loro percorso, ricevitore e risultato effettivi. Un registro dell'applicazione può mostrare l'invio o l'accettazione in un hop; non stabilisce necessariamente la consegna finale.
Utilizzare questi tipi di prove per testare spiegazioni concorrenti. Un aumento degli errori dopo una modifica DNS potrebbe anche coincidere con un nuovo modello che modifica il contenuto firmato. La correlazione restringe l’indagine ma non identifica la causa senza ulteriori prove.
Lavora attraverso una sequenza temporale limitata
Caso illustrativo: un rapporto copre dalle 00:00 alle 24:00 UTC. Un cambiamento di politica viene registrato alle 12:00 e un test controllato alle 12:20 supera l'allineamento DKIM. Il rapporto contiene 80 osservazioni positive e 20 negative, arrivando la mattina successiva alle 05:00.
È possibile dichiarare i totali degli intervalli e il test riuscito alle 12:20. Non è possibile attribuire tutti i 20 fallimenti a prima di mezzogiorno semplicemente perché il test è stato superato più tardi. L'azione successiva consiste nell'ottenere prove del ricevitore o dell'applicazione più ristrette o eseguire ulteriori test rappresentativi. L'arrivo alle 05:00 è un evento di raccolta, non l'orario dei 20 fallimenti.
Chiudi con un'affermazione causale della giusta forza
Etichettare le conclusioni come osservate, confermate o ancora ipotetiche. Nominare le prove a sostegno della causa sospetta e qualsiasi spiegazione concorrente non esclusa. Se il collegamento esatto è impossibile, mantenere l’incertezza anziché tracciare un limite preciso di guasto sul grafico.
Salva la sequenza temporale con riferimenti alla fonte, revisione della query, intervalli inclusi e classificazioni di proprietà. Registrare l'attivazione della verifica successiva, ad esempio il primo periodo di reporting comparabile completo dopo una riparazione. Una sequenza temporale riutilizzabile dovrebbe consentire ad un altro analista di ricostruire sia i fatti che i limiti della conclusione.
Continua l'indagine
Usa il procedura dettagliata sul report aggregato per i campi sottostanti e il guida alla diagnosi dell'allineamento quando il successo dell'autenticazione grezza non è soddisfacente DMARC.
Mantieni l'illustrazione all'interno delle sue prove
Per l'intervallo fittizio di 80 passaggi/20 fallimenti, mantenere sconosciuti tutti i 20 tempi di fallimento. Il test delle 12:20 è un'osservazione successiva e l'arrivo delle 05:00 è un evento di raccolta. Non è stata eseguita alcuna vera ricerca DNS o test di autenticazione e la sequenza temporale non individua un passaggio causale comprovato.