KSC i NIS2 zmieniają podejście do cyberbezpieczeństwa w organizacjach. Cyberbezpieczeństwo nie jest już wyłącznie zadaniem działu IT, ale obszarem zarządzania ryzykiem, odpowiedzialności kierownictwa, ciągłości działania, nadzoru nad dostawcami, obsługi incydentów i dokumentowania skuteczności wdrożonych środków.
W Polsce podstawowym aktem prawnym jest ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Ustawa wdraża dyrektywę Parlamentu Europejskiego i Rady UE 2022/2555, czyli dyrektywę NIS2.
KSC, czyli krajowy system cyberbezpieczeństwa, to polski system obejmujący podmioty, organy, CSIRT-y, procedury, obowiązki i mechanizmy współpracy w zakresie cyberbezpieczeństwa.
NIS2 to dyrektywa Unii Europejskiej, której celem jest podniesienie wspólnego poziomu cyberbezpieczeństwa w państwach członkowskich. Dyrektywa określa między innymi środki zarządzania ryzykiem cyberbezpieczeństwa, obowiązki zgłaszania incydentów, wymianę informacji, nadzór i egzekwowanie przepisów.
W Polsce wymagania NIS2 są realizowane przede wszystkim przez ustawę o krajowym systemie cyberbezpieczeństwa.
W praktyce KSC/NIS2 dotyczy zarządzania ryzykiem, odpowiedzialności kierownictwa, dokumentacji, incydentów, ciągłości działania, dostawców ICT, audytów oraz działań korygujących.
Pierwszym krokiem powinna być analiza, czy organizacja spełnia przesłanki uznania za podmiot kluczowy albo podmiot ważny.
Obowiązki mogą dotyczyć między innymi organizacji z obszarów:
Sama działalność w danym sektorze nie oznacza automatycznie objęcia obowiązkami. Należy sprawdzić załącznik nr 1 albo załącznik nr 2 do ustawy, rodzaj podmiotu, wielkość organizacji, charakter świadczonej usługi albo realizowanego zadania oraz szczególne przesłanki wynikające z ustawy.
Ustawa KSC rozróżnia dwa podstawowe rodzaje podmiotów objętych obowiązkami:
Nie należy upraszczać tego w ten sposób, że załącznik nr 1 zawsze oznacza podmiot kluczowy, a załącznik nr 2 zawsze oznacza podmiot ważny. Kwalifikacja zależy od ustawy, załączników, wielkości podmiotu oraz szczególnych kategorii wskazanych w przepisach.
Podmiot wskazany w załączniku nr 1 może być:
Oznacza to, że załącznik nr 1 nie zawsze oznacza wyłącznie podmiot kluczowy.
Podmiot wskazany w załączniku nr 2 może być podmiotem ważnym, jeżeli spełnia albo przewyższa wymogi dla średniego przedsiębiorcy oraz nie jest podmiotem kluczowym.
Trzeba też uwzględnić kategorie, które ustawa uznaje za podmioty kluczowe niezależnie od wielkości. Dotyczy to między innymi dostawców usług DNS, kwalifikowanych dostawców usług zaufania, podmiotów krytycznych, określonych podmiotów publicznych z załącznika nr 1, rejestrów TLD oraz podmiotów świadczących usługi rejestracji nazw domen.
Jeżeli podmiot spełnia jednocześnie warunki dla podmiotu kluczowego i podmiotu ważnego, jest podmiotem kluczowym.
Odrębnie należy traktować przypadek uznania podmiotu decyzją organu właściwego do spraw cyberbezpieczeństwa. Jeżeli podmiot spełnia przesłanki ustawowe i prowadzi działalność określoną w załączniku nr 1, może zostać uznany za podmiot kluczowy. Jeżeli prowadzi działalność określoną w załączniku nr 2, może zostać uznany za podmiot ważny.
Przed rozpoczęciem wdrożenia warto przygotować analizę kwalifikacyjną KSC/NIS2. To dokument, który pokazuje, czy organizacja podlega pod przepisy i jakie obowiązki mogą ją dotyczyć.
Analiza powinna odpowiedzieć na pytania:
Efektem analizy powinna być jednoznaczna konkluzja:
Jeżeli organizacja spełnia przesłanki uznania za podmiot kluczowy albo ważny, składa wniosek o wpis do wykazu.
Termin wynosi 6 miesięcy od dnia spełnienia przesłanek. Ustawa przewiduje również możliwość wpisania podmiotu do wykazu z urzędu, jeżeli spełnia przesłanki i nie złożył wniosku w terminie.
Do wpisu mogą być potrzebne między innymi:
Wpis, zmiana wpisu i wykreślenie wpisu z wykazu mają charakter deklaratoryjny. Oznacza to, że obowiązki wynikają z faktu spełnienia przesłanek, a nie dopiero z samego wpisania do wykazu.
Najważniejszym obowiązkiem jest wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji, czyli SZBI.
SZBI powinien obejmować systemy informacyjne wykorzystywane w procesach wpływających na świadczenie usług albo realizację zadań organizacji. Ustawa wskazuje na obowiązek prowadzenia systematycznego szacowania ryzyka oraz wdrożenia odpowiednich i proporcjonalnych środków technicznych i organizacyjnych.
W praktyce SZBI powinien uwzględniać:
SZBI powinien być dostosowany do organizacji, zakresu jej działania, wykorzystywanych systemów, ryzyk oraz wymagań sektorowych.
Podmioty publiczne wymagają odrębnej analizy. Ustawa inaczej traktuje podmioty publiczne wskazane w załączniku nr 1 i inaczej podmioty publiczne wskazane w załączniku nr 2.
W sektorze podmiotów publicznych podmiotem kluczowym może być między innymi podmiot publiczny wskazany w załączniku nr 1 do ustawy.
Podmiotem ważnym może być natomiast podmiot publiczny, który nie jest podmiotem kluczowym, a jest samorządową jednostką budżetową, samorządowym zakładem budżetowym, samorządową instytucją kultury albo spółką wykonującą zadania o charakterze użyteczności publicznej, jeżeli realizuje zadanie publiczne z wykorzystaniem systemów informacyjnych.
Podmiot ważny będący podmiotem publicznym oraz wybrane podmioty z systemu szkolnictwa wyższego i nauki, w zakresie wskazanym w ustawie, nie stosują standardowego art. 8 ust. 1 wprost. Opracowują, wdrażają, realizują, monitorują i utrzymują system zarządzania bezpieczeństwem informacji spełniający wymagania określone w załączniku nr 4 do ustawy.
Dla podmiotu ważnego będącego podmiotem publicznym ustawa przewiduje również odrębności w zakresie zgłaszania incydentów. Taki podmiot stosuje przepisy dotyczące incydentów z wyjątkiem przepisów o przekazywaniu wczesnego ostrzeżenia, sprawozdania okresowego, sprawozdania z postępu obsługi incydentu i sprawozdania końcowego.
Nie należy więc stosować jednego schematu dla wszystkich urzędów, jednostek organizacyjnych, instytucji kultury, zakładów budżetowych i spółek komunalnych.
Zarządzanie ryzykiem to jeden z głównych elementów KSC/NIS2.
Organizacja powinna regularnie identyfikować i oceniać ryzyka dotyczące usług, procesów, działalności lub zadań realizowanych z wykorzystaniem systemów informacyjnych.
W zależności od rodzaju podmiotu analiza ryzyka może obejmować między innymi:
Analiza ryzyka powinna prowadzić do decyzji dotyczących sposobu postępowania z ryzykiem, priorytetów wdrożeniowych, odpowiedzialności, terminów oraz wymaganych środków technicznych i organizacyjnych.
Organizacja powinna posiadać dokumentację dotyczącą bezpieczeństwa systemu informacyjnego.
W praktyce warto rozróżnić dwa poziomy dokumentacji:
Dokumentacja normatywna – określa zasady, wymagania i sposób postępowania. Obejmuje m.in. polityki, procedury, instrukcje, plany, metodyki i regulaminy.
Dokumentacja operacyjna – obejmuje zapisy potwierdzające wykonywanie czynności, w tym rejestry, raporty, protokoły, wyniki testów, potwierdzenia, logi i zapisy systemowe.
Przykłady:
Ustawa wskazuje, że dokumentacja normatywna może obejmować m.in. dokumentację SZBI, ochrony infrastruktury, systemu zarządzania ciągłością działania, techniczną systemu informacyjnego oraz dokumentację wynikającą ze specyfiki świadczonej usługi. Dokumentacja operacyjna obejmuje zapisy poświadczające wykonywanie czynności wymaganych przez dokumentację normatywną.
Dokumentację należy nadzorować, chronić przed nieuprawnionym dostępem, wersjonować oraz przechowywać zgodnie z wymaganiami ustawy i przepisami archiwalnymi, jeżeli mają zastosowanie.
Zakres dokumentacji powinien wynikać ze statusu podmiotu, rodzaju świadczonych usług lub realizowanych zadań, wykorzystywanych systemów informacyjnych, zakresu SZBI, wyników szacowania ryzyka, wymagań sektorowych oraz przyjętego modelu realizacji obowiązków.
Poniższy wykaz ma charakter przykładowy i pomocniczy. Nie stanowi katalogu zamkniętego dokumentów wymaganych w każdym przypadku.
Przykładowa dokumentacja może obejmować:
W konkretnym podmiocie dokumentacja może być szersza, węższa albo inaczej nazwana, jeżeli odpowiada wymaganiom ustawy, rzeczywistemu zakresowi działania organizacji i wynikom szacowania ryzyka.
Organizacja objęta obowiązkami KSC/NIS2 powinna posiadać proces obsługi incydentów obejmujący:
W przypadku incydentu poważnego podmiot kluczowy albo ważny co do zasady:
Dostawca usług zaufania ma szczególny obowiązek zgłoszenia incydentu poważnego niezwłocznie, nie później niż w ciągu 24 godzin od momentu jego wykrycia.
Podmiot kluczowy albo ważny powinien wyznaczyć osoby odpowiedzialne za kontakt z podmiotami krajowego systemu cyberbezpieczeństwa.
Standardowo są to co najmniej dwie osoby. Dla wybranych mikro- i małych przedsiębiorców oraz dla podmiotu ważnego będącego podmiotem publicznym ustawa przewiduje co najmniej jedną osobę.
Kierownik podmiotu kluczowego albo ważnego ponosi odpowiedzialność za wykonywanie obowiązków w zakresie cyberbezpieczeństwa. Odpowiedzialność ta pozostaje również wtedy, gdy część albo całość obowiązków powierzono innej osobie.
Kierownictwo powinno zapewnić:
Kierownik podmiotu oraz osoba, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa, powinni raz w roku przejść szkolenie z obowiązków wynikających z ustawy. Udział w szkoleniu powinien być udokumentowany.
Osoba realizująca zadania dotyczące SZBI albo obsługi incydentów powinna przed rozpoczęciem tych zadań przedstawić informację z Krajowego Rejestru Karnego potwierdzającą niekaralność za przestępstwa przeciwko ochronie informacji.
Wymóg ten można spełnić również przez posiadanie ważnego poświadczenia bezpieczeństwa upoważniającego do dostępu do informacji niejawnych o klauzuli „poufne” lub wyższej.
Podmiot kluczowy albo ważny powinien powołać wewnętrzne struktury odpowiedzialne za cyberbezpieczeństwo albo zawrzeć umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa.
Możliwe są trzy modele:
Model wewnętrzny – organizacja realizuje obowiązki własnymi zasobami.
Model zewnętrzny – organizacja powierza określone zadania dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa.
Model mieszany – część zadań realizuje organizacja, a część dostawca zewnętrzny, pełnomocnik, konsultant, SOC, audytor albo inny wyspecjalizowany podmiot.
Najważniejsze jest jasne przypisanie odpowiedzialności: kto prowadzi analizę ryzyka, kto utrzymuje dokumentację, kto obsługuje incydenty, kto kontaktuje się z CSIRT, kto raportuje kierownictwu, kto nadzoruje dostawców i kto przygotowuje organizację do audytu.
Bezpieczeństwo dostawców jest istotnym elementem KSC/NIS2.
Organizacja powinna wiedzieć:
Minimalne działania wobec dostawców ICT obejmują:
Ustawa KSC wskazuje, że przy środkach dotyczących bezpieczeństwa i ciągłości łańcucha dostaw należy uwzględniać m.in. podatności związane z dostawcą sprzętu lub oprogramowania oraz ogólną jakość produktów ICT, usług ICT i procesów ICT pochodzących od dostawcy.
KSC/NIS2 wymaga przygotowania organizacji na zakłócenia, awarie i incydenty wpływające na usługi.
Organizacja powinna określić:
W tym obszarze dobrym punktem odniesienia jest ISO 22301, ponieważ porządkuje analizę wpływu na działalność, plany ciągłości, plany odtworzenia, testy i ćwiczenia.
Podmiot kluczowy przeprowadza audyt bezpieczeństwa systemu informacyjnego wykorzystywanego w procesie świadczenia usługi co najmniej raz na 3 lata.
Pierwszy audyt podmiot kluczowy powinien zapewnić w terminie 24 miesięcy od dnia spełnienia przesłanek uznania za podmiot kluczowy.
Jeżeli podmiot został uznany za kluczowy decyzją organu, termin należy liczyć od dnia doręczenia tej decyzji.
Organ właściwy może również nakazać przeprowadzenie zewnętrznego audytu:
Audytu nie może przeprowadzić osoba, która realizuje w audytowanym podmiocie zadania z zakresu SZBI, obowiązków informacyjnych, obsługi incydentów albo zgłoszeń, ani osoba, która wykonywała takie zadania w ciągu roku przed rozpoczęciem audytu.
Najważniejsze terminy organizacyjne:
Jeżeli podmiot został uznany za kluczowy albo ważny decyzją organu, terminy 12 miesięcy na realizację obowiązków i 24 miesięcy na pierwszy audyt należy liczyć od dnia doręczenia decyzji.
ISO/IEC 27001, ISO 22301 i wytyczne ENISA mogą być wykorzystane jako praktyczne punkty odniesienia przy wdrażaniu KSC/NIS2. Nie zastępują jednak analizy wymagań ustawowych i nie zwalniają automatycznie z obowiązków wynikających z ustawy.
ISO/IEC 27001 wspiera wdrożenie SZBI, analizę ryzyka, dokumentację, audyty, przeglądy zarządzania i działania korygujące.
ISO 22301 wspiera ciągłość działania, analizę wpływu na działalność, plany ciągłości, plany odtworzenia, testy i ćwiczenia.
ENISA może być wykorzystywana jako źródło rekomendacji i dobrych praktyk. Ustawa KSC przewiduje możliwość uwzględniania rekomendacji ENISA przy określaniu szczegółowych wymagań dla SZBI.
Praktyczne wdrożenie można podzielić na następujące kroki:
Najczęstsze błędy przy przygotowaniu do KSC/NIS2 to:
KSC i NIS2 wymagają od organizacji uporządkowanego, udokumentowanego i nadzorowanego systemu cyberbezpieczeństwa. Zakres działań zależy od statusu podmiotu, sektora, rodzaju świadczonych usług lub realizowanych zadań, wykorzystywanych systemów informacyjnych, wyników szacowania ryzyka oraz wymagań sektorowych. Najważniejsze jest prawidłowe przeprowadzenie analizy kwalifikacyjnej. Dopiero potem można poprawnie określić zakres SZBI, dokumentacji, obsługi incydentów, audytu, ciągłości działania i nadzoru nad dostawcami.
Przygotowujemy analizę kwalifikacyjną KSC/NIS2, ocenę luk, plan wdrożenia, dokumentację SZBI, dokumentację ciągłości działania, procedury incydentowe, rejestry, klauzule cyberbezpieczeństwa dla dostawców ICT oraz przygotowanie do audytu bezpieczeństwa.
Jesteś zainteresowany?
Skontaktuj się z nami.
Zapewnimy kompleksowe wsparcie w zakresie pozyskania dotacji z Funduszy Europejskich.
Oferujemy przygotowanie wniosku, audyty technologiczne, opracowanie mapy drogowej inwestycji, pomoc we wdrożeniu zgodnie z wymaganiami UE oraz rozliczenia projektu.
Administratorem Państwa danych osobowych jest DM TEAM sp. z o.o. ul. Karola Olszewskiego 6, 25-663 Kielce. Państwa dane osobowe podane w formularzu przetwarzane będą: w celu udzielenia odpowiedzi na zapytanie złożone w formularzu, na podstawie naszego prawie uzasadnionego interesu, jakim jest kontakt między nami a Państwem, służący udzieleniu Państwu odpowiedzi na zadane pytania, przesłaniu żądanej informacji – w ramach tego konkretnego zapytania (na podstawie art. 6 ust. 1 lit. f RODO), przez okres uzasadniony obsługą zapytania oraz w celach marketingowych – jeżeli wyrazili na to Państwo zgodę, wskazanym przez Państwa kanałem komunikacji (na podstawie art. 6 ust. 1 lit. a RODO), do momentu wycofania przez Państwa zgody na przetwarzanie lub utraty użyteczności danych. Przysługuje Państwu prawo do: dostępu do danych, ich sprostowania, usunięcia, ograniczenia przetwarzania, przeniesienia danych, wniesienia sprzeciwu na przetwarzanie oraz wniesienia skargi do organu nadzorczego. Pełna informacja o przetwarzaniu danych osobowych znajduje się na naszej stronie internetowej w Polityce Prywatności.
