Oprogramowanie open source a proponowana ustawa o cyberodporności
Opracowane przez zespół NLnet Labs 14. listopada 2022.
Autor Maarten Aertsen
NLnet Labs uważnie śledzi wniosek legislacyjny Komisji Europejskiej dotyczący prawie całego sprzętu i oprogramowania na rynku europejskim. Cyber_Resilience_Act_(CRA) ma na celu zapewnienie cyberbezpieczeństwa produktów z elementami cyfrowymi poprzez określenie wymogów i obowiązków dla producentów.
'Commercial' + Critical = Compliance overload?
W tym poście podzielimy się naszym zrozumieniem przepisów i ich (niezamierzonymi) negatywnymi skutkami dla twórców oprogramowania open source. W tym momencie mamy pytania i wątpliwości, a nie odpowiedzi lub rozwiązania.
Uważamy, że obecna propozycja nie wykorzystuje dużej szansy. Na wysokim poziomie „podstawowe wymagania dotyczące bezpieczeństwa cybernetycznego” nie są nieuzasadnione, ale koszty ogólne związane ze zgodnością mogą wahać się od trudnych do niemożliwych dla małych lub pozbawionych gotówki programistów. Agencja ratingowa mogłaby zapewnić wsparcie programistom open source utrzymującym krytyczne fundamenty naszego społeczeństwa cyfrowego. Ale zamiast wprowadzać zachęty dla integratorów lub wsparcie finansowe za pośrednictwem agencji ratingowych, obecna propozycja przeciąży małych programistów pracą związaną z zapewnianiem zgodności.
Pod koniec artykułu dowiesz się wszystkiego o „działalności komercyjnej”, „produktach krytycznych” i obciążeniu zgodnością, jakie powoduje ta kombinacja.
Chcielibyśmy się mylić co do większości naszych analiz, więc jeśli uważasz, że sytuacja jest mniej ponura, niż ją przedstawiamy, porozmawiaj ze mną, abym mógł zaktualizować ten przegląd. Jeśli jednak podzielasz nasze obawy, oto co możesz zrobić:
Rozgłosić. Pomóż innym programistom. Porozmawiaj z ludźmi wokół ciebie, którzy mają umiejętności prawne i polityczne. Poinformuj ich, w jaki sposób propozycja agencji ratingowej wpływa na nich, ich organizację lub całe społeczeństwo. Przeczytaj propozycję. Ten post koncentruje się na określaniu zakresu na wysokim poziomie. Więcej, istnieje również propozycja KE dotycząca odpowiedzialności. Skontaktuj się i porozmawiaj z decydentami w Komisji, swoim rządzie lub ulubionym eurodeputowanym ITRE: sprawozdawcą jest Nicola Danti, a sprawozdawcami pomocniczymi są Henna Verkkunen, Eva Kaili, Ignazio Corrao i Evžen Tošenovský.
Jako społeczność technologiczna ponosimy wspólną odpowiedzialność za przyczynianie się do jakości kształtowania polityki, która ma wpływ na nas, a poprzez naszą pracę na całe społeczeństwo.
NLnet Labs to fundacja non-profit, której misją jest rozwój oprogramowania open source i otwartych standardów na rzecz Internetu, w szczególności w zakresie routingu DNS i BGP.
Nasze rozumienie ustawy
Po utworzeniu ram (dobrowolnej) certyfikacji w ramach unijnego Aktu o cyberbezpieczeństwie, a następnie uregulowaniu usług sieciowych i informacyjnych wykorzystywanych do świadczenia usług kluczowych dyrektywą NIS2, Komisja Europejska (KE) zamierza teraz ustanowić obowiązkowe wymagania dla produktów z elementami cyfrowymi w oparciu o istniejące ramy UE w zakresie przepisów dotyczących bezpieczeństwa produktów i odpowiedzialności. W niedalekiej przyszłości producenci tosterów, maszyn do lodów i oprogramowania (open source) będą mieli ze sobą coś wspólnego: aby udostępnić swoje produkty na rynku europejskim, będą musieli potwierdzić swoją zgodność z prawodawstwem UE dotyczącym produktów poprzez umieszczenie znaku CE cechowanie. Dla naszych odbiorców, w pozostałej części tego postu, gdy agencja ratingowa mówi o producentach, zamiast tego będziemy pisać o programistach (oprogramowania open source).
W niedalekiej przyszłości produkty fizyczne i oprogramowanie typu open source będą miały jeszcze jedną wspólną cechę: oznakowanie CE
Podstawowe wymagania dotyczące cyberbezpieczeństwa dla produktów z elementami cyfrowymi
Ustawa o odporności cybernetycznej zawiera zestaw podstawowych wymagań dotyczących bezpieczeństwa cybernetycznego i postępowania z lukami w zabezpieczeniach dla producentów (załącznik I). Będzie wymagać, aby produktom towarzyszyły informacje i instrukcje dla użytkownika (załącznik II). Producenci będą musieli przeprowadzić ocenę ryzyka i sporządzić dokumentację techniczną (załącznik V), aby wykazać, że spełniają zasadnicze wymagania.
Bądźmy szczerzy, sprzęt i oprogramowanie, na którym wszyscy polegamy, powinno być zaprojektowane z myślą o bezpieczeństwie, a nie dostarczane ze znanymi lukami, które można wykorzystać. Powinno też otrzymywać aktualizacje zabezpieczeń przez rozsądny czas. Chociaż język jest na bardzo wysokim poziomie, w stylu „musisz być taki wysoki, żeby jeździć” to jest ogólnie w porządku. Ale liczą się szczegóły.
Produkty, produkty krytyczne – i konsekwencje
Komisja wie, że w naszym społeczeństwie nie wszystkie produkty są tak samo uzależnione. W związku z tym agencja ratingowa rozróżnia produkty i produkty krytyczne „odzwierciedlające poziom ryzyka cybernetycznego związanego z tymi produktami”. Załącznik III zawiera dwie kategorie produktów krytycznych, odpowiednio w klasie I i II. Niektóre najważniejsze informacje z tych list:
Te listy krytycznych kategorii produktów nie są statyczne. Komisja może w przyszłości dodawać lub usuwać kategorie na podstawie ich poziomu ryzyka cybernetycznego. Ryzyko to określane jest przez następujące kryteria:
Artykuł 6 ust. 2
a) funkcjonalność produktu z elementami cyfrowymi związana z cyberbezpieczeństwem oraz czy produkt z elementami cyfrowymi ma co najmniej jedną z następujących cech:
(i) jest przeznaczony do uruchamiania z podwyższonymi uprawnieniami lub zarządzania uprawnieniami;
(ii) ma bezpośredni lub uprzywilejowany dostęp do sieci lub zasobów obliczeniowych;
(iii) jest przeznaczony do kontrolowania dostępu do danych lub technologii operacyjnej;
(iv) pełni funkcję krytyczną dla zaufania, w szczególności funkcje bezpieczeństwa, takie jak kontrola sieci, bezpieczeństwo punktów końcowych i ochrona sieci.
b) zamierzone użycie we wrażliwych środowiskach, w tym w warunkach przemysłowych lub przez kluczowe jednostki typu, o którym mowa w załączniku [załącznik I] do dyrektywy [dyrektywa XXX/XXXX (NIS2)];
c) zamierzone wykorzystanie do wykonywania funkcji krytycznych lub wrażliwych, takich jak przetwarzanie danych osobowych;
d) potencjalny zakres niekorzystnego wpływu, w szczególności pod względem jego intensywności i możliwości oddziaływania na wiele osób;
e) zakres, w jakim korzystanie z produktów z elementami cyfrowymi spowodowało już straty materialne lub niemajątkowe lub zakłócenia lub wzbudziło poważne obawy co do wystąpienia negatywnego wpływu.
Istnieją konsekwencje dla producentów produktów krytycznych. Aby je zrozumieć, musimy porozmawiać o stronie zgodności agencji ratingowych.
Wykazanie zgodności: jak wykazać, że wymagania zostały spełnione?
Deweloperzy muszą zadeklarować zgodność z wymaganiami określonymi w CRA, a tym samym przyjąć odpowiedzialność za zgodność. Być może widziałeś oświadczenie o zgodności, gdy kupowałeś pralkę lub inny produkt konsumencki w UE (jeśli nie, zobacz przykład w załączniku IV). Oprogramowanie pralki również wymaga oznaczenia CE na wspomnianej deklaracji lub na swojej stronie internetowej. Jak to działa?
Artykuł 6 ust. 4 Produkty krytyczne z elementami cyfrowymi podlegają procedurom oceny zgodności, o których mowa w art. 24 ust. 2 i 3.
Deweloper musi postępować zgodnie z jedną z trzech możliwych procedur oceny zgodności. Mogą albo:
1. Przeprowadzić samoocenę; lub (żargon: kontrola wewnętrzna, moduł A);
2. Ubiegać się o badanie produktu przez audytora, a następnie ustanowić mechanizmy kontroli i równowagi dla swoich procesów rozwojowych; lub (żargon: badanie typu UE przez jednostkę notyfikowaną, a następnie wewnętrzna kontrola produkcji, moduł B i C)
3. Wystąpić o ocenę ich systemu jakości przez audytora. (udokumentowane zasady, procedury i instrukcje) (żargon: pełne zapewnienie jakości, moduł H)
Te kolejne opcje pociągają za sobą coraz większą ilość pracy związanej ze zgodnością. Wariant 3 może być korzystniejszy dla producentów z dużą liczbą różnych produktów.
Wykazanie zgodności krytycznych produktów wiąże się z kosztami dla zewnętrznych audytorów
Ocena zgodności to miejsce, w którym ujawniają się konsekwencje rozróżnienia między produktami a produktami krytycznymi: twórcy produktów krytycznych mogą nie przeprowadzać samooceny i muszą angażować zewnętrznych audytorów. Dostępne są dla nich tylko opcje 2 i 3.
Po omówieniu niektórych zagadnień wstępnych przejdziemy teraz do implikacji dla twórców oprogramowania open-source.
Wpływ na twórców oprogramowania open source
Wszystkie kategorie produktów krytycznych obejmują szeroko stosowane implementacje w oprogramowaniu typu open source
Łatwo zauważyć, że istnieją projekty open source, które tworzą produkty w prawie wszystkich kategoriach produktów krytycznych (oprogramowania). Pomyśl o Keycloak, Wireguard, BIND, OpenSSH, FreeBSD, Boulder, OpenWRT, BIRD i FRR, aby wymienić tylko kilka z powyższego fragmentu listy.
I chociaż określone kategorie – a tym samym projekty, których to dotyczy – mogą pojawić się lub zniknąć w nadchodzących negocjacjach w sprawie wniosku, szeroki zasięg agencji ratingowej jest dość jasny.
Oprogramowanie NLnet Labs do routingu DNS i BGP jest używane przez operatorów sieci na całym świecie (w żargonie unijnym: przez kluczowe podmioty objęte NIS2 w sektorze infrastruktury cyfrowej). A na podstawie aktualnej listy w załączniku III jest całkiem prawdopodobne, że prawie całe oprogramowanie typu open source, które udostępniamy bezpłatnie, zostanie uznane za produkt krytyczny klasy I lub klasy II.
Ale czekaj, czy nie ma wyjątku dla open source?
Tak*, ale z bardzo dużą gwiazdką. Cytując punkt 10. preambuły agencji ratingowej:
Aby nie utrudniać innowacji ani badań, niniejsze rozporządzenie nie powinno obejmować bezpłatnego oprogramowania o otwartym kodzie źródłowym, opracowanego lub dostarczonego poza działalnością komercyjną. [..]
Najpierw przyznajmy i doceńmy, że Komisja Europejska w ogóle stworzyła wyjątek. Oznacza to, że możemy teraz spierać się o specyfikę wybranego wyjątku i jego implikacje, a nie o zalety otwartego oprogramowania.
Co to jest działalność komercyjna?
CRA nie definiuje tego terminu. Jednak rozmowy z osobami bardziej zaznajomionymi z prawodawstwem dotyczącym produktów nakierowały mnie na przewodnik EU_Blue_Guide dotyczący wdrażania unijnych przepisów dotyczących produktów:
Przez działalność handlową rozumie się dostarczanie towarów w kontekście biznesowym. Organizacje non-profit można uznać za prowadzące działalność komercyjną, jeżeli działają w takim kontekście. Można to ocenić jedynie w indywidualnych przypadkach, biorąc pod uwagę regularność dostaw, cechy produktu, intencje dostawcy itp. W zasadzie okazjonalne dostawy dokonywane przez organizacje charytatywne lub hobbystów nie powinny być uznawane za mające miejsce w kontekście biznesowym.
Oprogramowanie typu open source jest dostarczane zarówno w kontekście biznesowym, jak i poza nim. A wyjątek „okazjonalne dostawy” w tym cytacie wydaje się mieć ograniczone zastosowanie w przypadku projektów, od których społeczeństwo jest uzależnione. Czy uważasz system operacyjny typu open source (MINIX), który jest dostępny bezpłatnie od 35 lat, za „okazjonalną dostawę”? Co oznacza jego integracja ze wszystkimi procesorami Intela od 2015 roku, jeśli chodzi o bycie „towarem” poza „kontekstem biznesowym”? Co powiecie na projekt BIND, który od 40 lat stanowi podstawowy element infrastruktury internetowej typu open source?
Rozróżnienie między rozwojem open source bez dochodów, pewnymi dochodami i pełnymi dochodami?
Czy po przeczytaniu tego możesz teraz ocenić, czy oprogramowanie open source, na którym polegasz, jest rozwijane w ramach działalności komercyjnej? Zdecydowanie czujemy się niewykwalifikowani, aby dokonać takiego rozróżnienia. Jednak bardzo ważne jest, aby zrozumieć, czy agencja ratingowa ma zastosowanie do twojego projektu. Oprócz niepewności dla deweloperów może istnieć niepewność prawna co do granic pojęcia „działalność komercyjna” w kontekście dostarczania oprogramowania typu open source. Nierozsądne jest oczekiwanie, że ruch open source przejdzie przez sądy, aby stworzyć precedensy prawne niezbędne do wyjaśnienia tej sprawy.
Pobieranie opłat za wsparcie sprawia, że open source staje się działalnością komercyjną.
Istnieje duża podaż nieobsługiwanego i niedostatecznie obsługiwanego oprogramowania. Dotyczy to również oprogramowania open source, w tym projektów, na których wiele polega (popularny przykład: OpenSSL w 2014 r.). Im szersze oprogramowanie jest zależne, tym wyższe wymagania i oczekiwania stawiane są jego twórcom. Wychodząc naprzeciw oczekiwaniom, programiści nierzadko szukają możliwości pracy nad takimi projektami w pełnym wymiarze godzin. Czy zatem niepewność związana z „działalnością komercyjną” w agencjach ratingowych powinna zniechęcać wolontariuszy do zarabiania na życie i pracy nad oprogramowaniem typu open source w pełnym wymiarze godzin? Uważamy, że w najlepszym interesie społeczeństwa byłoby, gdyby pracowali nad swoim kodem.
Jednym z powszechnych sposobów uzyskiwania przez programistów open source niezbędnych do tego dochodów jest przyjmowanie pracy w organizacji korzystającej z ich oprogramowania, praca jako wolny strzelec nad płatnymi funkcjami lub sprzedawanie czasu spędzonego na zapewnianiu wsparcia.
NLnet Labs ma szczęście być stabilnym finansowo dzięki darowiznom i płatnemu wsparciu organizacji, które cenią sobie ciągłą stabilność opracowywanego przez nas oprogramowania typu open source i na którym polegają. Niestety, nasza sytuacja finansowa nie odzwierciedla szerszej społeczności open source, w której troska o pieniądze jest bardzo realna.
Powróćmy do CRA. W punkcie 10. wymieniono kilka przykładów działalności komercyjnej:
W kontekście oprogramowania działalność komercyjna może charakteryzować się nie tylko naliczaniem ceny za produkt, ale także naliczaniem ceny za usługi wsparcia technicznego, udostępnianiem platformy oprogramowania, za pośrednictwem której producent zarabia na innych usługach, lub wykorzystywaniem danych osobowych z powodów innych niż wyłącznie poprawa bezpieczeństwa, kompatybilności lub interoperacyjności oprogramowania.
Sformułowanie w rozdziale 10. dotyczące usług wsparcia technicznego wyraźnie określa praktykę świadczenia płatnego wsparcia dla agencji ratingowych. To z kolei może zmniejszyć atrakcyjność proszenia deweloperów o wkład w ciągłą stabilność i dostępność oprogramowania typu open source poprzez płatne umowy wsparcia.
Zachęty do należytej staranności i doskonalenia, gdy produkt open source jest używany jako składnik.
Produkt typu open source może być używany jako elementy składowe innych produktów. Na przykład nasz darmowy i otwarty program do rozpoznawania nazw DNS (produkt) Unbound jest komponentem komercyjnych urządzeń oferowanych przez firmę Infoblox (inny produkt). CRA ma implikacje dla takich integracji:
Artykuł 10 ust. 4
4. W celu wypełnienia obowiązku określonego w ust. 1 producenci dochowują należytej staranności podczas integrowania komponentów pochodzących od osób trzecich w produktach z elementami cyfrowymi. Zapewniają one, aby takie komponenty nie zagrażały bezpieczeństwu produktu z elementami cyfrowymi.
Wydaje się to obiecującym mechanizmem zachęcającym do wkładu w projekty open source, które są używane jako komponent. W naszej dotychczasowej praktyce Infoblox opiera się na Unbound w niektórych produktach, ale także wspiera finansowo jego rozwój. Niestety obecny wniosek nie wykracza poza badanie due diligence. Sandboxing komponentu poprzez zmniejszenie jego zdolności do przyczyniania się do naruszenia bezpieczeństwa produktu może być jednym ze sposobów spełnienia określonego wymagania. Takie podejście może być bardzo opłacalne i skuteczne z punktu widzenia bezpieczeństwa, ale nie przyniosłoby korzyści bezpieczeństwu samego komponentu (i jego wykorzystania w innych miejscach). Nie zachęca też integrującego producenta do pomocy deweloperowi open source w samodzielnym wypełnianiu obowiązków agencji ratingowej. Jest to szczególnie istotne, jeśli komponent jest (również) produktem (samodzielnym).
Audyty procesów biznesowych bardzo słabo pasują do projektów open source, które nie są prowadzone przez firmy.
Przypomnijmy, że samoocena nie jest dostępna dla krytycznych produktów. Mamy trzy zastrzeżenia do pozostałych dwóch dostępnych opcji obejmujących audyty osób trzecich:
1. Audyty (i audytorzy) są bardzo ukierunkowane na firmy i procesy biznesowe, które nie są dobrze dopasowane do liczby działających projektów open source.
2. Prawo, zgodność i audyt to umiejętności niekoniecznie obecne w grupach programistów open source, którzy poza tym są dobrze przygotowani do tworzenia bezpiecznego oprogramowania.
3. Audyty mogą być bardzo drogie. Koszty przestrzegania przepisów mogą być zaporowe w przypadku projektów, które (częściowo) opierają się na wolontariuszach i/lub są (częściowo) utrzymywane z darowizn, płatnych funkcji lub wsparcia rzeczowego ze strony użytkowników ich oprogramowania.
NLnet Labs działa bardzo różnie od (tradycyjnych) producentów i nie zatrudnia specjalistów z zakresu prawa, zgodności ani audytów. Prawie cały nasz personel składa się z programistów i inżynierów badawczych. Powyższe obawy bardzo dotyczą nas. Oczekujemy jednak, że będziemy pracować nad oznakowaniem CE, nawet jeśli odciąga to pieniądze od tego, co robimy najlepiej.
Wydaje się, że Komisja rozważyła kwestię kosztów i zaleca audytorom rozważenie obniżek cen w niektórych przypadkach:
Artykuł 24 ust. 5 Jednostki notyfikowane uwzględniają szczególne interesy i potrzeby małych i średnich przedsiębiorstw (MŚP) przy ustalaniu opłat za procedury oceny zgodności i obniżają te opłaty proporcjonalnie do ich szczególnych interesów i potrzeb.
Należy zauważyć, że mowa tu o MŚP, podczas gdy wiele projektów typu open source jest bardziej konstruktem społecznym niż formalnym podmiotem prawnym. W jaki sposób audytor powinien ustalać wynagrodzenie za pracę grupy osób, z których część może mieć dochód z przyczynienia się do rozwoju wspólnego projektu? Niejasne jest również, gdzie audytor powinien odzyskać swoje straty wynikające z niższych opłat. W końcu niektóre projekty open source są na poziomie krytyczności i złożoności przewyższającym wiele komercyjnych produktów na rynku.
Nadmierne wymagania dotyczące zgodności?
Niepokoją nas nadmierne wymagania dotyczące zgodności obciążające poszczególne osoby i całe grupy deweloperów utrzymujących „krytyczne produkty”, od których już zależy nasze społeczeństwo, podczas gdy oni próbują z tego żyć. Istnieje znaczna nierównowaga między użytkowaniem, a (finansowym) wsparciem oprogramowania open source. Cytując statystyki, które przedstawiliśmy w ostatnim raporcie BITAG dotyczącym bezpieczeństwa routingu:
Spośród około 2000 instalacji oprogramowania Routinator Relying Party i 1400 sieci korzystających z oprogramowania oddelegowanego urzędu certyfikacji Krill, mniej niż dziesięć finansuje ich rozwój.
Czy to nie oddaliłoby nas od wyznaczonego przez CRA celu, jakim jest zajęcie się poważnym problemem społecznym: „niskim poziomem bezpieczeństwa cybernetycznego produktów z elementami cyfrowymi”? Czy agencja ratingowa zachęci programistów do tworzenia bezpieczniejszego oprogramowania, czy nałoży koszty przestrzegania przepisów, które zniechęcą ich do tego? Wiele projektów open source nie będzie bać się podstawowych wymagań bezpieczeństwa, ani wymagań dotyczących obsługi luk w zabezpieczeniach. Niektóre faktycznie wywodzą się ze społeczności open source. Inne są powszechnie uważane za najlepsze praktyki. Uważamy, że obecna propozycja nie wykorzystuje dużej szansy. Na wysokim poziomie „podstawowe wymagania bezpieczeństwa cybernetycznego” nie są nieuzasadnione, ale narzut związany ze zgodnością może być trudny lub niemożliwy dla małych lub pozbawionych gotówki programistów. Agencja ratingowa mogłaby zapewnić wsparcie programistom open source utrzymującym krytyczne fundamenty naszego społeczeństwa cyfrowego. Ale zamiast wprowadzać zachęty dla integratorów lub wsparcie finansowe za pośrednictwem agencji ratingowych, obecna propozycja przeciąży małych programistów pracą związaną z zapewnianiem zgodności.
Link do źródła: https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/
//-----------------------------------------------------------
Komentarz tłumacza
Powyższe rozważania dotyczą projektu prawnego, który może bardzo mocno ograniczyć tworzenie oprogramowania open source. Chyba łatwo się domyślić jakie to może mieć konsekwencje również dla nas, hobbystów. Może się szybko okazać, że w Unii Europejskiej nie będzie łatwego, darmowego dostępu do USB, MQTT, czy nawet komunikacji radiowej, a narzędzia rozwojowe oferowane przez producentów będą albo niedostępne, albo bardzo drogie.
Dodałem też kilka linków, więcej można znaleźć w materiale źródłowym.
Autor Maarten Aertsen
NLnet Labs uważnie śledzi wniosek legislacyjny Komisji Europejskiej dotyczący prawie całego sprzętu i oprogramowania na rynku europejskim. Cyber_Resilience_Act_(CRA) ma na celu zapewnienie cyberbezpieczeństwa produktów z elementami cyfrowymi poprzez określenie wymogów i obowiązków dla producentów.
'Commercial' + Critical = Compliance overload?
W tym poście podzielimy się naszym zrozumieniem przepisów i ich (niezamierzonymi) negatywnymi skutkami dla twórców oprogramowania open source. W tym momencie mamy pytania i wątpliwości, a nie odpowiedzi lub rozwiązania.
Uważamy, że obecna propozycja nie wykorzystuje dużej szansy. Na wysokim poziomie „podstawowe wymagania dotyczące bezpieczeństwa cybernetycznego” nie są nieuzasadnione, ale koszty ogólne związane ze zgodnością mogą wahać się od trudnych do niemożliwych dla małych lub pozbawionych gotówki programistów. Agencja ratingowa mogłaby zapewnić wsparcie programistom open source utrzymującym krytyczne fundamenty naszego społeczeństwa cyfrowego. Ale zamiast wprowadzać zachęty dla integratorów lub wsparcie finansowe za pośrednictwem agencji ratingowych, obecna propozycja przeciąży małych programistów pracą związaną z zapewnianiem zgodności.
Pod koniec artykułu dowiesz się wszystkiego o „działalności komercyjnej”, „produktach krytycznych” i obciążeniu zgodnością, jakie powoduje ta kombinacja.
Chcielibyśmy się mylić co do większości naszych analiz, więc jeśli uważasz, że sytuacja jest mniej ponura, niż ją przedstawiamy, porozmawiaj ze mną, abym mógł zaktualizować ten przegląd. Jeśli jednak podzielasz nasze obawy, oto co możesz zrobić:
Rozgłosić. Pomóż innym programistom. Porozmawiaj z ludźmi wokół ciebie, którzy mają umiejętności prawne i polityczne. Poinformuj ich, w jaki sposób propozycja agencji ratingowej wpływa na nich, ich organizację lub całe społeczeństwo. Przeczytaj propozycję. Ten post koncentruje się na określaniu zakresu na wysokim poziomie. Więcej, istnieje również propozycja KE dotycząca odpowiedzialności. Skontaktuj się i porozmawiaj z decydentami w Komisji, swoim rządzie lub ulubionym eurodeputowanym ITRE: sprawozdawcą jest Nicola Danti, a sprawozdawcami pomocniczymi są Henna Verkkunen, Eva Kaili, Ignazio Corrao i Evžen Tošenovský.
Jako społeczność technologiczna ponosimy wspólną odpowiedzialność za przyczynianie się do jakości kształtowania polityki, która ma wpływ na nas, a poprzez naszą pracę na całe społeczeństwo.
Nasze rozumienie ustawy
Po utworzeniu ram (dobrowolnej) certyfikacji w ramach unijnego Aktu o cyberbezpieczeństwie, a następnie uregulowaniu usług sieciowych i informacyjnych wykorzystywanych do świadczenia usług kluczowych dyrektywą NIS2, Komisja Europejska (KE) zamierza teraz ustanowić obowiązkowe wymagania dla produktów z elementami cyfrowymi w oparciu o istniejące ramy UE w zakresie przepisów dotyczących bezpieczeństwa produktów i odpowiedzialności. W niedalekiej przyszłości producenci tosterów, maszyn do lodów i oprogramowania (open source) będą mieli ze sobą coś wspólnego: aby udostępnić swoje produkty na rynku europejskim, będą musieli potwierdzić swoją zgodność z prawodawstwem UE dotyczącym produktów poprzez umieszczenie znaku CE cechowanie. Dla naszych odbiorców, w pozostałej części tego postu, gdy agencja ratingowa mówi o producentach, zamiast tego będziemy pisać o programistach (oprogramowania open source).
W niedalekiej przyszłości produkty fizyczne i oprogramowanie typu open source będą miały jeszcze jedną wspólną cechę: oznakowanie CE
Podstawowe wymagania dotyczące cyberbezpieczeństwa dla produktów z elementami cyfrowymi
Ustawa o odporności cybernetycznej zawiera zestaw podstawowych wymagań dotyczących bezpieczeństwa cybernetycznego i postępowania z lukami w zabezpieczeniach dla producentów (załącznik I). Będzie wymagać, aby produktom towarzyszyły informacje i instrukcje dla użytkownika (załącznik II). Producenci będą musieli przeprowadzić ocenę ryzyka i sporządzić dokumentację techniczną (załącznik V), aby wykazać, że spełniają zasadnicze wymagania.
Bądźmy szczerzy, sprzęt i oprogramowanie, na którym wszyscy polegamy, powinno być zaprojektowane z myślą o bezpieczeństwie, a nie dostarczane ze znanymi lukami, które można wykorzystać. Powinno też otrzymywać aktualizacje zabezpieczeń przez rozsądny czas. Chociaż język jest na bardzo wysokim poziomie, w stylu „musisz być taki wysoki, żeby jeździć” to jest ogólnie w porządku. Ale liczą się szczegóły.
Produkty, produkty krytyczne – i konsekwencje
Komisja wie, że w naszym społeczeństwie nie wszystkie produkty są tak samo uzależnione. W związku z tym agencja ratingowa rozróżnia produkty i produkty krytyczne „odzwierciedlające poziom ryzyka cybernetycznego związanego z tymi produktami”. Załącznik III zawiera dwie kategorie produktów krytycznych, odpowiednio w klasie I i II. Niektóre najważniejsze informacje z tych list:
Te listy krytycznych kategorii produktów nie są statyczne. Komisja może w przyszłości dodawać lub usuwać kategorie na podstawie ich poziomu ryzyka cybernetycznego. Ryzyko to określane jest przez następujące kryteria:
Artykuł 6 ust. 2
a) funkcjonalność produktu z elementami cyfrowymi związana z cyberbezpieczeństwem oraz czy produkt z elementami cyfrowymi ma co najmniej jedną z następujących cech:
(i) jest przeznaczony do uruchamiania z podwyższonymi uprawnieniami lub zarządzania uprawnieniami;
(ii) ma bezpośredni lub uprzywilejowany dostęp do sieci lub zasobów obliczeniowych;
(iii) jest przeznaczony do kontrolowania dostępu do danych lub technologii operacyjnej;
(iv) pełni funkcję krytyczną dla zaufania, w szczególności funkcje bezpieczeństwa, takie jak kontrola sieci, bezpieczeństwo punktów końcowych i ochrona sieci.
b) zamierzone użycie we wrażliwych środowiskach, w tym w warunkach przemysłowych lub przez kluczowe jednostki typu, o którym mowa w załączniku [załącznik I] do dyrektywy [dyrektywa XXX/XXXX (NIS2)];
c) zamierzone wykorzystanie do wykonywania funkcji krytycznych lub wrażliwych, takich jak przetwarzanie danych osobowych;
d) potencjalny zakres niekorzystnego wpływu, w szczególności pod względem jego intensywności i możliwości oddziaływania na wiele osób;
e) zakres, w jakim korzystanie z produktów z elementami cyfrowymi spowodowało już straty materialne lub niemajątkowe lub zakłócenia lub wzbudziło poważne obawy co do wystąpienia negatywnego wpływu.
Istnieją konsekwencje dla producentów produktów krytycznych. Aby je zrozumieć, musimy porozmawiać o stronie zgodności agencji ratingowych.
Wykazanie zgodności: jak wykazać, że wymagania zostały spełnione?
Deweloperzy muszą zadeklarować zgodność z wymaganiami określonymi w CRA, a tym samym przyjąć odpowiedzialność za zgodność. Być może widziałeś oświadczenie o zgodności, gdy kupowałeś pralkę lub inny produkt konsumencki w UE (jeśli nie, zobacz przykład w załączniku IV). Oprogramowanie pralki również wymaga oznaczenia CE na wspomnianej deklaracji lub na swojej stronie internetowej. Jak to działa?
Artykuł 6 ust. 4 Produkty krytyczne z elementami cyfrowymi podlegają procedurom oceny zgodności, o których mowa w art. 24 ust. 2 i 3.
Deweloper musi postępować zgodnie z jedną z trzech możliwych procedur oceny zgodności. Mogą albo:
1. Przeprowadzić samoocenę; lub (żargon: kontrola wewnętrzna, moduł A);
2. Ubiegać się o badanie produktu przez audytora, a następnie ustanowić mechanizmy kontroli i równowagi dla swoich procesów rozwojowych; lub (żargon: badanie typu UE przez jednostkę notyfikowaną, a następnie wewnętrzna kontrola produkcji, moduł B i C)
3. Wystąpić o ocenę ich systemu jakości przez audytora. (udokumentowane zasady, procedury i instrukcje) (żargon: pełne zapewnienie jakości, moduł H)
Te kolejne opcje pociągają za sobą coraz większą ilość pracy związanej ze zgodnością. Wariant 3 może być korzystniejszy dla producentów z dużą liczbą różnych produktów.
Wykazanie zgodności krytycznych produktów wiąże się z kosztami dla zewnętrznych audytorów
Ocena zgodności to miejsce, w którym ujawniają się konsekwencje rozróżnienia między produktami a produktami krytycznymi: twórcy produktów krytycznych mogą nie przeprowadzać samooceny i muszą angażować zewnętrznych audytorów. Dostępne są dla nich tylko opcje 2 i 3.
Po omówieniu niektórych zagadnień wstępnych przejdziemy teraz do implikacji dla twórców oprogramowania open-source.
Wpływ na twórców oprogramowania open source
Wszystkie kategorie produktów krytycznych obejmują szeroko stosowane implementacje w oprogramowaniu typu open source
Łatwo zauważyć, że istnieją projekty open source, które tworzą produkty w prawie wszystkich kategoriach produktów krytycznych (oprogramowania). Pomyśl o Keycloak, Wireguard, BIND, OpenSSH, FreeBSD, Boulder, OpenWRT, BIRD i FRR, aby wymienić tylko kilka z powyższego fragmentu listy.
I chociaż określone kategorie – a tym samym projekty, których to dotyczy – mogą pojawić się lub zniknąć w nadchodzących negocjacjach w sprawie wniosku, szeroki zasięg agencji ratingowej jest dość jasny.
Ale czekaj, czy nie ma wyjątku dla open source?
Tak*, ale z bardzo dużą gwiazdką. Cytując punkt 10. preambuły agencji ratingowej:
Aby nie utrudniać innowacji ani badań, niniejsze rozporządzenie nie powinno obejmować bezpłatnego oprogramowania o otwartym kodzie źródłowym, opracowanego lub dostarczonego poza działalnością komercyjną. [..]
Najpierw przyznajmy i doceńmy, że Komisja Europejska w ogóle stworzyła wyjątek. Oznacza to, że możemy teraz spierać się o specyfikę wybranego wyjątku i jego implikacje, a nie o zalety otwartego oprogramowania.
Co to jest działalność komercyjna?
CRA nie definiuje tego terminu. Jednak rozmowy z osobami bardziej zaznajomionymi z prawodawstwem dotyczącym produktów nakierowały mnie na przewodnik EU_Blue_Guide dotyczący wdrażania unijnych przepisów dotyczących produktów:
Przez działalność handlową rozumie się dostarczanie towarów w kontekście biznesowym. Organizacje non-profit można uznać za prowadzące działalność komercyjną, jeżeli działają w takim kontekście. Można to ocenić jedynie w indywidualnych przypadkach, biorąc pod uwagę regularność dostaw, cechy produktu, intencje dostawcy itp. W zasadzie okazjonalne dostawy dokonywane przez organizacje charytatywne lub hobbystów nie powinny być uznawane za mające miejsce w kontekście biznesowym.
Oprogramowanie typu open source jest dostarczane zarówno w kontekście biznesowym, jak i poza nim. A wyjątek „okazjonalne dostawy” w tym cytacie wydaje się mieć ograniczone zastosowanie w przypadku projektów, od których społeczeństwo jest uzależnione. Czy uważasz system operacyjny typu open source (MINIX), który jest dostępny bezpłatnie od 35 lat, za „okazjonalną dostawę”? Co oznacza jego integracja ze wszystkimi procesorami Intela od 2015 roku, jeśli chodzi o bycie „towarem” poza „kontekstem biznesowym”? Co powiecie na projekt BIND, który od 40 lat stanowi podstawowy element infrastruktury internetowej typu open source?
Rozróżnienie między rozwojem open source bez dochodów, pewnymi dochodami i pełnymi dochodami?
Czy po przeczytaniu tego możesz teraz ocenić, czy oprogramowanie open source, na którym polegasz, jest rozwijane w ramach działalności komercyjnej? Zdecydowanie czujemy się niewykwalifikowani, aby dokonać takiego rozróżnienia. Jednak bardzo ważne jest, aby zrozumieć, czy agencja ratingowa ma zastosowanie do twojego projektu. Oprócz niepewności dla deweloperów może istnieć niepewność prawna co do granic pojęcia „działalność komercyjna” w kontekście dostarczania oprogramowania typu open source. Nierozsądne jest oczekiwanie, że ruch open source przejdzie przez sądy, aby stworzyć precedensy prawne niezbędne do wyjaśnienia tej sprawy.
Pobieranie opłat za wsparcie sprawia, że open source staje się działalnością komercyjną.
Istnieje duża podaż nieobsługiwanego i niedostatecznie obsługiwanego oprogramowania. Dotyczy to również oprogramowania open source, w tym projektów, na których wiele polega (popularny przykład: OpenSSL w 2014 r.). Im szersze oprogramowanie jest zależne, tym wyższe wymagania i oczekiwania stawiane są jego twórcom. Wychodząc naprzeciw oczekiwaniom, programiści nierzadko szukają możliwości pracy nad takimi projektami w pełnym wymiarze godzin. Czy zatem niepewność związana z „działalnością komercyjną” w agencjach ratingowych powinna zniechęcać wolontariuszy do zarabiania na życie i pracy nad oprogramowaniem typu open source w pełnym wymiarze godzin? Uważamy, że w najlepszym interesie społeczeństwa byłoby, gdyby pracowali nad swoim kodem.
Jednym z powszechnych sposobów uzyskiwania przez programistów open source niezbędnych do tego dochodów jest przyjmowanie pracy w organizacji korzystającej z ich oprogramowania, praca jako wolny strzelec nad płatnymi funkcjami lub sprzedawanie czasu spędzonego na zapewnianiu wsparcia.
Powróćmy do CRA. W punkcie 10. wymieniono kilka przykładów działalności komercyjnej:
W kontekście oprogramowania działalność komercyjna może charakteryzować się nie tylko naliczaniem ceny za produkt, ale także naliczaniem ceny za usługi wsparcia technicznego, udostępnianiem platformy oprogramowania, za pośrednictwem której producent zarabia na innych usługach, lub wykorzystywaniem danych osobowych z powodów innych niż wyłącznie poprawa bezpieczeństwa, kompatybilności lub interoperacyjności oprogramowania.
Sformułowanie w rozdziale 10. dotyczące usług wsparcia technicznego wyraźnie określa praktykę świadczenia płatnego wsparcia dla agencji ratingowych. To z kolei może zmniejszyć atrakcyjność proszenia deweloperów o wkład w ciągłą stabilność i dostępność oprogramowania typu open source poprzez płatne umowy wsparcia.
Zachęty do należytej staranności i doskonalenia, gdy produkt open source jest używany jako składnik.
Produkt typu open source może być używany jako elementy składowe innych produktów. Na przykład nasz darmowy i otwarty program do rozpoznawania nazw DNS (produkt) Unbound jest komponentem komercyjnych urządzeń oferowanych przez firmę Infoblox (inny produkt). CRA ma implikacje dla takich integracji:
Artykuł 10 ust. 4
4. W celu wypełnienia obowiązku określonego w ust. 1 producenci dochowują należytej staranności podczas integrowania komponentów pochodzących od osób trzecich w produktach z elementami cyfrowymi. Zapewniają one, aby takie komponenty nie zagrażały bezpieczeństwu produktu z elementami cyfrowymi.
Wydaje się to obiecującym mechanizmem zachęcającym do wkładu w projekty open source, które są używane jako komponent. W naszej dotychczasowej praktyce Infoblox opiera się na Unbound w niektórych produktach, ale także wspiera finansowo jego rozwój. Niestety obecny wniosek nie wykracza poza badanie due diligence. Sandboxing komponentu poprzez zmniejszenie jego zdolności do przyczyniania się do naruszenia bezpieczeństwa produktu może być jednym ze sposobów spełnienia określonego wymagania. Takie podejście może być bardzo opłacalne i skuteczne z punktu widzenia bezpieczeństwa, ale nie przyniosłoby korzyści bezpieczeństwu samego komponentu (i jego wykorzystania w innych miejscach). Nie zachęca też integrującego producenta do pomocy deweloperowi open source w samodzielnym wypełnianiu obowiązków agencji ratingowej. Jest to szczególnie istotne, jeśli komponent jest (również) produktem (samodzielnym).
Audyty procesów biznesowych bardzo słabo pasują do projektów open source, które nie są prowadzone przez firmy.
Przypomnijmy, że samoocena nie jest dostępna dla krytycznych produktów. Mamy trzy zastrzeżenia do pozostałych dwóch dostępnych opcji obejmujących audyty osób trzecich:
1. Audyty (i audytorzy) są bardzo ukierunkowane na firmy i procesy biznesowe, które nie są dobrze dopasowane do liczby działających projektów open source.
2. Prawo, zgodność i audyt to umiejętności niekoniecznie obecne w grupach programistów open source, którzy poza tym są dobrze przygotowani do tworzenia bezpiecznego oprogramowania.
3. Audyty mogą być bardzo drogie. Koszty przestrzegania przepisów mogą być zaporowe w przypadku projektów, które (częściowo) opierają się na wolontariuszach i/lub są (częściowo) utrzymywane z darowizn, płatnych funkcji lub wsparcia rzeczowego ze strony użytkowników ich oprogramowania.
Wydaje się, że Komisja rozważyła kwestię kosztów i zaleca audytorom rozważenie obniżek cen w niektórych przypadkach:
Artykuł 24 ust. 5 Jednostki notyfikowane uwzględniają szczególne interesy i potrzeby małych i średnich przedsiębiorstw (MŚP) przy ustalaniu opłat za procedury oceny zgodności i obniżają te opłaty proporcjonalnie do ich szczególnych interesów i potrzeb.
Należy zauważyć, że mowa tu o MŚP, podczas gdy wiele projektów typu open source jest bardziej konstruktem społecznym niż formalnym podmiotem prawnym. W jaki sposób audytor powinien ustalać wynagrodzenie za pracę grupy osób, z których część może mieć dochód z przyczynienia się do rozwoju wspólnego projektu? Niejasne jest również, gdzie audytor powinien odzyskać swoje straty wynikające z niższych opłat. W końcu niektóre projekty open source są na poziomie krytyczności i złożoności przewyższającym wiele komercyjnych produktów na rynku.
Nadmierne wymagania dotyczące zgodności?
Niepokoją nas nadmierne wymagania dotyczące zgodności obciążające poszczególne osoby i całe grupy deweloperów utrzymujących „krytyczne produkty”, od których już zależy nasze społeczeństwo, podczas gdy oni próbują z tego żyć. Istnieje znaczna nierównowaga między użytkowaniem, a (finansowym) wsparciem oprogramowania open source. Cytując statystyki, które przedstawiliśmy w ostatnim raporcie BITAG dotyczącym bezpieczeństwa routingu:
Spośród około 2000 instalacji oprogramowania Routinator Relying Party i 1400 sieci korzystających z oprogramowania oddelegowanego urzędu certyfikacji Krill, mniej niż dziesięć finansuje ich rozwój.
Czy to nie oddaliłoby nas od wyznaczonego przez CRA celu, jakim jest zajęcie się poważnym problemem społecznym: „niskim poziomem bezpieczeństwa cybernetycznego produktów z elementami cyfrowymi”? Czy agencja ratingowa zachęci programistów do tworzenia bezpieczniejszego oprogramowania, czy nałoży koszty przestrzegania przepisów, które zniechęcą ich do tego? Wiele projektów open source nie będzie bać się podstawowych wymagań bezpieczeństwa, ani wymagań dotyczących obsługi luk w zabezpieczeniach. Niektóre faktycznie wywodzą się ze społeczności open source. Inne są powszechnie uważane za najlepsze praktyki. Uważamy, że obecna propozycja nie wykorzystuje dużej szansy. Na wysokim poziomie „podstawowe wymagania bezpieczeństwa cybernetycznego” nie są nieuzasadnione, ale narzut związany ze zgodnością może być trudny lub niemożliwy dla małych lub pozbawionych gotówki programistów. Agencja ratingowa mogłaby zapewnić wsparcie programistom open source utrzymującym krytyczne fundamenty naszego społeczeństwa cyfrowego. Ale zamiast wprowadzać zachęty dla integratorów lub wsparcie finansowe za pośrednictwem agencji ratingowych, obecna propozycja przeciąży małych programistów pracą związaną z zapewnianiem zgodności.
Link do źródła: https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/
//-----------------------------------------------------------
Komentarz tłumacza
Powyższe rozważania dotyczą projektu prawnego, który może bardzo mocno ograniczyć tworzenie oprogramowania open source. Chyba łatwo się domyślić jakie to może mieć konsekwencje również dla nas, hobbystów. Może się szybko okazać, że w Unii Europejskiej nie będzie łatwego, darmowego dostępu do USB, MQTT, czy nawet komunikacji radiowej, a narzędzia rozwojowe oferowane przez producentów będą albo niedostępne, albo bardzo drogie.
Dodałem też kilka linków, więcej można znaleźć w materiale źródłowym.
Fajne? Ranking DIY
