Wdrożenie EDR-u jest ważnym elementem ochrony endpointów, ale samo w sobie nie rozwiązuje problemu. Po uruchomieniu platformy szybko pojawiają się znacznie bardziej praktyczne pytania: które detekcje wymagają reakcji, jak ocenić zachowanie procesu, gdzie szukać dodatkowego kontekstu i kiedy izolacja hosta rzeczywiście jest właściwym krokiem.
CrowdStrike Falcon dobrze pokazuje, jak wiele zależy tutaj od sposobu pracy zespołu. Platforma dostarcza telemetrię, mechanizmy prewencji oraz narzędzia dochodzeniowe i reakcyjne. Ostatecznie ktoś musi jednak zinterpretować zebrane informacje i zdecydować, co oznaczają one w konkretnym środowisku.
Falcon działa w oparciu o lekki sensor instalowany na chronionych systemach i chmurową platformę, do której trafiają dane dotyczące aktywności endpointów. Z perspektywy użytkownika konsoli oznacza to dostęp nie tylko do samych alertów, lecz także do kontekstu potrzebnego do dalszej analizy.
I właśnie ten kontekst jest najważniejszy.
Alert mówi, że coś się wydarzyło. Process Tree pomaga zrozumieć co
Lista detekcji może być dobrym miejscem rozpoczęcia analizy, ale rzadko powinna być jej końcem.
Wyobraźmy sobie proces PowerShell oznaczony przez system jako podejrzany. Sama nazwa programu niewiele jeszcze mówi. PowerShell może być wykorzystywany przez administratora do automatyzacji rutynowych zadań, ale równie dobrze może pojawić się jako element łańcucha ataku.
Znaczenie zaczyna mieć dopiero odpowiedź na kolejne pytania.
Co uruchomiło proces? Czy jego rodzicem był legalny komponent systemu, narzędzie administracyjne czy na przykład aplikacja biurowa? Jakie procesy zostały uruchomione później? Czy pojawiła się komunikacja sieciowa? Czy podobna aktywność wystąpiła również na innych urządzeniach?
Do takiej analizy służy między innymi Process Tree. Pozwala ono prześledzić zależności między procesami i zobaczyć zdarzenie jako sekwencję aktywności, a nie pojedynczy punkt na osi czasu.
To istotna różnica. Dwa alerty dotyczące tego samego procesu mogą oznaczać dwie zupełnie różne sytuacje. Bez znajomości procesu nadrzędnego, kolejnych działań i kontekstu hosta łatwo wyciągnąć zbyt daleko idące wnioski.
Polityka ochrony musi pasować do środowiska
Kolejny obszar, który często wygląda prosto dopiero do momentu pierwszego wdrożenia produkcyjnego, to konfiguracja polityk prewencyjnych.
Falcon pozwala definiować ustawienia ochrony, przypisywać polityki do określonych grup hostów i kontrolować kolejność ich stosowania. Technicznie możliwości jest więc sporo. Problemem nie jest samo znalezienie odpowiedniego przełącznika w konsoli, lecz ocena konsekwencji jego użycia.
Zbyt zachowawcza konfiguracja może ograniczać skuteczność ochrony. Z kolei wprowadzanie restrykcyjnych ustawień bez wcześniejszego sprawdzenia ich wpływu na środowisko potrafi prowadzić do niepotrzebnych zakłóceń.
Jeszcze więcej ostrożności wymagają wyjątki.
W dokumentacji CrowdStrike znajdziemy różne ich typy, między innymi IOA Exclusions, Machine Learning Exclusions, Sensor Visibility Exclusions czy wyjątki związane z certyfikatami. Nie są to różne nazwy tej samej funkcji. Poszczególne mechanizmy wpływają na inne elementy działania platformy.
Dlatego wyjątek nie powinien być traktowany jako szybki sposób na pozbycie się problematycznego alertu.
Najpierw trzeba ustalić, co dokładnie powoduje detekcję, jakiego mechanizmu ona dotyczy i jaki będzie efekt wprowadzenia wykluczenia. Dopiero później można zdecydować, czy wyjątek rzeczywiście jest uzasadniony i jak wąsko można go zdefiniować.
Gdy gotowa detekcja to za mało, pozostaje telemetria
Podczas rzeczywistego dochodzenia szybko przychodzi moment, w którym informacje widoczne w pojedynczej detekcji przestają wystarczać.
Załóżmy, że analityk znajduje podejrzany plik na jednym urządzeniu. Kolejne pytanie jest oczywiste: czy plik pojawił się również gdzie indziej?
Można też pójść dalej. Czy na innych hostach uruchamiano proces o podobnych parametrach? Czy widoczna jest ta sama linia poleceń? Czy aktywność wystąpiła wcześniej? Jak szeroki może być zakres zdarzenia?
W Falconie do pracy z takimi danymi wykorzystywane są między innymi Event Search i CrowdStrike Query Language, czyli CQL.
CQL pozwala filtrować i przeszukiwać telemetrię oraz budować zapytania dostosowane do konkretnego scenariusza analitycznego. To szczególnie istotne wtedy, gdy zamiast reagować wyłącznie na to, co zostało już sklasyfikowane jako detekcja, chcemy samodzielnie sprawdzić hipotezę.
W praktyce różnica jest zasadnicza. Alert pokazuje zdarzenie, które zwróciło uwagę systemu. Praca z telemetrią pozwala sprawdzić, co wydarzyło się wokół niego i czy podobne symptomy są obecne w pozostałej części środowiska.
Podatność krytyczna nie zawsze powinna trafić na początek kolejki
Falcon obejmuje również obszary związane z widocznością zasobów i zarządzaniem ekspozycją.
Falcon Discover pozwala między innymi identyfikować aplikacje i zasoby obecne w środowisku oraz urządzenia, na których nie działa sensor Falcon. Falcon Exposure Management rozszerza tę perspektywę o podatności, błędne konfiguracje oraz inne elementy wpływające na powierzchnię ataku.
Samo znalezienie podatności jest jednak dopiero częścią problemu.
W dużej organizacji liczba wykrytych luk może być na tyle duża, że usuwanie ich wyłącznie według wartości CVSS nie daje zespołowi wystarczającej informacji o realnym priorytecie.
CrowdStrike wykorzystuje w tym obszarze między innymi ExPRT.AI. Mechanizm bierze pod uwagę dodatkowy kontekst, w tym dane dotyczące wykorzystania podatności, threat intelligence, telemetrię oraz charakter danego zasobu.
Z perspektywy zespołu bezpieczeństwa chodzi o bardzo praktyczne pytanie: którą podatnością należy zająć się najpierw?
CVE z wysokim wynikiem CVSS nie musi automatycznie oznaczać największego ryzyka w konkretnym środowisku. Znaczenie ma również to, czy podatność jest możliwa do wykorzystania w danych warunkach, czy istnieją informacje o jej aktywnej eksploatacji oraz jak ważny jest system, którego dotyczy.
Izolować host czy najpierw zebrać więcej danych?
Kiedy analiza potwierdzi incydent, sytuacja zmienia się z dochodzeniowej w operacyjną. Trzeba ograniczyć możliwość dalszego działania napastnika i jednocześnie zachować wystarczająco dużo informacji, żeby właściwie ocenić zdarzenie.
Falcon udostępnia do tego między innymi Real Time Response.
RTR umożliwia zdalną pracę na chronionym hoście. W zależności od uprawnień i scenariusza można wykorzystać je do zebrania dodatkowych informacji o systemie, sprawdzania procesów, analizy aktywności, wykonywania określonych działań naprawczych czy usuwania wskazanych artefaktów.
Platforma pozwala również izolować hosty, korzystać z kwarantanny plików czy uruchamiać skanowanie na żądanie.
Najtrudniejsza część nadal pozostaje jednak po stronie człowieka.
Czy host powinien zostać odizolowany natychmiast? Czy najpierw warto zebrać dodatkowy materiał? Czy usunięcie pliku zakończy problem, czy pozbawi analityka ważnego artefaktu? Czy incydent dotyczy pojedynczej stacji, czy podobna aktywność występuje już na kolejnych urządzeniach?
Nie ma jednej odpowiedzi, którą można zastosować do każdego zdarzenia. Reakcja powinna wynikać z aktualnego obrazu sytuacji.
Falcon jako narzędzie pracy, a nie kolejna konsola z alertami
Process Tree, Event Search, CQL, polityki, wyjątki, Exposure Management czy Real Time Response można poznawać osobno. W codziennej pracy rzadko jednak funkcjonują w oderwaniu od siebie.
Detekcja prowadzi do analizy procesu. Proces do sprawdzenia telemetrii. Telemetria może ujawnić kolejne hosty lub artefakty. Dopiero później pojawia się decyzja o izolacji, dalszym dochodzeniu albo remediacji.
I właśnie umiejętność przejścia przez ten cały ciąg jest znacznie bardziej wartościowa niż sama znajomość poszczególnych ekranów konsoli.
To podejście wykorzystujemy również podczas dwudniowego szkolenia CrowdStrike Falcon w I Know IT. Program obejmuje między innymi architekturę platformy, analizę detekcji i Process Tree, konfigurację polityk oraz wyjątków, pracę z Event Search i CQL, Exposure Management, a następnie praktyczną analizę i reakcję na scenariusz incydentu.
Technologia pokazuje sygnał. Zespół musi zrozumieć jego znaczenie
CrowdStrike Falcon daje zespołowi bezpieczeństwa dostęp do dużej ilości danych oraz narzędzi potrzebnych do analizy i reakcji. Nie oznacza to jednak, że każdy alert automatycznie staje się jednoznaczną odpowiedzią.
Czasem trzeba przeanalizować drzewo procesów. Innym razem przeszukać telemetrię, porównać aktywność na kilku hostach albo sprawdzić, czy wprowadzony wyjątek nie osłabi ochrony bardziej, niż zakładano.
Największa wartość EDR-u pojawia się wtedy, gdy osoba pracująca z platformą potrafi połączyć te informacje i na ich podstawie podjąć właściwą decyzję.
Bo między informacją „system coś wykrył” a odpowiedzią „wiemy, co się wydarzyło i co należy zrobić” nadal pozostaje analiza.
Masz pytania? Skontaktuj się z nami – pomożemy dobrać szkolenie do Twoich potrzeb.
Zespół I know IT | Eksperci Cybersecurity | Doradztwo | Szkolenia