Od alertu w EDR do izolacji hosta: schemat skutecznej reakcji na incydent endpoint

Problem zgłoszony przez dział: mamy alert w EDR – co zrobić, żeby nie pogorszyć sytuacji

W SOC pada sygnał: EDR wyłapał podejrzany proces, a za nim kaskadę nietypowych połączeń. Co się dzieje? Najczęstsze pułapki są dwie. Pierwsza: panika i natychmiastowa izolacja hosta bez weryfikacji, która odcina krytyczny system od produkcji lub blokuje pracę całego zespołu. Druga: odwlekanie decyzji, bo “może to fałszywy alarm”. W obu przypadkach rośnie koszt incydentu – raz biznesowy, dwa razy techniczny (rozszerzanie zasięgu ataku).

Skuteczny schemat reakcji na endpoint zaczyna się od jasnych kryteriów decyzji: kiedy izolować i jakim wariantem, kiedy najpierw rozszerzyć rozpoznanie, a kiedy wystarczy zamknięcie procesu i monitoring. Kluczowy jest też porządek działań: zabezpieczenie dowodów, szybkie odcięcie wektorów lateral movement, a dopiero później długie analizy. Ten tekst porządkuje proces “od alertu w EDR do izolacji hosta”, porównuje warianty reakcji i podpowiada, jak wybierać je bezpiecznie.

Szybki brief decyzyjny: o co najczęściej pyta zespół?

• Czy izolować host natychmiast, czy najpierw zrobić triage?
• Jaka izolacja: pełna sieciowa, selektywna (np. pozostawienie kanału EDR), czy tylko ograniczenie wybranych protokołów?
• Co zebrać przed izolacją, żeby nie utracić dowodów, a jednocześnie nie pozwolić atakującemu na ruch boczny?
• Jak odróżnić prawdziwy incydent od głośnego, ale nieszkodliwego alertu “noise”?
• Manualnie, półautomatycznie czy w pełni automatycznie? Który wariant reakcji wdrożyć jako standard?
• Kiedy gra toczy się o minuty (ransomware, eksfiltracja), a kiedy można dać sobie kwadrans na doprecyzowanie kontekstu?
• Jak wrócić bezpiecznie do produkcji po izolacji i jak zmierzyć, że reakcja była skuteczna?

Od pierwszego sygnału do hipotezy: co wiemy, a czego nie wiemy po alercie z EDR

Co zwykle wiemy na starcie

Alert EDR najczęściej zawiera: nazwę hosta i użytkownika, proces i jego rodzica (process tree), fingerprinty pliku (hash), komendę uruchomienia (command line), adresy IP/URL, które proces kontaktował, oraz klasyfikację techniki według MITRE ATT&CK. Niekiedy dochodzi “confidence score” i poziom ważności ustalony polityką.

To już sporo, by zarysować hipotezy: czy to technika ładowania DLL, czy oskryptowany LOLBin, czy beacon do C2, czy wreszcie znany ransomware w fazie pre-encryption. Jednak brakuje zwykle dwóch elementów: pełnego kontekstu użytkownika (co robił) oraz odpowiedzi, czy to zjawisko jest odosobnione, czy już występuje na innych hostach.

Czego zwykle nie wiemy i co trzeba szybko sprawdzić

Brakuje nam potwierdzenia zasięgu: czy podobne zachowanie widać w logach z ostatnich godzin i na jakich maszynach. Nie wiemy też, czy istnieje trwała persystencja (klucze rejestru, zadania harmonogramu, launch agents w macOS, crontab i systemd w Linux), i czy po stronie kont domenowych nie doszło do nadużycia uprawnień. Te braki uzupełniamy szybkim triage o niskiej inwazyjności.

Ustalanie hipotez i priorytetów

Trzy proste pytania porządkują sytuację: co wiemy? czego nie wiemy? jaki mamy czas reakcji? Jeśli alert wskazuje na TTP charakterystyczne dla ruchu bocznego (np. użycie PSExec/SMB, RDP z nietypowego źródła, WMI), priorytetem jest ograniczenie komunikacji i ryzyka eskalacji. Gdy sygnał dotyczy możliwej eksfiltracji (długie połączenia do znanego C2, duże ilości danych), ważniejsze bywa natychmiastowe przecięcie kanału sieciowego. Jeśli to jedynie podejrzany makro-skrypt bez dalszych skutków – czasem wystarczy zabić proces i rozpocząć pogłębioną analizę.

Trzy warianty reakcji: manualna, półautomatyczna i automatyczna – co wybrać i kiedy

Organizacje zazwyczaj stoją przed wyborem modelu działania. Każdy ma plusy i minusy – inny koszt, inne ryzyko błędu, inny poziom dojrzałości wymagany w zespole SOC/IRT.

Wariant A: manualny triage i ręczna izolacja

Opis: Analiza alertu przez analityka, ręczne potwierdzenie incydentu, decyzja o izolacji hosta i jej wykonanie w konsoli EDR lub przez zespół sieciowy.

• Plusy: wysoki poziom kontroli, możliwość uwzględnienia kontekstu biznesowego, mniejsze ryzyko odcięcia krytycznych systemów “przez automat”.
• Minusy: wolniejszy czas reakcji (MTTR), większa zmienność jakości, ryzyko ludzkich błędów, obciążenie SOC przy wielu alertach.
• Dla kogo: mniejsze środowiska, systemy o wysokiej krytyczności, działy bez SOAR.

Wariant B: półautomatyczny playbook z zatwierdzeniem

Opis: SOAR/EDR automatycznie zbiera kontekst (listy procesów, połączeń, szybkie IOC match), sugeruje działanie i czeka na “approve” analityka, który jednym przyciskiem uruchamia izolację/containment.

• Plusy: szybsza i powtarzalna reakcja, zachowana kontrola człowieka przy kluczowym kroku, możliwość logowania i audytu decyzji.
• Minusy: wymaga przygotowania i utrzymania playbooków, czasem zbyt zachowawcza automatyzacja (fałszywe alarmy nadal zajmują analityka).
• Dla kogo: większość średnich i dużych organizacji; dobry kompromis między szybkością a kontrolą.

Wariant C: pełna automatyzacja z politykami

Opis: EDR/SOAR samoczynnie izoluje host przy spełnieniu warunków wysokiej pewności (np. znany ransomware, uruchomienie szyfratora, pewne wskaźniki C2). Analityk dostaje notyfikację post factum.

• Plusy: minimalny czas reakcji, “ratowanie” środowiska przed lawiną szyfrowania, stała jakość nawet w nocy i święta.
• Minusy: ryzyko odcięcia krytycznych hostów błędnie wykrytym alertem, duże wymagania testowe, konieczność precyzyjnych wyjątków (allowlist).
• Dla kogo: dojrzałe SOC 24/7, środowiska z wysokim ryzykiem ransomware, działy z dobrym pokryciem telemetrycznym i kontrolą zmian.

Porównanie modeli reakcji – kluczowe różnice

Warianty izolacji hosta: pełna, selektywna i alternatywy containment

Izolacja nie jest jednowymiarowa. Narzędzia EDR/NAC/SDN pozwalają dziś dobrać zakres “odcięcia” do sytuacji. Błędem jest używać jednego młotka do wszystkich gwoździ: pełna izolacja przy każdym incydencie albo przeciwnie – zawsze tylko kill procesu.

Pełna izolacja sieciowa przez EDR

Mechanizm: agent EDR nakłada politykę blokującą wszystkie połączenia z/na host poza kanałem do konsoli EDR (by utrzymać kontrolę zdalną). Zwykle odcina SMB, RDP, HTTP/S, DNS, wszystko.

• Zalety: najszybsze przerwanie lateral movement i eksfiltracji, jednocześnie zachowany kanał dowodzenia przez EDR.
• Ryzyka: nagłe zerwanie usług (np. skaner w linii produkcyjnej), przerwanie pracy użytkownika na krytycznym stanowisku, możliwy brak dostępu do repo do pobrania narzędzi sanitize.

Selektywna izolacja z kontrolowanymi wyjątkami

Mechanizm: ograniczenie ruchu do minimalnego zestawu dozwolonych kierunków (np. tylko kanał EDR, ewentualnie wybrane repozytoria narzędzi IR), reszta blokowana lokalną zaporą lub polityką agenta.

• Zalety: zachowuje sterowność hosta, pozwala dokończyć zbieranie dowodów i uruchomić skrypty sanitarne, mniejsze ryzyko przerwania krytycznych zadań niż przy pełnym “airgapie”.
• Ryzyka: zbyt szerokie wyjątki potrafią zostawić furtkę do ruchu bocznego; zbyt wąskie – zerwą dostęp do narzędzi IR lub serwisów nazw (DNS).
• Kiedy ma sens: gdy widzimy podejrzane TTP, ale brak oznak szyfrowania/eksfiltracji; przy hostach, które muszą „żyć”, żeby pobrać artefakty czyszczące lub wykonać eksport logów.

Izolacja na warstwie sieci (NAC/SDN)

Mechanizm: przeniesienie portu/urządzenia do sieci kwarantannowej (NAC) lub odcięcie przepływów polityką SDN/segmentacji. Działa również dla maszyn bez agenta EDR.

• Zalety: skuteczne, gdy agent jest wyłączony lub atak dotyczy urządzeń typu serwery druku, IoT, stacje w OT; polityka może być wymuszona centralnie i mierzalna.
• Ryzyka: ryzyko odcięcia nie tych przepływów, co trzeba (błędy klasyfikacji), możliwość utraty kanału do EDR, jeśli ruch nie jest wyłączony selektywnie.
• Kiedy ma sens: brak agenta, kompromitacja na poziomie sieci/portu, potrzeba szybkiego “geofencingu” ruchu bez wchodzenia na hosta.

Containment bez odcinania hosta: punktowe ograniczenia

Czasem szybciej i bezpieczniej jest ściąć wektor ataku, zostawiając host w produkcji. Chodzi o kroki, które redukują ryzyko bez twardej izolacji.

• Zabicie i zbanowanie binarki/skryptu (kill + ban hash/path) w EDR/EPP – ogranicza powrót procesu w całej flocie.
• Blokada domen/IP w proxy/firewallu – odcina C2/eksfiltrację w skali całej organizacji.
• Wygaszenie sesji i reset haseł (AD/SSO), unieważnienie tokenów – minimalizuje nadużycie poświadczeń.
• Włączenie lokalnych reguł zapory (SMB/RDP/WMI deny) – szybkie stłumienie lateral movement z/na host.
• Tymczasowe zdjęcie konta/hosta z wrażliwych grup i zakresów dostępu – zawężenie uprawnień “tu i teraz”.

Plusy: mniejsza ingerencja w produkcję, szybki efekt skali (zwłaszcza blokady w warstwie sieci). Minusy: napastnik może pozostać na hoście i zmienić TTP; zbyt wczesne “dotykanie” artefaktów może zafałszować obraz dla analizy powłamaniowej.

Co zabrać z systemu, zanim go odetniesz: mały pakiet dowodów

Celem jest krótka lista artefaktów o wysokiej wartości dowodowej, które da się zebrać szybko i bez ciężkich zrzutów. Co wiemy? Proces, który wywołał alert, jego rodzic i komunikacje. Czego nie wiemy? Skala, persystencja, nadużycie kont. Poniższy pakiet redukuje te luki.

• Process tree i pełne command line dla podejrzanych procesów + listy uruchomionych usług/driverów.
• Aktywne połączenia i ostatnie adresy z DNS cache (kontekst C2/eksfiltracji).
• Informacja o aktywnych sesjach (lokalnych i zdalnych), ostatnich logowaniach uprzywilejowanych.
• Szybki zrzut kluczowych punktów persystencji: harmonogram zadań, Run/RunOnce, WMI Event Subscriptions, crontab/systemd.
• Listy plików utworzonych/zmodyfikowanych przez podejrzany proces w ostatnim oknie czasu (ścieżki, hashe).
• Eksport kluczowych wpisów z EDR timeline dla hosta (ułatwia korelację po izolacji).

Gdy sygnał wskazuje na rozpoczęte szyfrowanie lub aktywną eksfiltrację, priorytetem jest izolacja; część danych można dozbierać już po odcięciu przez kanał EDR/konsole IR. Ciężkie zrzuty pamięci dyskowej i pełne memory dumpy – tylko gdy czas i ryzyko pozwalają.

Dobór wariantu do scenariusza: krótkie mapowanie

W praktyce decyzję ułatwia zestawienie scenariusz – priorytet – działanie. Prosta tabelka porządkuje najczęstsze przypadki bez udawania, że wszystko da się zautomatyzować jednakowo.

Najczęstszy błąd przy tym mapowaniu to mylenie „dużego hałasu” z wysoką pewnością kompromitacji. Kryterium powinno być dwuskładnikowe: pewność detekcji (sygnały skorelowane, artefakty na dysku/pamięci)

Progi izolacji: decyzja oparta na dwóch wektorach

Decyzję upraszcza zasada dwóch wektorów: pewność detekcji × potencjalny wpływ na środowisko. Co wiemy? Jakie sygnały się potwierdzają. Czego nie wiemy? Skalę i zasięg uprawnień napastnika.

• Pewność detekcji (sygnały skorelowane, artefakty na dysku/pamięci):
  • Wysoka: wiele niezależnych źródeł (EDR + AV + proxy), artefakty persystencji, łańcuch rodzic–dziecko z podejrzanym CLI, znane IoC, próby dumpu poświadczeń.
  • Niska: pojedynczy heurystyczny alert bez wsparcia w artefaktach, brak komunikacji zewnętrznej, brak śladów zmian trwałych.
• Potencjalny wpływ:
  • Wysoki: host uprzywilejowany (admin, serwer krytyczny), węzeł tranzytowy między segmentami, sesja VPN z dostępem szerokim.
  • Niski: pojedynczy endpoint użytkownika z ograniczonymi uprawnieniami, odseparowany segment testowy.

Minimalne progi działania – praktyczne reguły:

• Wysoka pewność × wysoki wpływ: pełna izolacja EDR natychmiast + globalne blokady wskaźników.
• Wysoka pewność × niski wpływ: selektywna izolacja lub kill+ban, dodatkowo wzmocnienie zapory hosta i obserwacja.
• Niska pewność × wysoki wpływ: selektywna izolacja z wąskimi wyjątkami (kanał EDR, repo IR), szybkie zebranie pakietu dowodów; rozważ NAC/SDN.
• Niska pewność × niski wpływ: containment bez odcinania (ban hash/domena, ograniczenia RDP/SMB), intensywny monitoring przez określone okno.

Krótki przykład: korelacja trzech źródeł + próba odczytu LSASS – decyzja o pełnej izolacji; pojedyncze makro Office bez łączności zewnętrznej – kill+ban i selektywna izolacja tylko na czas triage.

Wyprowadzenie hosta z kwarantanny: trzy ścieżki powrotu

Sposób przywrócenia zależy od ryzyka resztkowego i kosztu przestoju. Poniżej trzy realne ścieżki, które da się wpisać w playbook.

1) Szybka remediacja „na żywo” i powrót do sieci

• Kroki: usunięcie artefaktów (ban hash, kill, czyszczenie persystencji), weryfikacja kluczowych wskaźników (procesy, połączenia, zadania), krótkie okno obserwacji.
• Plusy: minimalny downtime, brak potrzeby reinstalacji, dobre dla stacji roboczych.
• Minusy: ryzyko pozostałości, wymaga dojrzałych narzędzi i checklist.
• Dla kogo: biuro, dev/test, systemy z niską krytycznością, gdy nie wykryto eksfiltracji ani eskalacji uprawnień.

2) Reinstalacja/reimage z goldena i kontrolowany powrót

• Kroki: backup danych użytkownika (jeśli polityka na to pozwala), czysta instalacja, twarda walidacja polityk, rejoin do domeny, wzmożony monitoring po powrocie.
• Plusy: niskie ryzyko resztkowe, standaryzacja konfiguracji.
• Minusy: dłuższy czas wyłączenia, angaż ITSM/SD i change management.
• Dla kogo: stacje produkcyjne, punkty kasowe, hosty z podejrzeniem persystencji lub kradzieży poświadczeń.

3) Przedłużona kwarantanna do pełnej analizy powłamaniowej

• Kroki: rozszerzone zbiory (full memory dump, artefakty dyskowe), wyłączenie z produkcji do czasu hipotez i timeline.
• Plusy: pełniejszy obraz zdarzenia, materiał dla działań systemowych (reguły, hardening).
• Minusy: długi przestój, wymaga kompetencji DFIR i przestrzeni na zrzuty.
• Dla kogo: serwery krytyczne, incydenty z realną eksfiltracją, ślady APT/lateral movement.

Modele zatwierdzania i komunikacji podczas izolacji

Przycisk „izoluj” bywa technicznie prosty, organizacyjnie – już nie. Poniższe warianty pokazują różne kompromisy między ryzykiem a ciągłością działania.

Decyzja i odpowiedzialność

• SOC on-call w ramach playbooka
  • Opis: analityk dyżurny zatwierdza reakcję w określonych progach (runbook + SLO).
  • Plusy: szybkość, spójność decyzji.
  • Minusy: presja na pojedynczą rolę; wymaga jasnych kryteriów eskalacji.
  • Dla kogo: organizacje z dojrzałymi playbookami i przeszkolonym SOC.
• Akceptacja właściciela usługi/menedżera dyżurnego
  • Opis: izolacja krytycznych hostów wymaga dodatkowego „approve” z biznesu/IT.
  • Plusy: lepsze zarządzanie ryzykiem operacyjnym.
  • Minusy: opóźnienie decyzji; ryzyko „zbytniego ważenia” produkcji nad bezpieczeństwem.
  • Dla kogo: środowiska OT, systemy o bardzo wysokim RTO/RPO.
• Pełna automatyzacja warunkowa
  • Opis: predefiniowane sygnały „katastroficzne” wyzwalają izolację bez człowieka.
  • Plusy: najszybsza bariera dla ransomware/lateral movement.
  • Minusy: wymaga bardzo dobrych testów i wyjątków; możliwość fałszywych pozytywów.
  • Dla kogo: duże floty, SOC 24/7, dojrzałe EDR/SOAR.

Komunikacja i minimalizacja szkód ubocznych

• Cichy tryb dla użytkownika + automatyczny ticket do Service Desk – mniej paniki, spójna obsługa zgłoszeń.
• Baner systemowy na hoście z krótką instrukcją (kontakt, numer incydentu) – przydatne przy dłuższej kwarantannie.
• Webhook do kanału on-call (Slack/Teams) + wpis w CMDB/ITSM – synchronizacja z change management i monitoringiem.

Kryteria wyboru rozwiązania dla własnej organizacji

Finalny układ powinien odzwierciedlać ryzyko, zasoby i dojrzałość narzędziową. Kilka praktycznych kryteriów ułatwia wybór.

• Skala i rozproszenie floty – im większa, tym większy sens półautomatu/automatu z jasnymi wyjątkami.
• Dojrzałość SOC i pokrycie 24/7 – im mniejsze, tym większy sens reguł automatycznych z twardymi progami izolacji i jasnymi wyjątkami.
• Topologia sieci – przy dobrej segmentacji i NAC/SDN warto wykorzystać izolację sieciową; w sieciach spłaszczonych skuteczniejsza bywa izolacja hostowa EDR.
• Wymagania RTO/RPO – im niższe, tym częściej wybór padnie na izolację selektywną z białą listą krytycznych usług.
• Wymogi dowodowe/zgodności – przy incydentach o charakterze śledczym planuj wariant utrzymujący telemetrię i możliwość zdalnej akwizycji (EDR kanał, repo IR).

Warianty izolacji: porównanie architektur containmentu

Izolacja to nie jeden przycisk. Poniżej cztery realne warianty, które organizacje łączą w playbookach. Co wiemy? Środowiska różnią się segmentacją, krytycznością usług i narzędziami. Czego nie wiemy? Jak agresywny musi być containment, by nie „zabić” operacji.

Wariant A: Pełna izolacja hostowa w EDR

• Opis: agent blokuje cały ruch sieciowy poza kanałem do chmury/koncentratora EDR (czasem także do repo IR).
• Plusy: szybka, spójna, niezależna od sieci; minimalizuje lateral movement i eksfiltrację.
• Minusy: odcina narzędzia administracyjne (RDP/WinRM/SSH), może ograniczyć GPO/udostępnienia; wymaga wcześniej przetestowanych wyjątków.
• Pułapki: brak ścieżki „break-glass” dla zespołu IR; błędna identyfikacja adresów backendu EDR skutkuje całkowitą utratą łączności z agentem.
• Dla kogo: stacje robocze, serwery o niskiej liczbie zależności sieciowych.

Wariant B: Selektywna izolacja hostowa (allowlist)

• Opis: agent przepuszcza tylko wybrane kierunki/usługi (EDR, repo IR, kontrolery domeny, serwer zarządzania patchami, serwis backupu).
• Plusy: lepsza ciągłość operacji krytycznych; umożliwia zdalną remediację i kolekcję dowodów.
• Minusy: złożoność list wyjątków; ryzyko przeoczenia tunelowania przez dozwolone usługi.
• Pułapki: „puchnięcie” allowlisty po kolejnych incydentach; brak okresowych przeglądów i testów skutkuje zbyt porowatą izolacją.
• Dla kogo: serwery produkcyjne, urządzenia o wysokim RTO/RPO, hosty wrażliwe na pełne odcięcie.

Wariant C: Izolacja sieciowa (NAC/SDN/Firewall)

• Opis: przeniesienie hosta do VLAN kwarantanny lub zamknięcie portu/ACL; działa także dla urządzeń bez agenta.
• Plusy: jednolita kontrola w warstwie sieci; obejmuje IoT/OT i sprzęt niezarządzany przez EDR.
• Minusy: wymaga ścisłej integracji z CMDB i automatyzacją; nie blokuje procesów lokalnych ani ataku wewnątrz hosta.
• Pułapki: hosty multi-homed (Wi‑Fi + LAN) omijające kwarantannę; zbieżność reguł ACL z trasowaniem i NAT.
• Dla kogo: środowiska z dojrzałym NAC/SDN, OT/IoT, drukarki, punkty kasowe.

Wariant D: Hybryda EDR + NAC (dwa noże bezpieczeństwa)

• Opis: jednoczesna izolacja hostowa i sieciowa; EDR utrzymuje kanał telemetrii, NAC ogranicza ruch L2–L4.
• Plusy: odporność na luki w jednym z mechanizmów; lepsza kontrola nad ruchem bocznym oraz exfiltracją.
• Minusy: koordynacja wyjątków w dwóch systemach; ryzyko zamknięcia dostępu do repo IR przez źle zsynchronizowane polityki.
• Pułapki: brak wspólnego źródła prawdy (CMDB/tagi) i dryf polityk w czasie; trudniejsze testy DR.
• Dla kogo: duże organizacje z SOC 24/7, krytyczne segmenty, wymagania regulacyjne.

Kiedy który wariant ma sens: praktyczne matryce

• Stacja robocza użytkownika z alertem o wysokiej pewności i aktywnym beaconie C2 – pełna izolacja EDR; równolegle blokady w proxy. Cel: szybkie przecięcie kanału i zbiory minimalne.
• Serwer aplikacyjny z transakcjami biznesowymi, pojedyncze wskaźniki i brak potwierdzonych artefaktów – selektywna izolacja EDR (EDR + AD + repo IR + monitoring), krótkie okno triage i decyzja o reimage lub powrót.
• Drukarka sieciowa/terminal płatniczy bez agenta z anomaliami ruchu – izolacja NAC/SDN do VLAN kwarantanny; w tle analiza PCAP i weryfikacja firmware.
• Kontroler domeny z oznakami dumpu poświadczeń – hybryda: NAC ogranicza ruch do segmentu IR, EDR utrzymuje telemetrię; zespół DFIR zbiera pamięć i artefakty przed reimage. Wyjątek: nie stosować pełnej izolacji, która odcina AD od krytycznych replikacji w czasie dochodzenia.

Najczęstsze błędy w doborze wariantu i jak ich uniknąć

• Mylenie hałasu z pewnością – pojedynczy heurystyczny alert nie uzasadnia pełnej izolacji krytycznego hosta. Zanim klikniesz, zadaj dwa pytania: co wiemy (artefakty, korelacje)? czego nie wiemy (zasięg uprawnień, lateral movement)?
• Brak testów allowlisty – wyjątki spisane na wiki nie działają w nocy. Utrzymuj testy regresyjne polityk izolacji i kwartalne przeglądy wyjątków.
• Izolacja bez telemetrii – odcięcie, które uniemożliwia kolekcję dowodów, opóźnia remediację i zamyka drogę do root cause.
• Niedoszacowanie ścieżek alternatywnych – Wi‑Fi, modemy LTE, tunelowanie przez dozwolone domeny. Polityka musi obejmować wszystkie interfejsy.
• Brak „break-glass” – konto, sieć i procedura awaryjna dla IR powinny być gotowe przed pierwszym incydentem, nie po.

Rekomendacja operacyjna: jak wybrać i wdrożyć bazowy zestaw

Sensowny punkt startu to układ warstwowy z jasną decyzją, kiedy eskalować izolację.

• Domyślna ścieżka dla stacji roboczych: pełna izolacja EDR + automatyczne blokady wskaźników w proxy/DNS; powrót ścieżką 1 lub 2 w zależności od artefaktów.
• Serwery aplikacyjne i bazy danych: selektywna izolacja EDR z minimalną, przetestowaną allowlistą (EDR, AD, repo IR, monitorowanie, backup). Kryterium przejścia do pełnej: korelacja ≥2 źródeł + ślady eskalacji uprawnień.
• Urządzenia bez agenta i OT/IoT: NAC/SDN z VLAN kwarantanny i dedykowaną podsiecią IR; ścieżka dowodowa przez tap/span lub sensor NDR.

Krytyczne są progi decyzyjne i zegary. Ustal krótkie okna: np. 15 minut na triage po alertach o wysokiej pewności i 30–60 minut na potwierdzenie eskalacji uprawnień. Jeśli w tym czasie nie ma twardych artefaktów, zawęź izolację zamiast ją zaostrzać. Gdy pojawia się korelacja z kilku źródeł (EDR + AD + proxy), przełącz izolację o poziom wyżej bez dodatkowych zgód.

Najczęściej zadawane pytania (FAQ)

EDR zgłosił podejrzany proces — izolować host od razu czy zrobić szybki triage?

Zacznij od trzech pytań kontrolnych: co wiemy, czego nie wiemy, ile mamy czasu. Jeśli widzisz TTP charakterystyczne dla ruchu bocznego (PSExec/SMB, WMI, nietypowe RDP) lub oznaki eksfiltracji/C2 (długie połączenia, duże transfery, znane domeny C2), priorytetem jest szybkie odcięcie komunikacji. Gdy detekcja wskazuje na znany ransomware w fazie pre-encryption — izoluj bez czekania.

Jeśli alert dotyczy pojedynczego makra/LOLBin bez śladów sieci i bez dalszych procesów potomnych, często wystarczy zabić proces, włączyć wzmocniony monitoring i wykonać krótki triage kontekstowy. Zwlekanie „bo to może noise” zwiększa ryzyko eskalacji; panika i odcięcie krytycznego hosta bez rozeznania podnosi koszt biznesowy.

Pełna czy selektywna izolacja hosta w EDR — co wybrać i kiedy?

Pełna izolacja sieciowa (zostaje tylko kanał EDR) najszybciej ucina lateral movement i eksfiltrację. Sprawdza się przy podejrzeniu ransomware, aktywnym beaconie C2 lub gdy brak jest zaufania do stanu hosta. Ryzyko: przerwanie usług produkcyjnych lub pracy użytkownika.

Selektywna izolacja ogranicza ruch do minimum (kanał EDR, ewentualnie repozytorium narzędzi IR), pozwalając dozbierać dowody i uruchomić skrypty sanitarne. Dobra dla hostów krytycznych i tam, gdzie musisz zachować zdalną sterowność. Zbyt szerokie wyjątki potrafią jednak zostawić „furtkę”. Praktyczny kompromis: szybki blok protokołów wysokiego ryzyka (SMB/RDP/WMI) + selektywne wyjątki.

Co zebrać przed izolacją, żeby nie utracić kluczowych dowodów?

Zbieraj szybko, mało inwazyjnie — bez długich skanów. Priorytetem są dane, które znikają lub zmieniają się w czasie. Jeśli sytuacja jest gwałtowna (ransomware/eksfiltracja), izoluj najpierw, a zbiory rób kanałem EDR.

• Process tree + command line, hash pliku, rodzic-proces, ścieżki wykonywalne.
• Aktywne połączenia sieciowe, ostatnie adresy IP/URL, rozmiary/ilości transferów.