Wiadomość przychodząca może przejść uwierzytelnienie domeny i nadal prosić odbiorcę o zrobienie czegoś niebezpiecznego. Uwierzytelnienie może również zakończyć się niepowodzeniem, ponieważ zepsuła się legalna trasa. Traktuj uwierzytelnianie jako jedną z mierzonych właściwości wiadomości, a następnie zastosuj inne mechanizmy kontrolne systemu odbierającego i proces weryfikacji biznesowej organizacji. Pominięcie tych kroków powoduje zarówno fałszywe zapewnienie, jak i niepotrzebne zakłócenia.
Wskaż trzy decyzje
Pierwsza decyzja ma charakter techniczny: czy uwierzytelniony identyfikator jest zgodny z domeną autora w ramach mających zastosowanie DMARC zasady? Drugi ma charakter operacyjny: jak środowisko odbiorcze powinno traktować komunikat, biorąc pod uwagę politykę i inne sygnały? Trzeci jest specyficzny dla danej firmy: czy żądane działanie jest zgodne z prawem i autoryzowane? RFC 9989 definiuje uwierzytelnianie i politykę opartą na domenie; nie zamienia przesłanej wiadomości w zgodę na zapłacenie faktury. Specyfikacja DMARC.
Zapisz te decyzje w oddzielnych polach. W przypadku żądania zmiany faktury pole uwierzytelniające może być pass, pole obsługi oczekuje na sprawdzenie w kwarantannie, a pole biznesowe może być niezweryfikowane. Te wartości są zgodne. Odbiorca może korzystać z sygnałów spoza DMARC , a pracownik powinien postępować zgodnie z niezależnym procesem zatwierdzania, nawet jeśli poczta została uwierzytelniona.
Użyj wyników z zaufanej granicy
Jakiś Nagłówek Authentication-Results jest użyteczny tylko wtedy, gdy jest zrozumiałe jego pochodzenie. Osoby atakujące mogą wstawić tekst nagłówka do wiadomości. Organizacja odbierająca musi odróżnić wyniki uzyskane przez jej zaufaną usługę uwierzytelniania od niezaufanych potwierdzeń. RFC 8601 opisuje tę granicę zaufania. Wyniki uwierzytelnienia.
Zachowaj nieprzetworzoną wiadomość i dzienniki zaufanego systemu odbierającego. Porównaj widoczną domenę From z każdą zweryfikowaną DKIM domena podpisująca i SPF tożsamość faktycznie oceniana. Unikaj traktowania wyświetlanej nazwy, pola Reply-To lub przekazanego zrzutu ekranu jako domeny uwierzytelnionego autora. Jeżeli wiadomość została przekazana dalej, przed podjęciem decyzji, który dowód ma zastosowanie, zapisz pierwotny punkt oceny i późniejsze przekształcenia.
Porównaj trzy żądania syntetyczne
Rozważmy trzy hipotetyczne komunikaty o zmianie płatności. Pierwszy z nich twierdzi, że jest brand.test, ale ma jedynie przechodzący podpis evil.test i nie ma przepustki SPF ; zakładany jedyny uwierzytelniony identyfikator nie jest ścisły wyrównanie. Drugi wykorzystuje brand-pay.test zarówno w tożsamości From, jak i przechodzącej tożsamości DKIM , więc jego modelowane uwierzytelnianie przebiega pomyślnie pomimo problemów związanych z wyglądem. Trzeci konsekwentnie korzysta z brand.test i również przechodzi pomyślnie, co umożliwia nadużycie konta lub nieautoryzowane żądanie.
Proponowane działanie biznesowe dla każdego przypadku to: wstrzymaj zmianę i samodzielnie ją zweryfikuj. Są to wymyślone dane wejściowe uwierzytelniania, a nie wyniki kryptograficzne lub odbiorcze. W pisemnych przypadkach zakłada się, że podane tożsamości są jedynymi dostępnymi uwierzytelnionymi identyfikatorami, izolują ścisłe dopasowanie dokładnej domeny i nie wdrażają pełnego wykrywania DMARC . Nie wykonano żadnego testu wiadomości, podpisu ani odbiorcy. Pokazuje, dlaczego działania biznesowego nie można obliczyć na podstawie samej wartości logicznej uwierzytelnienia.
Obsługa projektu bez pomijania przeglądu
Wybierz autoryzowane wiadomości testowe dla każdej ścieżki kontrolnej i zapisz, czy system je odrzucił, poddał kwarantannie, dostarczył lub później naprawił. Etykieta funkcji dostawcy nie jest dowodem skonfigurowanego zachowania. Uwzględnij wyjątki i reguły zezwalające w teście, ponieważ mogą one zmienić efektywny wynik. Unikaj szerokiego umieszczania na liście dozwolonych jedynie po to, aby przejść przez uszkodzoną, legalną trasę.
W przypadku wniosków finansowych skorzystaj z wcześniej ustalonego kanału kontaktu. FBI zaleca niezależną weryfikację wniosków o płatność i zmian w danych konta. Nie używaj danych kontaktowych wprowadzonych w podejrzanej wiadomości jako niezależnego kanału. Wytyczne FBI dotyczące kompromisów w zakresie biznesowej poczty elektronicznej.
Zakończ przegląd wszystkimi trzema decyzjami i dowodami dotyczącymi każdej nierozwiązanej kwestii. Umożliwia to zespołowi pocztowemu naprawienie uwierzytelnienia, podczas gdy finanse zatrzymują wstrzymanie płatności, lub zabezpieczeniem zbadanie przechodzącej, ale podejrzanej wiadomości bez twierdzenia, że DMARC jest wadliwy.
Źródło i granica wykonania
RFC 9989 sekcje 4.4, 5.3.5 i 5.4 rozróżnić uwierzytelnianie, dopasowanie i obsługę; przepustka nie potwierdza treści wiadomości. Decyzje operacyjne są tutaj zaleceniami o określonym zakresie i wyraźnie hipotetycznymi przykładami, a nie nowymi testami klienta, dostawcy lub wydarzenia historycznego. Każda rzeczywista zmiana wymaga własnego autoryzowanego zakresu, zachowanych dowodów i odpowiedzialnej decyzji.