[ Wymagania regionalne ]

Zbadaj uwierzytelnianie w domenie banku z wyraźnymi granicami jednostek i domen

Zbadaj domeny banków, korzystając z wyraźnych mapowań instytucji, marek, filii i oddziałów, nie traktując wybranych witryn internetowych jako całego majątku nadawcy.

Przez zespół badawczy EmailAuth · 8 minut czytania

[Kluczowe punkty]

  • Użyj populacji bankowej odpowiedniej dla jurysdykcji i zachowaj jej limity.
  • Oddzielne ważenie instytucjonalne i domenowe, z uwzględnieniem wspólnych marek i oddziałów.
  • Nie wnioskuj o ryzyku klienta ani zgodności wyłącznie na podstawie publicznego DNS .
Na tej stronie

Zdefiniuj podmiot bankowy przed zmierzeniem jego domeny

Badanie domeny bankowej musi rozróżnić instytucję licencjonowaną, spółkę holdingową, markę, oddział i dostawcę usług technologicznych. Jednostki te mogą dzielić witrynę internetową lub obsługiwać różne domeny, a ich relacje mogą ulec zmianie w wyniku fuzji lub rebrandingu. Obserwacja DNS na publicznej stronie internetowej marki nie opisuje automatycznie całej bazy e-mailowej instytucji prawnej. Mapowanie podmiot-domena jest zatem częścią dowodu, a nie wstępnym szczegółem, który należy odrzucić.

W tym manuskrypcie zaproponowano metodę bez gromadzenia populacji banku lub skanowania domen. Nie zawiera żadnych twierdzeń dotyczących bezpieczeństwa, zgodności, wypłacalności lub ryzyka klienta prawdziwej instytucji. Celem jest stworzenie powtarzalnego mapowania i technicznie ograniczonego wyniku, a nie tabeli rankingowej zbudowanej na podstawie niejednoznacznych nazw marek.

Użyj organu odpowiedniego dla wybranej jurysdykcji

W przypadku ubezpieczonego banku w USA, Dokumentacja API FDIC BankFind odróżnia dane instytucji od danych o lokalizacji lub oddziale. Jest to przydatna oficjalna struktura źródłowa, a nie globalna lista wszystkich banków lub usług finansowych. Badanie obejmujące inną jurysdykcję musi uwzględniać odpowiedni organ i jego zakres. Nie należy mieszać różnych populacji regulacyjnych w ramach jednego niekwalifikowanego mianownika bankowego.

Dokumentacja FDIC stwierdza również, że główne adresy internetowe są podawane przez instytucje i że powiązane witryny znajdują się poza kontrolą FDIC. Zastrzeżenie zawarte w nim jest ważne dla interpretacji: wymieniona witryna internetowa jest wskazówką dotyczącą mapowania opartą na źródle, a nie potwierdzeniem każdej strony lub kompleksowym spisem domen nadawców. Zachowaj pochodzenie pola i datę weryfikacji, zamiast traktować pole witryny internetowej jako pełne potwierdzenie bezpieczeństwa.

Zbuduj model relacji zamiast płaskiej listy nazwisk

Utwórz osobne identyfikatory dla instytucji, grupy macierzystej, jeśli to konieczne, oddziału lub lokalizacji oraz marki publicznej. Połącz każdą próbkowaną domenę z konkretnym podmiotem i źródłem wspierającym tę relację. Rejestruj daty wejścia w życie fuzji, zmiany nazw marek i wycofanych domen. W jednym wierszu oznaczonym znaną grupą bankową można ukryć kilka licencjonowanych podmiotów i różne obowiązki operacyjne.

Zdefiniuj sposób ważenia domen współdzielonych. Liczenie każdego oddziału jako osobnego wdrożenia uwierzytelniania może dać dużej sieci oddziałów nieproporcjonalny wpływ. Licząc tylko domenę nadrzędną, można pominąć spółki zależne z niezależnymi ustaleniami dotyczącymi wysyłania. Żadne podejście nie jest z natury właściwą odpowiedzią na każde pytanie; badanie musi wybrać jednostkę i wyjaśnić jej konsekwencje przed obliczeniem jakiegokolwiek wskaźnika.

Oddziel próbki witryn internetowych od majątku nadawcy

Instytucja może używać odrębnych domen do poczty pracowniczej, powiadomień dla klientów, obsługi kart, ankiet, marketingu, rekrutacji i komunikacji zlecanej na zewnątrz. Próbka publicznej witryny internetowej zwykle nie identyfikuje ich wszystkich. Nie generuj wiarygodnych subdomen ani nie szukaj wiadomości od klientów, aby wypełnić tę lukę bez autoryzowanego zakresu badań. Mapowanie powinno wskazywać, czy domena jest witryną internetową pobraną z próby, niezależnie potwierdzonym nadawcą czy nierozstrzygniętym kandydatem.

RFC 7208 ocenia SPF przy użyciu odpowiedniej tożsamości SMTP . RFC 9989 ocenia DMARC wyrównanie do widocznej domeny From i definiuje wykrywanie zasad. Zasady te uściślają ograniczenie: publikacja w jednej domenie internetowej nie może ustanowić uwierzytelnienia wiadomości wysyłanych przez inną domenę lub trasę kontrolowaną przez dostawcę.

Zachowaj kontrolę i niepewność atrybucji

Informacje rejestracyjne mogą pomóc w udokumentowaniu związku domeny, ale nie powinny być traktowane jako dowód bieżącej kontroli operacyjnej. RFC 9083 definiuje obiekty, role i zdarzenia RDAP; RFC 9537 opisuje informacje redakcyjne, jeśli zostały wdrożone. Odpowiedź chroniona prywatnością lub niekompletna powinna pozostać ograniczeniem widoczności, a nie zarzutem, że bank ukrywa własność.

Podobnie wspólny host DNS lub dostawca wysyłający nie ustala, czy instytucje mają wspólną politykę bezpieczeństwa lub konto administracyjne. Zapisz zaobserwowaną zależność oddzielnie od wywnioskowanej kontroli. Jeśli nie można potwierdzić przypisania własności lub nadawcy, zaznacz relację jako nierozwiązaną i wyklucz ją w ramach zadeklarowanej reguły, zamiast zapewniać pewność na podstawie znanej nazwy usługi.

Zaprojektuj pomiar DNS niezależnie

Zamroź zmapowaną listę domen i określ dokładne nazwy właścicieli, typy rekordów, kontekst mechanizmu rozpoznawania nazw, znaczniki czasu, ponowne próby i wersje analizatora. Rozróżnij wyszukiwanie dokładnej nazwy od bieżącego odkrycia mających zastosowanie zasad. Zachowaj nieprzetworzone odpowiedzi i kategorie błędów, aby inny analityk mógł odtworzyć wynik. Nieudanego zapytania nie należy opisywać jako banku pozbawionego uwierzytelnienia bez odpowiednich dowodów i zakresu.

Trzymaj obserwacje autorytatywne i rekurencyjne oddzielnie, jeśli zostały zebrane. Zachowaj wiele Rekordy TXT i ciągi znaków przed wyborem protokołu. Klasyfikacja powinna określać, co zaobserwowano przy wybranej nazwie, a nie pozytywną lub negatywną ocenę całej instytucji. W tej pracy nie zebrano żadnych zapytań DNS , sond SMTP ani próbek odebranych wiadomości.

Unikaj wnioskowania o ryzyku dla konsumentów i zgodności

Sama publikacja DNS nie pokazuje, czy ujawniono informacje finansowe klientów, czy doszło do oszustwa lub czy instytucja spełniła wymogi prawne. Wnioski te wymagają innych dowodów i wykwalifikowanego przeglądu. Brakująca lub nieważna obserwacja dotycząca polityki może uzasadniać ustalenie techniczne w zakresie badania, nie stając się jednocześnie twierdzeniem o bezpieczeństwie usług banku.

Nie należy klasyfikować instytucji według uproszczonego wyniku uwierzytelniania, chyba że miara, waga i ograniczenia są przejrzyste i uzasadnione. Polityka żądająca egzekwowania nie dowodzi, że każdy legalny strumień jest zgodny lub że zapobiega się wszelkim podszyciom. W badaniu nie należy sugerować, że zaobserwowane niższe ustawienie bezpośrednio przewiduje stratę finansową klienta.

Arkusz mapowania encja-domena

Utwórz kolumny dla jurysdykcji, źródła organu, daty źródła, identyfikatora instytucji, typu podmiotu, relacji nadrzędnej, marki, powiązania z oddziałem i domeny próbkowanej. Dodaj dowody połączenia domeny, daty obowiązywania, pewność mapowania, rolę domeny, plan zapytań i wykluczenia. Zachowaj tabelę relacji, gdy odwzorowania jeden do wielu nie mogą być wiernie reprezentowane w jednym wierszu.

Pakiet wersji powinien obejmować mapowanie, pochodzenie źródła, znormalizowane dane wejściowe zapytań, nieprzetworzone obserwacje i zasady klasyfikacji. Recenzent powinien być w stanie prześledzić opublikowane ustalenia aż do instytucji i dokładnej domeny, nie zgadując, o jaką markę lub spółkę zależną chodziło. Wrażliwe dane klientów, dane konta i prywatne informacje o pracownikach są niepotrzebne w przypadku tej metody i nie można ich zbierać w celu jej upiększenia.

Fikcyjna diagnoza: strona internetowa grupy staje się każdą spółką zależną

Fikcyjny badacz wybiera publiczną witrynę internetową grupy bankowej i jako wynik raportuje zaobserwowaną politykę dla każdej spółki zależnej. Z przeglądu map wynika, że ​​lista źródłowa wyróżnia kilka instytucji, podczas gdy dowody domeny obsługują jedynie witrynę grupy. Proponowana korekta polega na opublikowaniu obserwacji w węższym serwisie internetowym i oznaczeniu szerszego majątku nadawcy jako niezmierzonego.

Zespół mógł później uzyskać autoryzowane dowody w domenie zależnej i rozszerzyć zakres w ramach poprawionej wersji zbioru danych. Nie powinno to wypełniać luk domyślonymi nazwami ani sugerować luki w zabezpieczeniach, ponieważ mapowanie jest niekompletne. Ten scenariusz jest fikcyjny i nie zawiera żadnych zarzutów dotyczących prawdziwego banku, domeny, skanu ani zgodności.

Stan wydania

Katalog wymaga publikacji mapowania podmiot-domena i rozróżnienia między próbkowanymi domenami internetowymi a szerszą grupą nadawców. To oryginalne mapowanie pozostaje 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 przedstawia projekt badania specyficzny dla banku, a nie zapełniony zbiór danych lub ustalenia dotyczące instytucji.

[Na wynos]

Przed interpretacją obserwacji uwierzytelnienia domeny bankowej opublikuj relację i zakres podmiot-domena.

[ Według roli ]

Co to oznacza dla Ciebie

Wybierz swoją rolę, aby uzyskać praktyczne dalsze kroki.

Badacz bankowości

Zidentyfikuj podmiot objęty regulacją

Marka lub oddział niekoniecznie jest tą samą jednostką liczącą co instytucja.

Kolejne kroki

  1. Zachowaj identyfikatory organów.
  2. Śledź fuzje i zmieniaj daty.

Analityk domenowy

Powiązany przykład domeny internetowej

Główna witryna internetowa nie jest kompletnym spisem poczty.

Kolejne kroki

  1. Oznacz role domeny.
  2. Zachowaj widoczne nierozwiązane atrybucje.

Recenzent redakcyjny

Unikaj nieuzasadnionych twierdzeń o ryzyku

Wyniki DNS nie potwierdzają strat finansowych ani braku zgodności.

Kolejne kroki

  1. Przejrzyj język wrażliwy na zarzuty.
  2. Wymagaj dowodów w przypadku szerszych roszczeń nadawcy-majątku.

[ Często zadawane pytania ]

Często zadawane pytania

Czy dane FDIC obejmują każdy bank na świecie?

Nie. Dane dotyczące instytucji i lokalizacji stanowią przykład dotyczący konkretnej jurysdykcji; inne populacje potrzebują odpowiednich źródeł.

Pakiet FDIC BankFind: Dokumentacja API

Czy linki do witryn internetowych FDIC stanowią kompletny spis nadawców?

Nie. Dokumentacja mówi, że główne adresy internetowe są podawane przez instytucje i uwzględniają ograniczenia odpowiedzialności za powiązane witryny.

Pakiet FDIC BankFind: Dokumentacja API

Czy każdą gałąź można liczyć jako niezależne wdrożenie?

Tylko w ramach projektu wyraźnie obciążonego gałęziami; domeny współdzielone w przeciwnym razie powodują powtarzające się obserwacje techniczne.

Czy witryna nadrzędna ustanawia uwierzytelnianie pomocnicze?

Nie. Mapowanie musi obsługiwać każdą zadeklarowaną jednostkę i relację domeny.

Czy RDAP może udowodnić aktualną własność operacyjną?

Nie samodzielnie. Role, wydarzenia i ograniczenia redakcyjne muszą pozostać widoczne.

RFC 9083 : Odpowiedzi JSON dla RDAP

Czy brak polisy świadczy o ryzyku finansowym klienta?

Nie. Dowody DNS nie potwierdzają narażenia, oszustwa ani zgodności z prawem.

Czy banki zostały przeskanowane lub sklasyfikowane?

Nie. Nie zebrano żadnego zbioru danych oryginalnej instytucji ani obserwacji technicznych.

Jakie dowody z publikacji pozostają otwarte?

Mapowanie podmiot-domena i wyraźne rozróżnienie między domenami internetowymi a szerszą grupą nadawczą pozostają otwarte.

[ Źródła ]

Źródła

  1. RFC 9989: DMARC

    Sekcje §4.7 Format rekordu polityki DMARC · §4.8 Definicja formalna · §4.10 Przegląd drzewa DNS · §5.3.2 Ustalenie, czy ma zastosowanie mechanizm DMARC · §4.4 Wyjaśnienie wyrównania identyfikatorów · A.6 Usunięcie znacznika pct

  2. RFC 7208 : Ramy zasad dotyczących nadawców

    Sekcje §2.4 POCZTA OD Tożsamości · §3.2 Wiele rekordów DNS · §4.5 Wybieranie rekordów · §4.6.4 Limity wyszukiwania DNS · §5.2 dołączenie · §6.1 przekierowanie · §8 Obsługa wyników

  3. RFC 9083 : Odpowiedzi JSON dla RDAP

    Sekcje §4 Wspólne struktury danych · §5.1 Klasa obiektu Entity · §5.3 Klasa obiektu Domain

  4. RFC 9537 : Zredagowane pola w odpowiedziach RDAP

    Sekcje §3 Metody redagowania · §4 Zredagowana odpowiedź RDAP

  5. Pakiet FDIC BankFind: Dokumentacja API

    Sekcje Przegląd · Pliki definicji API: definicje API instytucji i lokalizacji · Za chwilę opuścisz FDIC.gov: zastrzeżenie dotyczące głównego adresu internetowego

[ Słowniczek ]

Słowniczek

Jednostka instytucjonalna
Podmiot bankowy zidentyfikowany przez wybrany organ, odrębny od oddziału lub marki.

Pakiet FDIC BankFind: Dokumentacja API

Podstawowe mapowanie witryny
Poparty źródłem link do publicznej witryny internetowej, a nie pełne potwierdzenie dotyczące nadawcy.

Pakiet FDIC BankFind: Dokumentacja API

Majątek nadawcy
Zestaw rzeczywistych przepływów pracy i tożsamości wysyłania, które wymagałyby oddzielnych autoryzowanych dowodów.
Niepewność atrybucji
Ograniczenie w łączeniu domeny publicznej lub zależności od kontroli operacyjnej.

RFC 9537 : Zredagowane pola w odpowiedziach RDAP

Pochodzenie przedsiębiorstwa

Dlaczego najlepsze instytucje finansowe i rządy wycofali swoje panele bezpieczeństwa poczty e-mail.

Tradycyjne platformy uwierzytelniania poczty e-mail oferują pulpit nawigacyjny i proszą inżynierów o wykonanie pracy. W środowiskach o dużej stawce ręczny nadzór oznacza opóźnione egzekwowanie, zmianę konfiguracji i niemonitorowane domeny-cienie.

EmailAuth to platforma agentowego pochodzenia wiadomości e-mail. Nasi agenci egzekwują p=reject, dostosuj zewnętrznych nadawców i przenieś swoje domeny do pełnych adresów RFC 9989 zgodność, nowy standard DMARC , z możliwością kontroli przez człowieka.

Rządy Duże przedsiębiorstwa Instytucje finansowe poziomu 1

SaaS · Dedykowany najem · Lokalne rozwiązanie typu air-gapped · Szyfrowanie BYOK

Baza wiedzy