EDR a MDR: dlaczego samo ESET Inspect nie oznacza monitoringu bezpieczeństwa 24/7?
W środę o 23:47 na jednej ze stacji roboczych księgowości uruchamia się PowerShell (narzędzie, z którego ten konkretny użytkownik wcześniej nigdy nie korzystał). Proces nawiązuje połączenie z zewnętrznym adresem IP. ESET Inspect rejestruje to zdarzenie i generuje detekcję zgodną z taktykami macierzy MITRE ATT&CK.
Co dzieje się dalej? Odpowiedź na to pytanie to właśnie główna różnica między EDR a MDR – i punkt, w którym wiele organizacji zderza się ze ścianą, odkrywając lukę między tym, co technologia potrafi wykryć, a tym, co fizycznie musi zrobić człowiek.
Zakładamy, że znasz systemy klasy EDR albo już korzystasz z ESET Inspect, dlatego w tym artykule skupiamy się na praktyce. Jak ocenić, czy Twoja organizacja ma dziś zdolność operacyjną do obsługi tego, co wykrywa system? Gdzie kończy się zakres samego narzędzia, a zaczyna praca analityka? Zestawiamy ze sobą EDR oraz MDR, aby pomóc Ci podjąć właściwą decyzję.
Co zapewnia ESET Inspect jako warstwa technologiczna?
ESET Inspect, działający we współpracy z platformą ESET PROTECT to systemem klasy EDR/XDR – Endpoint Detection and Response, narzędzie do wykrywania i reagowania na poziomie urządzeń końcowych. To konkretny zestaw możliwości, które pozwalają na:
- szczegółową widoczność aktywności na stacjach roboczych i serwerach – procesy, pliki, połączenia sieciowe, zmiany w rejestrze,
- wykrywanie incydentów, anomalii i zachowań, które odbiegają od normy,
- analizę wskaźników naruszenia (IOC) i powiązanie zdarzeń z taktykami oraz technikami z macierzy MITRE ATT&CK,
- możliwość podjęcia działań technicznych: izolacja urządzenia od sieci, zakończenie procesu, zablokowanie pliku wykonywalnego, uruchomienie zdalnej powłoki terminalowej,
- silnik reguł pozwalający tworzyć własne scenariusze detekcji.
To całkiem sporo. Monitoring ESET Inspect działa nieprzerwanie – telemetria z urządzeń końcowych spływa do konsoli 24 godziny na dobę, niezależnie od tego, czy ktokolwiek z niej w danym momencie korzysta.
Ostatnie zdanie jest istotne. System zbiera dane i generuje detekcje przez całą dobę, ale to czy ktoś je analizuje przez całą dobę, to zupełnie inna kwestia. To właśnie różnica między EDR a MDR, do której jeszcze wrócimy, ale najpierw…
Co nadal musi zrobić administrator lub analityk?
Zanim jednak przejdziemy do samej reakcji, warto zadać pytanie: dlaczego ten komputer w ogóle jest aktywny o tak późnej porze? To doskonały moment, by przypomnieć, jak ważne jest wylogowywanie się i całkowite wyłączanie sprzętu po skończonej pracy. Pozostawienie uruchomionej i podpiętej do sieci stacji roboczej na noc to nic innego, jak zafundowanie cyberprzestępcom, cichego okna na przeprowadzenie ataku.
Wróćmy do PowerShella z 23:47. Detekcja zaświeciła się w konsoli na czerwono. Co dalej?
Ktoś musi ją zobaczyć. Jeśli nikt nie weryfikuje alertów w nocy, powiadomienie czeka do rana. Proces, który mógł być pierwszym krokiem ataku, miał kilka godzin na dalsze działanie, zanim ktokolwiek zareagował.
Załóżmy jednak, że ktoś patrzy na konsolę na bieżąco. Kolejny krok to ocena zdarzenia. Samo uruchomienie PowerShella nie jest dowodem ataku – to w końcu narzędzie administracyjne używane na co dzień. Ważny jest kontekst:
- Kto go uruchomił?
- Czy robił to wcześniej?
- Z czym się połączył?
- Co działo się potem?
Ta sama logika dotyczy innych scenariuszy: PsExec użyty do zdalnego wywoływania poleceń na kolejnych urządzeniach, logowanie RDP o nietypowej porze z nowej lokalizacji, czy proces próbujący uzyskać dostęp do pamięci LSASS w celu pozyskania poświadczeń.
Żeby ocenić sytuację, konieczne jest dochodzenie – sprawdzić historię użytkownika i urządzenia, zweryfikować reputację połączenia, ustalić sekwencję zdarzeń… Obsługa systemu EDR wymaga czasu, doświadczenia w analizie logów i, co najważniejsze, dostępności tu i teraz, a nie w wolnej chwili między resetowaniem haseł a spotkaniem projektowym.
Jeśli analiza potwierdzi, że sytuacja wymaga reakcji, ktoś musi podjąć decyzję o działaniu. Izolacja urządzenia jest prosta do wykonania w konsoli. Pytanie, czy w tym konkretnym przypadku jest to działanie proporcjonalne. Czy może niepotrzebnie zatrzyma ważny proces biznesowy? Wymaga oceny, a nie tylko kliknięcia przycisku.
To trzy odrębne kompetencje:
- dostępność w czasie rzeczywistym,
- umiejętność analizy kontekstu,
- doświadczenie w podejmowaniu decyzji o reakcji.
Żadnej z nich nie dostarcza sama licencja na oprogramowanie.
Dlaczego wygenerowanie detekcji nie kończy obsługi zdarzenia?
Detekcja to sygnał, a nie zamknięta sprawa. Warto podkreślić, że takich sygnałów każdego dnia jest bardzo wiele. Jeśli ktoś myśli, że w konsoli pojawiają się tylko detekcje potwierdzające rzeczywisty incydent bezpieczeństwa, to jest w błędzie. W rzeczywistości większość z nich stanowią detekcje fałszywie pozytywne (false positives), ale dowiadujemy się o tym dopiero po przeprowadzonej przez człowieka analizie.
Czy EDR działa 24/7? Tak, w sensie zbierania danych i generowania alertów, telemetria nie robi sobie przerwy na noc. Tylko, że pełny cykl wygląda mniej więcej tak tak:
Detekcja → Kwalifikacja → Dochodzenie → Decyzja → Reakcja → Dokumentacja
→ Wnioski na przyszłość
System EDR odpowiada wyłącznie za pierwszy element tego łańcucha. Do kolejnych kroków potrzebny jest człowiek.
Organizacja może mieć doskonale wdrożony ESET Inspect i jednocześnie nie mieć realnej zdolności do zamknięcia tego cyklu poza standardowymi godzinami pracy. Nie dlatego, że administrator nie potrafi tego zrobić. Po prostu ograniczony ilościowo zespół nie może jednocześnie utrzymywać infrastruktury, wspierać użytkowników, realizować bieżących projektów, a do tego analizować każdą sekwencję zdarzeń o dowolnej porze.
Z kolei niezamknięte detekcje z jednego dnia należy zweryfikować jak najszybciej – najlepiej już następnego dnia rano. Problem w tym, że one nie znikają, a system generuje je nieprzerwanie także przez weekend, święta czy urlopy administratorów. Zaległości szybko zaczynają przypominać efekt kuli śnieżnej, nad którą z czasem coraz trudniej zapanować.
To nie ocena kompetencji zespołu IT, tylko stwierdzenie faktu. Czas to zawsze deficyt, którego nie da się rozciągnąć niezależnie od tego, jak dobrze ktoś zna środowisko.
Różnica między EDR a MDR - czym MDR uzupełnia ESET Inspect?
Dochodzimy do sedna. Co właściwie oznacza ESET Inspect a MDR razem, a czym różnią się osobno?
EDR to technologia – dostarcza widoczność, dane i możliwości reakcji. MDR (Managed Detection and Response) to usługa. Zespół ludzi, który tę technologię obsługuje w sposób ciągły, przejmując ciężar operacyjny.
Warto doprecyzować jeszcze jedną rzecz: dokumentacja ESET wskazuje różne kwalifikujące poziomy subskrypcji dla samego ESET Inspect oraz osobne pakiety producenta obejmujące jego własną usługę MDR. Usługa MDR Perceptus jest budowana w oparciu o technologię ESET Inspect, ale nie jest tożsama ani z samą licencją, ani z MDR świadczonym bezpośrednio przez producenta. To osobny model współpracy operacyjnej.
MDR Perceptus zamyka lukę, która pojawiła się w poprzedniej sekcji:
Ciągły monitoring – certyfikowani inżynierowie obserwują środowisko 24/7/365, więc detekcja z 23:47 nie czeka do rana.
Kwalifikacja i kontekst – zespół analizuje ciąg zdarzeń, reputację obiektów, użytkownika, urządzenie, porę i częstotliwość działania, żeby odróżnić aktywność administracyjną od czegoś, co wymaga dalszego dochodzenia.
Dochodzenie – jeśli sytuacja tego wymaga, analitycy ustalają źródło, skalę i przebieg zdarzenia, zamiast poprzestawać na samym alercie.
Reakcja według uzgodnionego scenariusza – działania takie jak izolacja urządzenia, blokowanie pliku czy zakończenie procesu są wykonywane w granicach wcześniej ustalonych z klientem zasad. W sytuacjach nietypowych albo wymagających decyzji biznesowej zespół kontaktuje się z wyznaczonym przedstawicielem organizacji, zamiast działać bez kontekstu, którego nie ma.
Dokumentacja i rozwój – po obsłudze zdarzenia zespół analizuje przyczynę, przygotowuje rekomendacje i rozwija reguły detekcji w samym ESET Inspect, żeby konsola z czasem lepiej odpowiadała specyfice środowiska.
EDR mówi, co się dzieje na urządzeniach. MDR pomaga rozpoznać, co z tego ma znaczenie i jak należy zareagować. Administrator nadal zna środowisko najlepiej (zależności, wyjątki, historię zmian). My dodajemy ciągłość obserwacji i specjalistyczną analizę dokładnie tam, gdzie brakuje rąk do pracy.
Kiedy organizacja może wystarczająco dobrze obsługiwać EDR samodzielnie?
Nie każda organizacja potrzebuje modelu zarządzanego już dziś.
Samodzielna obsługa ESET Inspect ma sens, gdy spełnionych jest kilka warunków jednocześnie:
- Zespół IT ma czas na regularną analizę konsoli, a nie tylko sprawdzanie jej „przy okazji” innych zadań.
- W organizacji jest więcej niż jedna osoba znająca środowisko na tyle dobrze, żeby ocenić kontekst zdarzenia, ponieważ pojedynczy specjalista to pojedynczy punkt awarii, także wtedy, gdy jest na urlopie.
- Środowisko nie wymaga dyżuru poza standardowymi godzinami pracy, albo organizacja ma na to osobny, ustalony proces.
- Skala środowiska – liczba urządzeń, użytkowników, lokalizacji – pozwala na bieżąco nadążać z liczbą generowanych detekcji bez efektu zmęczenia alertami.
- Zespół posiada aktualną wiedzę o panujących trendach grup APT (Advanced Persistent Threat) oraz na bieżąco śledzi nowe cyberzagrożenia.
Jeśli te warunki są spełnione, samodzielna obsługa EDR powinna być wystarczająca.
Kiedy warto rozważyć model zarządzany?
Zastanów się nad przejściem na model zarządzany, gdy w Twoim dziale IT pojawia się kilka sygnałów:
- alerty z ESET Inspect weryfikowane są z opóźnieniem, dopiero po wystąpieniu skutków albo przy okazji innych zadań,
- w organizacji nie ma dyżuru ani kompetencji dochodzeniowych dostępnych poza godzinami pracy,
- legalne narzędzia administracyjne (PowerShell, PsExec, RDP) utrudniają jednoznaczne odróżnienie normalnej aktywności od potencjalnego ataku typu Living Off The Land,
- brakuje spisanych, uzgodnionych procedur: kto może izolować urządzenie, kiedy informować przełożonych, jakie dowody zachować,
- konfiguracja i reguły w konsoli nie są regularnie przeglądane ani optymalizowane, bo brakuje na to czasu,
- organizacja potrzebuje raportów i ścieżki dokumentującej, jak obsłużono zdarzenia – na potrzeby audytu, klienta albo grupy kapitałowej,
- kluczowy administrator lub specjalista bezpieczeństwa odszedł z firmy, a wiedza o obsłudze incydentów odeszła razem z nim,
- środowisko urosło – nowe oddziały, praca zdalna, więcej endpointów i liczba zdarzeń przewyższa dostępny czas zespołu.
Żaden z tych sygnałów osobno nie musi oznaczać, że trzeba natychmiast zmieniać model obsługi. Pojedynczy problem można rozwiązać wewnętrznie. Jednak kilka z nich występujących jednocześnie to dobry powód, żeby sprawdzić, czy obecny sposób pracy z ESET Inspect faktycznie nadąża za tym, co system wykrywa.
Sprawdź, kto dziś analizuje detekcje z ESET Inspect poza godzinami pracy w Twojej organizacji i co dokładnie może zostać zrobione po potwierdzeniu incydentu. To pytanie samo w sobie daje dobrą odpowiedź na to, czy obecny model obsługi wystarcza, czy warto go rozszerzyć.
Jeśli Twoje środowisko potrzebuje wsparcia analityków operujących w trybie ciągłym -skontaktuj się z nami.
Chcesz zadbać o cyberbezpieczeństwo?
Skontaktuj się z nami!
Zostaw dane – oddzwonimy
Nasz specjalista odezwie się do Ciebie najpóźniej kolejnego dnia roboczego. Nie musisz wypełniać pola wiadomości, ale krótka informacja o interesującym Cię temacie rozmowy będzie dla nas cenną wskazówką.
