Eine authentifizierte Nachricht kann immer noch eine betrügerische Anfrage enthalten. Diese Aussage trifft nicht zu SPF, DKIM oder DMARC unwichtig. Es definiert ihre Grenze.
Die E-Mail-Authentifizierung liefert Beweise über Domänenidentitäten und die Nachrichtenverarbeitung. Die Geschäftsgenehmigung beantwortet eine andere Frage: War diese Person oder dieses System berechtigt, diesen Antrag zu stellen, und sollte die Organisation entsprechend handeln? Ein sicherer Prozess braucht beides.
Fragen Sie, was der Pass tatsächlich beweist
Unter RFC 9989 §5.3.5 Und RFC 9989 §5.4bedeutet ein DMARC -Pass auf Nachrichtenebene, dass der Empfänger mindestens einen passierenden SPF oder DKIM Pfad gefunden hat, dessen authentifizierte Domäne mit der Domäne in From übereinstimmt. Es beweist nicht:
- welche Person das Konto kontrolliert hat;
- dass das Konto nicht kompromittiert wurde;
- dass eine Rechnungs- oder Bankänderung legitim ist;
- dass ein Link oder Anhang harmlos ist;
- dass es sich bei der Domain um die Marke handelt, die der Empfänger im Sinn hatte.
Die genaue Aussage ist nützlich: Die Nachricht stellte eine Von-Domäne dar und lieferte einen qualifizierten Authentifizierungsnachweis für diese Domäne. Vermeiden Sie es, es in die umfassendere Behauptung umzuwandeln, dass der Absender oder die Nachricht sicher sei.
Klassifizieren Sie den Identitätsmissbrauch, bevor Sie eine Antwort auswählen
Verschiedene Angriffe können in einem Posteingang ähnlich aussehen, aber auf unterschiedlichen Seiten der Authentifizierungsgrenze angesiedelt sein.
- Muster: Fälschung exakter Domains; Was die Authentifizierung zeigen kann: Kein ausgerichteter Durchgangsweg, vorbehaltlich der Beweise und Handhabung durch den Empfänger; Kontroll- und Reaktionsschwerpunkte: DMARC Richtlinie, Absenderabdeckung, Empfängerkontrollen und Untersuchung
- Muster: Lookalike-Domäne; Was die Authentifizierung zeigen kann: Das Lookalike kann seine eigene Domäne erfolgreich authentifizieren. Kontroll- und Reaktionsschwerpunkte: Domänenüberwachung, Benutzerhinweise, Filterung, Meldung und angemessene Maßnahmen gegen Missbrauch
- Muster: Täuschung durch Anzeigenamen; Was die Authentifizierung zeigen kann: Eine unabhängige Domäne kann sich unter Angabe eines bekannten Namens authentifizieren. Kontroll- und Reaktionsschwerpunkt: Analyse des Anzeigenamens, Kontext, Benutzerberichte und unabhängige Überprüfung
- Muster: Kompromittiertes autorisiertes Konto; Was die Authentifizierung zeigen kann: Die echte Domäne kann die Authentifizierung bestehen; Kontroll- und Reaktionsschwerpunkt: Kontosicherheit, Sitzungs- und Anmeldeuntersuchung, Eindämmung und Geschäftsüberprüfung
- Muster: Kompromittierter Lieferant; Was die Authentifizierung zeigen kann: Die echte Domain des Anbieters kann passieren; Kontroll- und Reaktionsschwerpunkt: Koordinierung von Lieferantenvorfällen, Transaktionskontrollen und Bestätigung über alternative Kanäle
DMARC ist am stärksten gegen unbefugte Nutzung der von ihm abgedeckten Domain-Identität. Es begründet weder den Besitz visuell ähnlicher Domänen, noch überprüft es die Richtigkeit eines Anzeigenamens oder entscheidet, ob ein echtes Konto mit der entsprechenden Berechtigung verwendet wurde.
Verfolgen Sie einen fiktiven Zahlungsänderungsvorfall
Das folgende Szenario ist synthetisch. Es soll die Beweiskette zeigen, ohne dass ein Kundenvorfall impliziert wird.
Ein Finanzmitarbeiter erhält eine Anfrage von accounts@supplier.example Bitte um Änderung der Bankdaten. Unter der Annahme einer anwendbaren Richtlinie zeigen die Ergebnisse vertrauenswürdiger Empfänger einen abgestimmten DKIM Pass für supplier.example, sodass die Nachricht DMARC passiert. Auch der Threadverlauf und der Schreibstil kommen mir bekannt vor.
Der Mitarbeiter stimmt der Änderung aufgrund dieser Signale nicht zu. Sie rufen eine zuvor verifizierte Lieferantennummer an und erfahren, dass die Mailbox kompromittiert wurde. Die Organisation friert die angeforderte Änderung ein, behält die ursprüngliche Nachricht bei und stellt dem Lieferanten Zeitstempel und relevante Header zur Verfügung.
Die Authentifizierung funktionierte wie vorgesehen: Es zeigte sich, dass die Nachricht die authentifizierte Domäne des Anbieters verwendete. Die unabhängige Überprüfungskontrolle stoppte eine nicht autorisierte Transaktion, die durch die Domänenauthentifizierung nicht beurteilt werden konnte.
Bewahren Sie Protokollbeweise und Geschäftsbeweise auf
Bewahren Sie für einen Folgevorfall eine zugriffskontrollierte Originalnachricht auf, bevor Sie eine redigierte Kopie erstellen. RFC 8601 §7.1 definiert vertrauenswürdige Ergebnisgrenzen; Änderungen an signiertem Material können sich auf die erneute Überprüfung auswirken RFC 6376 §3.7. Zu den nützlichen technischen Beweisen können die vertrauenswürdigen gehören Authentication-Results, relevante Felder „Empfangen“, „Von“, „Antwort an“, Return-Path, DKIM Signaturen, Nachrichtenkennungen, Zeitstempel und Empfangsprotokolle.
Zu den nützlichen Geschäftsnachweisen gehören die Anfrage, die beabsichtigte Aktion, festgelegte Genehmigungsregeln, die zur Überprüfung verwendete Kontaktmethode und das Ergebnis. Halten Sie Fakten von Schlussfolgerungen getrennt. Ein Rohdurchlauf ist kein Beweis für eine Kompromittierung, und ein DMARC Fehler ist kein Beweis dafür, dass ein Schaden entstanden ist.
Unter RFC 9990 §3.1, können aggregierte DMARC Berichte Domaininhabern dabei helfen, beobachtete Authentifizierungs- und Dispositionsmuster zu verstehen. Sie stellen keine vollständige Aufzeichnung einzelner Nachrichten dar und liefern in der Regel nicht den Inhalt, der für die Entscheidung darüber erforderlich ist, ob eine bestimmte Anfrage genehmigt wurde. Unter RFC 9989 §5.3.9, Fehlerberichte, sofern sie generiert werden, erfordern einen sorgfältigen Umgang mit Datenschutz und Zugriff und sind nicht allgemein verfügbar.
Integrieren Sie eine unabhängige Überprüfung in sensible Arbeitsabläufe
Bei Aktionen mit großer Wirkung sollten Steuerelemente verwendet werden, die nicht ausschließlich von der eingehenden Nachricht abhängen. Beispiele hierfür sind:
- Überprüfung von Änderungen der Bankdaten über einen zuvor genehmigten Kanal;
- Für Zahlungen über definierten Schwellenwerten ist eine doppelte Genehmigung erforderlich;
- Verhindern, dass ein E-Mail-Thread sowohl die Anfrage als auch den Verifizierungskontakt übermittelt;
- Nutzung authentifizierter Portale für den Austausch sensibler Daten;
- Dringende Geheimhaltung, ungewöhnliches Timing oder Kontrollumgehungen werden als Risikosignale behandelt.
Hierbei handelt es sich um geschäftliche Kontrollen und nicht um einen Ersatz für die Authentifizierung. Die Authentifizierung reduziert Unklarheiten über die Domänennutzung, während Transaktionskontrollen die Folgen einer authentifizierten, aber nicht autorisierten Anfrage verringern.
Kommunizieren Sie die Grenze, ohne das Programm zu schwächen
Ich sage, dass DMARC nicht jeden stoppt Phishing Die Technik ist genau. Zu sagen, dass es daher unwirksam sei, ist nicht der Fall. Eine durchgesetzte Richtlinie kann die erfolgreiche unbefugte Nutzung einer geschützten Domäne reduzieren, den Nachweis des Empfängers verbessern und den Besitz legitimer Sendepfade deutlich machen.
Die richtige Botschaft ist vielschichtig: Domäne schützen, Konten sichern, Doppelgänger und irreführende Darstellungen erkennen und vertrauliche Aktionen unabhängig überprüfen. Benutzen Sie die DMARC Identitätsleitfaden für das Ergebnis auf Domänenebene und die Absenderbestand für autorisiertes Serviceeigentum.
Halten Sie die Schlussfolgerung innerhalb der Beweise
Der fiktive Zahlungsänderungsfall hat zwei unabhängige Ergebnisse: Domänenauthentifizierung bestanden; Die geplante Transaktion wurde nach gesonderter Prüfung nicht genehmigt. Melden Sie keine Kompromittierung allein durch einen Pass. Bewahren Sie nur autorisierte Offenlegungen von Vorfällen auf und behalten Sie einen vertrauenswürdigen Verifizierungskontakt außerhalb der eingehenden Anfrage bei. Es wurde kein Lieferant kontaktiert und es wurde keine Transaktion oder Reaktion auf Vorfälle durchgeführt.