Ścieżka zgodności · Ustawa o KSC

Sprawozdanie z postępu obsługi incydentu — jak spełnić art. 12b UKSC krok po kroku

Gdy obsługa incydentu poważnego nie zakończyła się w terminie sprawozdania końcowego: sprawozdanie z postępu obsługi do właściwego CSIRT sektorowego oraz sprawozdanie końcowe w ciągu miesiąca od zakończenia obsługi. Poniżej ta norma rozłożona na warstwy: wymagania → kontrole standardów → rozwiązania. Zacznijcie od pytania, czy ten obowiązek Was wiąże — odpowiedź jest pierwszą sekcją pod spodem.

wiąże: podmiot kluczowy i podmiot ważny art. 12b UKSC transponuje art. 23 ust. 4 NIS2 NIST CSF 2.0

Zaplanujcie wdrożenie z Inteca Przegląd ścieżek

                2
                wymagania wiążące wyprowadzone z art. 12b UKSC.
              

2 mapowania na 2 kontrole katalogu: NIST CSF 2.0 — każde z pisemnym uzasadnieniem.

4 kategorie rozwiązań (taksonomia ECSO), do których prowadzą kontrole tej ścieżki.

2 rozwiązania referencyjne na końcu ścieżki: narzędzia open source i szablony dokumentów Inteca; dla 2 kategorii model nie wskazuje rozwiązania.

Krok zero

Kogo wiąże ten obowiązek?

Zanim przeczytacie choć jedno wymaganie — sprawdźcie, czy ta ścieżka jest Wasza. Odpowiedź nie jest pisana ręcznie: wynika z zakresu obowiązku zapisanego w modelu prawnym.

wiąże wprost

Podmioty kluczowe i Podmioty ważne

Ten obowiązek wiąże podmioty kluczowe i podmioty ważne. Jeśli jesteście w wykazie w tej klasie, ta ścieżka jest Waszą listą zadań.

nie wiąże

Podmioty ważne — sektor publiczny

Ten obowiązek nie wiąże podmioty ważne z sektora publicznego — model nie wskazuje dla tej klasy odpowiednika w tym samym artykule.

nie wiecie?

Sprawdźcie swój rodzaj podmiotu

Klasa podmiotu to nie wszystko — decyduje rodzaj podmiotu, sektor i wielkość. Kwalifikator KSC wskaże Wasz rodzaj, a wynik powie wprost, czy ten obowiązek jest w Waszym katalogu.

Ten blok wygląda tak samo na każdej ścieżce: obowiązek z UKSC pokaże tu klasy podmiotów (kluczowy / ważny / publiczny), obowiązek z CIR — dostawców cyfrowych. Dyrektywa NIS2 nie ma własnych ścieżek — pokazujemy ją niżej, jako źródło obowiązku.

Skąd ten obowiązek

Art. 23 ust. 4 NIS2 → art. 12b UKSC

Dyrektywa NIS2 wiąże państwa, nie Was — dlatego nie ma osobnej ścieżki. Ma za to 1 przepis ogólny, który Polska przeniosła do tego przepisu ustawy.

źródło · dyrektywa

Art. 23 ust. 4 NIS2

„Kaskada zgłoszeniowa poważnego incydentu do CSIRT lub właściwego organu: wczesne ostrzeżenie (24h), zgłoszenie incydentu (72h), sprawozdanie okresowe na wniosek, sprawozdanie końcowe (miesiąc) oraz sprawozdanie z postępu prac przy incydencie trwającym."

Model łączy ten obowiązek z 1 przepisem dyrektywy relacją „transponuje", z oceną „równoważna".

ta ścieżka · UKSC

Art. 12b UKSC

„przekazuje właściwemu CSIRT sektorowemu sprawozdanie z postępu obsługi tego incydentu"; „przekazuje właściwemu CSIRT sektorowemu sprawozdanie końcowe niepóźniej niż w ciągu miesiąca od zakończenia obsługi incydentu poważnego"

Polska przeniosła ten przepis do ustawy — to wiersze tabeli niżej (2 wymagania wiążące). Treść cytowana z modelu, nie pisana.

Przebieg ścieżki

Od ustawy do narzędzia i szablonu

Diagram pokazuje jedną nitkę ścieżki — wymaganie 1 z 2 wiążących — w komplecie warstw. Tabela niżej rozwija pozostałe wymagania.

przepis obowiązek wymaganie kontrola standardu rozwiązanie

Diagram wygenerowany z żywego modelu IRNIS przy publikacji tej strony.

Warstwa wymagań i kontroli

Wymagania tego obowiązku i ich odpowiedniki w standardach

Każdy wiersz to jedno atomowe wymaganie — dokładnie w brzmieniu z modelu, o które zapyta audytor — z kontrolami, na które mapuje je model.

Wymaganie (brzmienie z modelu)	Charakter	Kontrole standardów
Procesy i procedurywymagania wiążące — proceduralne
Podmiot przekazuje właściwemu CSIRT sektorowemu sprawozdanie z postępu obsługi incydentu poważnego.	proceduralne	NIST CSF · RC.CO-03
Podmiot przekazuje właściwemu CSIRT sektorowemu sprawozdanie końcowe nie później niż w ciągu miesiąca od zakończenia obsługi incydentu poważnego.	proceduralne	NIST CSF · RS.CO-03

Komplet wymagań tego obowiązku — 2 wiersze, generowanych z modelu przy każdej publikacji. Każde mapowanie na kontrolę ma w modelu pisemne uzasadnienie i ocenę dopasowania — na stronie pokazujemy cel mapowania.

Kolumna „kontrole" mówi Wam, gdzie tę samą rzecz mierzy Wasz certyfikat ISO albo profil NIST — jeśli kontrolę już macie wdrożoną i udokumentowaną, ta część ścieżki jest do reużycia, nie do budowy od zera.

Warstwa rozwiązań

Czym to zrealizować — rekomendacje referencyjne

Kontrole prowadzą do 4 kategorii rozwiązań (taksonomia ECSO); model wskazuje dla nich 2 rozwiązania referencyjne; dla 2 kategorii — żadnego, i strona mówi to wprost. Wasze własne narzędzie tej samej kategorii też domyka ścieżkę.

DFIR-IRIS

Platforma open source do obsługi incydentów: sprawy, oś czasu, artefakty i zadania zespołu reagowania — operacyjny zapis tego, o co zapyta CSIRT i audytor.

rekomendowaneopen sourcenarzędzieIncident Management

Szablon: Plan reagowania na incydenty i komunikacji

Autorski szablon planu reagowania na incydenty i komunikacji — klasyfikacja, eskalacja, terminy zgłoszeń, komunikaty do stron.

szablon Intecaszablon planuCrisis Communication

Communications coaching & consulting · Cyber Threat Intelligence — bez rekomendacji w modelu

Kontrole prowadzą też do tych kategorii, ale model nie wskazuje dla nich rozwiązania referencyjnego. Wasze własne narzędzie tej kategorii domyka ścieżkę tak samo.

dowolna realizacja

Uczciwie o granicach

Czego ta ścieżka nie zrobi za Was

Nie zastąpi dowodów operacyjnych

Ścieżka daje strukturę i uzasadnienia — mapę tego, co wykazać. Zapisy, decyzje, logi i podpisane dokumenty musicie wytworzyć u siebie; o oczekiwaniach audytora więcej na stronie audyt KSC/NIS2.

Chcecie przejść tę ścieżkę z przewodnikiem?

Inteca poprowadzi wdrożenie warstwa po warstwie: od wymagań przepisu, przez kontrole standardów, po narzędzia i bazę dowodową pod audyt.

Umówcie konsultację Wróćcie do przeglądu ścieżek