Behandeln Sie die Zahlungsautorität als separate Frage
Die E-Mail eines Lieferanten kann korrekt authentifiziert sein und dennoch eine nicht autorisierte Zahlungsänderungsanforderung enthalten. Ein kompromittiertes Postfach oder eine kompromittierte Anwendung nutzt möglicherweise die legitime Sendeinfrastruktur des Anbieters, während ein Imitator möglicherweise eine andere Domäne mit einem vertrauten Anzeigenamen verwendet. Die unmittelbare geschäftliche Frage ist, ob die angeforderte Änderung autorisiert ist, und nicht, ob die Nachricht das Wort „pass“ enthält. Halten Sie die finanzielle Entscheidung von der technischen Untersuchung getrennt, sodass keines das andere ersetzt.
RFC 9989 Grenzen DMARC auf Domänenauthentifizierungsbeziehungen und schließt ausdrücklich die Inhaltsanalyse und Authentifizierung anderer Entitäten als Domänen aus. Es kann keine Änderung eines Bankkontos genehmigen oder die Absichten eines Mitarbeiters eines Lieferanten feststellen. Ein positives Ergebnis ist ein nützlicher Beweis für die Domain-Nutzung, es handelt sich jedoch nicht um eine Zahlungsanweisung, der die Organisation Folge leisten muss. Dieses Manuskript schlägt einen Verteidigungsprozess vor; Es wurde keine Zahlung, Kontoaktualisierung oder externer Kontakt durchgeführt.
Behalten Sie die Anfrage bei, ohne sie auszuführen
Halten Sie die angeforderte Änderung im bestehenden Einkaufs- oder Finanzprozess zurück. Notieren Sie, was in der Nachricht geändert werden soll, welchen Lieferantendatensatz sie betrifft, wann die Änderung wirksam werden soll und wer sie erhalten hat. Vermeiden Sie es, vollständige Finanzdetails in ein allgemein zugängliches Vorfallticket zu kopieren. Ein genehmigter eingeschränkter Datensatz kann das Original bewahren, während die Arbeitszusammenfassung die Änderung mithilfe einer Referenzkennung und des minimal erforderlichen Kontexts beschreibt.
Behalten Sie die ursprüngliche Botschaft und ihre Herkunft bei. Eine weitergeleitete Kopie oder ein Screenshot kann helfen, zu zeigen, wie die Anfrage aussah, sie ist jedoch nicht mit der Originalnachricht oder den Empfängerprotokollen austauschbar. Notieren Sie die Abholzeit und die Zeitzone. Wenn jemand bereits gehandelt hat, eskalieren Sie es über das in der Organisation etablierte Verfahren für Finanzvorfälle, anstatt davon auszugehen, dass die Änderung stillschweigend rückgängig gemacht werden kann. Dieser Artikel gestattet keine Überweisungen, Rückrufe oder Kommunikation mit einer Bank.
Stellen Sie fest, welche Identität verwendet wurde
Vergleichen Sie die tatsächliche Von-Domäne mit der Lieferantendomäne im Datensatz des vertrauenswürdigen Lieferanten. Behalten Sie den Anzeigenamen, die Antwortadresse, die Umschlagidentität usw. bei DKIM Domain separat signieren. Eine Nachricht einer anderen Domäne kann sich für die eigene Domäne authentifizieren und den Leser über die Zugehörigkeit irreführen. Eine exakte Anbieter-Domain-Nachricht mit angepasster Authentifizierung kann immer noch von einem missbrauchten Konto oder Dienst stammen. Wählen Sie die Kompromisshypothese nicht nur deshalb, weil die Anfrage ungewöhnlich ist.
Verwenden Sie bei der Interpretation der Authentifizierung vertrauenswürdige Empfängernachweise. RFC 8601 erklärt warum Authentication-Results Felder erfordern eine Vertrauensgrenze. Eine vom Absender bereitgestellte Zeile, ein Screenshot oder ein weitergeleiteter Header-Auszug begründen möglicherweise nicht die Bewertung des jeweiligen Empfängers. Notieren Sie, welcher Empfänger das Ergebnis erzeugt hat und welcher ausgerichtete Pfad beobachtet wurde. Wenn die Beweise unvollständig sind, sagen Sie dies, anstatt eine Gut-oder-Schlecht-Schlussfolgerung in die Finanzentscheidung einzubeziehen.
Überprüfen Sie dies über eine etablierte unabhängige Route
Der IC3-Cloud-E-Mail-BEC-Beratung, veröffentlicht am 6. April 2020, empfiehlt die unabhängige Überprüfung verdächtiger Geschäftsanfragen. Verwenden Sie einen Lieferantenkontaktweg, der vor der fragwürdigen Anfrage eingerichtet wurde, z. B. den vorhandenen verifizierten Lieferantendatensatz der Organisation. Eine neue Telefonnummer, alternative E-Mail-Adresse oder ein Bestätigungslink, der nur in dieser Nachricht angegeben wird, stellt keine unabhängige Quelle dar. Das zitierte Gutachten unterstützt dieses allgemeine Prinzip und nicht eine aktuelle Behauptung eines Vorfalls.
Bitten Sie den autorisierten Unternehmensprüfer, die konkret vorgeschlagene Änderung durch den festgelegten Prozess zu bestätigen. Die Bestätigung, dass eine Person den Absendernamen erkennt, ist schwächer als die Bestätigung, dass die Änderung selbst angefordert und genehmigt wurde. Wenn Richtlinien separate Genehmiger erfordern, bewahren Sie diese Trennung auf. Lassen Sie nicht zu, dass die Dringlichkeit in der Nachricht die Genehmigungsanforderungen der Organisation ersetzt. Der technische Analyst kann Identitätsnachweise vorlegen, sollte aber nicht stillschweigend zum Finanzgenehmiger werden.
Koordinieren Sie die technische Untersuchung sorgfältig
Wenn Beweise auf einen Missbrauch des Lieferantenkontos hinweisen, kommunizieren Sie über einen zugelassenen verifizierten Kontakt und geben Sie nach der Autorisierung nur die relevanten redigierten Beweise weiter. Der autorisierte Responder des Lieferanten ist für die Untersuchung seiner Systeme verantwortlich. Die empfangende Organisation sollte nicht behaupten, dass sie eine Lieferantenübernahme nachgewiesen hat, nur weil eine Nachricht authentifiziert wurde und der Lieferant die Zahlungsaufforderung abgelehnt hat. Eine Integration, ein delegierter Sender oder ein anderer Mechanismus erfordert möglicherweise eine Untersuchung.
Anleitung von Microsoft zum Umgang mit kompromittierten Konten listet verdächtige Posteingangsregeln, Weiterleitungen und fehlende Nachrichten als mögliche Indikatoren auf und beschreibt die Kontoreaktion für Microsoft 365 . Dabei handelt es sich um eine Referenz für einen autorisierten Lieferanten, der in dieser Umgebung reagiert, und nicht um die Erlaubnis, die Konten einer anderen Organisation zu prüfen. Kein Kontozugriff, Sitzungswiderruf, Regellöschung oder Anmeldedatenerfassung ist Teil der Arbeit dieses Manuskripts.
Ein Arbeitsblatt zum Nachweis von Zahlungsänderungen
Erstellen Sie ein Arbeitsblatt mit vier verknüpften Abschnitten. Im Anforderungsabschnitt werden die Lieferantenreferenz, der Änderungstyp, das angeforderte Datum und der Geschäftsinhaber erfasst. Der Identitätsabschnitt zeichnet tatsächliche Domänen, vertrauenswürdige Authentifizierungsbeobachtungen und die Beweisquelle auf. Im Verifizierungsbereich werden der unabhängig festgelegte Kontaktweg, der autorisierte Prüfer sowie die genaue Frage und Antwort erfasst. Im Entscheidungsabschnitt werden die Genehmigung oder Ablehnung, die erforderlichen Genehmiger, der zulässige Implementierungspfad und alle ungelösten Untersuchungen erfasst.
Halten Sie Finanzkonto-IDs von Kopien für allgemeine Zwecke fern. Verwenden Sie konsistente Platzhalter, wenn ein Vergleich wichtig ist, und bewahren Sie das vollständige Original nur an einem zugelassenen, eingeschränkten Ort auf. Fügen Sie eine Spalte hinzu, in der beobachtete Fakten von Hypothesen unterschieden werden. „Bei unserem Empfänger beobachtete auf die Domäne des Anbieters ausgerichtete DKIM “ ist nur dann eine Tatsache, wenn die Beweise dies belegen; „Mitarbeiter des Lieferanten hat der Änderung zugestimmt“ erfordert eine gesonderte geschäftliche Bestätigung. Das Arbeitsblatt sollte Ersteres niemals automatisch in Letzteres umwandeln.
Fiktive Diagnose: ein bekannter Lieferantenthread
Ein fiktives Facility-Team erhält in einem etablierten Lieferantengespräch eine Anfrage mit der Bitte, zukünftige Zahlungsdetails zu ändern. Die Nachricht verwendet die echte Domain des Anbieters und leitet hypothetisch DMARC an den Empfänger weiter. Der Empfänger geht davon aus, dass der vorhandene Thread und das Authentifizierungsergebnis die Änderung sicher machen. Stattdessen unterbricht ein zweiter Prüfer die Aktualisierung und überprüft den genehmigten Lieferantendatensatz auf die festgelegte Verifizierungsroute.
In der Übung verweigert der Lieferantenkontakt die Genehmigung der Änderung. Diese Antwort unterstützt die Ablehnung der Anfrage im Rahmen des Geschäftsprozesses, der Mechanismus bleibt jedoch ungelöst, bis autorisierte technische Beweise verfügbar sind. Die Untersuchung würde die Nachricht bewahren und eine minimale genehmigte Zusammenfassung weitergeben, anstatt die vollständigen Zahlungsdetails weithin weiterzuleiten. Hierbei handelt es sich um ein fiktives Szenario, nicht um ein echtes Dementi, eine Kompromissfindung, einen Verifizierungsanruf oder einen verhinderten Verlust. Es zeigt, warum Unternehmensverifizierung und Domänenauthentifizierung unterschiedliche Fragen beantworten.
Schließen Sie die finanziellen und technischen Spuren getrennt ab
Notieren Sie die Anordnung der angeforderten Änderung, auch wenn die technische Untersuchung noch andauert. Erklären Sie umgekehrt nicht, dass das Geschäftsproblem gelöst ist, nur weil ein Konto gesichert wurde: Möglicherweise hat jemand bereits einen Lieferantendatensatz geändert oder auf die Anfrage reagiert. Gleichen Sie die tatsächlichen Geschäftsunterlagen mit der autorisierten Entscheidung ab und dokumentieren Sie, wer das Ergebnis überprüft hat. Jede solche Aktion erfordert die normale Autorität der Organisation; hier wurde keine durchgeführt.
Der Katalog erfordert ein redigiertes Missbrauchsszenario mit Identitätsnachweis, Kontrollgrenze und unabhängiger Geschäftsüberprüfung. Der ursprüngliche Beweis bleibt offen. Das vorgeschlagene Arbeitsblatt und die fiktive Übung genügen ihm nicht. Auch die Prüfung durch menschliche Spezialisten, die Anwendbarkeit der Quelle, die Produktionswege, die Zugänglichkeit und die Freigabe durch den Eigentümer bleiben offen. Eine veröffentlichungsfähige Version erfordert ein autorisiertes Beweispaket, das den Verifizierungsprozess demonstriert, ohne finanzielle Kennungen preiszugeben oder unbegründete Behauptungen über einen Lieferanten zu erheben.