Analizowanie Directory i Identity Details w Sophos ITDR

Directory w Sophos ITDR to roboczy spis tożsamości, tożsamości nieludzkich (NHI), grup i urządzeń, które ITDR pobiera od połączonych dostawców tożsamości. Karty wskaźników pokazują liczbę monitorowanych obiektów; kliknięcie otwiera odpowiedni widok. Aby rozpocząć analizę, należy przejść z tego ogólnego zestawienia przez nazwę wyświetlaną do szczegółowych danych obiektu.

Szybka ścieżka: w obszarze My Products > Identity > Directory najpierw wybrać właściwą kartę, zastosować wyszukiwanie i filtry oraz sprawdzić pochodzenie danych. W przypadku użytkownika otworzyć Display Name, a następnie w sekcjach Summary, Activity Log, Findings, Insights, Group Membership i Dark Web Intelligence zweryfikować konkretną hipotezę. Pojedynczy tag, wysoki Risk Score lub nietypowe logowanie są sygnałami pomagającymi ustalić priorytet, ale same w sobie nie stanowią jeszcze dowodu przejęcia konta.

Ustalenie granic produktu przed rozpoczęciem analizy

ITDR Directory nie jest usługą katalogową Sophos Fusion (dawniej Sophos Central). Pokazuje kontekst bezpieczeństwa zarejestrowany przez integrację ITDR lub sensor ITDR. Natomiast obszar Global Settings > Platform > Directory service udostępnia użytkowników i grupy współdzielonym funkcjom i produktom Central. Wynikają z tego trzy ważne ograniczenia:

• Braku tożsamości w ITDR Directory nie rozwiązuje ponowne uruchomienie synchronizacji Central Directory Sync. Najpierw należy sprawdzić integrację ITDR, zestaw obiektów po stronie dostawcy i stan pobierania danych.
• Obiekt w ITDR Directory nie jest automatycznie zarządzanym użytkownikiem Central i nie oznacza przypisania produktu ani instalacji Endpoint.
• Filtry, tagi i samo otwieranie stron szczegółów w ITDR nie zmieniają obiektów Entra ID, Active Directory, Intune ani katalogu Central. Poprawki techniczne wprowadza się w systemie źródłowym, a następnie weryfikuje w ITDR; niezależnie od tego mogą być dostępne wyraźnie autoryzowane działania reagowania uruchamiane w przewidzianych do tego miejscach Actions.

Sophos XDR ma również inne przeznaczenie. ITDR Directory dostarcza kontekst inwentarza, stanu zabezpieczeń i tożsamości. Zapytanie lub analiza w XDR koreluje natomiast telemetrię i zdarzenia z obsługiwanych źródeł danych. Dlatego Activity Log w Identity Details nie jest kompletną osią czasu XDR, a ustalenie ITDR nie jest automatycznie detekcją XDR. W analizie zagrożenia obejmującej wiele przypadków potwierdzone wskazania ITDR należy korelować z dostępnymi danymi XDR, Endpoint, Entra i sieciowymi, nie traktując braku telemetrii jako wyniku świadczącego o braku anomalii.

Prawidłowe odczytywanie zasobu Directory

Widok dostępny w obszarze My Products > Identity > Directory zawiera cztery karty o różnych zastosowaniach:

Pola wyszukiwania zawężają dany widok według nazwy. Wyszukiwanie i filtry działają wyłącznie na wyświetlanych danych pobranych przez ITDR. Brak wyniku nie dowodzi zatem ani nieistnienia obiektu u dostawcy, ani jego usunięcia. Przed eskalacją należy sprawdzić pisownię, kartę, aktywne filtry, dzierżawę dostawcy oraz czas pobrania danych.

Wyszukiwanie, sortowanie i filtrowanie tożsamości

Widok Identities może być prezentowany jako karty lub lista. Domyślnie użytkownicy są posortowani alfabetycznie. W menu sortowania można na przykład wybrać malejący Risk Score, aby znaleźć tożsamości wymagające analizy w pierwszej kolejności. Pole Search Identities filtruje według nazw.

Dobór użytecznych filtrów zależy od celu analizy. Na potrzeby wstępnego ustalania priorytetów filtr Status zawęża wyniki według stanu konta zgłoszonego przez dostawcę tożsamości, a Risk Severity według zakresu obliczonego wskaźnika Risk Score. Is Admin oznacza kontekst administratora ustawiony przez dostawcę lub na podstawie rozpoznanych ról uprzywilejowanych, Is VIP — wybór do monitorowania VIP Monitoring, a Is Compromised — obecność aktywnych wycieków danych uwierzytelniających. Is Dormant wyszukuje konta, dla których od ponad 90 dni nie zarejestrowano logowania.

Do klasyfikacji konta służą atrybuty organizacyjne Department i Employee Type, o ile dostawca je udostępnia. Is Guest oznacza konto gościa u dostawcy tożsamości, natomiast Is Cloud Only — konto istniejące wyłącznie u dostawcy tożsamości w chmurze, bez identyfikatorów lokalnych. Kontekst MFA zapewniają pola Has MFA, Has Passwordless MFA, Primary MFA Method i MFA Method. Według atrybutów lokalizacji utrzymywanych u dostawcy filtrują Country i Region.

Pusta wartość filtra nie jest wynikiem negatywnym. Jeżeli dostawca nie udostępnia atrybutu, licencja ogranicza dostęp przez API lub Microsoft nie udostępnił jeszcze zaktualizowanych danych, ITDR nie może wiarygodnie wypełnić pola. Dotyczy to w szczególności danych MFA, administracyjnych, dotyczących urządzeń i aktywności.

W widoku kart strzałka na końcu karty wyświetla dodatkowe informacje; jednocześnie rozwinięta może być tylko jedna karta. W widoku listy strzałka po lewej stronie rozwija wiersz. Menu kolumn umożliwia przypinanie kolumn, automatyczne dopasowanie ich rozmiaru, resetowanie, dodawanie lub usuwanie. Te ustawienia widoku nie zmieniają ani obiektu, ani jego oceny.

Jeśli działania reagowania zostały wcześniej autoryzowane, są dostępne dla użytkownika przez Actions na rozwiniętej karcie lub w kolumnie Actions w widoku listy. Dostępność danego punktu wejścia lub działania zależy od stanu tożsamości i konfiguracji; wykonanie wymaga również odpowiednich uprawnień operatora i wewnętrznego procesu zatwierdzania. Filtry, tagi i otwieranie szczegółów pozostają odrębnymi funkcjami, które nie wprowadzają zmian. Po wykonaniu działania należy sprawdzić jego wynik w systemie źródłowym, a następnie zaktualizowany stan w ITDR.

Traktowanie ikon i tagów jako kontekstu, a nie werdyktu

Ikony oznaczają User, MFA User, Deleted User, Locked User, Admin lub Guest. Dodatkowe tagi opisują różne właściwości i nie należy ich odczytywać jako wspólnej oceny ryzyka: Admin oznacza, że konto zostało rozpoznane jako konto administratora, Guest wskazuje gościa w dzierżawie, Deleted User — konto usunięte u dostawcy, a Locked User — konto wyłączone.

MFA User oznacza włączone MFA, Compromised — aktywny wyciek danych uwierzytelniających, a Dormant Account — tożsamość bez zarejestrowanego logowania w ciągu ostatnich 90 dni. Cloud Only oznacza brak identyfikatorów lokalnych; w przypadku Hybrid identyfikatory lokalne są dostępne i synchronizowane między chmurą a środowiskiem lokalnym. Human klasyfikuje tożsamość jako należącą do człowieka, a VIP oznacza objęcie jej funkcją VIP Monitoring.

Human i Non Human to tagi klasyfikacji, a nie poziomy ryzyka. Konto człowieka reprezentuje osobę. Do NHI należą w szczególności jednostki usługi (Service Principals), aplikacje, Agent Identities, Agent Identity Blueprints i inne tożsamości maszynowe. Obiekty NHI analizuje się w Non-Human Identities. Opcjonalne konto użytkownika sparowane z agentem pojawia się natomiast w Identities z tagiem Agent Identity. To, że nazwa wyświetlana brzmi jak nazwa osoby lub usługi, nie stanowi wiarygodnej klasyfikacji.

Rozróżnianie Application Object i Service Principal

Obiekt Application Object w Microsoft Entra jest globalną definicją zarejestrowanej aplikacji w jej dzierżawie macierzystej. Opisuje między innymi konfigurację tożsamości aplikacji i ma identyfikator App ID, czyli Client ID. W przypadku jednostki usługi typu Application Service Principal jest konkretną lokalną instancją tej aplikacji w określonej dzierżawie. Ten typ odwołuje się do Application Object i określa w danej dzierżawie, co aplikacja może robić, kto może uzyskiwać do niej dostęp i do jakich zasobów może ona uzyskiwać dostęp. Ta relacja nie dotyczy każdego typu jednostki usługi: Service Principal typu Managed identity nie ma powiązanego Application Object, natomiast Legacy Service Principal nie ma powiązanej rejestracji aplikacji.

Widok Non-Human Identities obejmuje aplikacje Enterprise Applications, pozostałe Service Principals i obiekty Microsoft Entra Agent ID pobrane przez ITDR w monitorowanej dzierżawie Entra. Nie ogranicza się do Service Principals typu Application i nie jest drugą listą globalnych rejestracji aplikacji. Nie gwarantuje to jednak, że pobrano już wszystkie obiekty istniejące u dostawcy. Nie każdy przedstawiony kontekst NHI ma rejestrację aplikacji. Aplikacja wielodzierżawowa może mieć Application Object w dzierżawie macierzystej, ale osobny Service Principal typu Application w każdej z wielu dzierżaw korzystających z aplikacji. Dlatego należy łącznie porównywać Display Name, dzierżawę, App/Client ID, Object ID, właściciela i uprawnienia. Takie same nazwy nie oznaczają tego samego obiektu; różne lokalne jednostki usługi tego typu mogą odwoływać się do tej samej aplikacji globalnej.

Filtrowanie NHI i analiza Non-Human Identity Details

Search Non-Human Identities zawęża widok według nazwy. Do ukierunkowanej analizy dostępne są następujące filtry:

• Status: stan u dostawcy, na przykład Active, Disabled lub Deleted.
• Resource Type: bazowy typ obiektu, na przykład Application, ServiceIdentity, ManagedIdentity, SocialIdp lub Legacy. Te wartości interfejsu nie gwarantują istnienia powiązanej rejestracji aplikacji.
• Has Password Credentials: określa, czy skonfigurowano poświadczenie oparte na haśle.
• Has Key Credentials: określa, czy skonfigurowano poświadczenie oparte na certyfikacie.
• Is Agent: określa, czy obiekt jest klasyfikowany jako Agent Identity lub Agent Identity Blueprint Principal.
• Agent Type: wybór Agent Identity lub Blueprint Principal.

W przypadku spisu agentów można na przykład zacząć od Is Agent, wybrać wymagany Agent Type i otworzyć Display Name. Filtry poświadczeń opisują konfigurację danego obiektu, a nie ważność jego poświadczeń czy udany test uwierzytelniania. Zwłaszcza w przypadku agentów należy uwzględnić także nadrzędny blueprint; agent bez własnego hasła nie jest automatycznie obiektem pozbawionym możliwości dostępu.

Kliknięcie Display Name otwiera Non-Human Identity Details. W obszarze Details nazwa wyświetlana jest odnośnikiem do obiektu w Microsoft Entra admin center. Status wskazuje stan aktywny, wyłączony lub usunięty; Type — bazowy typ zasobu, na przykład Application lub ServiceIdentity. Created At, Updated At i Deleted At umiejscawiają cykl życia obiektu w czasie. Te metadane nie są zdarzeniami logowania.

App Owners zawiera użytkowników lub Service Principals mających techniczną kontrolę administracyjną nad poświadczeniami, konfiguracją i uprawnieniami. Każdy wpis pokazuje nazwę wyświetlaną, typ użytkownika, rolę, dział i stan. Findings zawiera ustalenia związane z NHI, uporządkowane według ryzyka; kliknięcie otwiera ich szczegóły. Przy decyzjach dotyczących stanu i późniejszej walidacji obowiązuje proces obsługi ustaleń.

W Permissions należy rozróżnić Application Permissions — bezpośrednio nadane uprawnienia app-only — i Delegated Permissions, obowiązujące w imieniu zalogowanego użytkownika. Obie tabele pokazują nazwę API, wartość claim, uprawnienie, typ uprawnienia i datę nadania. Nietypowe uprawnienie należy zweryfikować u dostawcy pod kątem zamierzonego celu biznesowego, wydawcy, udzielonej zgody i odpowiedzialnego właściciela. Sam widok Directory nie wycofuje zgody ani nie usuwa uprawnień.

Agent Identity Blueprint, Blueprint Principal i tożsamość wykonawcza

Agent oparty na Microsoft Entra Agent ID składa się z powiązanych obiektów, a nie jednej rejestracji aplikacji:

• Agent Identity Blueprint to kontener na poświadczenia i zasady, z którego tworzy się jednego lub więcej agentów. Zawiera dane uwierzytelniające.
• Blueprint Principal to rekord tworzony w dzierżawie podczas dodawania blueprintu. Służy do zarządzania blueprintem i jego audytu w dzierżawie.
• Agent Identity to rzeczywista tożsamość wykonawcza agenta AI. Nie ma własnego hasła ani sekretu, lecz uwierzytelnia się tokenem za pośrednictwem nadrzędnego blueprintu.

W przypadku Agent Identities i Blueprint Principals obszar Details pokazuje dodatkowo Agent: Yes oraz Semantic role z wartością Agent Identity lub Blueprint Principal. W szczegółach NHI pole Blueprint lineage występuje tylko dla Agent Identities i odsyła do powiązanego Blueprint Principal. Z kolei karta Child Identities obiektu Blueprint Principal pokazuje wszystkie Agent Identities utworzone na jego podstawie. Pozwala to ustalić zależnych agentów przed zmianą wspólnego blueprintu. Ustalenie dotyczące pojedynczej tożsamości wykonawczej nie pozwala bez sprawdzenia uznać, że ten sam problem dotyczy wszystkich Child Identities.

Osobne sprawdzanie App Owners i Sponsors

Karta Sponsors pojawia się dla Agent Identities i Blueprint Principals. Wymienia użytkowników lub grupy odpowiedzialne za cel i cykl życia agenta, bez przyznawania im poprzez tę relację technicznego dostępu administracyjnego. App Owners zarządzają natomiast technicznie poświadczeniami, konfiguracją i uprawnieniami. Przypisanie sponsora nie jest zatem uprawnieniem do zmiany obiektu.

Przy przekazaniu sprawy należy uzgodnić decyzję biznesową ze Sponsors, a realizację techniczną z App Owners. Na przykład planowana zmiana poświadczeń we wspólnym blueprincie dotyczy nie tylko analizowanego agenta: najpierw należy przejść przez Blueprint lineage, sprawdzić Child Identities w Blueprint Principal i uzgodnić z odpowiedzialnymi osobami cele, których dotyczy zmiana, oraz zależności dostępu. Zmiany wprowadza się wyłącznie w systemie źródłowym i po zatwierdzeniu; zmiana stanu w ITDR nie zastępuje tej kontroli.

Sparowane konto użytkownika agenta w Identities

Microsoft udostępnia opcjonalne agent’s user account, na przykład do zadań związanych ze skrzynką pocztową lub funkcjami podobnymi do Teams, w których agent musi działać jak użytkownik. Konto jest sparowane z Agent Identity, ale zachowuje się jak użytkownik, a nie Service Principal. Dlatego ITDR pokazuje je w Identities z tagiem Agent Identity i otwiera dla niego Identity Details, a nie stronę szczegółów NHI.

W Summary > Details takie konto pokazuje Agent: Yes dla powiązania oraz Blueprint lineage jako odnośnik do blueprintu, z którego utworzono sparowaną Agent Identity. Obszar Sponsors wskazuje użytkowników i grupy odpowiedzialne za cykl życia i dostęp sparowanego agenta. Rola managera przewidziana przez Microsoft dla tych kont nie jest obecnie wyświetlana w ITDR; brak wpisu managera nie dowodzi więc braku odpowiedzialnej osoby. W trakcie analizy konto użytkownika, tożsamość wykonawczą i relację z blueprintem należy dokumentować osobno i porównywać z danymi u dostawcy.

Analizowanie grup i urządzeń

W obszarze Groups wyszukiwanie można zawęzić za pomocą czterech filtrów: Deleted oznacza grupy usunięte u dostawcy, Mail Enabled — grupy, które mogą odbierać wiadomości e-mail, a Security Enabled — grupy, które mogą sterować dostępem do zasobów. Assignable to Roles oznacza grupy, do których można przypisywać role.

Kliknięcie Group Name otwiera Group Details z pobranymi metadanymi grupy oraz tabelami przypisanych użytkowników, grup i aplikacji. Podczas przeglądu dostępu należy potwierdzić u dostawcy źródłowego typ grupy, właściciela, relacje bezpośrednie i zagnieżdżone oraz uzasadnienie biznesowe. Mail Enabled nie informuje, czy grupa jest używana do nadawania uprawnień; w tym celu istotne jest Security Enabled.

W obszarze Devices można wyszukiwać urządzenia i filtrować je według State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed i Compliant. Widok obejmuje urządzenia osobiste i firmowe zarejestrowane w Microsoft Entra ID. Obiekt urządzenia jest tożsamością u dostawcy; Microsoft Entra registered, Microsoft Entra joined i Microsoft Entra hybrid joined to różne konteksty rejestracji lub dołączenia i nie są równoznaczne z zainstalowanym agentem Sophos Endpoint.

Kliknięcie Display Name otwiera widok Device Details. W zależności od typu urządzenia strona pokazuje pobrane metadane, przypisane tożsamości, istotne ustalenia i inne dostępne informacje. Managed, Compliant, Rooted i Ownership są informacjami pochodzącymi od dostawcy. Jeśli ich brakuje, na potrzeby analizy należy udokumentować wartość jako niedostępną lub nieznaną. Nie wolno na tej podstawie wyprowadzać stanów „unmanaged”, „non-compliant” ani „not rooted”, podobnie jak własności osobistej lub firmowej. Brakująca wartość nie jest ponadto równoznaczna z wartością Unknown wyraźnie zgłoszoną przez dostawcę.

Metodyczne analizowanie Identity Details

W widoku Identities kliknięcie Display Name otwiera stronę Identity Details. Zamiast przeglądać każdą kartę bez postawionej hipotezy, zaleca się następującą procedurę:

1. Potwierdzić obiekt: porównać nazwę wyświetlaną, stan, typ, adresy e-mail i kontekst dostawcy z oczekiwanym użytkownikiem.
2. Określić priorytet: sprawdzić Risk Score, czynniki składowe, otwarte ustalenia oraz kontekst Compromised, Admin, MFA i Dormant. Wynik pomaga ustalić priorytet analizy, ale jej nie zastępuje.
3. Zweryfikować wiarygodność profilu i zasobów: porównać rolę, dział, region, strukturę organizacyjną oraz przypisane urządzenia Intune z oczekiwanym profilem.
4. Przeanalizować aktywność: ustawić zakres czasu i sprawdzić udane oraz nieudane logowania, pory, kraje, adresy IP i numery ASN pod kątem odchyleń.
5. Otworzyć powiązane dowody: analizować osobno ustalenia, detekcje, grupy i dane z dark webu, zamiast wnioskować o przyczynie na podstawie podsumowania.
6. Zweryfikować w systemie źródłowym: sprawdzić dane w Entra ID, lokalnym AD, Intune oraz, w razie potrzeby, w telemetrii XDR. Następnie wprowadzić zmiany techniczne w odpowiednim systemie źródłowym. Jeżeli zamiast tego przewidziano wyraźnie zatwierdzone działanie reagowania ITDR, skorzystać z dostępnego punktu wejścia Actions.
7. Sprawdzić wynik: po wprowadzeniu poprawki lub wykonaniu działania reagowania ponownie skontrolować wynik u dostawcy i w ITDR oraz udokumentować, który widok został już zaktualizowany, a który nadal oczekuje na kolejny cykl pobierania danych.

Summary

Sekcja Summary łączy profil, priorytet i najnowszą aktywność. W obszarze Details znajdują się dostępne informacje Entra ID, takie jak rola, dział, stan, kraj i region, czas utworzenia i modyfikacji, ostatnia zmiana hasła oraz inne przypisane adresy e-mail. Assets pokazuje urządzenia Intune przypisane użytkownikowi w Entra ID. Multi-Factor Authentication wskazuje dostawcę MFA, podstawową metodę MFA i inne skonfigurowane typy MFA. Kontekst organizacyjny zapewnia sekcja Organization, która prezentuje przełożonych, bezpośrednich podwładnych i strukturę organizacyjną; kliknięcie osoby otwiera ją w nowej karcie.

Wybrana tożsamość jest wyróżniona na schemacie organizacyjnym. Każda karta osoby pokazuje imię i nazwisko, rolę i dział lub zespół, odpowiednie ikony i tagi, takie jak Admin, bieżący Risk Score w prawym górnym rogu oraz liczbę otwartych ustaleń według poziomu ryzyka albo informację o ich braku. W przypadku konta użytkownika agenta sprawdza się także opisane powyżej pola agenta i Sponsors; struktura podległości służbowej ludzi nie jest równoważna tym relacjom odpowiedzialności.

Na potrzeby oceny bezpieczeństwa sekcja Recent Detections pokazuje Open Detections z ostatnich siedmiu dni i Closed Detections z ostatnich 30 dni; View All prowadzi do sekcji Insights. Risk Score zawiera aktualny wynik i najważniejsze czynniki składowe. Top Sign-in Locations podsumowuje najczęstsze lokalizacje logowania wraz z aktywnością z publicznych i prywatnych adresów IP. Jeśli dane są dostępne, sekcja Commonly Used Entities klasyfikuje udane uwierzytelnienia z ostatnich 30 dni według IP Addresses, Browser, Asset Name i OS Version.

W obszarze Top Sign-in Locations > View Details dla ostatnich 30 dni są wyświetlane przede wszystkim lokalizacja geograficzna, ASN i częstotliwość występowania najważniejszych adresów IP. IP type i Login outcome służą tam jako filtry; nie należy zakładać, że muszą występować jako wyświetlane kolumny wyników. Prywatnych adresów IP nie należy interpretować geograficznie tak jak adresów publicznych. Często pojawiające się miasto może wynikać z ruchu wychodzącego przez VPN lub chmurę; nieznany kraj może uzasadniać sprawdzenie, ale bez kontekstu czasu, urządzenia i dostawcy nie stanowi jeszcze incydentu.

Activity Log

Sekcja Activity Log pokazuje aktywność uwierzytelniania w okresie wybranym w prawym górnym rogu. Wskaźniki Total Activities, Successful Logins i Failed Logins przedstawiają najpierw wolumen. Do oceny przestrzennej sekcja Top sign-in locations pokazuje kraje, adresy IP, liczbę zdarzeń i rozkład na publiczne oraz prywatne adresy IP. Authentication locations uzupełnia te informacje o najczęstsze uwierzytelnienia z ostatnich 30 dni według adresu IP i ASN oraz umożliwia wyszukiwanie według lokalizacji, adresu IP lub ASN. Przebieg w czasie przedstawiają Logins per day, z oddzielnie pokazanymi udanymi i nieudanymi logowaniami, oraz Activity map w formie mapy cieplnej według dnia tygodnia i pory dnia.

Ten widok ITDR podsumowuje agregaty i wzorce. Nie zawiera tabeli zdarzeń, w której wszystkie te informacje byłyby zestawione obok siebie dla każdego logowania. Browser, Asset Name i OS Version należy natomiast oceniać jako 30-dniowe agregaty profilowe udanych uwierzytelnień w obszarze Summary > Commonly Used Entities i nie wolno przypisywać ich do pojedynczego wpisu w Activity Log. Do korelacji zdarzeń według dokładnego czasu i strefy czasowej, wyniku, źródłowego adresu IP, ASN, kraju, urządzenia, przeglądarki, systemu operacyjnego lub sąsiednich detections należy używać dostępnych dzienników zdarzeń Entra lub XDR. Częste nieudane próby w agregatach ITDR mogą wynikać z błędu użytkownika, nieaktualnych danych uwierzytelniających albo ataku; rozstrzyga o tym dopiero korelacja z dowodami dotyczącymi zdarzeń.

Findings, Insights, Group Membership i Dark Web Intelligence

Sekcja Findings wyświetla ustalenia dotyczące tej tożsamości według poziomu ryzyka. Pełny tekst w polu Recommendation pojawia się po najechaniu kursorem; kliknięcie nazwy ustalenia otwiera szczegóły. Należy wtedy sprawdzić stan, ryzyko, kategorię, powiązane dowody i zalecany sposób naprawy. Ręczna zmiana stanu nie jest tym samym co techniczne usunięcie problemu u dostawcy.

Sekcja Insights domyślnie pokazuje Open Detections z ostatnich siedmiu dni; okres można zmienić za pomocą narzędzia Date Picker. Closed Detections obejmuje ostatnie 30 dni. Brak wyników w domyślnym okresie nie wyklucza zatem wcześniejszej aktywności.

Sekcja Group Membership wyświetla grupy użytkownika. Pole wyszukiwania zawęża listę; kliknięcie Group Name otwiera grupę i jej pozostałych członków. Szczególnie istotne są nieoczekiwane członkostwa uprzywilejowane, umożliwiające przypisywanie ról, zagnieżdżone lub niepotrzebne już z biznesowego punktu widzenia. Zmiany wprowadza się u dostawcy źródłowego.

Sekcja Dark Web Intelligence pokazuje dane o wyciekach powiązane z tożsamością. Kliknięcie Breach Source otwiera odpowiedni rekord. Rekord dokumentuje ujawnienie danych uwierzytelniających. Na potrzeby oceny należy łącznie sprawdzić czas wycieku, kontekst publikacji lub naruszenia, stan konta i ostatnią zmianę hasła. Rekord nie dowodzi automatycznie, że obecnie używane dane uwierzytelniające są ważne ani że doszło do logowania.

Uwzględnianie granic danych dostawców i czasów aktualizacji

Sophos ITDR obsługuje Microsoft Entra ID i lokalne Active Directory, jednak nie każdy dostawca udostępnia te same obiekty i pola. W integracji obejmującej wyłącznie lokalne AD mogą nie być dostępne dane specyficzne dla chmury, takie jak zasoby Intune, jednostki usługi Entra, metody MFA czy aktywność logowania Entra. Z kolei lokalny sensor ITDR rejestruje dodatkowe typy obiektów AD na potrzeby kontroli stanu zabezpieczeń; nie powoduje to jednak automatycznie kompletności kart chmurowych.

Po początkowym pełnym pobraniu danych Entra ITDR sprawdza aktualizacje z różną częstotliwością zależnie od typu danych: szczegóły użytkowników, jednostek usługi, aplikacji, grup i urządzeń mniej więcej co dziesięć minut, konfigurację MFA mniej więcej co 15 minut, ostatnie logowanie użytkownika mniej więcej co sześć godzin, a dane domeny mniej więcej co 24 godziny. Są to interwały pobierania, a nie gwarancja, że Microsoft udostępnił już zmienioną informację źródłową przez swoje API.

Do uzyskania przewidzianego zakresu danych ITDR wymagana jest licencja Entra ID P1 lub P2. W przypadku Entra ID Free interfejsy API i kontrole stanu zabezpieczeń są ograniczone, dlatego integracja może wyświetlać stan Provisioning Failed. Po podwyższeniu poziomu licencji informacje administracyjne lub MFA w systemie Microsoft mogą pozostawać nieaktualne nawet przez tydzień. W takim przypadku należy najpierw sprawdzić odpowiedni raport aktywności Microsoft Entra. Jeśli sam widok u dostawcy nie został jeszcze zaktualizowany, ITDR nie może pokazać nowszego stanu.

MFA innego producenta w starszej konfiguracji Okta lub Duo może być również wyświetlane jako brak ochrony, ponieważ Entra nie przechowuje informacji MFA na poziomie użytkownika. Wartości Has MFA = false nie wolno wtedy traktować w oderwaniu jako dowodu braku kontroli MFA. Konfiguracja dostawcy, Conditional Access, aktualne External Authentication Methods i kontrolowany test logowania muszą być ze sobą zgodne.

Weryfikacja i rozwiązywanie problemów

Brak obiektu lub obiekt na niewłaściwej karcie

1. Zresetować aktywne wyszukiwanie i filtry oraz sprawdzić pisownię i alternatywną nazwę wyświetlaną.
2. Sprawdzić, czy właściwym widokiem jest Identities, Groups, Devices czy Non-Human Identities. Sparowane konto użytkownika agenta należy do Identities, natomiast Agent Identity i Blueprint Principal — do widoku NHI.
3. Potwierdzić dzierżawę i źródłowego dostawcę tożsamości; w przypadku aplikacji rozróżnić Application Object, Service Principal, App/Client ID i Object ID, a w przypadku agentów dodatkowo sprawdzić Semantic role i Blueprint lineage.
4. Wyszukać obiekt bezpośrednio u dostawcy, sprawdzić jego stan i ustalić, czy został usunięty oraz czy ma kontekst Guest, Cloud Only, Hybrid lub Service.
5. W ustawieniach integracji ITDR sprawdzić stan i ostatnie udane pobranie. Nie uruchamiać w zastępstwie ponownej synchronizacji Central Directory Sync.
6. Ponowić sprawdzenie dopiero po upływie okna pobierania właściwego dla danego typu danych i udokumentować czasy.

Pusty lub nieoczekiwany filtr albo pole MFA, administratora lub urządzenia

• Usunąć filtry i sprawdzić surowy atrybut u dostawcy.
• Sprawdzić licencję Entra, dostępność API i stan integracji.
• W przypadku MFA sprawdzić dodatkowo dostawcę, metodę podstawową i pozostałe metody oraz konfigurację innego producenta.
• W przypadku urządzeń rozróżnić rejestrację lub dołączenie, zarządzanie przez Intune, zgodność oraz ochronę Sophos Endpoint.
• Po zmianach licencji lub atrybutów zweryfikować najpierw zaktualizowany widok u dostawcy, a nie tylko ITDR.
• Wartość pustą, No data lub brak tagu udokumentować jako stan nieznany, a nie jako „nie”.

Lokalizacja logowania lub wzorzec aktywności wygląda podejrzanie

W sekcji Activity Log należy najpierw porównać zakres czasu, wolumen logowań, agregaty sukcesów i niepowodzeń, kraje, adresy IP, ASN oraz wzorce dni i godzin. W obszarze Top Sign-in Locations można użyć IP type i Login outcome jako filtrów.

Browser, Asset Name i OS Version należy osobno ocenić w sekcji Commonly Used Entities jako agregaty 30-dniowe. Dokładny czas zdarzenia i strefę czasową, a także wynik, urządzenie, przeglądarkę i system operacyjny pojedynczego logowania należy następnie skorelować w dostępnych dziennikach zdarzeń Entra lub XDR. Trzeba przy tym sprawdzić również powiązane Findings i Insights.

NAT, VPN, sieci komórkowe, ruch wychodzący przez chmurę i podróże mogą zmieniać wyświetlaną lokalizację. W przypadku potwierdzonego ryzyka działania reagowania należy wykonywać wyłącznie zgodnie z wewnętrznym procesem obsługi incydentów i przy użyciu wymaganych uprawnień.

Weryfikacja widoku po usunięciu problemu

Najpierw należy potwierdzić zmianę techniczną w systemie źródłowym. Następnie zaczekać do spodziewanego czasu pobrania danych przez ITDR, zresetować filtry i ponownie otworzyć tę samą tożsamość lub ten sam obiekt. Sprawdzić poprawione pole, zależne tagi, powiązane ustalenia oraz właściwy okres analizy. Risk Score, ustalenia i atrybuty dostawcy mogą mieć różne cykle aktualizacji; wynik, który jeszcze się nie zmienił, nie podważa udanej zmiany w źródle. Jeśli widok pozostaje nieprawidłowy po upływie oczekiwanego okna, na potrzeby eskalacji należy zabezpieczyć dowód od dostawcy, dzierżawę, identyfikator obiektu, czas zmiany, stan integracji i zrzuty ekranu.

Udokumentowane zakończenie analizy

Na zakończenie należy udokumentować obiekt, dzierżawę, dostawcę i typ tożsamości. Trzeba również odnotować użyte wyszukiwanie i filtry, okres analizy, sprawdzone obszary szczegółowe, brakujące dane dostawcy oraz wyniki weryfikacji w systemie źródłowym i w ITDR. Kontekst Human i NHI, a także Application Object i Service Principal, muszą przy tym pozostać rozdzielone.