Jak zbudować plan reagowania na incydenty, który naprawdę działa?

Większość organizacji nie zawala reagowania na incydenty dlatego, że brakuje im narzędzi. Zawala, bo nikt wcześniej nie uzgodnił, kto robi co, i pierwszy prawdziwy incydent zamiast w szybką akcję zamienia się w spotkanie.

Zacznij od faz, nie od playbooka

NIST SP 800-61 określa cztery fazy: przygotowanie, detekcja i analiza, zawieranie/eradykacja/odzyskiwanie oraz działania poinciudentowe. Ta kolejność ma znaczenie. Zespoły uwielbiają przejść prosto do zawierania, bo to wygląda na produktywne, ale jeśli nie zrobiłeś pracy przygotowawczej, nie znasz własnej sieci wystarczająco dobrze, by cokolwiek w niej bezpiecznie zawrzeć.

Przygotowanie to bieżące rejestry zasobów, nie arkusz kalkulacyjny z 2022. To wiedza o oknie retencji logów (jeśli wynosi 7 dni, a napastnik przez 30 dni siedział w systemie, już straciłeś oś czasu). To wstępnie przygotowane narzędzia forenzyczne — Velociraptor, KAPE, albo nawet udokumentowana procedura tar/dd do obrazów dysku — żeby nikt nie pobierał narzędzi na zainfekowany host podczas aktywnego incydentu.

Zdefiniuj poziomy ważności, zanim będą ci potrzebne

SEV1 (aktywna eksfiltracja danych, detonacja ransomware'u, kompromitacja konta domain admin) wymaga innego podejścia niż SEV3 (izolowany malware na jednej stacji roboczej bez uprawnień). Napisz to jako macierz: wpływ vs. zasięg vs. pewność. Przydziel każdemu poziomowi ważności wymagany czas odpowiedzi i ścieżkę eskalacji. Jeśli incident commander dla SEV1 to ta sama osoba, która musi zatwierdzić każdy zakup za 500 dolarów, zbudowałeś wąskie gardło prosto w swojej procedurze awaryjnej.

Rola incident commandera nie jest opcjonalna

Jedna osoba prowadzi incydent. Niekoniecznie najstarszy inżynier domyślnie — osoba najlepiej przygotowana do koordynacji, delegacji i podejmowania decyzji dotyczących zawierania pod presją. Ta osoba niekoniecznie przy incydencie dotyka klawiatury; śledzi oś czasu, zarządza komunikacją z Legal i kierownictwem, decyduje, kiedy przejść do izolacji segmentu lub wyłączenia systemu.

Bez tej roli dostajesz pięć osób SSH'd w to samo pudełko, żadna z nimi nie rozmawia, i nikt nie przechwytuje pamięci volatilnej, zanim ktoś restartuje maszynę, żeby "zobaczyć, czy to naprawy".

Decyzje zawierania, które mają znaczenie

Najtrudniejsze wezwanie w większości incydentów to: izolować teraz czy obserwować trochę dłużej, by zrozumieć skalę? Odcięcie dostępu sieciowego zbyt wcześnie alertuje napastnika, który wciąż porusza się lateralnie, i niszczy szansę zobaczenia jego następnego ruchu. Czekanie zbyt długo pozwala ransomware'owi skończyć szyfrowanie udziałów.

Rozsądny kompromis: używaj segmentacji sieci i izolacji EDR (CrowdStrike, Defender for Endpoint, SentinelOne, wszystkie to wspierają), aby odciąć hosta od ruchu lateralnego, pozostawiając go włączonym do przechwytywania pamięci. Pełne wyłączenie powinno być ostateczności — zabija volatilne dowody i dla przypadków ransomware'u może wyzwolić zachowanie anti-forenzyczne wbudowane w niektóre payloady.

Luki w logowaniu, które będziesz żałować podczas incydentu, nie wcześniej

Domyślne ustawienia Windows Event Log to za mało. Jeśli nie masz wdrożonego Sysmon z przyzwoitą konfiguracją (baseline configs SwiftOnSecurity'ego lub Olafa Hartonga to dobry punkt wyjścia), będziesz rekonstruować drzewa procesów z fragmentów. Po stronie sieci, logów NetFlow lub Zeek ma znaczenie więcej, niż większość organizacji zdaje sobie sprawę, dopóki ich nie potrzebują