Badanie i naprawa problemów w Sophos ITDR Dark Web Intelligence

Dark Web Intelligence pokazuje rekordy wycieków, które Sophos zebrał dla skonfigurowanych domen. Celem tego podręcznika operacyjnego nie jest traktowanie każdego wykrycia jako bieżącego dostępu do konta. Najpierw sprawdzane są tożsamość, odniesienie czasowe, typ hasła i status wycieku. Następnie reaguje się tylko za pomocą zatwierdzonego procesu dla tożsamości, która jest faktycznie powiązana.

Credential Leaks o statusie Active zwiększają Risk Score tożsamości. Rekordy historyczne pozostają jednak widoczne również wtedy, gdy są nieaktywne. Tabela służy więc zarówno jako aktualny przegląd bieżących ryzyk, jak i jako dowód starszych odkryć.

Skrócony przebieg

1. Otwórz My Products > Identity > Dark Web Intelligence i udokumentuj domyślne filtry.
2. Nadaj priorytet aktywnemu rekordowi i zapisz Source, powiązaną tożsamość, typ hasła oraz Publish Date, Leaked Date i Breach Date.
3. Sprawdź, dlaczego rekord ma status Active; nie utożsamiaj każdego wiersza z unikalnym kontem ani hasłem.
4. Dla powiązanego Finding porównaj wyświetlany poziom ważności z macierzą, uwzględniając typ konta, typ hasła i siłę MFA.
5. Potwierdź odpowiedzialność i zatwierdzenie. Dopiero wtedy wykonaj odpowiednią, już zatwierdzoną reakcję.
6. Napraw poświadczenia w odpowiedzialnym Identity Provider zgodnie z zatwierdzonym procesem. Nie używaj Finding ani statusu wycieku jako zamiennika tej naprawy.
7. Po co najmniej jednym 15-minutowym cyklu ponownie sprawdź status, Finding i Risk Score oraz udokumentuj dowody.

Widoki i filtry domyślne

Dostęp bezpośredni

My Products > Identity > Dark Web Intelligence

Po bezpośrednim otwarciu tej strony tabela jest filtrowana według statusu wycieku Active i statusu tożsamości Active. Przed rozpoczęciem analizy zapisz zrzut ekranu lub zanotuj aktywne filtry. Pusty widok domyślny nie dowodzi braku historycznych danych o wyciekach; aby je sprawdzić, celowo poszerz filtry statusu.

Dostęp przez Identity Overview

Identity Overview > Credential Leaks

Kliknięcie metryki w widżecie Credential Leaks otwiera Dark Web Intelligence z widokiem odpowiadającym tej metryce:

Breached Email Accounts i Unique Passwords Breached to zagregowane metryki danych źródłowych. Nie istnieje dodatkowy filtr tabeli, który w pełni odzwierciedlałby ich unikalną metodę liczenia. W związku z tym metryka nie może zostać dokładnie odtworzona na podstawie wierszy tabeli widocznych po kliknięciu.

Interpretuj metryki poprawnie

Metryki u góry strony Dark Web Intelligence odnoszą się do aktywnych wycieków:

Te wartości używają różnych jednostek: źródeł, zapisów wycieków, kont i unikalnych haseł. Nie można ich po prostu dodać ani zweryfikować poprzez liczenie wierszy w tabeli.

Zbadaj zapis wycieku

1. Zdefiniuj zakres

Najpierw zwróć uwagę na filtry i sortowanie. Dla pierwszej selekcji istotne są przynajmniej te cechy:

• Status wycieku Active lub Inactive
• Status tożsamości i powiązana tożsamość
• Plaintext lub Hashed
• Kontekst administratora, nie-administratora lub VIP, jeśli wskazano
• Source
• Publish Date, Leaked Date i Breach Date
• powiązany Finding, jeśli występuje

Nie należy priorytetowo traktować wyłącznie według najnowszego znacznika czasu w tabeli. Rekord z nowym Publish Date może zawierać starsze treści, zwłaszcza w przypadku list kombinacyjnych.

2. Otwórz szczegóły

Kliknij w pole Source. Panel szczegółów pokazuje dodatkowe informacje o wycieku oraz, jeśli są dostępne, powiązaną tożsamość. Przed odpowiedzią wiersz tabeli i panel szczegółów muszą odnosić się do tego samego źródła i tożsamości.

Jeśli nie przypisano tożsamości, rekord pozostaje istotny dla śledztwa historycznego, ale uznaje się go za nieaktywny. Actions jest w tym przypadku wyłączony. Nie przypisuj tożsamości na podstawie domysłu i nie działaj przeciwko podobnie nazwanemu kontu.

3. Rozróżnij pola daty

Publish Date

Czas, kiedy Sophos po raz pierwszy znalazł zapis wycieku w analizowanych przez siebie danych. Nie odnosi się ani do czasu udostępnienia publicznego, ani koniecznie do czasu incydentu.

Leaked Date

Data, kiedy zestaw danych stał się publicznie dostępny. Ta data jest porównywana z ostatnią zmianą hasła w celu oceny, czy ryzyko związane z poświadczeniami jest aktualne.

Breach Date

Czas, w którym doszło do podstawowego naruszenia. Zapewnia kontekst incydentu, ale może być niedostępny.

Brak Breach Date nie sprawia, że Leaked Date staje się potwierdzonym czasem naruszenia. Podobnie, nowy Publish Date nie dowodzi, że hasło zostało niedawno skompromitowane. Dla logiki statusu kluczowe jest, czy ostatnia zmiana hasła miała miejsce przed czy po odpowiednim czasie pierwszego wycieku.

4. Oceń duplikaty i combolisty

Ta sama osoba może pojawić się w kilku wierszach w jednym źródle. Do typowych powodów należą:

• osoba pojawia się kilka razy w oryginalnym zestawie danych;
• ta sama treść została rozpoznana w ogólnym źródle, takim jak combolista;
• starsze dane o wyciekach ponownie stają się widoczne w kolekcji znalezionej później.

Wiele wierszy nie oznacza więc automatycznie wielu przejętych kont ani wielu aktualnych przypadków ujawnienia hasła. Dla każdego wiersza porównaj źródło, datę, typ hasła i powiązaną tożsamość. Metryki Emails i Unique Passwords stosują logikę deduplikacji; wiersze tabeli nie są deduplikowane w ten sam sposób.

Kiedy wyciek ma status Active lub Inactive

Wyciek ma status Active, jeśli spełnione są oba warunki:

1. Rekord może być powiązany z aktywną tożsamością w skonfigurowanym Identity Provider.
2. Ostatnia zmiana hasła powiązanego konta miała miejsce przed pierwszym wyciekiem.

Active zatem oznacza ryzyko związane z poświadczeniami, które wciąż jest istotne. Sam status nie dowodzi pomyślnego logowania przez osobę trzecią ani trwającego ataku.

Wyciek ma status Inactive, jeśli przynajmniej jeden z udokumentowanych scenariuszy ma zastosowanie:

• Nie ma zgodnej tożsamości w skonfigurowanych Identity Providerach.
• Ostatnia zmiana hasła miała miejsce po czasie wycieku.
• Hasło do konta zostało niedawno zmienione.
• Konto zostało dezaktywowane lub usunięte.
• Powiązany Finding uzyskał status Resolved lub Dismissed.

Dane historyczne dotyczące monitorowanych domen są zbierane i przechowywane. Nieaktywny zbiór danych nie jest więc wadliwy ani nieistotny z powodu swojego wieku. Może wyjaśnić, dlaczego ta sama osoba lub źródło pojawia się kilka razy.

Kiedy zostanie utworzony Finding

Sophos opisuje następujące przetwarzanie Findings dotyczących przejęcia konta:

1. Sophos sprawdza, czy w skonfigurowanych Identity Provider istnieje aktywna tożsamość.
2. Sophos określa na podstawie dostępnych danych historycznych, kiedy wartość w postaci jawnej lub hash został ujawniony po raz pierwszy. Ma to na celu rozpoznanie starych treści w nowych listach kombinacji.
3. W przypadku wartości w postaci zwykłego tekstu Sophos porównuje ją z globalnymi wymaganiami dotyczącymi złożoności haseł w Microsoft Entra ID, aby odfiltrować nieprawidłowe wartości.
4. Sophos porównuje czas pierwszego wycieku hasła z ostatnią zmianą hasła. Jeśli pierwszy wyciek nastąpił po tej zmianie, Sophos tworzy Finding.

Findings są tworzone tylko dla aktywnych tożsamości. Surowe dane pozostają widoczne na Dark Web Intelligence nawet jeśli żadna aktywna tożsamość nie jest powiązana.

Macierz powagi dla naruszenia konta

Według Sophos poziom ważności Finding zależy od typu konta, typu hasła i siły MFA:

Macierz priorytetowo traktuje pracę, ale nie zastępuje oceny indywidualnego przypadku. Szczególnie w przypadku kont administracyjnych należy potwierdzić faktyczne powiązanie konta przed podjęciem reakcji. Niższy stopień powagi nie oznacza, że nie jest wymagana żadna naprawa.

Obsługa wartości haseł

Sophos podaje, że nie przechowuje ani haseł w postaci jawnej, ani wartości skrótu oraz że nie może pobierać tych wartości z Identity Providers. Podczas gromadzenia danych Sophos stosuje własną funkcję skrótu do zaobserwowanych wartości, a następnie klasyfikuje rekord jako Plaintext lub Hashed. Według Sophos metoda ta umożliwia określanie unikalnych wartości i wskaźników pochodnych bez przechowywania źródłowej wartości hasła.

Operacyjnie oznacza to:

• Plaintext opisuje typ obserwowanej treści wycieku, a nie hasło dostępne w Sophos Fusion (dawniej Sophos Central).
• Nie próbuj odzyskać oryginalnej wartości z Sophos Fusion, zrzutów ekranu ani eksportów.
• Nie kopiuj podejrzanych haseł, wartości hash ani nowych danych uwierzytelniających do zgłoszeń, notatek ani wiadomości czatu.
• Ustaw nowe hasło wyłącznie za pomocą zatwierdzonego procesu Identity Provider i obsługuj je w przeznaczonym do tego systemie haseł.

Autoryzowana odpowiedź i naprawa

Zdecyduj, zanim podejmiesz jakiekolwiek działanie

Przed Actions muszą być spełnione wszystkie następujące punkty:

• Powiązana tożsamość jest wyraźnie potwierdzona przez panel szczegółów.
• Właściciel konta, typ konta i funkcja biznesowa są znane.
• Sprawdzono aktualny status wycieku, typ hasła oraz trzy pola daty.
• Response Actions są autoryzowane dla tenanta.
• Osoba wykonująca działanie ma upoważnienie obejmujące tę konkretną tożsamość i oczekiwany wpływ.
• W przypadku kont uprzywilejowanych lub współdzielonych zaangażowano odpowiedzialnego właściciela usługi lub systemu.

Jeżeli choć jeden z tych warunków nie jest spełniony, nie uruchamiaj żadnego działania. Przekaż rekord odpowiedzialnej osobie w zespole ds. tożsamości lub bezpieczeństwa wraz ze znacznikiem czasu, stanem filtrów oraz informacją o brakującej zgodzie.

Odpowiedz w Dark Web Intelligence

Jeżeli Response Actions są autoryzowane, są dostępne dla powiązanych tożsamości w tabeli lub w szczegółach wycieku:

1. Otwórz właściwy wiersz lub panel szczegółów potwierdzonej tożsamości.
2. Wybierz Actions.
3. Wybierz wyłącznie wcześniej zatwierdzoną Response Action.
4. Przeczytaj i postępuj zgodnie ze wszystkimi instrukcjami i potwierdzeniami wyświetlanymi na ekranie.
5. Dokumentuj działanie, operatora, czas, tożsamość celu i widoczny wynik, ale nie przechwytuj poświadczeń.

Można używać wyłącznie Response Actions dostępnych w tenancie i autoryzowanych przez organizację. Jeśli nie istnieje odpowiednia tożsamość, Actions pozostanie wyłączony; nie należy tego obejść.

Napraw ryzyko związane z poświadczeniami

Naprawę techniczną przeprowadza się za pośrednictwem Identity Provider odpowiedzialnego za konto i zgodnie z zatwierdzonym procesem obsługi poświadczeń:

1. Sprawdź ostatnią zmianę hasła i status konta potwierdzonej tożsamości względem czasu wycieku.
2. Jeżeli nie można wykluczyć, że dane logowania zaobserwowane w wycieku są nadal ważne, rozpocznij lub wykonaj autoryzowaną zmianę hasła dokładnie dla tego konta.
3. Jeśli konto jest wyłączone lub usunięte, potwierdź status dostawcy zamiast ponownego aktywowania konta w celu naprawy.
4. Jeśli rekord nie jest powiązany z tożsamością, traktuj go jako historyczny, nieaktywny wyciek i nie zgaduj tożsamości konta.
5. Powiązany Finding obsłuż zgodnie z właściwym procesem dopiero po udokumentowaniu faktycznej naprawy poświadczeń. Używaj Dismissed tylko po merytorycznie uzasadnionej i udokumentowanej decyzji, a nie w celu skrócenia kolejki.

Nie wyciągaj z rekordu wycieku wniosku, że potrzebne są dodatkowe zmiany konta, sesji, MFA lub katalogu. Takie działania wymagają osobno potwierdzonego powodu oraz odpowiedniej zgody.

15-minutowa kadencja i walidacja

Sophos sprawdza Dark Web Intelligence co 15 minut. Sophos stale monitoruje i gromadzi wyniki dotyczące wycieków; po wykryciu aktywnego wycieku Finding jest zazwyczaj generowany w ciągu 15 minut. „Zazwyczaj” nie oznacza gwarantowanego maksymalnego czasu.

Po naprawie nie zapisuj od razu ostatecznego sukcesu. Zamiast tego:

1. Zapisz czas zakończenia zmiany hasła lub potwierdzonej zmiany konta wraz ze strefą czasową.
2. Poczekaj przynajmniej na pełny 15-minutowy cykl. Weź pod uwagę, że pobranie zaktualizowanych danych Identity Provider przez Sophos może wymagać dodatkowego czasu.
3. Ponownie otwórz My Products > Identity > Dark Web Intelligence.
4. Wyszukaj tę samą tożsamość i źródło z tymi samymi filtrami.
5. Sprawdź, czy status wycieku zmienił się z Active na Inactive oraz czy wyświetlany status tożsamości jest poprawny.
6. Sprawdź oddzielnie powiązany Finding. Brak nowego Finding nie jest wystarczającym dowodem, jeśli wyciek nadal ma status Active.
7. Monitoruj Risk Score tożsamości jako sygnał uzupełniający. Nie jest to główny dowód zmiany hasła.
8. Dokumentuj wartość początkową, działanie, czas zakończenia, czas walidacji oraz status końcowy.

Kryteria akceptacji

Przetwarzanie jest zakończone tylko wtedy, gdy:

• tożsamość i źródło wycieku są wyraźnie udokumentowane;
• typ hasła i pola daty zostały ocenione;
• naprawa poświadczeń została potwierdzona we właściwym Identity Provider lub konto zostało wyraźnie dezaktywowane lub usunięte;
• naprawiony rekord wycieku nie ma już statusu Active po przetworzeniu;
• powiązany Finding został obsłużony w ramach kontrolowanego procesu;
• żadne wartości tajne nie znajdują się w dokumentacji.

Jeśli rekord pozostaje Active po kilku 15-minutowych cyklach, najpierw ponownie sprawdź faktyczną ostatnią zmianę hasła, status konta oraz powiązaną tożsamość. Jeśli te informacje są poprawne, a status nadal nie daje się wyjaśnić, należy zarejestrować stan filtra, źródło, wszystkie trzy pola dat, odniesienie do tożsamości, odniesienie Finding oraz znacznik czasu. Następnie eskaluj sprawę do wsparcia Sophos. Nie wprowadzaj żadnych dalszych zmian w koncie na podstawie domysłów.

Karta triażowa

Tenant / środowisko:
Czas walidacji ze strefą czasową:
Ścieżka i aktywne filtry:
Source:
Powiązana tożsamość:
Status tożsamości:
Typ konta: Administrator / Nie-administrator / niejasny
Monitorowanie VIP: tak / nie / niejasne
Typ hasła: Plaintext / Hashed
Stan wycieku przed działaniem:
Publish Date:
Leaked Date:
Breach Date: Wartość / niedostępne
Wiele wierszy lub kontekst combolisty:
Odwołanie Finding i powaga:
Ostatnia zmiana hasła według Identity Provider:
Zatwierdzenie odpowiedzi:
Wykonano autoryzowaną akcję:
Czas ukończenia wraz ze strefą czasową:
Walidacja po 15-minutowym cyklu:
Stan wycieku po pomiarze:
Status Finding po akcji:
Risk Score jako sygnał kontynuacyjny:
Otwarta odchyłka / eskalacja:

Unikaj powszechnych błędów

• Liczenie każdego wiersza tabeli jako osobnego konta: Duplikaty i combolisty mogą tworzyć wiele wierszy dla tej samej osoby.
• Traktowanie Publish Date jako Breach Date: Trzy pola dat opisują różne zdarzenia; Breach Date może być niedostępna.
• Interpretowanie Inactive jako „usunięty”: Dane historyczne są zachowywane i mogą nadal być widoczne.
• Uznanie pustego widoku domyślnego za brak zagrożeń: Widok bezpośredni domyślnie pokazuje tylko aktywne wycieki aktywnych tożsamości.
• Ręczne zamknięcie Finding zamiast naprawy: Zmiana statusu nie zmienia danych logowania w Identity Provider.
• Wymuszanie Actions bez powiązanej tożsamości: Bez pasującej tożsamości przycisk jest celowo wyłączony.
• Mylenie Plaintext z możliwym do odzyskania hasłem: Sophos podaje, że nie przechowuje ani wartości jawnych, ani wartości skrótu.
• Oczekiwanie natychmiastowej aktualizacji: Sprawdzanie odbywa się co 15 minut; dane tożsamości ze źródła mogą wymagać dodatkowego czasu przetwarzania.