Rejestr ryzyka związany z uwierzytelnianiem poczty elektronicznej powinien wyjaśniać, która usługa biznesowa może zostać naruszona i jaka decyzja zmniejsza to ryzyko. „DMARC brak” to ustalenie techniczne, a nie pełne zestawienie ryzyka. Połącz warunek z wiarygodnym zagrożeniem lub ścieżką awarii, procesem, którego to dotyczy, istniejącymi zabezpieczeniami i odpowiedzialnym właścicielem.
Opisz usługę i scenariusz
Dla każdego wpisu zapisz usługę, domenę, właściciela aplikacji, stan techniczny, czas dowodu i prawdopodobne konsekwencje. Zachowaj wyraźną niepewność. Niezauważony nadawca stanowi lukę w dowodach, podczas gdy zweryfikowany, niewyrównany legalny nadawca stanowi wadę uwierzytelniania. Żadna z nich nie dowodzi automatycznie, że osoba atakująca wykorzystała usługę.
RFC 9989 określa uwierzytelnianie domeny i wyrównanie zachowanie. Jego zabezpieczenia nie zapewniają, że każde uwierzytelnione żądanie jest uzasadnione. Rejestr ryzyka musi odróżniać bezpośrednie podszywanie się pod Twoją domenę od przejętego autoryzowanego konta lub: podobna domena który przechodzi uwierzytelnianie dla siebie.
Oddziel ryzyko nieodłączne i pozostałe
Opisz scenariusz przed kontrolami, a następnie wyjaśnij, co zmienia każde istniejące zabezpieczenie. W przypadku instrukcji dotyczących faktury weryfikacja wywołania zwrotnego płatności może rozwiązać fałszywe żądania biznesowe, których samo uwierzytelnienie domeny nie jest w stanie rozwiązać. Nie sugeruj, że istnienie pisemnych zasad dotyczących oddzwonień dowodzi, że ludzie konsekwentnie ich przestrzegają.
Skorzystaj z uzgodnionych w organizacji definicji prawdopodobieństwa i wpływu. Unikaj przedstawiania wymyślonej precyzji, takiej jak roczne prawdopodobieństwo oszustwa wynoszące 17,3% bez dowodów. Jeżeli dane są niewystarczające, należy zastosować rating jakościowy wraz z uzasadnieniem i czynnikiem wywołującym przegląd. Zapisz, kto jest upoważniony do zaakceptowania pozostałego ryzyka, zamiast traktować zgodę techniczną administratora poczty jako akceptację biznesową.
Skorzystaj z połączonego przykładu
Załóżmy, że hipotetyczny wpis R-1 dotyczy płac. Warunkiem jest brak aktualnych dowodów o wyrównanym przebiegu w zarejestrowanej usłudze krytycznej. Potencjalną konsekwencją są brakujące powiadomienia dotyczące listy płac, jeśli nieprzetestowana trasa nie powiedzie się podczas egzekwowania. Jest to scenariusz warunkowy, a nie twierdzenie, że pracownicy przegapili wiadomości. Dział finansów jest właścicielem usługi, zespół pocztowy jest właścicielem dochodzenia, a zamknięcie wymaga aktualnego testu trasy oraz potwierdzenia właściciela usługi.
R-2 obejmuje podszywanie się pod osobę chcącą zapłacić fakturę za pośrednictwem domeny wyglądającej należącej do atakującego. Proponowana kontrola polega na niezależnej weryfikacji poprzez już zaufaną drogę kontaktu. Opublikowanie silniejszej polityki w domenie ofiary nie spełnia testu końcowego R-2. Dla każdego wpisu wymagaj ustalenia, właściciela, decyzji i wyraźnego dowodu zamknięcia, zanim potraktujesz proponowany rejestr jako kompletny. Jest to zalecana zasada przeglądu, a nie przeprowadzona walidacja lub dowód, że kontrola działa.
Zadbaj o to, aby rejestr działał
Wybierz wyraźnie leczenie: napraw, unikaj ryzykownych działań, w stosownych przypadkach przenieś określoną ekspozycję lub zaakceptuj pozostałe ryzyko w drodze autoryzowanego procesu decyzyjnego. Ustaw termin i wyzwalacz przeglądu. Plan leczenia nie jest dowodem jego ukończenia; zachować osobno aktualny zapis testu lub decyzji.
Te hipotetyczne wpisy ilustrują różne scenariusze, niezaobserwowane ataki lub zaakceptowane ryzyko biznesowe. Przegląd kompletności może zidentyfikować brakujące pola, ale nie może potwierdzić oceny ryzyka ani ustalić, czy działają rzeczywiste zabezpieczenia. Rzeczywisty dowód i zatwierdzoną decyzję o przyjęciu należy przechowywać oddzielnie od proponowanego leczenia.
Przeglądaj rejestr po migracji, nowych nadawcach, incydentach i zmianach biznesowych. Zamknij tylko konkretny scenariusz, którego dowody spełniają podany test, i zachowaj wystarczającą ilość historii, aby wyjaśnić, dlaczego został zamknięty.
NIST SP 800-30 Rev. 1 sekcje 2.3 i 3.2 opisują czynniki ryzyka, podejścia do oceny i dokumentowanie wyników oceny. Wspierają wyraźne określenie prawdopodobieństwa, wpływu i niepewności; powyższe pola rejestru dotyczące poczty e-mail i przykłady są propozycją zastosowania, a nie zalecaną listą kontrolną zgodności. Przewodnik po ocenie ryzyka.