Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Oprogramowanie open source a proponowana ustawa o cyberodporności

Marek_Skalski 15 Nov 2022 22:21 1347 9
Computer Controls
  • Oprogramowanie open source a proponowana ustawa o cyberodporności

    Oprogramowanie open source a proponowana ustawa o cyberodpornościOpracowane 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.
    Zapewniamy również specjalistyczną wiedzę techniczną organom decyzyjnym, w tym organom regulacyjnym i rządom, aby miały one wiedzę potrzebną przy podejmowaniu decyzji dotyczących polityki publicznej związanych z infrastrukturą internetową.


    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).

    Oprogramowanie open source a proponowana ustawa o cyberodporności
    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:

    Oprogramowanie open source a proponowana ustawa o cyberodporności
    Załącznik III: krytyczne produkty z elementami cyfrowymi


    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.

    Oprogramowanie open source a proponowana ustawa o cyberodporności
    XKCD: Zależność autorstwa Randalla Munroe (CC BY-NC 2.5)


    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.

    Cool? Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    Marek_Skalski
    VIP Meritorious for electroda.pl
    Offline 
    Byłem w Ryjo, byłem w Bajo, miałem bilet na Hawajo, wszystko ...
    Byłem VIPem, byłem modem, byłem administratorem, wszystko ...
    Marek_Skalski wrote 1330 posts with rating 1006, helped 111 times. Live in city Eindhoven. Been with us since 2019 year.
  • Computer Controls
  • #2
    Nepto
    Level 15  
    W sumie to nie jestem na 100% pewien, czy to faktycznie bedzie az tak ograniczac dostepnosc oprogramowania.
    Sa dwa glowne przypadki:
    1/ hobbysci
    Ci wydaje sie, ze nie beda musieli dostosowywac sie do dyrektywy, bo beda podlegac pod wyjatek
    2/ firmy udostepniajace oprogramowanie jako produkt uboczny albo reklame swoich pozostalych uslug/produktow
    Tutaj wydaje sie, ze i tak beda one musialy przejsc proces audytu i certyfikacji na potrzeby swojej glownej produkcji.

    Ja patrze na to z punktu widzenia szkod i zgryzoty jakie przynosi korzystanie ze slabej jakosci oprogramowania i kiedys jednak trzeba bedzie zauwazyc i zaczac rozwiazywac problem oprogramowania.
    Nie kojarze zadnych innych klas produktow, w ktorych mamy wylaczenia odpowiedzialnosci typu "as is" - mozesz uzywac, ale nie dajemy absolutnie zadnej gwarancji, ze sie nie zapali, nie wybuchnie, nie utnie palca uzytkownika itd...
  • Computer Controls
  • #3
    Marek_Skalski
    VIP Meritorious for electroda.pl
    Jeżeli jakiś producent układów udostępnia zestawy rozwojowe oraz oprogramowanie do nich, to zazwyczaj są one dostarczane na zasadzie "as is" i do tej pory nikomu to nie przeszkadzało. Po wejściu nowych przepisów, taki zestaw rozwojowy, który nie jest rozdawany za darmo, którego oprogramowanie jest rozwijane i udostępniane przez producenta układów, będzie wymagało certyfikacji, ponieważ podpada pod działalność komercyjną.
    Przykład: STMicroelectronics produkuje mikrokontrolery, układy radiowe, układy uwierzytelniania, a do tego płytki rozwojowe. Do tego wszystkiego dostarcza oprogramowania o kodzie zamkniętym oraz całą masę programów demonstracyjnych czy aplikacyjnych, których źródła są dostępne w otwartym repozytorium (github). Kod jest open-source, a działalność firmy komercyjna. Po wejściu ustawy, każdy jeden program oraz płytka musi przejść (kosztowną) certyfikację CE, czego do tej pory nie było i wszystkim żyło się dobrze. W przyszłości, Nucleo nie będzie już kosztować 10 czy 20 EUR, ale dużo więcej. Alternatywnie, nie będzie dostępne w krajach Unii Europejskiej ze względu na brak zgodności z przepisami. A jak w grę wchodzi jeszcze dostęp do sieci internetowej, np. przez WiFi lub Eth, to za chwilę wszystkie ESP32 czy Bekeny też będą zabronione w UE. To wszystko w imię szeroko rozumianego bezpieczeństwa. Ale czy na pewno?
  • #4
    tmf
    Moderator of Microcontroller designs
    @Marek_Skalski Moim zdaniem w ten sposób Europa sobie kolejny raz strzela w kolano, a właściwe w klatkę piersiową, bo kończyny już sobie dawno odstrzeliliśmy durną polityką. Efekt będzie taki, że duże firmy Europę oleją, bo przecież produkcja już i tak jest przeniesiona poza EU, Chiny i inne kraje nie potrzebują naszego know-how, bo większość innowacji i tak już odbywa się poza EU, a my hobbyści i nie tylko, zostaniemy z ręką w nocniku i bezpiecznym oprogramowaniem - bezpiecznym, bo jakiś urzędnik tak stwierdził.
    Chętnych na kierunki techniczne będzie jeszcze mniej, bo skąd się mają brać jeśli odetniemy im źródło tanich narzędzi, płytek i wszystkiego tego co potencjalnie może zachęcić młodego człowieka do techniki, a małe firmy i start upy dobijemy kolejnymi regulacjami. Za to z pewnością będziemy mieli więcej aktywistów dbających o nasze szczęście.
  • #5
    RitterX
    Level 39  
    Zrobiono taką samą furtkę jak "Dyrektywą o Nowym Podejściu" czyli samocertyfikacja polegająca na tym, że ktoś bierze osobistą odpowiedzialność za produkt. Jeżeli ktoś chce "d..chron" to występuje o certyfikację. Różnica byłaby/będzie taka, że oddzielnie będzie wystawione CE na sprzęt oraz oprogramowanie. To pociąga za sobą konieczność certyfikacji kolejnych wersji oprogramowania, wzięcia za nie odpowiedzialności czyli użytkownicy przestaną być w wielu przypadkach ß-testerami :) .

    Nie oszukujmy się romantyczne czasy kodowania to przeszłość dlatego i bez nowej dyrektywy przynajmniej, niektórych obowiązują zasady np. MISRA C . Pojawia się coraz więcej naprawdę odpowiedzialnych urządzeń typu autonomiczny system prowadzenia samochodu. Tu pojawia się problem gdyż oprogramowanie nie musi pochodzić od jednego dostawcy a współdziałanie na poziomie wielu podsystemów nie koniecznie musi być poprawne bo suma części jeszcze nie jest całością.

    Przykład STM32 np. W poza certyfikacją radiową czyli sprzętową dotyczącą anteny oraz modułu nadawczego powinien posiadać certyfikację oprogramowania gdyż w ten sposób jest sterowana wykonawcza część radiowa. To znaczy, że oprogramowanie powinno w przypadku awarii modułu, zamiast siać po paśmie, go dezaktywować.

    Open Source ≠ bezpłatne. W licencji LGPL i podobnych nie ma słowa o tym, że nie można na nim zarabiać.
    Wiele firm posługujących się otwartym oprogramowaniem zarabia na nim w sposób pośredni, np. kompilator arm-gcc jak i bezpośredni poprzez udzielenie wsparcia, usługi podmiotowi, któremu dostarcza gotowe oprogramowanie.
    Open Source to brzmi naprawdę świetnie ale ile znacie osób, które nie metodą prób i błędów a "z buta" jest w stanie poprawnie skonfigurować i skompilować kernel Linuxa? Szukanie błędów w oprogramowaniu albo dziur w rozwiązaniach sieciowych to nie jest bajka do ogarnięcia za pomocą YT w 24H. Firmy świadczą usługi, wsparcie i na tym zarabiają. Taki jest model by sfinansować sporą część projektów otwarto źródłowych.
    Zagadką pozostaje co zrobić z dziesiątkami milionów preambuł w plikach projektów open source gdzie jest napisane "bez żadnej gwarancji użytkowania ani odpowiedzialności..." :D ? Widocznie prawodawcy UE, specjaliści od wszystkiego nigdy nie widzieli takiego pliku, warunków użytkowania na oczy i to bardzo wiele, w całym tym EU-cyrku, wyjaśnia.

    Zdecydowana większość sprzętu wymagającego oprogramowania jest sprowadzana spoza UE. To są "black box" i nikt w UE nie będzie w stanie certyfikować np. nowych procesorów Intela, AMD a nawet Huawei ;) pod kątem zgodności w sposób jaki sobie wyobrazili w swoich małych główkach "humaniści" prawodawcy UE.
    Przypomnę hecę z bezpieczeństwem pamięci cache w Intel-ach. Tego typu kwiatki wypływają z czasem i zarówno sławne na cały świat laboratoria "auditorów" UE jak i zwykli programiści oraz hobbyści mogą wystawiać certyfikaty zgodności jedynie w dobrej wierze i nic poza tym. Skoro na daną chwilę określona podatność nie była znana to nie ma takiej możliwości by ktokolwiek mógł być pociągnięty do odpowiedzialności.

    Podsumowując, jeżeli jak zwykle prawodawcy EU czegoś doszczętnie nie spieprzą to nic specjalnie się dla nas nie zmieni. Jeżeli standardowo spieprzą to zostaną bardzo szybko postawieni do pionu przez izby przemysłowe w dużych krajach. Mam tu na myśli Niemcy, Francję ale i Hiszpanię czy Włochy.

    Nie istnieje coś takiego jak cyberodporność. Nawet w klasztorach siedzą grzesznicy :) i to powinno dać do myślenia.
  • #6
    tmf
    Moderator of Microcontroller designs
    RitterX wrote:
    Podsumowując, jeżeli jak zwykle prawodawcy EU czegoś doszczętnie nie spieprzą to nic specjalnie się dla nas nie zmieni.

    Niestety nie tak do końca - urośnie stos durnych regulacji. Już teraz jest ich tyle, że rozpoczynając jakąkolwiek działalność właściwie należałoby zacząć od sztabu prawników, którzy sprawdzą, czy to co robisz jest zgodne z jakąś tam dyrektywa, nie na rusza jakiś tam patentów itd. A w tym czasie w Azji wszyscy idą do przodu i stopniowo zdobywają przewagę nad EU.
  • #7
    Marek_Skalski
    VIP Meritorious for electroda.pl
    @RitterX Ogólnie zgadzam się z Twoją opinią, ale czy na pewno przeczytałeś cały artykuł otwierający ten temat?
    Samoocena lub żargonowo kontrola wewnętrzna, (moduł A) jest niedopuszczalna w przypadku działalności komercyjnej. A nie sposób odmówić działalności komercyjnej producentom zestawów rozwojowych, którzy jednocześnie produkują komponenty użyte w tych zestawach. Jeżeli producent dostarcza jednocześnie oprogramowanie demonstracyjne i szkoleniowe, którego źródła są dostępne (inaczej jest to mało sensowne), to z automatu podpada pod konieczność certyfikacji HW i SW przez niezależne laboratoria. Jeszcze gorzej będzie, jak przykładowy STMicro będzie musiał najpierw dostać certyfikację na Azure RTOS (Microsoft, open source) czy FreeRTOS (Amazon, open source), aby użyć systemu operacyjnego w swoich przykładowych aplikacjach. I to wszystko w ramach dbania o cyberbezpieczeństwo w Europie. Aż strach myśleć jak sobie poradzi reszta świata bez tych szczegółowych regulacji, które formalnie sprowadzają się do zwiększonych kosztów czasowych, finansowych, formalnych, aby dostać znaczek CE. W wielu przypadkach zbędny, ponieważ użytkownik może dowolnie zmodyfikować źródła i uzyskać efekt inny od zamierzonego działaniem celowym lub przypadkowym błędem. Stoję na stanowisku, że dotychczas istniejące regulacje w tym zakresie były wystarczająco dobre, a nowe prawo wprowadza tylko zbędne obciążenia, nie dając nic w zamian.
    Można teraz szukać sposobów obejścia tego przez wydzielenie sekcji rozwoju zestawów i oprogramowania jako fundacji działającej charytatywnie, ale czy to zadziała dla odpłatnych zestawów rozwojowych?
    Można ewentualnie wskazywać potencjalnym klientom serwery poza EU i zastrzegać w ogólnych warunkach brak odpowiedzialności, ale to jest leczenie trądu za pomocą soku pomarańczowego.

    tmf wrote:
    większość innowacji i tak już odbywa się poza EU, a my hobbyści i nie tylko, zostaniemy z ręką w nocniku i bezpiecznym oprogramowaniem - bezpiecznym, bo jakiś urzędnik tak stwierdził.
    To jest bardzo prawdopodobny scenariusz, ponieważ ilość rozwiązań technicznych i patentów w Azji już przekracza w wielu obszarach to co łącznie tworzą Stany Zjednoczone i Europa. Jeżeli decyzją urzędnika mamy dostać bezpieczne oprogramowanie, to będzie ono pozbawione różnych elementów lub wręcz okrojone do minimum, aby zminimalizować ryzyko. Nie będę wcale zaskoczony jak pojawi się zakaz lub kara za modyfikację takie certyfikowanego oprogramowania. A przecież celem naszej działalności jest poszukiwanie, eksperymentowanie, dopasowanie do swoich potrzeb.
    Mam wrażenie, że umysły techniczne nie są już lubiane w Europie. Tacy ludzie za dużo analizują, zamiast wierzyć w piękne idee i plany, np. Agenda 2030, Fit for 55, itp.

    Ale może jest jakiś sposób, aby wywierać nacisk na urzędników w Brukseli, którzy tak bardzo chcą naszego bezpieczeństwa i może jest jakiś sposób na zmianę tych niekorzystnych zapisów? Pewnym problemem jest to, że demokratycznie wybrani europosłowie nie mają nic do powiedzenia w kwestii projektów prawa tworzonego przez członków Komisji Europejskiej, którzy wybierani są według zupełnie innych zasad i kryteriów, a do których dotrzeć zwykle nie można ze względu na anonimowość twórców prawa unijnego. Nie wiem jak przełamać tę barierę. :(
  • #8
    tmf
    Moderator of Microcontroller designs
    Marek_Skalski wrote:
    Ale może jest jakiś sposób, aby wywierać nacisk na urzędników w Brukseli, którzy tak bardzo chcą naszego bezpieczeństwa i może jest jakiś sposób na zmianę tych niekorzystnych zapisów?

    Co raz częściej myślę, że zamiast kopać się z koniem, prościej zmienić otoczenie...
    Jak piszesz, obecnie cenieni są wyznawcy, a ktoś kto poddaje analizie i krytyce to co mu się wciska to wywrotowiec i wichrzyciel :) Ale dla mnie bardziej przerażające jest to, że temat, który zasadniczo dotyczy dużej części użytkowników elektrody, właściwie przeszedł bez echa - wynika z tego, że większość osób (prawie wszczyscy) mają kompletnie gdzieś co tam biurokraci wymyślą.
  • #9
    RitterX
    Level 39  
    Marek_Skalski wrote:
    @RitterX Ogólnie zgadzam się z Twoją opinią, ale czy na pewno przeczytałeś cały artykuł otwierający ten temat?
    Samoocena lub żargonowo kontrola wewnętrzna, (moduł A) jest niedopuszczalna w przypadku działalności komercyjnej.

    Na samym końcu będzie to dopuszczalne vide heca po przyjęciu "auditorskiej" dyrektywy, która zakończyła się w bardzo szybkim tempie "Dyrektywą o Nowym Podejściu". Nie ma sensu dyskutować nad czymś co jest technicznym trupem czyli B i C. To, jeżeli w ogóle pozostanie, będzie na zasadzie alternatywności certyfikacji.
    Marek_Skalski wrote:
    Jeżeli producent dostarcza jednocześnie oprogramowanie demonstracyjne i szkoleniowe, którego źródła są dostępne (inaczej jest to mało sensowne), to z automatu podpada pod konieczność certyfikacji HW i SW przez niezależne laboratoria.

    Na jakiej podstawie laboratorium "auditorskie" wystawi certyfikat np. dla systemu sterowania cewkami stellaratora Wendelstein 7-X ? Albo czegoś prostszego FlyByWire dla nowego AirBus-a? Albo coś trudniejszego, komercyjny kod optymalizacji struktury białka za pomocą komputera kwantowego :) . Na zasadzie przejrzenia kodu?!
    Sporo rzeczy, coraz więcej jest tak silnie związana ze sprzętem i szerzej z cyberprzestrzenią, że nie sposób tego oddzielnie analizować. Większość zamkniętych rozwiązań, na których bazują europejskie firmy jest czarnymi skrzynkami, których z definicji nie można certyfikować w sposób B, C, D,... A to jest działalność komercyjna!
    Na Brukselę nie będą naciskali dłubacze w ARM-ach a duzi gracze, którzy bez łaski i skrupułów pożegnają na początek kilku durnych komisarzy i rojących równoległą rzeczywistość urzędników. Mieliśmy już przygotowania dyrektywy dotyczącej AI i nic z tego nie wynika.
    Marek_Skalski wrote:
    Można teraz szukać sposobów obejścia tego

    Właśnie, że nie. W ten sposób, wchodzisz w dialog a tym samym zdajesz się na łaskę urzędników UE czyli dostaniesz kolejne wersje "auditu" ...F,G,H.... . Aby przestali roić to musi być dla nich twarde lądowanie.
    Generalnie jest to przejaw rozpaczy urzędników UE, którzy zdają sobie sprawę, że panują i rozumieją coraz mniej rzeczywistości. To co proponują po prostu nie może się udać.
    Rzucili to na zasadzie by inni to nieco ucywilizowali czyli zgłaszając propozycje karmimy nimi eurotrole. Gdy tymczasem jedyną sensowną strategią jest ich wyoranie i to się stanie gdy np. Siemens przegra na świecie kilka przetargów gdyż nie będzie miał "zauditowanego" do końca projektu gdyż "auditowanie" trwać musi. Zleceniodawcy chcą mieć gotowe rozwiązania a brak miejscowego certyfikatu oznacza, że kupią rozwiązanie od USA, Japonii, Chin,... ale nie UE.

    Na rynku IT, tylko związanego z Internetem, w UE brakuje ponad 1mln. pracowników, w bardziej specjalistycznych branżach gdzie też powstaje naprawdę złożone oprogramowanie, ilościowo nie jest to tak imponujące ale jeżeli firmy nie mogą znaleźć bystrzaków, których kształcenie zajmuje lata, do 20%...30% zakładanych projektów to o czym w ogóle jest owa dyrektywa? Tak z ciekawości, skąd wezmą "auditorów"? Kadry naukowej uczelni wyższych z całą pewnością nie starczy i pominę tutaj problemy z potencjalnymi "konfliktami interesów" oraz szeroko rozumianymi NDA. Co się stanie gdy pokusa będzie silna i "auditor" użyje cudzego, poddawanego certyfikacji, kodu w swojej niezależnej działalności albo kod wycieknie z jednostki akredytacyjnej nawet na drodze włamania?!
    Dla podmiotów z USA czy Chin jakiekolwiek naruszenie ich własności będzie oznaczało natychmiastowe pozwy na sumy liczone w mld. jak mln. z opcją wojny handlowej w tle.
    Ktoś tu bez pojęcia włazi na golasa do tureckiego więzienia z nadzieją, że jakoś to będzie. Świat tak nie działa a UE nie jest jego pępkiem.

    Propozycja UE nie ma elementu wykonalności i to zamyka całą sprawę. Będzie debatowana, będzie głosowana a następnie przepadnie w komisjach na etapie poprawek, których nie da się pogodzić i koniec bajki, do widzenia.
  • #10
    jestam
    Automation specialist
    Zgadzam się z @RitterX. To jest kompletny odjazd i próba dekretacji powszechnej szczęśliwości. Zderzenie z rzeczywistością będzie twarde i bolesne.

    Dotychczas CE dotyczyło "safety" i miało chronić osoby przed obrażeniami czy śmiercią przez badziewne produkty. Jak wyszło, wszyscy wiemy: tak sobie. Co roku powtarzają się historie lampek choinkowych, oznaczonych oczywiście CE (od China Export). Ale maszyny w przemyśle są bezpieczniejsze dla ludzi niż były kiedyś, a także w porównaniu do niektórych innych miejsc na świecie.

    Teraz zechciano, aby software działał pomimo wysiłków atakujących, czyli "security". Też bym chciał. Ale złota rybka jest lekko przygłucha i zamiast góry złota będzie góra błota.

    https://xkcd.com/2030
    Oprogramowanie open source a proponowana ustawa o cyberodporności