Polityka Zarządzania Incydentami Cyberbezpieczeństwa
Zasady wykrywania, klasyfikacji, obsługi i raportowania incydentów
1. Cel i Zakres
Niniejsza polityka określa zasady zarządzania incydentami cyberbezpieczeństwa w organizacji, w tym sposób ich wykrywania, klasyfikacji, obsługi, dokumentowania i raportowania do właściwych organów – w szczególności do właściwego CSIRT zgodnie z wymaganiami KSC.
⚠️
Obowiązek ustawowy: Art. 23 NIS2 i art. 10–15 nowelizacji KSC nakładają na podmioty kluczowe i ważne obowiązek posiadania zdolności do wykrywania incydentów oraz ich zgłaszania do właściwego CSIRT w ściśle określonych terminach (wczesne ostrzeżenie: 24 h, zgłoszenie: 72 h, raport końcowy: 1 miesiąc).
2. Definicje i Klasyfikacja Incydentów
2.1 Definicje
| Pojęcie | Definicja |
|---|---|
| Zdarzenie | Każde zaobserwowane wystąpienie w systemie lub sieci wskazujące na możliwe naruszenie bezpieczeństwa |
| Incydent | Zdarzenie mające rzeczywisty niekorzystny wpływ na bezpieczeństwo sieci i systemów informacyjnych |
| Poważny incydent | Incydent powodujący znaczne zakłócenie lub mogący powodować znaczne zakłócenie świadczenia usług kluczowych/ważnych (zob. kryteria istotności w pkt 2.3) |
| Incydent w łańcuchu dostaw | Incydent u dostawcy lub podmiotu zewnętrznego mający wpływ na organizację |
| Podatność | Słabość systemu, która może zostać wykorzystana przez zagrożenie |
| CSIRT | Właściwy Zespół Reagowania na Incydenty (CSIRT NASK / GOV / MON / sektorowy) |
2.2 Klasyfikacja według poziomu dotkliwości
| Poziom | Nazwa | Opis | Przykłady | Czas reakcji |
|---|---|---|---|---|
| P4 | Niski | Ograniczony wpływ, brak zakłóceń usług | Pojedyncze złośliwe oprogramowanie na stacji, próba phishingu bez powodzenia | ▸ [8h]do 24h |
| P3 | Średni | Umiarkowany wpływ, ograniczone zakłócenie | Atak DDoS na systemy pomocnicze, nieautoryzowany dostęp do danych nieklasyfikowanych | ▸ [4h]do 8h |
| P2 | Wysoki | Znaczny wpływ, zakłócenie usług ważnych | Atak ransomware na systemy backoffice, wyciek danych osobowych, kompromitacja konta uprzywilejowanego | ▸ [2h]do 4h |
| P1 | Krytyczny | Poważny incydent w rozumieniu KSC, zakłócenie usług kluczowych | Ransomware na OT/SCADA, atak na infrastrukturę krytyczną, wyciek danych na dużą skalę | ▸ [1h]do 2h |
2.3 Kryteria istotności – próg „poważnego incydentu" (KSC)
⚠ Krytyczne – organizacja określa progi zgodnie z KSC / wytycznymi ENISA
Incydent uznaje się za poważny (wymagający zgłoszenia do CSIRT), gdy spełniony jest co najmniej jeden z poniższych warunków:
| Kryterium | Próg organizacji | Wymaganie min. KSC/NIS2 |
|---|---|---|
| Czas niedostępności usługi kluczowej | ▸ [np. powyżej 30 min]próg wg sektora | Wg rozporządzenia wykonawczego do KSC dla sektora |
| Liczba dotkniętych użytkowników | ▸ [np. powyżej X użytkowników] | Wg rozporządzenia wykonawczego do KSC |
| Strata finansowa (szacunkowa) | ▸ [np. powyżej X PLN] | — |
| Wyciek danych osobowych | Każde naruszenie danych osobowych | RODO art. 33 (zgłoszenie do UODO 72h) |
| Wpływ na infrastrukturę krytyczną | Każde zdarzenie dotykające OT/ICS | Art. 23(3) NIS2 |
| Zasięg geograficzny | ▸ [np. incydent transgranicznie, min. 2 państwa UE] | Art. 23(6) NIS2 – zgłoszenie do ENISA |
3. Obowiązek i Terminy Zgłaszania – Wymóg KSC/NIS2
🕐
Terminy są ustawowe i nieprzekraczalne. Przekroczenie grozi karą administracyjną.
| Etap zgłoszenia | Termin | Adresat | Zawartość |
|---|---|---|---|
| Wczesne ostrzeżenie (Early Warning) |
24 godziny od wykrycia |
Właściwy CSIRT ▸ [CSIRT NASK / sektorowy] |
Informacja o wystąpieniu poważnego incydentu lub podejrzenia; wskazanie wpływu transgranicznego (jeśli dotyczy) |
| Zgłoszenie incydentu | 72 godziny od wykrycia |
Właściwy CSIRT | Ocena incydentu, wstępna klasyfikacja dotkliwości, wskaźniki kompromitacji (IoC), podjęte działania zaradcze |
| Raport pośredni (jeśli wymagany) |
Na żądanie CSIRT | CSIRT / organ nadzorczy | Aktualny status obsługi, ewolucja incydentu |
| Raport końcowy | 1 miesiąc od zgłoszenia lub od zamknięcia incydentu |
Właściwy CSIRT | Pełny opis incydentu, pierwotna przyczyna (RCA), podjęte środki zaradcze, wyciągnięte wnioski |
| Naruszenie danych osobowych (RODO) |
72 godziny od wykrycia |
UODO | Formularz UODO: charakter naruszenia, liczba osób, możliwe skutki, podjęte środki |
3.1 Ścieżka eskalacji i powiadamiania
Każdy pracownik, który wykryje lub podejrzewa incydent, zobowiązany jest niezwłocznie powiadomić:
- Swojego przełożonego ORAZ
- CISO / Osobę odpowiedzialną za cyberbezpieczeństwo przez:
- Telefon: ▸ [numer alarmowy 24/7]
- E-mail: ▸ [[email protected] lub dedykowany adres]
- System ticketowy: ▸ [nazwa systemu, np. ServiceNow / Jira]
⚠️
Zakaz samodzielnego usuwania śladów! Pracownik, który wykryje incydent, nie może podejmować działań mogących zniszczyć dowody (logi, pliki). Należy wyłącznie zgłosić zdarzenie i – jeśli to konieczne – odłączyć urządzenie od sieci.
4. Kategorie Incydentów
| Kategoria | Typ | Przykłady |
|---|---|---|
| MAL | Złośliwe oprogramowanie | Ransomware, wirus, trojan, spyware, rootkit, cryptominer |
| PHI | Phishing / Inżynieria społeczna | Spear phishing, vishing, smishing, BEC (Business Email Compromise) |
| NET | Ataki sieciowe | DDoS, skanowanie, man-in-the-middle, brute force, port scanning |
| WEB | Ataki na aplikacje webowe | SQL injection, XSS, CSRF, RFI/LFI, atak na API |
| ACC | Naruszenie kontroli dostępu | Nieautoryzowany dostęp, przejęcie konta, eskalacja uprawnień |
| DAT | Naruszenie danych | Wyciek danych, eksfiltracja, nieautoryzowane ujawnienie, zgubienie nośnika |
| INS | Insider threat | Celowe działanie pracownika, sabotaż, kradzież IP |
| SUP | Łańcuch dostaw | Kompromitacja oprogramowania dostawcy, backdoor w sprzęcie |
| PHY | Fizyczny | Kradzież sprzętu, nieautoryzowany dostęp do serwerowni |
| OTH | Inne | Nieuprawniona modyfikacja konfiguracji, błędna konfiguracja, anomalia w OT |
5. Role i Odpowiedzialności w Zarządzaniu Incydentami
Szczegółowa macierz RACI dla incydentów w DOC-004. Poniżej kluczowe obowiązki:
| Rola | Obowiązki przy incydencie |
|---|---|
| Każdy pracownik | Natychmiastowe zgłoszenie podejrzanego zdarzenia; nieusuwanie dowodów; odłączenie urządzenia jeśli konieczne |
| CISO / Koordynator IR | Ocena i klasyfikacja; uruchomienie procedury reagowania; powiadomienie CSIRT; eskalacja do zarządu; dokumentacja |
| Administrator IT | Zbieranie logów i dowodów forensycznych; izolacja systemów; wdrożenie środków zaradczych; odtwarzanie |
| Zarząd | Podejmowanie decyzji kryzysowych; autoryzacja działań nadzwyczajnych; komunikacja zewnętrzna (media, regulatorzy) |
| Radca prawny / DPO | Ocena obowiązków prawnych; zgłoszenie do UODO (jeśli dotyczy); dokumentacja prawna |
6. Rejestr Incydentów
Organizacja prowadzi centralny Rejestr Incydentów. Każdy incydent (niezależnie od poziomu) musi być zarejestrowany. Rejestr jest prowadzony przez CISO i przechowywany przez ▸ min. 5 latmin. 5 lat – KSC.
▸ Organizacja uzupełnia – narzędzie prowadzenia rejestru
Narzędzie: ▸ [np. system SIEM / ticketing (ServiceNow / Jira) / dedykowany arkusz]
Lokalizacja: ▸ [ścieżka / URL do rejestru]
Dostęp: ▸ [kto ma dostęp do rejestru]
Minimalna zawartość wpisu w rejestrze incydentów:
| Pole | Opis | Wymagane? |
|---|---|---|
| ID incydentu | Unikalny identyfikator (np. INC-2024-001) | TAK |
| Data i godzina wykrycia | Timestamp pierwszego wykrycia | TAK |
| Kategoria (zob. pkt 4) | MAL / PHI / NET / WEB / ACC / DAT / INS / SUP / PHY / OTH | TAK |
| Poziom dotkliwości (P1–P4) | Zob. pkt 2.2 | TAK |
| Opis zdarzenia | Co się stało, jakie systemy dotknięte | TAK |
| Dotknięte systemy / usługi | Lista systemów/aktywów | TAK |
| Pierwotna przyczyna (RCA) | Po zamknięciu incydentu | TAK (po zamknięciu) |
| Podjęte działania | Chronologiczny log działań | TAK |
| Czy zgłoszono do CSIRT? | TAK/NIE + data i godzina zgłoszenia | TAK (jeśli P1) |
| Czy zgłoszono do UODO? | TAK/NIE + data | TAK (jeśli dotyczy) |
| Data zamknięcia | Timestamp zamknięcia incydentu | TAK |
| Wyciągnięte wnioski (lessons learned) | Co poprawić | TAK (po zamknięciu) |
7. Wyciąganie Wniosków i Doskonalenie
Po każdym incydencie P1 i P2 oraz wybranych incydentach P3 przeprowadzany jest przegląd post-incydentowy (Post-Incident Review / PIR) w ciągu ▸ [5 dni roboczych]max. 2 tyg. od zamknięcia incydentu.
PIR odpowiada na pytania:
- Co się stało i dlaczego (analiza przyczyn źródłowych – RCA)?
- Czy procedury zadziałały poprawnie?
- Czy zgłoszenie do CSIRT odbyło się w terminie?
- Jakie zmiany w zabezpieczeniach należy wdrożyć?
- Czy aktualizacja Rejestru Ryzyk (DOC-003) jest potrzebna?
Wnioski z PIR są przekazywane do CISO i implementowane jako działania naprawcze z określonym terminem i właścicielem.
8. Testowanie Zdolności do Reagowania
Organizacja regularnie testuje procedury zarządzania incydentami:
| Typ testu | Częstotliwość | Zakres | Odpowiedzialny |
|---|---|---|---|
| Ćwiczenie Tabletop (symulacja stołowa) | ▸ min. raz na rokmin. 1/rok – NIS2 | Scenariusz incydentu P1 z udziałem zarządu i CISO | ▸ CISO |
| Test komunikacji alarmowej | ▸ [co kwartał] | Weryfikacja kanałów zgłaszania, numerów kontaktowych | ▸ CISO / Admin IT |
| Test powiadamiania CSIRT | ▸ [raz w roku, w ramach ćwiczenia] | Weryfikacja formularzy, kanałów komunikacji z CSIRT | ▸ CISO |
9. Historia Zmian
| Wersja | Data | Autor | Opis | Zatwierdził |
|---|---|---|---|---|
| ▸ 1.0 | ▸ DD.MM.RRRR | ▸ | ▸ Pierwsze wydanie | ▸ Zarząd |
DOC-005 Polityka Zarządzania Incydentami | v1.0 | NIS2/KSC