Czym jest ITDR i czy go potrzebujemy?

Luka, którą ma wypełnić ITDR

Większość kontroli bezpieczeństwa jest dostrojona, żeby łapać coś, co wygląda źle. Narzędzia endpointowe szukają malware'u i podejrzanych procesów. Narzędzia sieciowe szukają ruchu, którego nie powinno tam być. Filtry e-mail szukają phishingu. Działają dobrze przeciwko atakom, w których gdzieś w łańcuchu jest rozpoznawalny zły obiekt.

Ataki na tożsamość coraz częściej w ogóle nie mają żadnego złego obiektu. Atakujący, który sphishował hasło i ciasteczko sesji, albo kupił działające dane uwierzytelniające od brokera dostępu, nie potrzebuje malware'u. Loguje się. Z punktu widzenia systemu ważne konto robi ważne rzeczy z ważnej sesji. Endpoint jest czysty. Ruch sieciowy jest zwyczajny. Nie ma pliku do poddania kwarantannie ani exploita do zablokowania, bo atakujący korzysta z frontowych drzwi dokładnie tak, jak zostały zaprojektowane.

To jest ta luka. Aktywność, która następuje po przejęciu danych uwierzytelniających, żyje w warstwie tożsamości, w logach uwierzytelniania i zdarzeniach katalogu, a ta warstwa jest jednocześnie najczęściej atakowaną rzeczą, jaką firma posiada, i jedną z najsłabiej obserwowanych. Raport Verizon 2026 Data Breach Investigations Report znalazł nadużycie danych uwierzytelniających w 39% naruszeń w całym łańcuchu ataku, co czyni je najbardziej wszechobecną techniką w tym zbiorze danych (Verizon, 2026). Dane samego Microsoftu to druga strona tego samego medalu: ponad 99,9% przejętych kont, które zaobserwowali, nie miało włączonego uwierzytelniania wieloskładnikowego, a MFA blokuje ponad 99,2% ataków polegających na przejęciu konta (Microsoft). MFA zamyka większość drzwi. ITDR dotyczy obserwowania tej części, której nie pokrywa mocne uwierzytelnianie, czyli tego, co dzieje się po ustanowieniu sesji, wliczając przypadki, w których atakujący pokonał albo ukradł drugi składnik.

Gartner sformalizował to, nazywając wykrywanie i reagowanie na zagrożenia tożsamości odrębną kategorią w swoich top trendach bezpieczeństwa i ryzyka na 2022, opisując ją jako zbiór narzędzi i najlepszych praktyk do obrony systemów tożsamości, i rekomendując organizacjom dodanie monitoringu technik ataku na tożsamość obok prewencyjnych kontroli tożsamości, które już miały (Gartner, 2022). To ujęcie ma znaczenie: ITDR to warstwa wykrywania i reagowania dla tożsamości, stojąca za kontrolami, które próbują nie wpuścić atakujących, na wypadek, gdyby te kontrole zawiodły.

Co ITDR faktycznie wykrywa

Ta kategoria jest definiowana mniej przez pojedynczą technologię, a bardziej przez zestaw sygnałów, które ma rozpoznawać. To zachowania odróżniające nadużytą tożsamość od legalnej, i większość z nich jest niewidoczna dla narzędzi endpointowych i sieciowych.

• Anomalne logowania i logowania niemożliwe pod względem podróży · Co robi atakujący: Logowanie się skradzionymi danymi uwierzytelniającymi z nowej lokalizacji · Sygnał: Logowanie geograficznie niemożliwe względem poprzedniego, nieznane urządzenie albo nietypowy wzorzec czasowy dla tego użytkownika
• MFA fatigue · Co robi atakujący: Zasypywanie próśb push po kradzieży hasła, w nadziei na przypadkowe tapnięcie · Sygnał: Seria powtarzających się próśb MFA, a potem zatwierdzenie, które nie pasuje do normalnego rytmu użytkownika
• Kradzież tokenu i sesji · Co robi atakujący: Odtworzenie skradzionego ciasteczka sesji, żeby całkowicie ominąć uwierzytelnianie · Sygnał: Ważna sesja pojawiająca się z nowego urządzenia albo IP bez świeżego logowania, więc sprawdzenie MFA nigdy się nie uruchamia
• Eskalacja uprawnień · Co robi atakujący: Przejście z podstawowego konta do kontroli administracyjnej · Sygnał: Konto zdobywające uprawnienia, których nie miało, albo uśpione uprzywilejowane konto, które się budzi
• Ataki na katalog · Co robi atakujący: Manipulowanie samym systemem tożsamości dla trwałości · Sygnał: Zmiany w konfiguracji katalogu, podejrzana replikacja albo znane wzorce ataku na Active Directory, jak fałszowanie ticketów

Warto zatrzymać się przy przypadku kradzieży tokenu, bo to ten, który pokonuje kontrolę, której większość firm ufa najbardziej. Gdy atakujący kradnie żywy token sesji przez zestaw phishingowy albo infostealera, nie tyle obchodzi MFA, co przybywa po nim. Sesja była już uwierzytelniona. Odtworzenie tego tokenu daje mu legalny dostęp bez konieczności zmierzenia się z ekranem logowania, dlatego samo mocne uwierzytelnianie tego nie widzi i dlatego detekcja kradzieży sesji i tokenu jest jednym z najwyraźniejszych powodów, dla których ta kategoria istnieje.

Detekcja to tylko połowa nazwy. Reagowanie w ITDR odnosi się do działania na te sygnały: wymuszenia dodatkowego wyzwania uwierzytelniającego, unieważnienia aktywnych sesji, wyłączenia konta albo rotacji danych uwierzytelniających, najlepiej wystarczająco szybko, żeby odciąć atakującego, zanim dostęp zamieni się w szkodę. Narzędzie, które tylko produkuje alerty w kolejce, nad którą nikt nie pracuje, to detekcja bez reagowania, i to jest częstsza porażka niż brakująca detekcja.

Jak ITDR ma się do narzędzi, które już masz

ITDR zachodzi na kilka rzeczy, które być może już prowadzisz, i w tym nakładaniu się żyje całe zamieszanie. Najczystszym sposobem, żeby rozdzielić tę czwórkę, jest pytanie, na jakie odpowiada każda z nich.

IAM (zarządzanie tożsamością i dostępem) decyduje, kto ma prawo wejść i do czego może sięgnąć. To warstwa polityki i provisioningu: konta, role, uprawnienia i samo logowanie. IAM jest prewencyjny. Rządzi dostępem przed i w momencie uwierzytelnienia. ITDR zaczyna się tam, gdzie kończy się IAM, po udanym logowaniu, obserwując, czy legalny dostęp jest nadużywany. Przydatne ujęcie: IAM to zamek i klucz, a ITDR to alarm, który zauważa, że klucz jest używany o trzeciej nad ranem przez kogoś, kto nie jest tobą.

EDR (endpoint detection and response) obserwuje urządzenia: laptopy, serwery, procesy, które na nich działają. Łapie malware, exploity i przejęcia na poziomie systemu. ITDR obserwuje tożsamości i zdarzenia uwierzytelniania. Te dwa się uzupełniają, bo prawdziwa intruzja zwykle przecina obie płaszczyzny. EDR może powiedzieć ci, że laptop zachowuje się dziwnie. ITDR może powiedzieć ci, czy ta dziwność wzięła się ze skradzionych danych uwierzytelniających i czy te same dane są teraz używane gdzie indziej. Prowadzone razem pozwalają śledzić atak zarówno przez urządzenie, jak i przez tożsamość, zamiast widzieć tylko połowę obrazu.

SIEM (security information and event management) to szeroka warstwa korelacji. Pobiera logi z całego środowiska, łącznie z logami tożsamości, i jest zbudowany pod kątem szerokości, dochodzeń i compliance. SIEM może trzymać zdarzenia tożsamości, ale szerokość to zarówno jego siła, jak i słabość: sygnał tożsamości przychodzi jako surowe logi wśród wszystkiego innego, a zamienienie tego w wysokiej jakości detekcję tożsamości wymaga reguł i tuningu, na które większość szczupłych zespołów nie ma czasu. ITDR to wyspecjalizowana wersja tej pracy. W dojrzałym setupie te dwa elementy wzmacniają się nawzajem, przy czym ITDR zasila SIEM bogatymi w kontekst alertami tożsamości i redukuje szum w warstwie tożsamości, zamiast z nim konkurować.

Żadne z nich nie zastępuje pozostałych. Błędem jest zakładanie, że skoro masz SIEM, albo skoro twój dostawca EDR wspomina o tożsamości, detekcje w warstwie tożsamości są już pokryte. Czasem są. Często zdarzenia tożsamości są zbierane, ale nie analizowane pod kątem konkretnych wzorców opisanych wyżej, a to jest różnica między posiadaniem logów a posiadaniem detekcji.

Czy firmy mid-market potrzebują dedykowanego narzędzia

To pytanie, wobec którego warto być szczerym, bo odpowiedź nie jest taka sama dla każdej firmy, a domyślna odpowiedź dostawcy, czyli tak, nie zawsze jest właściwa.

Zacznij od tego, gdzie faktycznie żyją twoje tożsamości. Jeśli twoja firma działa głównie na nowoczesnym chmurowym dostawcy tożsamości, jak Entra ID albo Okta, spora część wykrywania zagrożeń tożsamości jest już dostępna w środku. Ci dostawcy mają silniki ryzyka, które oceniają logowania, flagują niemożliwe podróże, wykrywają część wzorców odtwarzania tokenu, i pozwalają budować polityki dostępu warunkowego, które reagują automatycznie, wymuszając dodatkowe wyzwanie albo blokując ryzykowne logowanie. Dla firmy cloud-first, która jeszcze tego nie włączyła ani nie dostroiła, ruchem o najwyższej wartości jest skonfigurowanie tego, co już oferuje IdP, zanim zaczniesz oceniać cokolwiek nowego. Spora część podstawowej wartości ITDR leży nieużywana w licencji, za którą już płacisz.

Argument za dedykowanym narzędziem staje się mocniejszy, im bardziej skomplikowane jest twoje środowisko. Trzy warunki zwykle przechylają szalę:

• Hybrydowy Active Directory. Lokalny AD to wciąż miejsce, w którym duża część organizacji zarządza tożsamością, i jest to mocno atakowana, podatna warstwa, której nie obserwują chmurowe silniki ryzyka IdP. Wykrywanie ataków na katalog, fałszowania ticketów i ruchu bocznego wewnątrz AD to rdzeń tego, co robi dedykowane ITDR, a czego wbudowana detekcja chmurowa zwykle nie robi.
• Wiele magazynów tożsamości. Jeśli twoje tożsamości są rozproszone po więcej niż jednym IdP, AD i różnych kontach chmurowych i SaaS, natywna detekcja żadnego pojedynczego dostawcy nie widzi całego obrazu. Dedykowane narzędzie istnieje częściowo po to, żeby korelować dane między tymi magazynami, czyli robić dokładnie to, czego żaden pojedynczy magazyn nie potrafi zrobić dla pozostałych.
• Reagowanie, którego nie potrafisz inaczej wykonać. Wbudowana detekcja u części dostawców jest mocniejsza w wypatrywaniu zagrożenia niż w działaniu na nie w czasie rzeczywistym w całym majątku. Jeśli twoją luką jest reagowanie, nie widoczność, to konkretna rzecz, którą trzeba ocenić, a nie założyć.

Jest też pytanie o zdolność, które nie ma nic wspólnego z funkcjami. Detekcja tożsamości produkuje alerty, a alerty obniżają ryzyko tylko wtedy, gdy ktoś na nie reaguje. Szczupłemu zespołowi, który nie nadąża z alertami, które już dostaje, nie pomoże narzędzie generujące ich więcej. Dla części firm mid-market realistyczną ścieżką jest usługa managed, która prowadzi detekcję i reagowanie w ich imieniu, zamiast produktu, którym muszą sami operować. To legalna odpowiedź, a czasem właściwa.

Uczciwe podsumowanie: jeśli jesteś cloud-first z jednym uporządkowanym IdP, najpierw dostrój to, co masz, i może się okazać, że to pokrywa realistyczne ryzyko. Jeśli prowadzisz hybrydowy AD, kilka magazynów tożsamości, albo masz widoczność, ale nie masz szybkiego sposobu na reagowanie, to tam dedykowana zdolność zdobywa swoje miejsce. Decyzja powinna wynikać z twojego faktycznego środowiska, nie z samego istnienia tej kategorii.

Gdzie ITDR mieści się w sekwencji dojrzałości

ITDR to kontrola wykrywania i reagowania, co umieszcza ją później w sekwencji niż prewencja, która powinna być pierwsza. Kolejność, która sprawdza się dla większości zespołów mid-market, to: najpierw dopracuj prewencyjne kontrole tożsamości, potem dodaj detekcję na tym, co zostało.

Konkretnie oznacza to odporne na phishing MFA, uporządkowanego dostawcę tożsamości ze skonfigurowanym dostępem warunkowym, zamknięte konta uprzywilejowane i offboarding, który faktycznie usuwa dostęp. To obniża liczbę ataków na tożsamość, które w ogóle się udają, co oznacza mniej zdarzeń do złapania dla jakiejkolwiek warstwy detekcji. ITDR obserwuje ataki, które i tak się przebiją, skradzioną sesję pojawiającą się po uwierzytelnieniu, dane uwierzytelniające, które były ważne, bo były prawdziwe. Dodanie detekcji, zanim prewencja jest na miejscu, zwykle produkuje mnóstwo alertów o problemach, którym można było zapobiec taniej. Dodanie jej później oznacza, że alerty, które dostajesz, to te, które naprawdę wymagały człowieka.

Źródła

• Gartner Identifies Top Security and Risk Management Trends for 2022 · https://www.gartner.com/en/newsroom/press-releases/2022-03-07-gartner-identifies-top-security-and-risk-management-trends-for-2022 (Gartner nazywa ITDR top trendem 2022 i definiuje go jako narzędzia i praktyki do obrony systemów tożsamości)
• Identity Threat Detection and Response (ITDR) Explained, CrowdStrike · https://www.crowdstrike.com/en-us/cybersecurity-101/identity-protection/identity-threat-detection-and-response-itdr/ (definicja ITDR, ITDR kontra EDR, ITDR kontra IAM, możliwości reagowania)
• 2025 Data Breach Investigations Report, Verizon · https://www.verizon.com/business/resources/reports/dbir/ (rozpowszechnienie nadużycia danych uwierzytelniających i dane o dostępie początkowym przez skradzione dane uwierzytelniające)
• Cyber Signals and MFA guidance, Microsoft · https://www.microsoft.com/security/blog/ (MFA blokuje ponad 99,2% ataków polegających na przejęciu konta; ponad 99,9% przejętych kont nie miało MFA)
• ITDR vs SIEM: Do you need both?, Expel · https://expel.com/cyberspeak/itdr-vs-siem/ (jak ITDR i SIEM się uzupełniają, zamiast konkurować)
• Identity Threat Protection with Okta AI · https://www.okta.com/blog/ai/identity-threat-protection-with-okta-ai/ (zakres wbudowanej detekcji IdP i granice pokrycia chmura kontra lokalnie)