Zbuduj argumentację wokół wykazanych ulepszeń kontroli
A DMARC uzasadnienie biznesowe może wyjaśnić widoczność, zarządzanie nadawcami i ochronę przed konkretnym nieautoryzowanym użyciem domeny, bez zastanawiania się, w jakim stopniu udało się zapobiec oszustwom. Najmocniejszy przypadek łączy zaobserwowany problem z proponowaną zmianą kontroli, identyfikuje uzasadnione przepływy pracy związane z wysyłaniem, na które może to mieć wpływ, i określa, w jaki sposób wynik zostanie zweryfikowany. Nie przekształca każdej odrzuconej wiadomości w zapobieżoną stratę finansową lub obietnicę, której uwierzytelnienie eliminuje kompromis dotyczący poczty biznesowej.
RFC 9989 stwierdza, że DMARC dotyczy określonych form domeny dokładnej fałszowanie, a nie domeny podobne wizualnie, ataki nazw wyświetlanych lub analiza treści. Ograniczenia te należą do uzasadnienia biznesowego, a nie tylko do załącznika technicznego. W artykule zaproponowano metodę planowania opartą na dowodach. Nie zmieniono żadnej polityki, nie sprawdzono nadawcy, nie oszacowano strat ani nie podjęto żadnych zobowiązań finansowych.
Opisz problem bazowy wraz z jego granicami pokrycia
Zacznij od domen i legalnych procesów wysyłania, o których wie organizacja. Rejestruj, które usługi są własnością, które są nierozwiązane i które ścieżki uwierzytelniania mają dowody. Zachowaj skonfigurowaną intencję oddzielnie od obserwowanych wyników odbiornika. Lista SPF I DKIM rekordy nie są dowodem na to, że każdy przepływ pracy wykorzystuje je prawidłowo, natomiast przechodząca próbka nie pozwala na ustalenie pełnego zasięgu wszystkich wiadomości e-mail i odbiorców.
RFC 9990 definiuje zagregowane raportowanie, które może wnieść uwagi dotyczące uwierzytelniania. Sprawozdania te są cennym dowodem, należy jednak podać ich źródło i okres. Brakujące raporty nie świadczą o braku ruchu. Nieznani nadawcy mogą obejmować nieautoryzowaną aktywność, zapomniane legalne systemy lub niepełną interpretację. Sklasyfikuj je z dowodami, zanim użyjesz ich wyliczeń w uzasadnieniu biznesowym.
Oddziel cele od roszczeń finansowych
Przydatne cele mogą obejmować przypisywanie właścicieli do legalnych nadawców, ograniczanie nierozwiązanych błędów uwierzytelniania, ustanawianie sprawdzonych zasad i poprawę powtarzalności weryfikacji zmian. Każdy powinien mieć określoną miarę, okres odniesienia i źródło dowodów. Cel może mieć charakter operacyjny lub związany z bezpieczeństwem i nie ma charakteru pieniężnego. Uzasadnienie biznesowe nie staje się słabe tylko dlatego, że odmawia sfabrykowania strat, którym udało się zapobiec.
Jeśli potrzebny jest model finansowy, wykorzystaj zatwierdzone dane wejściowe organizacji i ujawnij założenia. Czas personelu, koszty subskrypcji i wysiłek wdrożeniowy można zmierzyć za pomocą odpowiednich zapisów, ale tutaj ich nie zmierzono. Hipotetyczna strata pomnożona przez liczbę odrzuconych wiadomości nie stanowi dającego się obronić szacunku oszczędności. Wiadomość mogłaby nigdy nie dotrzeć do osoby, nie wywołać działania ani nie spowodować straty, nawet bez proponowanej polityki. Scenariusz alternatywny wymaga dowodów, a nie retorycznej pewności.
Zbuduj matrycę gotowości nadawcy po nadawcy
Utwórz wiersz dla każdego uzasadnionego przepływu pracy z celem biznesowym, właścicielem, widoczną z domeny, oczekiwaną kopertą i tożsamością podpisu, bieżącymi dowodami, nierozwiązanymi awariami i zależnością od zmian. Zapisz zamierzoną dopasowaną ścieżkę uwierzytelniania w obszarze RFC 9989. Odróżnij twierdzenie dostawcy, że funkcja jest włączona, od obserwacji rzeczywistej autoryzowanej próbki dokonanej przez zaufanego odbiorcę. Do tego projektu nie pobrano żadnej próbki.
Matryca powinna identyfikować, które przepływy pracy są gotowe dla proponowanej polityki, a które wymagają naprawy lub udokumentowanego wyjątku. Unikaj traktowania wysokiego łącznego wskaźnika przepustowości jako dowodu na to, że niewielki, ale krytyczny przepływ pracy jest bezpieczny. Proces rozliczeń lub odzyskiwania niewielkich kwot może mieć znaczenie komercyjne, nawet jeśli w niewielkim stopniu wpływa na mianownik. Gotowość powinna zatem uwzględniać wpływ i zasięg biznesowy, a nie tylko ogólny odsetek.
Określ różnicę zasad i autoryzację
Zapisz proponowaną zmianę jako dokładną różnicę zasad w odniesieniu do domeny, której dotyczy problem, zamierzonego zachowania, warunków wstępnych i decyzji o wdrożeniu. Polityka powinna odzwierciedlać bieżący standard i faktyczne zastosowanie odbiorcy, a nie kopiować dotychczasowe założenia. Zidentyfikuj, kto jest właścicielem publikacji DNS , kto zatwierdza ryzyko biznesowe i kto weryfikuje wynik. Zalecenie techniczne samo w sobie nie stanowi upoważnienia do zmiany produkcji.
Udokumentuj kryteria zatrzymania i wycofania przed wykonaniem. Dostosowanie zasad może mieć wpływ na legalną pocztę, jeśli założenia dotyczące gotowości są błędne, natomiast przywrócenie wartości DNS może nie zastąpić natychmiast obserwacji w pamięci podręcznej ani nie cofnąć już obsłużonej poczty. Nie obiecuj wdrożenia bez ryzyka. Zachowaj poprzednią konfigurację i informacje o usługach zależnych, aby upoważniony operator mógł podjąć uzasadnioną decyzję o przywróceniu danych, jeśli uzasadniają to faktyczne dowody.
Zdefiniuj dowody po zmianie na prawej granicy
Zaplanuj zebranie wiarygodnych dowodów publikacji, zaufanych obserwacji otrzymanych wiadomości dla reprezentatywnych przepływów pracy i zagregowanych trendów w odpowiednio określonym okresie. RFC 8601 wyjaśnia dlaczego Authentication-Results dowód musi pochodzić z granicy zaufanego odbiorcy. Skopiowana linia przejścia bez pochodzenia nie wystarczy, aby udowodnić, że zamierzona ścieżka działała po zmianie.
Jeśli to możliwe, przejrzyj także diagnostykę dostawy dostawcy, ale zachowaj jej znaczenie. Odniesienie do zdarzenia SendGrid definiuje dostarczenie jako pomyślne dostarczenie do serwera odbierającego, a nie umieszczenie w skrzynce odbiorczej lub odczyt przez człowieka. Takie dowody mogą pomóc w odróżnieniu zmian w zakresie uwierzytelniania od innych problemów z dostawą, bez udowadniania przyczynowego wzrostu wyników biznesowych. Zapisz inne jednoczesne zmiany, które mogłyby wyjaśnić zaobserwowaną tendencję.
Arkusz uzasadnienia biznesowego
Utwórz sekcje dla obserwowanej linii bazowej, ograniczeń zasięgu, problemu operacyjnego, proponowanej różnicy w polityce, gotowości nadawcy, właścicieli, zatwierdzeń, oczekiwanych korzyści, wysiłku wdrożeniowego, ryzyka i planu weryfikacji. Trzymaj zmierzone wartości, założenia i niezmierzone wyniki w widoczny sposób oddzielone. Dołącz pole decyzyjne dla nierozwiązanych nadawców krytycznych i określone kryterium kontynuowania lub wstrzymywania. Arkusz powinien raczej sprawiać, że niepewność będzie możliwa do zastosowania, a nie ją ukrywać.
W przypadku każdej deklarowanej korzyści zapytaj, jakie dowody ją potwierdzają, a jakie zaprzeczają. Większą własność nadawcy można wykazać poprzez ukończoną inwentaryzację i zatwierdzenia. Ulepszony wyrównanie pokrycie wymaga porównywalnych obserwacji i stabilnych definicji. Zapobiegnięte oszustwom lub stratom finansowym wymaga znacznie silniejszej podstawy przyczynowej i nie należy ich wnioskować wyłącznie na podstawie protokołów. Proponowane ramy nie zawierają rzeczywistych obliczeń ROI ani sfabrykowanych statystyk wydajności.
Fikcyjna diagnoza: kusząca liczba strat, którym udało się zapobiec
Fikcyjny zespół projektowy widzi wiele wiadomości w kategorii raportów, którą uważa za nieautoryzowaną, i proponuje pomnożenie tej liczby przez średnią kwotę oszustwa. Recenzent odrzuca kalkulację, ponieważ zbiór danych nie określa, ile wiadomości zostałoby dostarczonych, przeczytanych, uwierzonych lub podjętych zgodnie z nimi. Nie rozstrzygnięto jeszcze, czy każde źródło w danej kategorii jest nieautoryzowane.
Proponowana zmiana koncentruje się na możliwych do sprawdzenia wynikach: uzupełnieniu odpowiedzialności nadawcy, rozwiązaniu uzasadnionych błędów, zatwierdzeniu zmiany polityki i zachowaniu dowodów po zmianie. Jeśli organizacja uzyska później niezależnie dane dotyczące incydentów i dane finansowe, wykwalifikowany właściciel może ocenić, czy jakiekolwiek dodatkowe roszczenie jest uzasadnione. Ten scenariusz jest fikcyjny; nie zaobserwowano ani nie obliczono żadnych raportów, kwot oszustw, strat, którym udało się zapobiec, ani oszczędności w ramach projektu.
Podaj, czego DMARC nie zastępuje
The Doradztwo BEC dotyczące poczty elektronicznej IC3 w chmurze, opublikowany w 2020 r., umożliwia niezależną weryfikację nietypowych wniosków biznesowych i ochronę kont. Kontrole te pozostają istotne, ponieważ zhakowane autoryzowane konto może wysyłać uwierzytelnioną pocztę, a inna domena może podszywać się pod firmę, nie naruszając własnego uwierzytelnienia. Uzasadnienie biznesowe DMARC powinno uwzględniać uzupełniające kontrole, a nie twierdzić, że je zastąpią.
Katalog wymaga matrycy gotowości poszczególnych nadawców, różnic w zasadach, zapisu zatwierdzeń i wyników po zmianie. Te oryginalne artefakty pozostają otwarte. Otwarte pozostają także przegląd specjalistów, możliwość zastosowania źródeł, trasy produkcji, dostępność i zezwolenie właściciela. Niniejsza wersja robocza zapewnia ramy dowodowe i fikcyjne ćwiczenia, a nie ukończone wdrożenie czy gwarancję finansową. Publikacja wymaga zatwierdzonych dowodów operacyjnych i twierdzeń ograniczonych do tego, co te dowody faktycznie wykazują.