opanowanie incydentu

Opanowanie incydentu (containment) to etap reagowania na incydenty, którego celem jest powstrzymanie rozszerzania się incydentu, zanim zagrożenie zostanie trwale usunięte. NIST definiuje je jako zapobieganie rozszerzaniu się incydentu; opanowanie chroni przed dodatkowymi szkodami i przed przeciążeniem zasobów organizacji ^[2]. Niebezpiecznik opisuje ten etap jako powstrzymanie ataku i ograniczenie szkodliwości incydentu oraz postępu związanych z nim szkód ^[7]. Polska ustawa o krajowym systemie cyberbezpieczeństwa używa pojęcia „ograniczenie skutków incydentu” jako części obsługi incydentu ^[3].

Miejsce w procesie

W klasycznym modelu NIST z 2012 roku cykl reagowania ma cztery fazy: przygotowanie; wykrywanie i analizę; opanowanie, usunięcie i odtworzenie; działania po incydencie ^[1]. W trzeciej fazie praca często wraca do analizy, na przykład żeby sprawdzić, czy złośliwe oprogramowanie nie zainfekowało kolejnych maszyn ^[1]. Wydanie z kwietnia 2025 roku przenosi te fazy na funkcje NIST CSF 2.0; opanowanie należy tam do funkcji Respond jako wynik RS.MI-01 „Incidents are contained” ^[2].

RYS. 1Opanowanie w cyklu reagowania

Opanowanie poprzedza usunięcie zagrożenia i przywrócenie działania. NIST podkreśla, że daje ono czas na przygotowanie strategii naprawczej dopasowanej do sytuacji ^[1].

Wybór strategii

Istotą opanowania jest decyzja: wyłączyć system, odłączyć go od sieci czy wyłączyć tylko część funkcji ^[1]. NIST zaleca, aby organizacja przygotowała osobne strategie dla głównych typów incydentów, bo inaczej opanowuje się infekcję przez pocztę, a inaczej atak DDoS ^[1]. Kryteria wyboru strategii według NIST ^[1]:

Typowe działania to izolacja maszyny, kwarantanna złośliwego pliku, zablokowanie konta, odcięcie komunikacji z serwerem C2 (command and control), blokada adresu IP na zaporze. NIST sugeruje, by część z nich wykonywały automatycznie narzędzia takie jak antywirus, na przykład przenosząc maszynę do odizolowanej sieci naprawczej ^[2]. Takie akcje wykonują systemy EDR (Endpoint Detection and Response) i SOAR (Security Orchestration, Automation and Response). Jednocześnie NIST zaleca pozostawienie analitykom możliwości ręcznego wyboru działań ^[2].

Część działań może wykonać ktoś spoza organizacji. NIST proponuje rozważyć upoważnienie dostawców internetu i usług chmurowych do samodzielnego opanowywania niektórych typów incydentów, na przykład ataków DDoS na dużą skalę ^[2]. Ręczny wybór działań jest według NIST łatwiejszy i szybszy, jeśli organizacja ma wcześniej ustalone kryteria i procedury, uwzględniające między innymi typ incydentu, na przykład przejęcie usługi chmurowej albo infekcję ransomware na komputerze pracownika ^[2]. Takie procedury zapisuje się jako playbooki.

Pułapki

Zwłoka celowa. Niektóre organizacje przekierowują napastnika do środowiska izolowanego (sandbox), żeby obserwować jego działania i zebrać dowody ^[1]. NIST ostrzega, że opóźnianie opanowania jest niebezpieczne, bo napastnik może w tym czasie rozszerzyć dostęp lub przejąć inne systemy ^[1]; strategię tę trzeba najpierw omówić z działem prawnym ^[2]. Jeśli organizacja wie o przejęciu systemu i pozwala mu trwać, może odpowiadać za ataki przeprowadzone z tego systemu na innych ^[1].

Reakcja napastnika. Odcięcie maszyny może wywołać dodatkowe szkody. NIST podaje przykład procesu, który okresowo sprawdza łączność z innym hostem, a po jej utracie nadpisuje lub szyfruje dane na dysku ^[1]. Odłączenie od sieci nie oznacza więc, że maszyna jest bezpieczna ^[1].

Utrata dowodów. Z punktu widzenia dowodowego lepiej wykonać migawkę systemu w stanie zastanym niż po tym, jak administratorzy nieumyślnie go zmienią ^[1]. Każde przekazanie dowodu powinno być udokumentowane w ramach chain of custody ^[1]. Dowody przydają się później w analizie śledczej.

W WordPressie

Na przejętej stronie opanowanie oznacza przede wszystkim odcięcie napastnika od dostępu i zatrzymanie szkód dla odwiedzających. CERT Polska zaleca po wykryciu infekcji odcięcie serwera HTTP od sieci, fizycznie lub logicznie, albo włączenie trybu serwisowego ^[4]. Równie pilne jest zabezpieczenie logów serwera HTTP i logów systemowych, zanim rotacja je nadpisze ^[4].

Dokumentacja WordPress.org radzi po wykryciu włamania zablokować środowisko tak, by ograniczyć dalsze zmiany ^[5]:

• wymusić zmianę haseł wszystkich użytkowników, zwłaszcza administratorów ^[5];
• wylogować aktywne sesje przez wymianę kluczy bezpieczeństwa i soli w wp-config.php ^[5];
• zmienić dostęp do FTP lub SFTP, panelu hostingu i bazy MySQL ^[5];
• przed czyszczeniem wykonać jeszcze jedną kopię środowiska, nawet zainfekowanego ^[5].

Na hostingu współdzielonym włamanie może dotyczyć więcej niż jednej strony, dlatego dokumentacja zaleca kontakt z dostawcą hostingu ^[5]. Po opanowaniu następuje usunięcie webshelli i innych tylnych furtek, a na końcu ponowna zmiana haseł, już po oczyszczeniu strony ^[5].

Na serwerze opanowanie można częściowo zautomatyzować. Moduł Active Response systemu Wazuh uruchamia skrypty blokujące złośliwy ruch lub usuwające złośliwe pliki po wystąpieniu określonego alertu ^[6]. Odpowiedź stanowa sama wycofuje się po zadanym czasie ^[6], co odpowiada kryterium czasu trwania z tabeli powyżej.

Obowiązki

Opanowanie nie zwalnia z raportowania. CERT Polska przypomina, że incydent należy zgłosić do właściwego zespołu CSIRT zgodnie z przepisami, niezależnie od tego, czy udało się go opanować ^[4]. Szczegóły opisuje hasło obowiązek zgłaszania incydentów. Jeśli incydent dotyczy danych osobowych, dochodzi też zgłoszenie naruszenia ochrony danych.