Plan Reagowania na Incydenty Cyberbezpieczeństwa
Playbooki, procedury techniczne i checklisty dla Zespołu Reagowania
1. Cel i Struktura Dokumentu
Niniejszy Plan Reagowania na Incydenty (IRP – Incident Response Plan) zawiera szczegółowe procedury techniczne i organizacyjne dla Zespołu Reagowania. Uzupełnia DOC-005 (polityka) i DOC-006 (procedury zgłaszania). Obejmuje:
- Ogólną procedurę reagowania (6 faz PICERL),
- Playbooki dla najczęstszych scenariuszy incydentów,
- Checklisty operacyjne,
- Procedury komunikacji kryzysowej.
ℹ️
Plan musi być dostępny offline – przechowywać wydrukowaną kopię w bezpiecznym miejscu dostępnym bez dostępu do systemów IT (mogą być niedostępne w trakcie incydentu).
▸ Organizacja uzupełnia – lokalizacja kopii offline
Kopia offline przechowywana w: ▸ [np. sejf CISO, recepcja główna, każdy administrator ma wydruk]
Data ostatniej aktualizacji kopii offline: ▸ DD.MM.RRRR
2. Ogólna Procedura Reagowania – 6 Faz PICERL
| Faza | Nazwa | Działania kluczowe | Odpowiedzialny |
|---|---|---|---|
| P | Przygotowanie (Preparation) | Utrzymanie narzędzi, szkoleń, planów; testy; kontakty CSIRT aktualne | ▸ CISO (stale) |
| I | Identyfikacja (Identification) | Wykrycie alertu, wstępna analiza, klasyfikacja P1–P4, zgłoszenie wewnętrzne | ▸ CISO / Admin IT |
| C | Zawieranie (Containment) | Krótkoterminowe (izolacja) + długoterminowe (patch, hardening) | ▸ Admin IT / CISO |
| E | Usuwanie (Eradication) | Eliminacja złośliwego kodu, zamknięcie wektora ataku, weryfikacja | ▸ Admin IT |
| R | Odtwarzanie (Recovery) | Przywracanie systemów, weryfikacja, monitoring po odtworzeniu | ▸ Admin IT / właściciel systemu |
| L | Wnioski (Lessons Learned) | PIR, aktualizacja dokumentacji, raport do CSIRT, komunikacja do zarządu | ▸ CISO |
3. Playbooki – Scenariusze Incydentów
Poniżej playbooki dla najczęstszych i najpoważniejszych typów incydentów. Organizacja może dodać scenariusze specyficzne dla swojego sektora.
PB-001
Ransomware / Szyfrowanie systemów
Kategoria: MAL | Priorytet: P1 | Czas reakcji: natychmiast
FAZA: Identyfikacja
- Potwierdzono zaszyfrowanie plików lub wyświetlenie żądania okupu?
- Zidentyfikowano dotknięte systemy (lista IP / nazwy)?
- Ustalono szacunkowy czas infekcji (kiedy ostatnie dobre pliki)?
- Czy backup jest dostępny i czy nie jest dotknięty?
FAZA: Zawieranie (wykonaj NATYCHMIAST)
1
Odłącz zainfekowane systemy od sieci (wyciągnij kabel/wyłącz Wi-Fi) – NIE wyłączaj zasilania bez zgody CISO
2
Zablokuj ruch wychodzący na porty 445, 139, 3389 na firewallu (lateral movement)
3
Wyłącz połączenia VPN i dostęp zdalny zewnętrznych dostawców
4
Powiadom CISO (tel. ▸ [numer]) – uruchomienie Etapu 2 IRP
5
Zrób zrzut pamięci RAM zainfekowanych systemów (jeśli możliwe – narzędzie: ▸ [np. Magnet RAM Capture, WinPmem])
6
Zabezpiecz logi systemowe, zdarzenia z SIEM, ruch sieciowy (PCAP z ostatnich 24–72h)
FAZA: Usuwanie
7
Zidentyfikuj wariant ransomware (www.nomoreransom.org, VirusTotal)
8
Oceń czy istnieje dekryptor (nomoreransom.org) – NIE płać okupu bez konsultacji z zarządem i prawnikiem
9
Sformatuj i reinstaluj zainfekowane systemy (nie naprawiaj – reinstaluj)
10
Zamknij wektor infekcji (patch podatności, reset haseł, usunięcie konta atakującego)
FAZA: Odtwarzanie
11
Przywróć z backupu sprzed infekcji (procedura DOC-012) – sprawdź czy backup jest czysty
12
Zweryfikuj integralność odtworzonych danych przed przywróceniem do produkcji
13
Monitoruj przez min. ▸ [72h] po odtworzeniu w poszukiwaniu śladów reinfekcji
Raportowanie
🕐
Wczesne ostrzeżenie do CSIRT: 24h | Zgłoszenie: 72h (procedura w DOC-006)
▸ Organizacja uzupełnia – kontakty specjalistyczne
Zewnętrzny IR (forensics): ▸ [nazwa firmy, telefon]
Ubezpieczyciel cyber: ▸ [nr polisy, telefon]
PB-002
Przejęcie konta / Nieautoryzowany dostęp (Account Compromise)
Kategoria: ACC | Priorytet: P1 (konto uprzywilejowane) / P2 (konto zwykłe)
FAZA: Identyfikacja
- Skąd alarm – SIEM, alert MFA, zgłoszenie użytkownika, wykrycie anomalii?
- Jakie konto zostało przejęte (uprzywilejowane / zwykłe)?
- Do jakich zasobów miało dostęp?
- Czy konto jest nadal aktywne?
FAZA: Zawieranie
1
Natychmiast zablokuj konto w Active Directory / IAM:
Disable-ADAccount -Identity [user]2
Unieważnij wszystkie aktywne sesje i tokeny (np. w Azure AD: Revoke-AzureADUserAllRefreshToken)
3
Zmień hasła kont usługowych, które mogły być dostępne dla przejętego konta
4
Zbierz logi logowań z ostatnich ▸ [30 dni] (Active Directory, VPN, aplikacje)
FAZA: Usuwanie i dochodzenie
5
Analiza logów – skąd nastąpiło logowanie, jakie działania podjęto, czy dane były eksfiltrowane
6
Sprawdź czy atakujący nie stworzył backdoor-kont lub nie zmodyfikował uprawnień innych kont
7
Reset hasła użytkownika + wymuszenie MFA przed ponownym dostępem
8
Oceń czy doszło do naruszenia danych osobowych → obowiązek zgłoszenia do UODO w 72h
PB-003
Wyciek / Eksfiltracja Danych (Data Breach)
Kategoria: DAT | Priorytet: P1 (dane osobowe / tajemnica) / P2 (dane wewnętrzne)
Szczególna uwaga: RODO i KSC
⚠️
Naruszenie danych osobowych → zgłoszenie do UODO w ciągu 72h (art. 33 RODO).
Jeśli naruszenie może skutkować wysokim ryzykiem dla praw osób → powiadom osoby, których dane dotyczą (art. 34 RODO).
Jeśli naruszenie może skutkować wysokim ryzykiem dla praw osób → powiadom osoby, których dane dotyczą (art. 34 RODO).
- Jakie dane wyciekły (kategoria, liczba rekordów, dane osobowe?)?
- Jakie osoby są dotknięte?
- Skąd wyciek (system źródłowy)?
- Czy dane trafiły do nieautoryzowanego podmiotu?
- Czy dane są szyfrowane / pseudonimizowane?
FAZA: Zawieranie
1
Zablokuj dostęp do systemu, z którego nastąpił wyciek
2
Zidentyfikuj i zablokuj kanał eksfiltracji (email, FTP, cloud storage, USB)
3
Zabezpiecz dowody (logi DLP, logi bazy danych, ruch sieciowy)
FAZA: Ocena prawna i raportowanie
4
Poinformuj DPO / radcę prawnego – ocena obowiązku zgłoszenia do UODO
5
Zgłoszenie do UODO ([email protected]) w ciągu 72h od stwierdzenia
6
Oceń konieczność powiadomienia dotkniętych osób (art. 34 RODO)
7
Zachowaj dokładną dokumentację decyzji i kroków (niezbędna dla UODO)
PB-004
Atak DDoS – Niedostępność Usług
Kategoria: NET | Priorytet: P1 (usługi kluczowe) / P2 (inne)
- Który serwis/usługa jest niedostępny?
- Jaki typ ataku DDoS (volumetric, protocol, application layer)?
- Skontaktowano się z operatorem telekomunikacyjnym?
- Czy dostępna jest ochrona anty-DDoS u dostawcy?
Działania
1
Aktywuj ochronę anty-DDoS u operatora / CDN (jeśli dostępna): ▸ [dane kontaktowe operatora, nr umowy]
2
Wdróż rate limiting i geo-blocking na poziomie firewall/WAF
3
Aktywuj plan failover / backup łącza: ▸ [dane alternatywnego dostawcy łącza]
4
Monitoruj log ruchu – zbieraj IoC (źródłowe IP, wzorce ataku)
5
Jeśli dotyczy usługi kluczowej → wczesne ostrzeżenie do CSIRT w 24h
▸ Organizacja uzupełnia
Dostawca anty-DDoS: ▸ [nazwa, numer kontaktu 24/7]
Operatorzy telekomunikacyjni (do zgłoszenia blokady upstream): ▸ [nazwa, tel]
▸ Organizacja dodaje playbooki specyficzne dla sektora
Przykładowe dodatkowe playbooki do przygotowania:
PB-005: Phishing / Business Email Compromise (BEC)
PB-006: Atak na systemy OT/SCADA (jeśli dotyczy)
PB-007: Kompromitacja systemu Supply Chain
PB-008: Nieautoryzowany dostęp fizyczny do infrastruktury IT
4. Komunikacja Kryzysowa
📢
Żadna komunikacja zewnętrzna (media, klienci, partnerzy) bez zgody zarządu i radcy prawnego. CISO koordynuje komunikację wewnętrzną. Rzecznik prasowy koordynuje zewnętrzną.
4.1 Komunikacja wewnętrzna
| Odbiorca | Treść komunikatu | Termin | Kanał |
|---|---|---|---|
| Zespół IR | Pełne informacje techniczne | Natychmiast | ▸ [np. Teams / Signal / telefon] |
| Zarząd | Podsumowanie: co się stało, wpływ, działania | W ciągu 2h (P1) | ▸ [np. e-mail zaszyfrowany / telefon] |
| Pracownicy (jeśli dot.) | Instrukcja: co robić / czego nie robić | Jak najszybciej | ▸ [np. e-mail zbiorowy / komunikat wewnętrzny] |
4.2 Komunikacja zewnętrzna
⚠ Krytyczne – zatwierdzenie przez zarząd i prawnika przed wysłaniem
| Odbiorca | Treść | Odpowiedzialny |
|---|---|---|
| CSIRT | Formularz zgłoszenia (DOC-006 zał. B/C) | ▸ CISO |
| UODO (jeśli naruszenie danych os.) | Formularz UODO w ciągu 72h | ▸ CISO / DPO |
| Klienci / użytkownicy (jeśli wymagane RODO) | ▸ [szablon powiadomienia do przygotowania] | ▸ Zarząd / Prawnik |
| Media | Oficjalny komunikat prasowy | ▸ Zarząd / Rzecznik |
| Dostawcy dotknięci incydentem | Informacja o incydencie (jeśli dotyczy) | ▸ CISO / Zarząd |
5. Wyposażenie i Narzędzia Zespołu IR
▸ Organizacja uzupełnia – narzędzia dostępne
| Kategoria | Narzędzie (organizacja wpisuje) | Lokalizacja / dostęp |
|---|---|---|
| SIEM | ▸ [np. Splunk / Microsoft Sentinel / OSSIM] | ▸ |
| EDR / Antywirus | ▸ [np. CrowdStrike / Defender / Sophos] | ▸ |
| Forensics – kopia dysków | ▸ [np. FTK Imager / DD] | ▸ |
| Forensics – analiza pamięci | ▸ [np. Volatility / Magnet RAM] | ▸ |
| Analiza ruchu sieciowego | ▸ [np. Wireshark / NetworkMiner] | ▸ |
| Zarządzanie incydentami | ▸ [np. TheHive / Jira / ServiceNow] | ▸ |
| Komunikacja awaryjna (poza IT) | ▸ [np. telefony komórkowe, Signal] | ▸ |
| Bezpieczne przechowywanie dowodów | ▸ [np. dedykowany dysk offline w sejfie] | ▸ [lokalizacja] |
6. Historia Zmian i Testy Planu
| Wersja | Data | Autor | Opis | Zatwierdził |
|---|---|---|---|---|
| ▸ 1.0 | ▸ DD.MM.RRRR | ▸ | ▸ Pierwsze wydanie | ▸ Zarząd |
Historia testów planu
| Data testu | Typ testu | Scenariusz | Wynik | Działania naprawcze |
|---|---|---|---|---|
| ▸ DD.MM.RRRR | ▸ [Tabletop / Live drill] | ▸ [np. Ransomware P1] | ▸ [Zdany / Częściowo / Niezadowalający] | ▸ |
DOC-007 Plan Reagowania na Incydenty | v1.0 | NIS2/KSC