Ministerstwo Cyfryzacji proponuje zmiany w ustawie o cyberbezpieczeństwie

Ministerstwo Cyfryzacji chce, aby zespoły szukające luk i podatności w programach komputerowych nie były ograniczone umowami licencyjnymi.

Takie rozwiązania znalazły się w projekcie nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa (t.j. Dz.U. z 2022 r. poz. 1863 ze zm.; dalej: KSC). Badając produkty, usługi lub procesy ICT (tj. związane z technologiami informacyjno-telekomunikacyjnymi), trzy krajowe zespoły reagowania na incydenty bezpieczeństwa komputerowego (CSIRT) będą mogły posuwać się nawet do dekompilacji kodu (patrz: grafika).

Obecnie ustawa o KSC zezwala wprawdzie na badanie urządzeń i oprogramowania w celu identyfikacji podatności, lecz nie określa, jakie działania może to obejmować – nie ma np. mowy o dekompilacji ani o tym, że postanowienia umów licencyjnych uważa się w części za nieważne.

– Dotychczas nie było w polskim prawie takich rozwiązań. Przypuszczam, że projekt ich wprowadzenia może mieć związek z faktem, że od kilku lat zauważamy wzrost liczby ataków na dostawców i rozwiązania z obszaru cyberbezpieczeństwa. Próby destabilizacji działania firm zajmujących się bezpieczeństwem IT i kompromitowanie ich rozwiązań bezpieczeństwa stały się jednym z trendów wśród grup cyberprzestępczych – komentuje Paweł Śmigielski, country manager Stormshield w Polsce, francuskiej firmy tworzącej rozwiązania do ochrony sieci teleinformatycznych.

W uzasadnieniu projektu nie podano przyczyny zastosowania takich środków. Nie odniesiono się też do kwestii zgodności planowanego ograniczenia autorskich praw z regulacjami Unii Europejskiej. A budzi ona wątpliwości prawników.

Wyjątki wykładane wąsko

Chodzi przede wszystkim o dyrektywę 2009/24/WE w sprawie prawnej ochrony programów komputerowych (dalej: dyrektywa) i konwencję berneńską.

Agnieszka Wachowska, radczyni prawna, co-managing partner kancelarii Traple Konarski Podrecki i Wspólnicy, wskazuje, że ponieważ projektowane przepisy wprowadzają nowy wyjątek od prawa reprodukcji, nieujęty wprost w dyrektywie – to powinny być zgodne z art. 9 ust. 2 konwencji berneńskiej. Stanowi on, że państwa w szczególnych wypadkach mogą wprowadzać takie wyjątki – pod warunkiem że „reprodukcja ta nie wyrządzi szkody normalnemu korzystaniu z dzieła ani nie przyniesie nieuzasadnionego uszczerbku prawowitym interesom autora”.

– Tym samym każdy nowo wprowadzany wyjątek powinien być przemyślany i wykładany wąsko – wyjaśnia Agnieszka Wachowska.

Natomiast dr Zbigniew Okoń, partner w kancelarii Rymarz Zdort Maruta, wskazuje na motyw 19 dyrektywy. Stwierdza on, że w kwestii spraw nieobjętych dyrektywą nie narusza ona wyjątków przewidzianych w prawie krajowym – jeśli są zgodne z konwencją berneńską. Takim wyjątkiem może być dozwolony użytek programów komputerowych, np. na potrzeby badań naukowych czy bezpieczeństwa publicznego.

– Nie mam też wątpliwości co do zgodności projektowanego rozwiązania z konwencją berneńską – mówi Zbigniew Okoń.

Wycieknie, nie wycieknie?

Jak podkreśla Agnieszka Wachowska, projekt nie przewiduje środków zabezpieczających badane produkty i usługi ICT przed ewentualnym „wyciekiem” poza CSIRT. Kwestia udostępniania kodu źródłowego jest w branży bardzo drażliwa.

– Te przepisy nie dają żadnych podstaw do udostępniania przez CSIRT kodu innym podmiotom. Pozwalają tylko na zbadanie oprogramowania, a nie na jego komercyjne wykorzystanie. Przedstawianie projektowanej procedury jako zagrożenia dla interesów producentów oprogramowania to demagogia. Jeśli ktoś chce naruszać obowiązujące prawo i wykradać kod, zrobi to i bez nowelizacji KSC – uważa natomiast Zbigniew Okoń.

Paweł Śmigielski zaznacza zaś, że projekt pozostawia wiele niewiadomych, szczególnie w kwestii uprawnień producentów. – Nie wyobrażam sobie na przykład, żeby badanie oprogramowania odbywało się bez odpowiedniej umowy z gwarancjami bezpieczeństwa dla producentów. W przeciwnym wypadku mogłoby dochodzić do wycieków badanych rozwiązań – mówi.

Takiego zabezpieczenia projektodawca jednak nie przewidział. Zdaniem doktora Okonia nie tylko nie jest potrzebne, ale wręcz stworzyłoby ono problemy.

– Byłoby to czasochłonne i wymagało uprzedzenia przed badaniem przez CSIRT, co niekoniecznie leży w interesie państwa. A co, gdyby producent odmówił podpisania takiej umowy? – wylicza Zbigniew Okoń. – Cel tej regulacji jest na tyle uzasadniony, że nie ma o czym dyskutować, zwłaszcza w warunkach wojny hybrydowej z Rosją – podsumowuje.

Bez kontroli

Agnieszka Wachowska – która analizuje nowelę KSC jako ekspertka Polskiej Izby Informatyki i Telekomunikacji (PIIT) i we współpracy ze Związkiem Pracodawców Branży Internetowej IAB Polska – wskazuje na inne przyczyny niepokoju dostawców rozwiązań ICT.

– Projekt nie przewiduje żadnej kontroli nad tymi badaniami, czasem ich trwania i częstotliwością. Mogą się one odbywać bez wiedzy producenta. Nie określono, jak CSIRT ma wchodzić w posiadanie oprogramowania ani w jakim środowisku będzie się odbywało badanie, tj. czy w testowym środowisku CSIRT, czy w istniejącej infrastrukturze – wylicza prawniczka. – Rozumiem, że przeciwko uprzedzaniu producenta o badaniu mogą przemawiać względy bezpieczeństwa, ale przynajmniej po fakcie powinien być informowany o przeprowadzonym badaniu – dodaje.

W razie wykrycia podatności CSIRT może zwrócić się do pełnomocnika rządu ds. cyberbezpieczeństwa o wydanie rekomendacji dotyczących niekorzystania z określonego sprzętu lub oprogramowania. Takie rekomendacje będą zaś elementem analizy w razie wszczęcia wobec danej firmy postępowania o uznaniu za dostawcę wysokiego ryzyka (HRV).

Postępowanie to – jak pisaliśmy w DGP 8 maja – jest jednym z kluczowych rozwiązań projektu. Uznanie producenta, importera czy dystrybutora za HRV będzie oznaczało zakaz zaopatrywania się w tej firmie i konieczność usunięcia wcześniej kupionego od niej sprzętu lub oprogramowania. Dla zapewnienia bezpieczeństwa narodowego takie kroki będzie musiało podjąć ok. 35 tys. podmiotów z prawie 20 sektorów. ©℗