Wypolerowany phishing Wiadomość może być przekonująca, ale styl jej pisania nie zmienia DMARC warunek zaliczenia. Przed podjęciem decyzji, która kontrola nie powiodła się, sprawdź tożsamość domeny i dowody uwierzytelnienia. Nie musisz udowadniać, że AI napisała tekst, aby zatrzymać nieautoryzowane żądanie biznesowe.
Oceniaj identyfikatory, a nie prozę
DMARC porównuje domenę autora z domenami uwierzytelnianymi przez SPF Lub DKIM. Do przejścia potrzebna jest co najmniej jedna przechodząca, wyrównana ścieżka. Wybór słów, gramatyka, pilność i to, czy model pomógł w przygotowaniu komunikatu, nie są danymi wejściowymi do tego testu identyfikacyjnego. RFC 9989.
Nie oznacza to, że treść nigdy nie może wpłynąć na uwierzytelnienie. DKIM podpisuje kanonizowaną treść i wybrane nagłówki. Edytowanie podpisanej wiadomości może unieważnić jej podpis. Różnica polega na zmianie bajtów po podpisaniu i utworzeniu dopracowanego tekstu przed utworzeniem prawidłowego podpisu. RFC 6376. Semantyczna ocena, czy proza brzmi jak napisana maszynowo, nie jest żadną operacją.
Oddziel trzy ścieżki nadużyć
Należący do atakującego podobna domena może uwierzytelnić się jako on sam, podszywając się pod firmę w wyświetlanym tekście. Zhakowane, legalne konto może korzystać z wyrównanej trasy wysyłania. Wiadomość żądająca dokładnej domeny bez dopasowanej ścieżki uwierzytelniania może zakończyć się niepowodzeniem DMARC . Przypadki te wymagają różnych badań technicznych, nawet jeśli treść wniosku o płatność jest identyczna.
Korzystaj z wyników zaufanego odbiorcy, a nie z oświadczeń dostarczonych przez nadawcę. Zachowaj widoczność rzeczywistego autora, domeny koperty i podpisu w aktach sprawy. Zespół ds. oszustw powinien także zachować wniosek biznesowy, żądaną zmianę i status niezależnej weryfikacji. Uwierzytelnienie nie potwierdza, że dana osoba zamierzała dokonać transferu lub go zatwierdziła.
Porównaj założenia dotyczące stałego identyfikatora
Dla każdego pisemnego przypadku załóż jedno ważne widoczne pole Od i kwalifikującą się ocenę DMARC . Porównaj zwykłe i polerowane etykiety bez zmiany jakichkolwiek danych wejściowych uwierzytelniających.
- Przypadek A: Od alerts@brand.test ; Przepustka SPF dla POCZTA OD bounce@brand.test ; NIE Podpis DKIM. DMARC przechodzi pod obiema etykietami stylu przez wyrównany SPF .
- Przypadek B: Od alerts@brand.test ; Przepustka SPF dla bounce@other.test ; DKIM przechodzi z d=other.test; załóżmy, że other.test nie jest zgodny z brand.test. Żaden uwierzytelniony identyfikator nie jest zgodny, więc DMARC nie działa w przypadku żadnej etykiety.
- Przypadek C: Z billing@lookalike.test ; Przepustka SPF dla bounce@lookalike.test ; brak podpisu DKIM . DMARC przechodzi test lookalike.test pod obiema etykietami, a nie w przypadku firmy podszywającej się w wyświetlanym tekście.
Są to narracyjne wnioski z ustalonych wyników, a nie sześć wykonanych wywołań funkcji, testy serwerów pocztowych lub testy porównawcze AI. Żaden model nie wygenerował prozy, ani detektor jej nie sklasyfikował. Przepustka SPF na poziomie komunikatu nie stanowi potwierdzenia wdrożenia wyłącznie SPF: sekcja 7.4 RFC9989 wymaga prawidłowego DKIM dla p=reject domeny.
Niezależnie zweryfikuj działanie biznesowe
W przypadku wniosku o zmianę płatności skontaktuj się z dostawcą za pośrednictwem ustalonego, niezależnego kanału i zastosuj normalny proces zatwierdzania. Nie używaj numeru telefonu podanego wyłącznie w podejrzanej wiadomości. FBI zaleca niezależną weryfikację zmian w płatnościach i koncie. Wytyczne FBI dotyczące kompromisów w zakresie biznesowej poczty elektronicznej.
Hipotetyczny scenariusz biznesowy przewiduje, że domain_pass=true, ale know_contact_confirmed=false i second_approval=false, więc proponowana reguła płatności będzie zawierać żądanie. Te pola weryfikacyjne zostały wymyślone, a nie zakończone wywołanie zwrotne. Zapisz prawdziwą autoryzowaną weryfikację przed uwolnieniem środków. Skoncentruj reakcję na ryzykownym działaniu i naruszeniu władzy, zamiast czekać na niepewne przypisanie do systemu sztucznej inteligencji.