KSC-realizacja

Wytyczne i materiały pomocnicze dotyczące realizacji ustawy o krajowym systemie cyberbezpieczeństwa (uKSC). Treść ma charakter operacyjno-audytowy — uzupełnia przepisy ustawy o praktyczne kroki i dowody dokumentacyjne.

Tekst ustawy o KSC (ISAP)

Przepisy o karach pieniężnych
Rozpoczęcie korzystania z systemu teleinformatycznego (art. 46 ust. 1)

SYS 46 — Wykaz KSC — logowanie do systemu teleinformatycznego

Art. 8 pkt 1 — systematyczne szacowanie i zarządzanie ryzykiem

Samo podejście do zarządzania ryzykiem powinno opierać się na uznanych standardach międzynarodowych (w polskich realiach kluczowa jest norma ISO/IEC 27005 oraz ISO/IEC 27001, na co wprost wskazują m.in. wymagania kompetencyjne dla audytorów KSC).

Poniżej wykaz kluczowych czynności oraz sposobu ich dokumentowania, które pozwalają wykazać przed organem właściwym ds. cyberbezpieczeństwa (np. podczas kontroli lub audytu), że obowiązek ten jest realizowany.

1. Czynności wdrożeniowe i operacyjne

Zarządzanie ryzykiem to proces ciągły (cykl Deminga: PDCA), a nie jednorazowe zdarzenie. Obejmuje następujące kroki:

  • Zdefiniowanie kontekstu i granic systemu: określenie, które dokładnie systemy informacyjne, infrastruktura (w tym OT/SCADA w przemyśle), zasoby ludzkie i dostawcy biorą udział w świadczeniu danej usługi kluczowej.
  • Inwentaryzacja i klasyfikacja aktywów: identyfikacja wszystkich zasobów powiązanych z usługą kluczową oraz przypisanie im wartości (poufność, dostępność, integralność).
  • Identyfikacja podatności i zagrożeń: regularne mapowanie zagrożeń dla aktywów.
  • Ocena i analiza ryzyka (szacowanie): prawdopodobieństwo wystąpienia zagrożenia oraz potencjalny wpływ na ciągłość usługi kluczowej.
  • Postępowanie z ryzykiem (mitygacja): decyzje właścicieli biznesowych:
    • Redukcja (modyfikacja): wdrożenie zabezpieczeń (np. MFA, podział sieci, backup).
    • Unikanie: rezygnacja z niebezpiecznego procesu.
    • Przeniesienie: np. ubezpieczenie cybernetyczne.
    • Akceptacja: świadoma zgoda zarządu na ryzyko szczątkowe poniżej progu akceptowalnego.
  • Przeglądy i aktualizacje: przeliczanie ryzyka w stałych interwałach (np. raz w roku) oraz ad hoc przy istotnych zmianach, krytycznych podatnościach (0-day) lub po poważnym incydencie.

2. Sposób udokumentowania

W realiach uKSC „jeśli coś nie zostało zapisane, to się nie wydarzyło”. Kluczowe artefakty dokumentacyjne:

A. Dokumenty procesowe (metodyka)

  • Metodyka szacowania ryzyka — skale, kryteria wpływu na usługę kluczową, progi akceptacji przez kierownictwo.
  • Polityka zarządzania ryzykiem IT/cyberbezpieczeństwa — role i odpowiedzialności.

B. Dokumenty operacyjne

  • Rejestr aktywów (inwentarz) powiązany z usługą kluczową.
  • Macierz / rejestr ryzyka — scenariusze, ryzyko pierwotne i szczątkowe, właściciele.
  • Plan postępowania z ryzykiem (RTP) — harmonogram działań naprawczych powyżej progu akceptacji.
  • Raport z sesji szacowania ryzyka — podsumowanie spotkania zespołu ds. ryzyka.

C. Dokumenty zarządcze

  • Formalna akceptacja ryzyka szczątkowego przez zarząd / kierownictwo OUK.
  • Powołanie zespołu ds. szacowania ryzyka — decyzja wewnętrzna ze składem osobowym.
Praktyczna wskazówka audytorska: dokumentacja szacowania ryzyka musi bezpośrednio „zasilać” dobór zabezpieczeń wynikających z rozporządzenia w sprawie warunków technicznych i organizacyjnych. Audytor zwykle wybiera system z rejestru aktywów, żąda powiązanych wpisów w rejestrze ryzyka i weryfikuje w RTP terminy oraz budżety działań naprawczych.
Art. 8 pkt 2 — środki techniczne i organizacyjne (lit. a–e)

Realizacja art. 8 pkt 2 uKSC to bezpośrednia konsekwencja wcześniejszego oszacowania ryzyka. Kluczowe sformułowania: odpowiednie i proporcjonalne oraz najnowszy stan wiedzy.

a) Utrzymanie i bezpieczna eksploatacja systemu informacyjnego

Cel: Zapewnienie, że system działa w sposób stabilny, kontrolowany i odporny na błędy oraz ataki.

Czynności:

  • Zarządzanie podatnościami i poprawkami (Patch Management): regularne skanowanie systemów i niezwłoczne instalowanie aktualizacji bezpieczeństwa (systemy operacyjne, bazy danych, firmware urządzeń sieciowych).
  • Zarządzanie konfiguracją (Hardening): wyłączanie niepotrzebnych usług, portów i protokołów; zmiana domyślnych haseł fabrycznych; stosowanie bezpiecznych konfiguracji (np. według standardów CIS Benchmarks).
  • Zarządzanie uprawnieniami (IAM): nadawanie uprawnień zgodnie z zasadą najmniejszych przywilejów (Least Privilege) oraz rozdzielenia obowiązków (Separation of Duties). Regularny przegląd kont (szczególnie uprzywilejowanych).
  • Kopie zapasowe (Backup): automatyczne tworzenie backupów, ich szyfrowanie oraz regularne, dokumentowane testy odtwarzania danych z kopii (np. raz na kwartał). Stosowanie zasady 3-2-1 (w tym kopie offline/immutable backup, odporne na ransomware).

Dokumentacja (dowody): polityka i procedury zarządzania uprawnieniami / kontami; procedura tworzenia i testowania kopii zapasowych wraz z logami/raportami z udanych testów odtworzeniowych; procedura zarządzania zmianą (Change Management) — rejestr zgłoszeń zmian w infrastrukturze IT; raporty ze skanów podatności i plany ich mitygacji.

b) Bezpieczeństwo fizyczne i środowiskowe, uwzględniające kontrolę dostępu

Cel: Ochrona infrastruktury sprzętowej przed nieuprawnionym dostępem fizycznym oraz zagrożeniami losowymi (pożar, zalanie, awaria zasilania).

Czynności:

  • Wydzielenie stref bezpieczeństwa: zamknięte serwerownie, szafy rackowe zabezpieczone zamkami, ograniczenie dostępu tylko dla personelu upoważnionego.
  • Kontrola dostępu (SKD): imienne karty dostępowe, biometria lub zamki szyfrowe rejestrujące wejścia i wyjścia.
  • Monitoring i ochrona: CCTV rejestrujące kluczowe punkty wejścia oraz systemy alarmowe (SSWiN).
  • Zabezpieczenia środowiskowe: klimatyzacja precyzyjna, wczesna detekcja i gaszenie pożaru (np. gazem), czujniki zalania.
  • Gwarancja zasilania: UPS oraz agregaty prądotwórcze (wraz z procedurą testowania pod obciążeniem).

Dokumentacja (dowody): polityka bezpieczeństwa fizycznego i środowiskowego; ewidencja osób upoważnionych do przebywania w serwerowni oraz rejestr wejść osób trzecich; logi SKD; protokoły z przeglądów technicznych (UPS, agregaty, ppoż., klimatyzacja).

c) Bezpieczeństwo i ciągłość dostaw usług

Cel: Zapewnienie, że zewnętrzni dostawcy (chmura, Internet, serwis, energia) nie stanowią słabego ogniwa w łańcuchu dostaw (Supply Chain Security).

Czynności:

  • Identyfikacja krytycznych dostawców — mapa zależności usługi kluczowej od podmiotów trzecich.
  • Weryfikacja i audyt dostawców — ocena dojrzałości cyberbezpieczeństwa (np. ISO 27001, raporty SOC 2).
  • Zapisy umowne (SLA / Cyber Security Annex) — czas reakcji, raportowanie incydentów, prawo do audytu, zakaz podzlecania bez zgody OUK.
  • Zarządzanie dostępem zdalnym dostawców — kontrola VPN/pulpitów zdalnych, dostęp na czas prac, nagrywanie sesji.

Dokumentacja (dowody): rejestr krytycznych dostawców i umów; umowy z klauzulami SLA i bezpieczeństwa informacji; procedura zarządzania dostawcami zewnętrznymi; raporty z weryfikacji/audytów dostawców.

d) Wdrażanie, dokumentowanie i utrzymywanie planów działania (BCP/DRP)

Cel: Ciągłość usługi kluczowej (BCP) i odtworzenie infrastruktury po katastrofie (DRP) przy zachowaniu poufności, integralności, dostępności i autentyczności.

Czynności:

  • Analiza BIA: krytyczne procesy, RTO i RPO.
  • Opracowanie planów awaryjnych — instrukcje krok po kroku (awaria zasilania, ransomware, niedostępność personelu).
  • Redundancja — HA, zapasowe łącza, redundantne zasilacze, DR site.
  • Cykliczne testy planów — symulacje stolikowe i testy techniczne minimum raz w roku.

Dokumentacja (dowody): raport BIA; plany BCP i DRP; strategia ciągłości zatwierdzona przez zarząd; protokoły i raporty z testów z wnioskami aktualizującymi plany.

e) Objęcie systemu informacyjnego systemem monitorowania w trybie ciągłym

Cel: Stała widoczność sieci i systemów w celu natychmiastowego wykrywania anomalii i prób ataków (24/7/365).

Czynności:

  • Centralizacja logów (SIEM/Log Management).
  • Monitorowanie ruchu i punktów końcowych — IDS/IPS, EDR/XDR, monitoring wydajności.
  • Struktura SOC (własna lub MSSP) analizująca alerty w trybie ciągłym.
  • Definicja reguł korelacji — np. 50 nieudanych logowań/min na konto administratora.

Dokumentacja (dowody): polityka/procedura monitorowania i retencji logów; umowa z zewnętrznym SOC lub struktura wewnętrznego SOC; raporty SIEM/EDR; rejestr incydentów z widoczną ścieżką audytową.

Art. 8 pkt 5 — środki zapobiegające i ograniczające wpływ incydentów (lit. a–d)

a) Stosowanie mechanizmów zapewniających poufność, integralność, dostępność i autentyczność danych

Wymaganie odnosi się do triady CIA poszerzonej o autentyczność — dla danych w spoczynku, w ruchu i w użyciu.

Czynności:

  • Poufność: szyfrowanie AES-256, TLS 1.3, DLP blokujące wyciek wrażliwych danych.
  • Integralność: funkcje skrótu (SHA-256), podpisy cyfrowe.
  • Dostępność: redundancja (klastry, load balancery), ochrona przed DDoS.
  • Autentyczność: obowiązkowe MFA (zwłaszcza administratorzy, dostęp zdalny), DKIM/SPF/DMARC dla poczty.

Dokumentacja (dowody): polityka kryptograficzna; procedury konfiguracji szyfrowania i MFA; raporty z testów odporności na DDoS; konfiguracja DNS poczty (SPF/DKIM/DMARC).

b) Dbałość o aktualizację oprogramowania

Aspekt zapobiegania incydentom poprzez eliminację znanych podatności (N-day) — uzupełnia eksploatację z art. 8 pkt 2 lit. a.

Czynności:

  • Automatyzacja i centralizacja — WSUS, SCCM, Ansible, narzędzia Linux.
  • Klasyfikacja i priorytetyzacja — łatki krytyczne (RCE, CVSS 9.0–10.0) w trybie pilnym po testach.
  • Wycofywanie systemów legacy (EoL) — identyfikacja i izolacja sieciowa.

Dokumentacja (dowody): procedura patch management ze SLA (np. łatka krytyczna = max 72 h); raporty compliance z systemów zarządzania aktualizacjami; metryki czasu instalacji poprawek.

c) Ochrona przed nieuprawnioną modyfikacją w systemie informacyjnym

Cel: wykrywanie i blokowanie wstrzyknięcia złośliwego kodu, zmiany konfiguracji lub manipulacji w logach.

Czynności:

  • FIM (File Integrity Monitoring): OSSEC, Tripwire — alert przy nieautoryzowanej zmianie plików krytycznych.
  • EDR/XDR: blokowanie podejrzanych zachowań procesów.
  • Immutable logs (WORM): logi SIEM odporne na kasowanie przez atakującego z uprawnieniami admina.
  • Restrykcyjne blokowanie praw zapisu do katalogów systemowych.

Dokumentacja (dowody): raporty i logi FIM; polityki EDR w trybie enforcement; architektura zabezpieczenia serwera logów.

d) Niezwłoczne podejmowanie działań po dostrzeżeniu podatności lub zagrożeń

Esencja zarządzania incydentami w trybie reaktywnym — kluczowe słowo: niezwłoczne.

Czynności:

  • Procedura Incident Response (IR) i playbooks (ransomware, wyciek danych, 0-day).
  • Virtual patching — reguły IPS/WAF/firewall gdy oficjalna poprawka niedostępna.
  • Szybka izolacja (containment) — odcięcie zainfekowanego segmentu/hosta.
  • Współpraca z CSIRT krajowym — zgłoszenia w terminie 24 h, stosowanie rekomendacji.

Dokumentacja (dowody): procedura zarządzania incydentami z matrycą eskalacji; playbooks; historia ticketów z osią czasu (wykrycie → działania → zamknięcie); dowody zgłoszeń do CSIRT.

Podsumowanie dla audytu KSC: środki muszą być proporcjonalne do ryzyka z art. 8 pkt 1. Brak korelacji między wysokim ryzykiem a brakiem adekwatnych środków z pkt 5 to częsta przyczyna negatywnych ocen audytorskich.
Art. 9 ust. 1 pkt 1 — osoba kontaktowa (system S46)

SYS 46 — Wykaz KSC — logowanie do rejestru

Z punktu widzenia audytu KSC samo wklepanie danych do systemu S46 to krok końcowy. Pełna realizacja wymaga udokumentowanej ścieżki:

1. Czynności wykonawcze

  • Formalne wyznaczenie — zarządzenie wewnętrzne, nie „ustne dogadanie”.
  • Dyspozycyjność 24/7/365 — osoba wiodąca (np. CISO) plus zastępcy.
  • Zgłoszenie do organów — dane teleadresowe w systemie S46, bieżąca aktualizacja przy rotacji kadrowej.

2. Dokumentacja (co sprawdza audytor)

  • Zarządzenie / akt powołania osoby kontaktowej.
  • Karta stanowiskowa z obowiązkami wynikającymi z uKSC.
  • Potwierdzenie z systemu S46 (zrzut ekranu profilu lub urzędowe potwierdzenie).
  • Procedura zastępstw (matryca eskalacji).
Art. 10 ust. 1 — dokumentacja cyberbezpieczeństwa
Art. 11 ust. 1 pkt 1 — obsługa incydentu

Realizacja obejmuje pełen cykl: wykrycie, analiza, powstrzymanie, usunięcie skutków i wnioski (ISO/IEC 27035, NIST SP 800-61).

1. Architektura procesu

Faza I: Przygotowanie i wykrywanie

  • Monitorowanie SIEM/EDR 24/7/365.
  • Punkt kontaktowy (Single Point of Contact) do zgłoszeń.

Faza II: Analiza i triaż

  • Weryfikacja false positive vs. realny incydent.
  • Klasyfikacja wpływu na usługę kluczową i priorytetyzacja.

Faza III: Powstrzymywanie, eradykacja, odtwarzanie

  • Izolacja (containment), usunięcie źródła, odtwarzanie z czystych backupów.

Faza IV: Działania poincydentalne

  • Analiza post-mortem i aktualizacja procedur/architektury.

2. Modele realizacji

  • In-house — własny CSIRT/CERT/SOC.
  • Outsourcing (MSSP) — zewnętrzny SOC; w OUK nadal potrzebny koordynator decyzyjny.

3. Dokumentacja

Formalna: procedura zarządzania incydentami, playbooks/runbooks, matryca eskalacji.

Operacyjna: system ticketowy z osią czasu (wykrycie → kwalifikacja → containment → zamknięcie), raporty poincydentalne.

Obsługa incydentów Rejestr incydentów

Techniczna: umowa SLA z SOC, certyfikaty/szkolenia personelu, raporty z ćwiczeń (cyber exercises).

Art. 11 ust. 1 pkt 4 — zgłoszenie incydentu poważnego
Art. 11 ust. 1 pkt 5 — współpraca z CSIRT
Art. 32 ust. 2 — usuwanie podatności
Art. 14 ust. 1 — struktury wewnętrzne / umowy outsourcingowe
Audyt, kontrola i zalecenia pokontrolne

Art. 73 ust. 1 pkt 11 — audyt

Obowiązek przeprowadzenia audytu zgodności z uKSC.

Art. 73 ust. 1 pkt 12 — utrudnianie kontroli

Art. 73 ust. 1 pkt 13 — zalecenia pokontrolne

Dostawca usługi cyfrowy — art. 18 i art. 73 ust. 2

Art. 18 ust. 1 pkt 4 — zgłoszenie incydentu istotnego

Art. 18 ust. 1 pkt 5 — obsługa incydentu we współpracy z CSIRT

Art. 73 ust. 2 pkt 3 — usuwanie podatności (DUC)

Patrz sekcja Art. 32 ust. 2 — ten sam mechanizm wezwania do usunięcia podatności w wyznaczonym terminie.