Jakie zmiany wprowadzi nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa?

24 maja br. zakończyły się konsultacje społeczne do projektu ustawy o nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa (uKSC), wprowadzającej do polskiego ustawodawstwa dyrektywę NIS2. Z Łukaszem Wojewodą, dyrektorem Departamentu Cyberbezpieczeństwa w Ministerstwie Cyfryzacji rozmawiamy o procedowanym projekcie ustawy, różnicach względem poprzednich wersji ustawy, powodach ograniczenia projektu legislacji do zapisów związanych stricte z implementacją NIS2 oraz o realnych terminach, kiedy ustawa może zacząć działać.

Prace nad projektem nowelizacji ustawy o KSC wróciły w 2024 roku na tzw. szybką ścieżkę. Trudno się dziwić, ponieważ czasu do 17 października zostało niewiele. Czym się różni obecny projekt – czy te różnice sprawiają, że ma większe szanse na przyjęcie?

Porównując poprzednie projekty i obecny, doliczyliśmy się 17 lub 18 wersji noweli ustawy od tej, która obowiązuje w tej chwili.

…17 przeprowadzonych bez sukcesu.

Jednym z powodów, dla których nie udało się zamknąć procesu legislacyjnego, było to, że projekty były bardzo obszerne, również tematycznie.
Ustanowiliśmy Krajowy System Cyberbezpieczeństwa w 2018 roku, natomiast projekty nowelizacji posiadały komponenty, które oddziaływały z systemem, ale niekoniecznie były jego podstawową częścią. Dopóki dysponowaliśmy czasem – jak podczas poprzedniej próby nowelizacji, wydawało się to ambitnym, ale właściwym i realnym scenariuszem. Zaplanowaliśmy wówczas cały szereg zmian prawnych. Miały one najpierw nowelizować KSC, częściowo uwzględniając już postulaty NIS2. A następnie uzupełnić ją o pozostałe elementy zawarte w dyrektywie. Była to strategia wielu kroków.

Przygotowując na zlecenie Ministerstwa Cyfryzacji kolejny projekt wiedzieliśmy już, że tego czasu nie ma. Dlatego zaproponowaliśmy kierownictwu, aby podzielić całą regulację na dedykowane akty prawne. Udany precedens stanowi chociażby ustawa o szczególnych zasadach wynagradzania osób realizujących zadania z zakresu cyberbezpieczeństwa. Wówczas to działanie było niezbędne do tego, aby zatrzymać specjalistów z zakresu cyberbezpieczeństwa w administracji publicznej, szczególnie w wysokopoziomowych instytucjach bardzo ważnych z punktu widzenia bezpieczeństwa państwa. Interwencja w postaci ustawy dedykowanej konkretnemu celowi została przeprowadzona z sukcesem. Wyciągając wnioski z tego doświadczenia zaproponowaliśmy, aby w kolejnej wersji noweli ustawy skupić się nad tym, co nas czeka tu i teraz.

Dlatego aktualna nowelizacja obejmuje implementację wymagań dyrektywy NIS2 i to, co jest z nią blisko związane. Oceniliśmy, że procedura wyłonienia dostawców wysokiego ryzyka to element, który powinien być częścią ustawy. Natomiast certyfikacja – był jej poświęcony rozdział wcześniejszej noweli – jest elementem, który wynika z Cyber Security Act uznaliśmy więc, że ten zakres równie dobrze mógłby zostać ujęty w odrębnej regulacji, która będzie szła swoim torem. Miałaby ona powiązanie z Krajowym Systemem Cyberbezpieczeństwa, ale pierwszym krokiem jest sam system certyfikacji, a dopiero w kolejnym kroku pomyślimy, jak obligatoryjne musiałoby być jego działanie.

Mamy zatem nowelizację KSC, w której jest implementacja NIS2 i procedura dotycząca dostawców wysokiego ryzyka, natomiast równolegle, przygotowany jest projekt ustawy o certyfikacji. Cały rozdział, który był w poprzedniej wersji noweli ustawy obecnie się usamodzielnia. Nawiązując do naszej rozmowy sprzed ponad roku: nadal jest to strategia kroków legislacyjnych, ale pierwszy krok jest bardzo duży i zawiera całość implementacji NIS2.

A inne elementy, które zawierał poprzedni projekt? Na przykład kwestia SOC – Security Operations Centers?

Z niektórych rozwiązań starego projektu ustawy zrezygnowaliśmy, ponieważ NIS2 już w swoim zakresie nam to poukładał. SOC-i wewnętrzne i zewnętrzne są takim przykładem. Podmioty, które wykonują takie zadania, po prostu będą pod parasolem dyrektywy.

Pozostały natomiast w nowelizacji CSIRT-y (Computer Security Incident Response Team) sektorowe oraz krajowe. Jeśli zachodzi potrzeba współpracy, konsolidacji, to regulacja zawiera możliwość spełnienia funkcji sektorowych na poziomie CSiRT krajowego. Inne elementy, takie jak polecenie zabezpieczające, zawarte w poprzedniej noweli, są także i w obecnym projekcie.

Czy w tej ostatniej kwestii spodziewa się Pan protestów, tak miało miejsce przy okazji poprzedniego projektu?

Wydaje mi się, że udało się wreszcie uwolnić z pola narracyjnego, w którym polecenie zabezpieczające funkcjonowało jako narzędzie do cenzurowania. Taki pomysł nie przyświecał nigdy autorom – byliśmy zdziwieni, że ktoś taką narrację wysnuł.

Nasze założenie, niezmiennie, jest bardzo proste. W przypadku wystąpienia incydentu krytycznego, minister w drodze decyzji może po prostu wydać, w określony sposób, polecenie zabezpieczające. Pamiętajmy, jest to decyzja w znaczeniu administracyjnym, czyli podlega określonemu procesowi. Jednocześnie, samo w sobie uznanie incydentu za krytyczny jest rzadką sytuacją.

Ile było dotąd incydentów uznanych za krytyczne na tym szczeblu?

Naprawdę niewiele. Musimy mieć świadomość, o jakiej wadze incydentu mówimy. Czy będzie ich przybywać, czas pokaże. Natomiast warto powtarzać stale, że to nie działa na zasadzie automatu, gdzie po zajściu poważnego – krytycznego zdarzenia w firmie minister cyfryzacji znienacka wydaje nakaz: wyłączajcie wszystko. Ciężko byłoby zresztą osobie logicznie myślącej dojść do takich wniosków po lekturze projektu regulacji w tym zakresie.

Za to centra wymiany i analizy informacji (Information Sharing and Analysis Centre, ISAC) nie znalazły swojego miejsca w noweli.

To prawda. Jest ku temu jednak kilka powodów.

Skupiliśmy się na implementacji dyrektywy NIS2 oraz tych elementów, które uznaliśmy za niezbędne do prawidłowego funkcjonowania Krajowego Systemu Cyberbezpieczeństwa. ISAC-i (Information Sharing and Analysis Center) i tak z założenia funkcjonują na zasadzie dobrowolności. Stwierdziliśmy więc, że nic nie stoi na przeszkodzie, aby były budowane już teraz. Nie ma potrzeby wprowadzać w tym zakresie regulacji.

Oczywiście, jeśli taka sugestia pojawi się w toku konsultacji, gruntownie ją rozważymy. Przykładowo, skonsultujemy się wówczas z gronem ekspertów, którzy zajmują się cyberbezpieczeństwem poziomu krajowego. Mamy także możliwość zasięgnięcia opinii u partnerów programu PWCyber.

Jeśli poszczególne podmioty będą skłonne wymieniać się pewnymi informacjami, to i tak muszą uwzględnić inne regulacje, określające jakimi informacjami i pod jakimi warunkami mogą się takimi informacjami dzielić. Wpisanie w ustawie, że ustanawiamy ISAC-i i od dziś można się dobrowolnie wymieniać informacjami o cyber nic nie zmieni – wszystko będzie i tak zależało od dobrej woli firm i zgodności z wewnętrznymi przepisami o tajemnicy przedsiębiorstwa czy regulacjami odnośnie ochrony danych osobowych.

Pozostaje za to w projekcie mechanizm przeniesiony z Toolbox 5G, czyli procedura definiowania dostawcy wysokiego ryzyka…

Tu się niewiele zmieniło wobec poprzedniej wersji projektu. Mechanizm jest podstawową częścią ustawy, czyli znowu proponujemy rozwiązanie, które było w poprzednich wersjach regulacji.

W naszym projekcie mikroprzedsiębiorcy, o obrotach poniżej 10 mln zł rocznie, nie podlegaliby konieczności wdrażania postanowień o uznaniu technologii określonego dostawcy za wysoce ryzykowną. Jest to poniekąd odpowiedź na prośby rynku. Pojawiały się bowiem głosy mówiące, aby od takich firm nie wymagać dostosowań ponad ich siły.

Oczywiście otwarta jest dyskusja do jak szerokiego grona mechanizm ten powinien mieć zastosowanie: może dopiero od poziomu średnich przedsiębiorców? Albo przeciwnie – może warto zrównać wszystkich w tym obowiązku, ponieważ mikroprzedsiębiorca, który działa w lokalnej społeczności, może działać na sprzęcie zakazanym w sieci wielkiego operatora. Rodzi to pewien paradoks z punktu widzenia użytkownika. Będzie on zabezpieczony w sieci dużego operatora, np. pozostając w aglomeracji, ale kiedy wyjedzie za miasto np. na działkę, znajdzie się w sieci, w której może funkcjonować technologia dostawcy wysokiego ryzyka, ponieważ siecią tą zarządza mały operator nie objęty reżimem ustawy.

Trudno więc o złoty środek, ale poszukujemy go kierując się przede wszystkim obowiązkiem zapewnienia bezpieczeństwa powszechnego. Oczywiście jesteśmy przy tym otwarci na dyskusję.

Może te sprawy same poukładają się tam, gdzie mali operatorzy są poddostawcami wielkich? Bezpieczeństwo w łańcuchu dostaw jest także składową regulacji…

Analiza łańcucha dostaw to osobny, choć powiązany mechanizm. W naszych intencjach leżało, aby wszystkie aspekty dyrektywy były wypełnione. Jeśli doszłoby do uruchomienia tej procedury, to wskazane jest wziąć pod uwagę zarówno aspekty techniczne, jak i nietechniczne. Takie podejście odwzorujemy w procedurze.
Jednocześnie, nie jest prawdą pojawiające się niekiedy w dyskursie publicznym stwierdzenie, że procedurze dostawcy wysokiego ryzyka nie można poddać producenta z kraju należącego do NATO lub Unii Europejskiej. W tym kontekście nie badamy po prostu niektórych czynników, ponieważ obecność w Unii Europejskiej czy w Sojuszu Północnoatlantyckim pewne rzeczy samoistnie wyjaśnia.

Naszym celem było ustanowienie procedury, która przyniesie możliwość działania w każdej sytuacji, która może zaistnieć. Natomiast – podobnie jak procedura polecenia zabezpieczającego – tak i procedura określenia dostawcy wysokiego ryzyka wymaga wielu elementów do wywołania.

Czy dobrze rozumiem, że istnieją co najmniej dwie ścieżki uruchomienia tej procedury? Z urzędu i niejako – z rynku, obywatelska – po zawiadomieniu, zgłoszeniu wniosku?

Procedura jest uruchamiana z urzędu przez ministra, ale oczywiście musi ona mieć jakieś podstawy. Minister może uruchomić procedurę, jeśli otrzyma informacje, które zawierają podstawy do jej wszczęcia.

Czy w zakresie zgłaszania takich informacji regulator spodziewa się większej aktywności podmiotów rynkowych, może obywateli czy raczej uprawnionych instytucji?

Informacje spływają do ministra rożnymi kanałami. Procedura jest uruchamiana z urzędu w chwili, kiedy organ posiądzie taką wiedzę. Prowadzi ją minister właściwy do spraw informatyzacji, kolejnym organem dysponującym możliwościami wnioskowania o wszczęcie procedury jest przewodniczący kolegium ds. cyberbezpieczeństwa, czyli Premier. Przewodniczący kolegium także ma swoje źródła informacji – zatem, jak widać, jest to podejście wielowątkowe.

Wiemy też jak w praktyce ta współpraca publiczno-prywatna wygląda. Wymiana informacji dokonuje się nieustannie poprzez różne gremia centralne, ale nie tylko. Mamy od 5 lat Program Współpracy w Cyberbezpieczeństwie – PWCyber. Jest to forum, na którym rozmawiamy, nierzadko w sposób wybijający z utartych schematów myślenia. Jako przykład podam dyskusję na panelu podczas ostatniego kongresu EKG w ramach pięciolecia Programu.

Rozmawialiśmy tam o bezpieczeństwie łańcucha dostaw i oprócz przedstawicieli dostawców technologii z wielu branży, w dyskusji uczestniczyli też integratorzy, którzy te technologie muszą wdrażać w konkretnych organizacjach. Ich spojrzenie na to, jakie są potrzeby badania bezpieczeństwa łańcucha dostaw, głębokości tej analizy, celowości certyfikacji są inne niż dostawców technologii. Pozytywnie oceniam więc fakt, że się przestrzeń do otwartej dyskusji i klarownego wskazywania różnic.

Wracając do procedury: urząd poinformowany o zdarzeniu powinien co najmniej zweryfikować, czy informacja ta jest prawdziwa. Jeżeli jest prawdziwa, winien ustalić czy podjęto już działania i sprawdzić, czy przesłanki wszczęcia procedury są wystarczające. Zawsze też można uruchomić procedurę i w jej toku wykazać, że nie ma przesłanek do uznania dostawcy za niebezpiecznego. Wszczęcie procedury nie przesądza o finale sprawy.

Nawiasem mówiąc, to podejście zdecydowanie mniej rygorystyczne niż funkcjonujące w wielu innych krajach europejskich. O ile u nas z definicji dopuszczeni są wszyscy dostawcy, to w niektórych krajach funkcjonuje tylko zamknięta i ograniczona lista dostawców zaakceptowanych do dostarczania technologii dla podmiotów z administracji. Dostać się na taka listę jest trudno.

Wracając do sprawy Operatora Strategicznej Sieci Bezpieczeństwa (OSSB). To kolejny element wyjęty do osobnej regulacji.

Przepisy dotyczące OSSB były tą częścią poprzedniej wersji ustawy, nad którą w ostatnim roku spędziliśmy najwięcej czasu, jeszcze zanim trafiła ona na poziom rządowy. Mając w pamięci różne potrzeby, interpretacje i oczekiwania podmiotów publicznych i komercyjnych w tej kwestii uznaliśmy, że ciężko było pogodzić każdego z interesariuszy.

W ramach dzielenia regulacji na elementy podstawowe dla implementacji NIS2 i dodatkowe zarekomendowaliśmy zatem, aby kwestia Operatora Strategicznej Sieci Bezpieczeństwa był prowadzony w ramach odrębnej regulacji. Nie jest więc tak, że skreślimy te przepisy i nigdy ich nie będzie. Zaproponowaliśmy jednak, że – jeśli mają znaleźć swoją kontynuację – to tak, jak z ustawą o certyfikacji, niech dokona się to na drodze odrębnej ustawy.

Propozycja przepisów wprowadzających System Bezpiecznej Łączności Państwowej znalazła się natomiast w projekcie ustawy o ochronie ludności i obronie cywilnej (UD70), przedstawionej przez Ministra Spraw Wewnętrznych i Administracji.

Czy tutaj nie ma żadnej presji związanej z terminem określonym prawnie? Inaczej niż w przypadku certyfikacji, która jak wiadomo jest już zapisem „z prolongatą” wdrożenia?

Nie, nie ma presji wynikającej z innej regulacji, ale jest potrzeba uregulowania tego zagadnienia. Otwartą kwestią pozostaje w jakiej formule. W odrębnej regulacji czy w szerszej ustawie, całościowo podchodzącej do zagadnienia budowania łączności komunikacji na poziomie nie tylko rządowym, ale w ogóle administracji publicznej, i to nie tylko sieciach mobilnych.

Jest to zresztą bardzo szeroki temat, który oczywiście wpływa na cyberbezpieczeństwo, ale w naszym rozumieniu nie jest jego podstawowym elementem. Idąc dawnym torem myślenia, równie dobrze moglibyśmy powiedzieć, że projekt ustawy Prawo komunikacji elektronicznej, która przeszła poziom konsultacji rządowych i przekazana jest do Parlamentu, także niesie skutki prawne dla cyberbezpieczeństwa. Dlaczego więc i jej nie włączyć do nowelizacji uKSC?

Powstałaby zapewne ogromna całościowa, kompletna ustawa, ale nasze doświadczenie wskazuje, że niezwykle trudno takie dokumenty procedować i wdrażać. Zagadnienie Operatora Strategicznej Sieci Bezpieczeństwa jest wyzwaniem co do pogodzenia interesów i potrzeb oraz tego, co jest w praktyce możliwe do zrealizowania.

Czy problemem jest rozdział kompetencji poszczególnych resortów i ustalenie, które instytucje miałyby być obsługiwane przez takiego operatora?

Ostatnia wersja ustawy była też krytykowana w obszarze przepisów OSSB, ponieważ wiele ważnych służb oraz instytucji różnego typu były wyłączane poza zakres obsługi przez taki podmiot. Rodziło to pytanie: po co nam operator w takim niepełnym zakresie? To pytania, które rozpalają rozmowy pomiędzy resortami.
Ponownie, wychodząc od funkcji czasu, jako elementu, który jest niezbędny w procesie wdrożenia dyrektywy NIS2, oceniliśmy, że nawet jeśli uznalibyśmy, że ten element powinien znaleźć się w ustawie jako podstawowa część, to nie byłoby wówczas najmniejszych szans osiągnąć porozumienie.

Brak tego porozumienia uniemożliwiałby doprowadzenie do skutecznej implementacji dyrektywy. Zbyt wiele elementów wymaga wyjaśnienia i uzgodnienia. Niestety, oczekiwania interesariuszy są nazbyt zbieżne – wszystkie referują i dążą do objęcia np. tego samego obszaru, a to jest niemożliwe. Poszukiwanie kompromisu będzie więc zapewne wymagało czasu.

Temat z powrócił w projekcie ustawy o ochronie ludności, ale obecnie nie jest na tym etapie co np. zagadnienie certyfikacji, gdzie można było wyjąć rozdział z dawnego projektu, opatrzyć nagłówkiem i przetworzyć w projekt osobnej ustawy. O ile wiemy, że certyfikacja jest nam bardzo potrzebna, to OSSB jest przedsięwzięciem bardzo ważnym, ale w naszym rozumieniu wymaga także dodatkowej pracy koncepcyjnej nad tym, co chcemy przez wprowadzenie instytucji Operatora Strategicznej Sieci Bezpieczeństwa osiągnąć.

Jakie wnioski wynikają z przebiegu procesu konsultacji projektu ustawy?

Jest więcej głosów jest pozytywnych, oceniających, że obecne podejście zwiększa prawdopodobieństwo uchwalenia projektu i implementacji NIS2. Są oczywiście także głosy, które kwestionują na przykład potrzebę specyficznego podejścia krajowego do niektórych zagadnień. Przypomnę jednak, że NIS2 jest tylko dyrektywą, jesteśmy zobowiązani do minimalnej harmonizacji. Proszę nas nie winić za to, że zrobimy więcej.

W szczególności trochę więcej, niż wynika to z dyrektywy obowiązywać będzie nasze podmioty kluczowe. Mieliśmy do tego pełne prawo, ale przesłanką było zapewnienie skuteczności prawa przy funkcjonowaniu innych aktów prawnych albo aktów prawnych, które są projektowane.

Takie podejście ułatwi m.in. rozumienie przepisów oraz identyfikację podmiotów ważnych i kluczowych. W zasadzie obowiązki, którym podlegają podmioty kluczowe i ważne, są takie same. Obie te kategorie podmiotów różni tylko – i może „aż” – sposób kontroli oraz wysokość ewentualnych kar. Natomiast dostosowanie podmiotów musi być takie samo.

Jaki jest dalszy harmonogram prac nad wprowadzeniem NIS2 do polskiego systemu prawnego?

Naszym zamiarem jest przeprowadzenie implementacji jak najszybciej. Myślę jednak, że finał, w postaci podpisu Prezydenta RP przed 17 października jest dziś założeniem optymistycznym. Chcielibyśmy, aby do tego czasu nowelizacja przynajmniej opuściła poziom rządowy.

Zakładając realnie, 17 października możemy nie mieć jeszcze obowiązującej ustawy. Chcielibyśmy nie naruszyć kolejnego terminu – pół roku później – którym jest data dostarczenia do Komisji Europejskiej wykazu podmiotów kluczowych i ważnych. Ten termin także jest wyzwaniem, ale w pełni możemy mu sprostać, choć spodziewamy się samorejestracji około 40 tys. podmiotów. Wówczas połowa przyszłego roku, zgodnie z zapowiedzią wicepremiera Krzysztofa Gawkowskiego, będzie terminem, kiedy ustawa zacznie działać.