Badanie i obsługa ustaleń Sophos ITDR

W sekcji My Products > Identity > Findings Sophos ITDR wyświetla wyniki kontroli połączonej infrastruktury tożsamości. Domyślnie tabela jest sortowana według ryzyka. Ustalenie nie jest automatycznym dowodem aktywnego naruszenia ani XDR Detection czy XDR Case. To element pracy ITDR, który należy ocenić, obsłużyć we właściwym systemie tożsamości, a następnie ponownie zweryfikować.

Bezpieczny proces wygląda następująco:

1. Ustal priorytety otwartych ustaleń według Risk i użyj filtrów, aby utworzyć możliwą do obsłużenia kolejkę pracy.
2. Przeczytaj Finding Details, Description, Definition i Recommendation; jeśli jest to konieczne, przejrzyj dane pierwotne w ramach Result i zmiany w ramach History.
3. Przed zmianą konfiguracji należy ocenić wpływ i zależności w swoim środowisku.
4. Usuń przyczynę w systemie lub usłudze tożsamości, których dotyczy problem, zamiast jedynie zmieniać stan w ITDR.
5. Zweryfikuj stan najpierw u dostawcy, a następnie w ITDR.
6. Ustaw stan Resolved lub Dismissed wyłącznie w wyniku świadomej decyzji. Ręczne ustawienie Resolved nie jest działaniem naprawczym.

Prawidłowa interpretacja stanów, poziomów ryzyka i kategorii

Stan

ITDR nie traktuje już ustaleń Resolved i Dismissed jako ryzyka dla środowiska. Statusy te mają jednak inne znaczenie operacyjne: Resolved oznacza usuniętą przyczynę lub ograniczone ryzyko, natomiast Dismissed oznacza świadomą decyzję dotyczącą ryzyka.

Ryzyko

Poziom ryzyka wynika z bazowej kontroli i pomaga ustalać priorytety. Na tym samym poziomie należy najpierw zbadać narażone tożsamości uprzywilejowane, oznaki przejęcia poświadczeń oraz ustalenia o szerokim oddziaływaniu. Konkretne zalecenie Recommendation pozostaje ważniejsze niż działanie ogólne.

Kategoria

ITDR używa następujących kategorii. Ich nazwy pozostają bez zmian w angielskim interfejsie Sophos:

• User Behavior
• Configuration
• Entra Conditional Access Gaps
• Dormant Resources
• Lateral Movement
• Credential Compromise
• Persistence
• Privilege Escalation
• Defense Evasion
• Exfiltration
• VIP Exposure

Kategoria opisuje rodzaj kontroli i może być zgodna z modelem MITRE ATT&CK, jeżeli jest to właściwe. Nie zastępuje ona szczegółowej analizy ani weryfikacji, czy zaobserwowana konfiguracja jest zamierzona w środowisku.

Filtrowanie wyników i tworzenie kolejki pracy

Składane menu filtrów po lewej stronie tabeli Identity Findings łączy następujące filtry:

• Risk: poziom ryzyka ustalenia.
• Status: Open, Resolved lub Dismissed.
• Reference Type: typ obiektu, którego dotyczy ustalenie.
• Category: kategoria ustalenia.
• Is New: ustalenia zaobserwowane po raz pierwszy w ciągu ostatnich siedmiu dni.
• Finding: tytuł ustalenia.
• First Seen: czas pierwszej obserwacji.
• Last Seen: czas ostatniej obserwacji.
• Last Modified: czas ostatniej zmiany.

Te dokładne wartości są dostępne dla Reference Type:

• User Object
• Application
• Group Object
• Device Object
• Tenant Configuration

Wybrane filtry pojawiają się nad tabelą. Użyj X, aby usunąć jeden filtr, albo Clear All, aby usunąć wszystkie. Tabela i adres URL aktualizują się dynamicznie zgodnie z wyborem. Filtrowany adres URL można więc zapisać jako widok roboczy lub udostępnić współpracownikom. Przed udostępnieniem sprawdź, czy odbiorcy mają dostęp do tego samego tenantu Sophos Fusion (dawniej Sophos Central) i czy adres URL może znaleźć się w danym zgłoszeniu.

Przydatna kolejka początkowa to Status = Open, a następnie Risk = Critical lub High. Potem zawęź wyniki za pomocą Category, Reference Type lub Is New. Dzięki temu nowe krytyczne zagrożenia dla tożsamości pozostają widoczne bez pomijania starszych otwartych pozycji.

Szczegółowe badanie ustalenia

Kliknięcie łącza w kolumnie Findings otwiera panel szczegółów. Przedstawia on powiązany obiekt, ryzyko, pola First Seen, Last Seen i Last Modified oraz zalecenie. Użyj ikony New Tab, aby otworzyć pełną stronę na nowej karcie.

Panel i pełny widok obejmują:

• Finding Details: podsumowanie zawierające poziom ryzyka, status, komentarze, znaczniki czasu i tagi.
• Description: opis ustalenia.
• Definition: Informacje o powiązanej kontroli tożsamości i jej referencjach.
• Recommendation: zalecenie Sophos dotyczące ograniczenia konkretnego ryzyka.

Aby uzyskać wiarygodne wyniki, należy odpowiedzieć na co najmniej następujące pytania:

1. Którego obiektu dotyczy ustalenie i czy Reference Type pasuje do oczekiwanego obiektu?
2. Czy dostawca tożsamości nadal posiada warunek opisany w Description i Definition?
3. Jaki jest zakres uprawnień, zależności i możliwych skutków zmiany?
4. Czy Recommendation pasuje do własnego środowiska i czy zmiana jest autoryzowana wewnętrznie?
5. Czy First Seen, Last Seen i Last Modified wskazują na nową, powtarzającą się lub już rozwiązaną kwestię?

Finding Details pokazuje komentarze i tagi. Dokumentacja Sophos dotycząca strony Findings nie opisuje jednak ani funkcji przypisywania, ani elementów sterujących do tworzenia lub zmieniania komentarzy i tagów. Odpowiedzialność i dowody zmian należy zatem rejestrować w zatwierdzonym systemie zarządzania zmianami lub zgłoszeniami; komentarze nie zastępują ani zgłoszenia zmiany, ani dowodu zmiany w systemie źródłowym.

Analiza Result jako danych pierwotnych

Karta Result przedstawia w formacie JSON nieprzetworzone dane wyjściowe wykonanej kontroli. Jest szczególnie przydatna, gdy podsumowanie nie wskazuje, który atrybut, obiekt lub wynik doprowadził do oceny.

Traktuj klucze i wartości JSON jako wynik konkretnej kontroli; nie wyprowadzaj z nich ogólnego schematu. Porównaj odpowiednie identyfikatory obiektów, stany i znaczniki czasu z aktualnymi informacjami u dostawcy tożsamości. Wrażliwe dane pierwotne należy umieszczać wyłącznie w zatwierdzonych zgłoszeniach lub notatkach z dochodzenia.

Śledzenie zmian za pomocą History

Karta History pokazuje wcześniejsze działania dotyczące ustalenia. Za pomocą View Diff można otworzyć dokładne zmiany. Zmiany statusu i inne etapy przetwarzania mogą być tam śledzone. W ten sposób można odróżnić nieoczekiwane ponowne otwarcie od nowego ustalenia.

Usunięcie przyczyny i potwierdzenie rezultatu

⚠️ Sprawdź przed wprowadzeniem zmian: zalecenie Sophos musi być zgodne ze środowiskiem, tolerancją ryzyka i zasadami zatwierdzania zmian. Zmiany ról, uwierzytelniania, dostępu warunkowego, aplikacji lub innych obiektów tożsamości mogą wpływać na użytkowników, aplikacje i dostęp. Przed wdrożeniem należy więc wyjaśnić zależności i przygotować plan wycofania.

Działania naprawcze wykonuje się w systemie, w którym ITDR wykrył problem, na przykład u połączonego dostawcy tożsamości lub w odpowiedniej usłudze aplikacyjnej. Status w ITDR steruje wyłącznie przepływem pracy ustaleń. Nie zmienia konfiguracji u dostawcy.

Kontrolowane zamknięcie składa się z czterech etapów:

1. Sprawdź stan u dostawcy: Potwierdź, że zatwierdzona zmiana została zapisana i działa dla wskazanego obiektu.
2. Ponownie sprawdź ustalenie: Przejrzyj powiązany obiekt oraz pola Last Seen, Result i History. Nieaktualny lub niezmieniony wynik nie stanowi dowodu powodzenia.
3. Poczekaj na automatyczne działanie: Jeśli ustalenie przestanie się pojawiać podczas ponownej kontroli, ITDR automatycznie je rozwiąże i doda komentarz. Kontrole stanu zabezpieczeń Entra ID i nieaktywnych zasobów są zwykle wykonywane co dwie godziny; ogólnoorganizacyjny Risk Posture Score jest aktualizowany codziennie.
4. Udokumentuj wynik: zapisz dowody z systemu dostawcy, stan ustalenia, znacznik czasu i, w stosownych przypadkach, View Diff w zatwierdzonej dokumentacji roboczej. Jeśli ustalenie pozostaje otwarte po oczekiwanym interwale kontroli, ponownie porównaj stan u dostawcy, obiekt i wynik JSON, zamiast wielokrotnie ręcznie zmieniać stan.

System może ponownie ustawić ręcznie rozwiązane ustalenie ze stanu Resolved na Open, gdy tylko ITDR ponownie zaobserwuje ten sam stan. Nie jest to błąd w modelu stanów, ale wskazanie, że przyczyna nadal istnieje, pojawiła się ponownie lub jest nadal widoczna w danych ocenianych przez ITDR.

Używanie Dismissed wyłącznie jako świadomej decyzji o ryzyku

⚠️ Dismissed wstrzymuje tworzenie kolejnych ustaleń: po odrzuceniu ustalenia ITDR nie tworzy nowych ustaleń dotyczących tego problemu na wskazanym obiekcie. Ustalenie pozostaje w tabeli, ale jest wykluczone z pulpitu i ogólnoorganizacyjnego Risk Posture Score. Przedwczesne odrzucenie może więc ukryć w zwykłym widoku ryzyko, które nadal istnieje lub później ponownie stanie się istotne.

Dismissed jest właściwy tylko wtedy, gdy dany stan jest oczekiwany, jego usunięcie jest w sposób udokumentowany niemożliwe lub operacyjnie nieuzasadnione, a odpowiedzialna strona akceptuje ryzyko rezydualne. Poza ITDR należy udokumentować co najmniej obiekt, uzasadnienie, mechanizmy kompensujące, zatwierdzenie i termin ponownego przeglądu. Ustalenie, którego technicznie nie można rozwiązać, może zamiast tego pozostać Open, dzięki czemu ryzyko pozostanie widoczne w wyniku i bieżącym monitorowaniu.

Priorytet dla Credential Compromise

Ustalenia dotyczące przejętych kont są generowane wyłącznie dla aktywnych tożsamości. ITDR sprawdza między innymi, czy istnieje aktywna tożsamość, kiedy hasło w postaci jawnej lub skrót hasła wyciekły po raz pierwszy oraz czy ta data jest późniejsza niż ostatnia zmiana hasła. Wartość w postaci jawnej jest również sprawdzana pod kątem globalnych wymagań złożoności haseł w Microsoft Entra ID. Dane pierwotne mogą nadal być widoczne w sekcji Dark Web Intelligence, niezależnie od tego, czy wygenerowano ustalenie.

Po wygenerowaniu ustalenia ITDR określa poziom ryzyka na podstawie typu konta, rodzaju wycieku i siły MFA:

W pierwszej kolejności należy obsłużyć ustalenia Critical, a następnie High; na tym samym poziomie najpierw zbadać konta uprzywilejowane i wycieki haseł w postaci jawnej. Niższa ocena przy włączonym lub odpornym na phishing MFA nie oznacza, że ustalenie można zignorować. Zatwierdzone środki ochronne i naprawcze należy wykonać we właściwym systemie tożsamości, zgodnie z procesem reagowania na incydenty. Następnie trzeba zweryfikować stan u dostawcy, ustalenie i historię zgodnie z powyższym opisem. Sam status nie potwierdza bezpieczeństwa tożsamości.

Rozdzielenie odpowiedzialności klienta, MDR i XDR

Sophos ITDR jest rozwiązaniem monitorowanym przez klienta. Nawet przy oddzielnie licencjonowanej usłudze Sophos MDR rutynowy triage i zarządzanie ustaleniami pozostają po stronie klienta. MDR Operations Team koncentruje się na aktywnych zagrożeniach dla tożsamości i może objąć dochodzeniem pojedyncze ustalenia Critical lub High, jeżeli wskazują na aktywne zagrożenie. Nie oznacza to automatycznego przejęcia wszystkich ustaleń ani wykonywania zmian u dostawcy tożsamości.

Dlatego w przypadku każdego eskalowanego ustalenia należy wyraźnie udokumentować:

• kto odpowiada za triage i decyzje dotyczące ryzyka,
• kto autoryzuje i wykonuje zmiany w systemie tożsamości,
• czy wskazanie aktywnego zagrożenia zostało przekazane uzgodnionemu procesowi MDR,
• kto przeprowadza ostateczną walidację skutku technicznego i stanu ITDR.

Ustalenia ITDR pozostają odrębne od XDR Detections i XDR Cases. Kontekst tożsamości może wspierać dalsze dochodzenie. Stan, komentarze i zamknięcie ustalenia ITDR nadal należą jednak do procesu ITDR i nie są tożsame z procesem XDR ani MDR.