Kompromis DKIM klucz prywatny może pozwolić osobie atakującej na utworzenie podpisów weryfikujących w domenie podpisującej, której dotyczy problem. Traktuj wydarzenie jako incydent związany z władzą podpisującą. Zastąpienie rekordu DNS to tylko jeden z elementów zabezpieczenia, a sama weryfikacja DKIM nie jest w stanie odróżnić autoryzowanego podpisującego od atakującego posiadającego ten sam klucz.
Ustal organ, którego to dotyczy
Zidentyfikuj domenę podpisującą, selektory, opiekuna klucza i każdą usługę korzystającą z klucza prywatnego. Zachowaj odpowiednie dzienniki audytu, konfigurację i reprezentatywne podejrzane wiadomości bez kopiowania sekretu do zgłoszeń lub czatu. Zapisz czas odkrycia, prawdopodobny czas narażenia oraz to, co jest wiadome i co podejrzewa.
Oddziel kradzież klucza prywatnego od nieautoryzowanego dostępu do usługi podpisywania. Osoba atakująca mająca dostęp do konta może kontynuować podpisywanie po zmianie klucza, chyba że dostęp ten zostanie ograniczony. Kompromis w zakresie administracji DNS to kolejna zależność wymagająca własnej reakcji. Koordynuj te dochodzenia pod nadzorem właściciela zdarzenia.
Zatrzymaj nowe nadużycia i unieważnij starą ścieżkę weryfikacji
Zawieś dotknięte trasy podpisywania lub poświadczenia w ramach zatwierdzonego procesu incydentów. RFC 6376 pozwala na unieważnienie poprzez opublikowanie pustej wartości p. Wyjęcie klucza uniemożliwia także jego pomyślne odzyskanie, gdy jego brak jest widoczny. Wybierz odpowiedź obsługiwaną przez platformę i zweryfikuj dokładną selektor i domenę przed jej zmianą.
Odwołanie nie jest natychmiastowe dla każdego odbiornika. Buforowane dane DNS i wiadomości już ocenione tworzą granicę zależną od czasu. Nie obiecuj, że zmiana DNS z mocą wsteczną unieważni podpisy w dostarczanej poczcie lub udowodni, że nie przyjęto żadnych obraźliwych wiadomości.
Normalne nakładanie się rotacji pozwala na weryfikację poprawnych wiadomości umieszczonych w kolejce. Podczas kompromisu umożliwienie sprawdzenia ujawnionego klucza może również chronić możliwości atakującego. Właściciel incydentu musi rozważyć zabezpieczenie przed awariami opóźnionych przesyłek pocztowych, zamiast automatycznie stosować rutynowy harmonogram nakładania się.
Przywróć podpisywanie czystą ścieżką
Wygeneruj kluczowy materiał zastępczy w ramach zaufanego procesu po usunięciu przyczyny narażenia. Preferuj nowy obsługiwany selektor, aby można było rozróżnić stare i nowe dowody. Zastosuj aktualne wymagania kryptograficzne. Do podpisywania RSA dokument RFC 8301 wymaga rsa-sha256 zamiast rsa-sha1 i zaleca co najmniej 2048-bitowy klawiatura.
Przykładowa odpowiedź: selektor Sales1 został ujawniony i jego konto podpisywania zostało zabezpieczone. Czysty podpisujący używa sprzedaży2, podczas gdy sprzedaż1 jest odwołana. Nowa poczta kontrolowana potwierdza sprzedaż2 i jest zgodna z Od; opóźniona poczta podpisana przez sales1 może się nie powieść. Ten przykład opisuje wyraźny kompromis, a nie ukończony incydent lub gwarancję uniwersalnego zachowania odbiorcy.
Sprawdź odzysk i zachowaj niepewność
Przetestuj każdą trasę, której dotyczy problem, a nie tylko jedną skrzynkę pocztową. Zapisz surowe wiadomości i zaufane wyniki, sprawdź nowy selektor, potwierdź wyrównanie i sprawdź, czy naruszone poświadczenia nie upoważniają już do podpisywania. Przejrzyj dzienniki dostawców i raporty odbiorców za okres narażenia, zwracając uwagę, że raporty nie obejmują każdego odbiorcy ani nie potwierdzają, kto wysłał każdą wiadomość.
Utrzymuj harmonogram powstrzymywania, obserwacji DNS , wdrażania zamienników i oceny wpływu na klienta. Kontroluj dostęp do kopii kryminalistycznych. Zamykaj incydent tylko ze zidentyfikowanym właścicielem w celu pozostałego dochodzenia i skorygowania problemu przechowywania kluczy lub błędu dostępu. Pomyślny nowy podpis dowodzi, że droga odzyskiwania działa; samo w sobie nie ustala pełnego zakresu wcześniejszego nadużycia.
Ćwicz na blacie przed sytuacją awaryjną
Na tej syntetycznej osi czasu konto usługi A utrzymuje sprzedaż1, a czyste konto B utrzymuje sprzedaż2. W minucie zerowej zawiera A. W pierwszej minucie opublikuj wycofanie sprzedaży 1. W drugiej minucie fikcyjny mechanizm rozpoznawania nazw nadal ma swój stary klucz w pamięci podręcznej, więc stare podpisy mogą pozostać w nim możliwe do zweryfikowania. W trzeciej minucie rozpocznij czystą ścieżkę sprzedaży2. W trzydziestej minucie zbierz wyniki otrzymane dla poszczególnych tras i dowody dostępu, zamiast deklarować odzyskanie danych z samego DNS . Te czasy ilustrują kolejność, a nie obiecany interwał propagacji.
Ten pisemny blat proponuje pięć wymaganych obserwacji odzyskiwania: stary dostęp wyłączony, przyczyna narażenia została usunięta, opublikowany nowy klucz, zweryfikowany nowy podpis i wyrównany nowy podpis. Scenariusz, w którym nowa poczta jest przekazywana, ale stary dostęp jest nadal aktywny, nie uruchamia bramy odzyskiwania. Scenariusz spełniający wszystkie pięć przechodzi przez modelowaną bramę. Obydwa zestawy obserwacji są syntetyczne; nie wykonano żadnego programu stołowego, dzierżawcy ani testu komunikatu. Rzeczywiste zabezpieczenie, obserwacje pamięci podręcznej, zatwierdzenia i testy wiadomości są nadal wymagane podczas prawdziwego incydentu.
Przypisz właściciela do każdej nierozwiązanej bramki odzyskiwania
W przypadku pisemnym KEY-01 zakłada się, że selektor zastępczy sales2 tworzy przechodzący wyrównany podpis dla From sales@example.org z d=example.org, ale stare konto usługi pozostaje aktywne. Właściciel incydentu musi pozostawić otwarte przywracanie i zająć się ograniczaniem dostępu; Pomyślny test podpisu administratora poczty nie może wypełnić tej luki. Stare pamięci podręczne programów do rozpoznawania nazw i zakres nadużyć w przeszłości pozostają nieznane. Tożsamości i wyniki są ustalonymi założeniami nauczania, a nie zrealizowanym wydarzeniem.