Bezpieczna ocena Sophos ITDR Identity Risk Score

Identity Risk Score ocenia ryzyko pojedynczej tożsamości użytkownika w skali od 0 do 10. Łączy prawdopodobieństwo incydentu bezpieczeństwa z potencjalnymi skutkami przejęcia tożsamości. Wysoka wartość jest więc sygnałem pomagającym ustalić priorytet, ale nie stanowi dowodu przejęcia ani automatycznego polecenia działania.

W codziennym triage sortuj według Risk Score malejąco, przeglądaj Contributing factors najwyżej sklasyfikowanych tożsamości i w pierwszej kolejności usuwaj otwarte ustalenia krytyczne lub wysokie oraz Security Factors, na które można bezpośrednio wpływać. Sama wartość liczbowa nie wystarcza do podjęcia uzasadnionej decyzji.

Gdzie znaleźć Risk Score

Sophos ITDR pokazuje wartość w trzech miejscach:

• W obszarze My Products > Identity > Directory > Identities tabela zawiera kolumnę Risk Score. W widoku kart wartość jest widoczna w prawym górnym rogu każdej karty.
• Po wybraniu tożsamości widok Identity Details > Summary pokazuje panel Risk Score z polami Current score, Contributing factors i czasem ostatniego obliczenia.
• W obszarze My Products > Identity > Identity Overview widżet Top 5 Risky Users łączy wysokie wyniki z otwartymi ustaleniami. Każdy wpis pokazuje nazwę tożsamości, otwarte ustalenia według ważności i bieżący wynik.

Do pełnej kontroli użyj ścieżki Directory > Identities > Identity Details > Summary. Widżet przeglądu pomaga szybko ustalić priorytety, ale nie zastępuje widoku szczegółowego.

Prawidłowa interpretacja pięciu przedziałów wyniku

Granice przedziałów są stałe, ale wagi czynników nie. Dlatego nie można obliczyć dokładnego wyniku na podstawie listy atrybutów. Dwóch użytkowników pełniących tę samą funkcję może mieć różne wyniki ze względu na stan MFA, role administracyjne, status gościa, ustalenia, lokalizację logowania albo wcześniejsze alerty i działania dochodzeniowe.

Niski wynik również nie gwarantuje bezpieczeństwa. Odzwierciedla jedynie ocenę sygnałów, które są obecnie dostępne dla modelu. Brak telemetrii, nieukończone tworzenie poziomu bazowego lub później wykryte ustalenie mogą zmienić klasyfikację.

Które tożsamości otrzymują wynik

Risk Scores są obecnie obliczane dla tożsamości użytkowników Active z Microsoft Entra ID i lokalnego Active Directory. Tożsamości ze statusem Deleted lub Disabled u dostawcy tożsamości nie otrzymują Risk Score. Tożsamości aplikacji i jednostki usługi są obecnie wyłączone z zakresu.

Zakres ten ma znaczenie przy dokonywaniu porównań: tożsamość bez wartości nie jest automatycznie niskim ryzykiem. Najpierw sprawdź jej typ tożsamości i status u podłączonego dostawcy tożsamości. Brak wartości jest wskazówką diagnostyczną tylko wtedy, gdy chodzi o aktywną tożsamość użytkownika.

Rozróżnianie Security Factors i Profile Factors

Panel Contributing factors rozróżnia dwa rodzaje wpływu:

• Factors raising Risk Score pokazuje czynniki zwiększające bieżącą wartość.
• Factors lowering Risk Score pokazuje czynniki ją obniżające.

W obu grupach Sophos rozróżnia Security Factors i Profile Factors.

Security Factors: Najpierw należy działać

Security Factors opisują stan zabezpieczeń, konfigurację i znaną aktywność. Czynniki, na które można wpływać bezpośrednio, obejmują:

• brak MFA;
• MFA bez metody bezhasłowej;
• otwarte ustalenia, określane w panelu jako Identity Exposures;
• administracyjne lub uprzywilejowane role katalogowe;
• status gościa;
• aktywne wycieki danych uwierzytelniających;
• duża liczba powiązanych adresów e-mail.

Inne sygnały obejmują konto hybrydowe synchronizowane z katalogu lokalnego oraz historię alertów i dochodzeń. Żadnego z nich nie można usunąć pojedynczą zmianą tożsamości: status hybrydowy opisuje architekturę katalogu, a historia odzwierciedla wcześniejsze alerty i dochodzenia.

Czynniki obniżające wynik obejmują wymuszone MFA, bezhasłową metodę MFA, historię bez istotnych alertów lub dochodzeń, ustalenia, których przyczyny usunięto, albo ustalenia oznaczone jako Dismissed, usunięcie zbędnych ról administratora i mniejszą liczbę powiązanych adresów e-mail. Model waży te sygnały; ta lista nie jest tabelą punktów addytywnych.

Profile Factors: Kontekst zamiast celu naprawczego

Profile Factors odnoszą się do atrybutów tożsamości, na przykład:

• Department;
• Job Title;
• City;
• Employee Type;
• obecność lub brak przełożonego;
• monitorowanie VIP, widoczne w panelu jako High-value identity, prioritize monitoring.

Te cechy mogą zwiększać lub zmniejszać wynik, ale zazwyczaj nie są błędami konfiguracji zabezpieczeń. Nie należy zmieniać działu, stanowiska ani lokalizacji wyłącznie po to, aby obniżyć liczbę. Błędne lub nieaktualne dane podstawowe można poprawić; prawidłowe dane profilu należy zachować jako kontekst ryzyka.

Puste pola, takie jak Department, Employee Type lub Job Title, nie muszą być neutralne. Model może oceniać brakujące informacje na podstawie podobnych tożsamości i wyciągać z nich kontekst ryzyka. Kompletne i poprawne dane katalogowe zapewniają zatem dokładniejszy kontekst, ale nie gwarantują konkretnego wyniku ani kierunku jego zmiany.

Według Sophos aktywne wycieki danych uwierzytelniających, status hybrydowy i monitorowanie VIP mogą podnosić wynik, ale nie przyczyniają się do jego obniżenia. Nie oznacza to, że monitorowanie VIP powinno zostać wyłączone: oznaczenie celowo zwiększa widoczność cennej tożsamości i nie powinno być usuwane tylko po to, aby poprawić wynik.

Co oznacza No data

Jeżeli sekcja panelu Risk Score pokazuje No data, w tej konkretnej kategorii nie ma żadnych czynników. Nie oznacza to automatycznie, że nie ma danych dotyczących całej tożsamości lub że jej integracja jest wadliwa.

Sprawdź kolejno:

1. Czy No data występuje tylko w podsekcji, na przykład w obniżających wynik Profile Factors?
2. Czy są jakieś czynniki w innych grupach?
3. Czy czas ostatniego obliczenia widoczny na dole panelu jest wiarygodny?
4. Czy jest to aktywna tożsamość użytkownika?
5. Czy oczekiwane atrybuty katalogowe i ustalenia są dostępne we właściwych miejscach?

Sprawdź dostarczanie danych przez integrację dopiero wtedy, gdy brakuje kilku oczekiwanych obszarów, czas obliczenia jest niewiarygodny lub aktywna tożsamość użytkownika w ogóle nie otrzymuje wyniku.

Uwzględnianie poziomu bazowego i cykli obliczeń

W przypadku nowego tenantu lub nowo dodanej tożsamości użytkownika ITDR najpierw tworzy profil zachowania. Dlatego wiele nowych tożsamości może pozostawać w przedziale Informational nawet przez 30 dni. Jest to możliwy okres budowania poziomu bazowego, a nie czas, w którym wolno ignorować ustalenia: otwarte ustalenia mogą podnieść wynik nawet nowej tożsamości.

Wyniki są przeliczane w codziennym cyklu oceny. Ponowne obliczenie może także nastąpić, gdy ITDR wykryje zmianę konta lub ustalenia. Wynik może zmienić się z dnia na dzień nawet bez widocznej zmiany w katalogu, ponieważ model uwzględnia historię alertów i dochodzeń oraz z czasem zmienia ich wagę.

Wkrótce po usunięciu przyczyny ustalenia może pojawić się zaktualizowana wartość. Ustalenia, których przyczyny usunięto, są jednak uwzględniane ze zmniejszoną wagą do następnego dziennego cyklu oceny; pełny efekt jest więc widoczny dopiero w wyniku następnego dnia. Mechanizmy te nie gwarantują konkretnej godziny aktualizacji ani dokładnie przewidywalnej zmiany liczby punktów.

Ograniczenia modelu ML

Risk Score pochodzi z modelu uczenia maszynowego, a nie ze stałej listy kontrolnej. Czynniki nie są ważone jednakowo, więc te same widoczne czynniki niekoniecznie muszą wytwarzać ten sam wynik lub tę samą zmianę dla dwóch tożsamości.

Według Sophos model jest trenowany na zagregowanych sygnałach dotyczących zachowania i kont z bazy klientów ITDR; wynik danej tożsamości jest obliczany na podstawie bieżących danych jej własnego tenantu. Niemniej jednak, istnieją wyraźne granice operacyjne:

• Wynik wskazuje na priorytet, a nie przyczynę incydentu. Ustalenie przyczyny wymaga ustaleń i dalszych wyników dochodzenia.
• Wysoka wartość nie dowodzi przejęcia. Uprzywilejowana tożsamość o słabym poziomie zabezpieczeń może otrzymać wysoki wynik nawet bez zaobserwowanej podejrzanej aktywności.
• Niska wartość nie dowodzi braku zagrożenia.
• Pokazane czynniki są operacyjnym wyjaśnieniem tej tożsamości, ale nie wzorem, z którego można odtworzyć wartość liczbową.
• Sama zmiana wyniku nie jest dowodem na to, że środek okazał się skuteczny technicznie.

Bezpieczne podejście polega na odczytaniu przyczyny w panelu, osobnym zweryfikowaniu podstawowej konfiguracji lub ustalenia, a dopiero potem wykorzystaniu wyniku jako dodatkowego wskaźnika efektu.

Bezpiecznie priorytetyzuj tożsamości

Sortowanie wyłącznie według najwyższej wartości liczbowej może prowadzić do pominięcia ważnego kontekstu. Postępuj zgodnie z poniższą procedurą:

1. W obszarze Directory > Identities sortuj według Risk Score malejąco.
2. Otwórz Identity Details > Summary dla najwyżej sklasyfikowanych tożsamości.
3. W sekcji Contributing factors sprawdź, czy występują otwarte krytyczne lub wysokie Identity Exposures.
4. Nadaj krytycznym i wysokim ustaleniom oraz aktywnym wyciekom danych uwierzytelniających wyższy priorytet niż samemu kontekstowi profilu.
5. Przy takiej samej pilności najpierw zbadaj tożsamości uprzywilejowane, administracyjne i monitorowane jako VIP ze względu na ich potencjalny wpływ.
6. Dla każdego działania zanotuj wartość początkową, pasmo, znacznik czasu i konkretny czynnik podnoszący wynik.
7. Usuń przyczynę źródłową; nie optymalizuj wyniku kosmetycznie.

Typowe bezpieczne działania obejmują usunięcie przyczyny krytycznych i wysokich ustaleń, wymuszenie MFA oraz, w miarę możliwości, udostępnienie bezhasłowej metody MFA. Aktywne wycieki danych uwierzytelniających obsługuj zgodnie z zatwierdzonym procesem reagowania na incydenty. Odbierz zbędne role administratora i usuń niepotrzebne powiązane adresy e-mail; w odpowiednich przypadkach przekształć konta gości w konta zarządzane. Każda zmiana wymaga standardowych zatwierdzeń obowiązujących w organizacji i osobnej kontroli działania.

Potwierdzenie efektu po zastosowaniu środka

Solidna kontrola oddziela skuteczność techniczną od odpowiedzi modelu:

1. Zapisz stan początkowy: Zanotuj tożsamość, Current score, pasmo, Factors raising Risk Score, otwarte ustalenia i znacznik czasu ostatniego obliczenia.
2. Usuń przyczynę: Na przykład faktycznie wymuś MFA u dostawcy tożsamości lub po zatwierdzeniu usuń zbędną rolę. Nie należy zmieniać kilku niezależnych czynników w tym samym czasie, jeśli efekt ma pozostać identyfikowalny.
3. Sprawdź stan techniczny: Sprawdź we właściwym systemie, czy zmiana jest skuteczna. Risk Score nie jest jej podstawowym potwierdzeniem.
4. Sprawdź dane ITDR: W widoku Identity Details > Summary potwierdź, że odpowiedni czynnik lub ustalenie jest prawidłowo wyświetlane po przetworzeniu.
5. Poczekaj na ponowne obliczenie: Sprawdź znacznik czasu na dole panelu. Po usunięciu przyczyny ustalenia sprawdź aktualizację krótkoterminową, a pełny efekt oceń po następnym cyklu dziennym.
6. Porównaj wynik: Porównaj wynik, pasmo i czynniki ze stanem początkowym. Oczekuj spójnego odzwierciedlenia usuniętej przyczyny, a nie z góry określonego wyniku.
7. Usuń pozostałe przyczyny: Jeśli wartość pozostaje wysoka, przejrzyj pozostałe Security Factors, otwarte ustalenia, a następnie kontekst profilu.

Walidacja jest zakończona po potwierdzeniu trzech elementów: środek techniczny jest skuteczny, ITDR prawidłowo wyświetla czynnik bazowy, a następne obliczenie wyniku jest wiarygodne w świetle pozostałych sygnałów.

Rozwiązywanie problemów z nieoczekiwanymi wynikami

Wynik nagle wzrasta gwałtownie

Najpierw otwórz widok szczegółów i poszukaj w sekcji Factors raising Risk Score nowych Identity Exposures, zwłaszcza krytycznych lub wysokich ustaleń. Następnie porównaj MFA, role, status gościa, wycieki danych uwierzytelniających i czas obliczenia. Skok nie dowodzi incydentu, ale wynik w przedziale krytycznym lub wysokim wymaga szybkiego dochodzenia.

Wynik nie zmniejsza się zgodnie z oczekiwaniami po korekcie

Sprawdź, czy zmiana rzeczywiście działa u właściwego dostawcy tożsamości i czy ITDR pokazuje już zaktualizowany czynnik. Ustalenie, którego przyczynę usunięto, może zachować zmniejszoną wagę resztkową do następnego cyklu dziennego. Jeśli później wynik nadal jest podwyższony, zbadaj pozostałe czynniki; nie oczekuj stałego spadku liczby punktów po jednym działaniu.

Wynik zmienia się bez zmiany katalogu

Nie musi to oznaczać błędu. Codzienne przeliczanie oraz upływ czasu od alertów i działań dochodzeniowych mogą zmieniać wartość. Zapisz poprzedni i nowy wynik, oba czasy obliczeń oraz wyświetlane czynniki. Badaj integrację dalej tylko wtedy, gdy dane są sprzeczne lub znacznik czasu jest niewiarygodny.

Aktywna tożsamość użytkownika nie ma wyniku

Najpierw potwierdź u dostawcy tożsamości status Active, typ User oraz przypisanie do podłączonego źródła Entra ID lub Active Directory. Następnie sprawdź, czy w ITDR są widoczne inne aktualne atrybuty tej tożsamości. Deleted, Disabled, aplikacje i jednostki usługi pozostają poza obecnym zakresem wyniku.

Wiele nowych tożsamości pozostaje Informational

Sprawdź datę wdrożenia i otwarte ustalenia. Taki stan może być normalny podczas trwającego do 30 dni okresu budowania poziomu bazowego. Otwarte ustalenia nadal wymagają natychmiastowej reakcji. Jeśli po 30 dniach wiele tożsamości pozostaje w przedziale Informational, sprawdź czas obliczenia, wyświetlane czynniki i aktualność danych, aby ustalić, czy ITDR przetwarza oczekiwane sygnały.

Jeżeli nie można wyjaśnić nieoczekiwanego stanu, zapisz oznaczenie tożsamości bez zbędnych dodatkowych danych osobowych, a także jej źródło, status, wynik, przedział, widoczne czynniki, czas obliczenia, odpowiednie identyfikatory ustaleń oraz czas ostatniej zatwierdzonej zmiany. Te szczegóły umożliwiają ukierunkowaną eskalację bez wyciągania niesprawdzonej przyczyny z samego wyniku.