Ein Authentifizierungsvorfall umfasst oft mehrere Uhren: das abgedeckte Intervall eines Berichts, das Eintreffen des Berichts, eine DNS Änderung, eine Anwendungsbereitstellung und einen kontrollierten Test. Sie auf einer Zeitachse zusammenzufassen ist nur dann hilfreich, wenn jedes Ereignis seine ursprüngliche Bedeutung behält. Eine tägliche Gesamtbericht Normalerweise kann ich Ihnen nicht genau sagen, wann die einzelnen enthaltenen Nachrichten fehlgeschlagen sind.
Schaffen Sie eine gemeinsame Zeitbasis
Referenzen: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Normalisieren Sie angezeigte Zeitstempel auf eine deklarierte Zeitzone und behalten Sie dabei die ursprünglichen Werte und die Genauigkeit bei. Erfassen Sie Taktquellen und bekannte Unsicherheiten. Unterscheiden Sie das Berichtsintervall von Ankunfts- und Aufnahmezeitstempeln. Eine verspätete Berichtszustellung sollte nicht als neuer Sendestoß zum Zeitpunkt des Eintreffens des Anhangs dargestellt werden.
Beschränken Sie die Untersuchung nach Möglichkeit auf eine Autorendomäne und einen verifizierten Dienst. Halten Sie nicht klassifizierte Quellen getrennt. Bewahren Sie die Melde- und Berichtsidentität, Nachrichtenanzahl, Quellgruppen und ausgewertete Identitäten sowie Entscheidungen zu Duplikaten und Überschneidungen. Diese Details bestimmen, welche Beobachtungen legitim verglichen werden können.
Fügen Sie DNS -Beweise hinzu, ohne den Verlauf neu zu schreiben
Referenzen: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
Notieren Sie die genehmigte Änderung, den geplanten Veröffentlichungszeitpunkt, maßgebliche Beobachtungen und alle Resolver-Beispiele, einschließlich Suchzeit und zurückgegebener TTL. Eine aktuelle DNS Antwort stellt fest, was diese Suche jetzt beobachtet hat; Es ist keine vollständige Geschichte dessen, was jeder Empfänger zuvor gesehen hat.
DNS Caching-Themen unten RFC 1034 §3.6; Qualifizierendes Aufschlagverhalten unten RFC 8767 §4 kann die Cache-Nutzung über die normale Frische hinaus verlängern. Behaupten Sie nicht, dass alle Empfänger zum Zeitpunkt der Veröffentlichung umgeschaltet haben oder genau ein TTL später angezeigt wurde. Behalten Sie die vorherige Konfiguration, das Änderungsprotokoll und die Nachweisgrenzen bei. Wenn ein Berichtsintervall eine Richtlinienänderung umfasst, kennzeichnen Sie es als gemischt oder potenziell gemischt, anstatt jede Beobachtung der endgültigen Richtlinie zuzuordnen.
Fügen Sie Antrags- und Empfängernachweise hinzu
Referenzen: RFC 5321 §4.2.5.
Platzieren Sie Anwendungsbereitstellungen, Gateway-Änderungen und Signaturänderungen neben den DNS Ereignissen. Behalten Sie kontrollierte Tests als Einzelbeobachtungen mit ihrem tatsächlichen Verlauf, Empfänger und Ergebnis bei. Ein Anwendungsprotokoll kann die Einreichung oder Annahme bei einem Sprung anzeigen; es begründet nicht unbedingt die endgültige Lieferung.
Verwenden Sie diese Beweistypen, um konkurrierende Erklärungen zu testen. Ein Anstieg der Fehler nach einer DNS Änderung kann auch mit einer neuen Vorlage zusammenfallen, die signierte Inhalte ändert. Durch die Korrelation wird die Untersuchung eingegrenzt, die Ursache kann jedoch ohne weitere Beweise nicht ermittelt werden.
Arbeiten Sie durch eine begrenzte Zeitleiste
Illustrativer Fall: Ein Bericht deckt den Zeitraum von 00:00 bis 24:00 UTC ab. Eine Richtlinienänderung wird um 12:00 Uhr aufgezeichnet und ein kontrollierter Test um 12:20 Uhr wird angepasst DKIM. Der Bericht enthält 80 bestandene und 20 nicht bestandene Beobachtungen und geht am nächsten Morgen um 05:00 Uhr ein.
Die Intervallsummen und den erfolgreichen Test können Sie um 12:20 Uhr bekannt geben. Sie können nicht alle 20 Fehlschläge der Zeit vor Mittag zuordnen, nur weil der Test später bestanden wurde. Die nächste Maßnahme besteht darin, engere Empfänger- oder Antragsnachweise zu erhalten oder zusätzliche repräsentative Tests durchzuführen. Das Eintreffen um 05:00 Uhr ist ein Sammelereignis, nicht der Zeitpunkt der 20 Ausfälle.
Schließen Sie mit einer kausalen Aussage über die richtige Stärke ab
Kennzeichnen Sie Schlussfolgerungen als beobachtet, bestätigt oder noch hypothetisch. Nennen Sie die Beweise, die die vermutete Ursache stützen, und etwaige konkurrierende Erklärungen, die nicht ausgeschlossen werden können. Wenn eine genaue Verknüpfung nicht möglich ist, behalten Sie die Unsicherheit bei, anstatt eine genaue Fehlergrenze in das Diagramm einzutragen.
Speichern Sie die Zeitleiste mit Quellenverweisen, Abfragerevision, enthaltenen Intervallen und Eigentumsklassifizierungen. Erfassen Sie den nächsten Verifizierungsauslöser, beispielsweise den ersten vollständigen vergleichbaren Berichtszeitraum nach einer Reparatur. Eine wiederverwendbare Zeitleiste sollte es einem anderen Analysten ermöglichen, sowohl die Fakten als auch die Grenzen der Schlussfolgerung zu rekonstruieren.
Setzen Sie die Untersuchung fort
Benutzen Sie die Komplettlösung für aggregierte Berichte für die zugrunde liegenden Felder und die Leitfaden zur Ausrichtungsdiagnose wenn der Erfolg der Rohauthentifizierung nicht zufriedenstellend ist DMARC.
Halten Sie die Illustration innerhalb ihrer Beweise
Lassen Sie für das fiktive Intervall von 80 bestandenen/20 fehlgeschlagenen Versuchen alle 20 Fehlerzeiten unbekannt. Der Test um 12:20 Uhr ist eine spätere Beobachtung und die Ankunft um 05:00 Uhr ist ein Sammelereignis. Es wurde keine echte DNS Suche oder ein Authentifizierungstest durchgeführt, und die Zeitleiste findet keine nachgewiesene kausale Umstellung.