Cyber Resilience Act und andere EU-Gesetzgebungsverfahren

So Okt 15 10:59:23 UTC 2023

Hallo Ilu

Am 12.10.23 um 21:03 schrieb Ilu:
> Hallo Joachim,
> 
> Deine Antwort geht an der Sache vorbei: Was Du zu DSGVO und NIS-2 
> schreibst, ist völlig richtig, hat aber nichts mit CRA zu tun. 

Das sehe ich anders: Wenn durch Konstruktionsfehler Sicherheitslücken 
entstehen [1] oder gar Menschen an Leib und Leben verletzt werden, 
könnte das das Interesse der Staatsanwältin wecken -- egal ob es nun um 
vernetzte Autos/Implantate/Solaranlagen oder Aufzüge geht.

Um
> Datenschutz und Sicherheit beim IT-Betrieb muss sich jedes Unternehmen 
> kümmern und ist insofern auch für die dafür ausgewählte Software 
> verantwortlich. CRA befasst sich aber nicht mit dem Betrieb, sondern mit 
> der Erstellung von Software(-produkten).

Es wäre ja auch unsinnig, zwei unterschiedliche Richtlinien mit gleichem 
Inhalt und Adressatinnen zu erlassen -- aber die Herstellerinnen von dem 
ganzen IoT-Kram müssen eben nicht nur CRA sondern auch noch NIS-2 
einhalten. Genauso wie in der Kreditwirtschaft nicht nur DORA sondern 
eben auch noch zusätzlich NIS-2 gilt (Der Bankenverband glaubt nämlich 
auch, dass für seine Mitglieder nur DORA gelte:-))

> 
> Es ist bereits jetzt klar, dass - wenn CRA so Gesetz wird - viele kleine 
> FOSS-Projekte in Europa eingestellt werden, weil sie CRA schlicht nicht 
> umsetzen können. 

Klar ist: Wer durch mangelhafte Leistungen Menschen in Gefahr bringt, 
fliegt raus. Und das ist auch gut so.

> Hunderte von internationalen FOSS-Projekten werden 
> Europa geo-blocken ("machen wir mit Nordkorea auch") und den Einsatz 
> ihrer Software in Europa verbieten. Ob das lizenzkonform ist, sei 
> dahingestellt, aber die Absicht besteht. Zum Beispiel die Linux 
> Foundation: "Expect to see open source “not approved for the EU” if the 
> EU CRA goes forward." Die EU sägt sich hier den Ast ab, auf dem sie 
> eigentlich mit ihren Open-Source-Initiativen sitzen will.

Für quelloffene Software lässt sich in jedem Fall leichter eine 
Stückliste derselben erstellen/eine Zertifzierung erhalten als mit 
proprietärer.

Sollte es dabei Schwierigkeiten mit der Finanzierung geben, wäre eben an 
der Stelle was zu tun.

> 
> Wer Freie Software erstellt, verschenkt etwas an die Gesellschaft. Die 
> EU wird mit ihrer nächsten Gesetzesinitiative PLD den Schenkern 
> vorschreiben, dass sie für die Qualität ihres Geschenks doch bitte in 
> vollem Umfang haften sollen. 

Wenn es anders wäre, könnten wir auch Kindern Waffen oder Handgranaten 
zum Spielen schenken.

Und zwar bei Freier Software jedem
> gegenüber, der diese Software nutzt (Ersteller proprietärer Software 
> haften nur gegenüber ihren Kunden). Da ist es nur folgerichtig, dass 
> Redhat ihre Repositories dichtgemacht haben.
> 
> Aber zurück zu Art. 11 CRA: Da geht es nicht um irgendwelche 
> Pflichtverletzungen, sondern darum, dass Sicherheitslücken an eine 
> Unzahl von staatlichen Behörden gemeldet werden sollen, bevor ein Patch 
> bereitsteht.

Ich wollte keineswegs behaupten, dass die Richtlinie kein 
VErbesserungspotential enthält.

Viele Grüße

Joachim

[1] 
https://www.automobil-industrie.vogel.de/autonomes-fahren-cybersicherheit-haftung-tisax-a-a39d410caecd198b73357be32aff65b8/
> 
> Am 12.10.23 um 15:43 schrieb Joachim Jakobs:
>> Hallo Ilu,
>>
>> Am 11.10.23 um 19:45 schrieb Ilu:
>>> Was dort nicht erwähnt wird (weil es nicht FOSS-spezifisch ist), ist 
>>> der richtige Klopper in Art. 11 CRA:
>>
>> AFAIK lassen sich menschliche/technische Lücken zunehmend 
>> automatisiert ausnutzen. Das sind die Risiken der Hyperkonnektivität.
>>
>> Deshalb MUSS die Verantwortliche den Nachweis erbringen, dass und wie 
>> sie  personenbezogene Daten per DSGVO, betriebliche Prozesse per NIS-2 
>> und softwarehaltige Produkte per CRA schützt. Das heißt: Die 
>> Verantwortliche MUSS Sicherheit 4.0 garantieren können, wenn sich ihre 
>> Verantwortung beispielsweise auf vernetzte Implantate, Autos oder 
>> Solaranlagen beziehen sollte.
>>
>> Die Bundesregierung hat im Deutschen Umsetzungsgesetz darauf geachtet, 
>> dass das Abwälzen der Verantwortung auf eine D/O-Versicherung 
>> ausgeschlossen ist -- die Verantwortliche ist und bleibt persönlich 
>> für Pflichtverletzungen, delegieren lassen sich lediglich Aufgaben:
>>
>> "Eine Pflichtverletzung liegt jedoch schon dann vor, wenn durch 
>> unzureichende Organisation, Anleitung bzw. Kontrolle Mitarbeitern der 
>> Gesellschaft Straftaten oder sonstige Fehlhandlungen ermöglicht oder 
>> auch nur erleichtert werden. Diesbezüglichen Verdachtsmomenten muss 
>> der Geschäftsführer unverzüglich nachgehen; weiterhin muss der 
>> Geschäftsführer geeignete organisatorische Vorkehrungen treffen, um 
>> Pflichtverletzungen von Unternehmensangehörigen hintanzuhalten" [1]
>>
>> Pflichten werden verletzt, wenn das Schutzniveau aus §1 ProdHaftG 
>> "Stand von Wissenschaft und Technik" nicht eingehalten wird:
>>
>> "Die Ersatzpflicht des Herstellers ist ausgeschlossen, wenn [...] der 
>> Fehler nach dem Stand der Wissenschaft und Technik in dem Zeitpunkt, 
>> in dem der Hersteller das Produkt in den Verkehr brachte, nicht 
>> erkannt werden konnte."
>>
>> Das sind die Rechtsfolgen aus den Risiken.
>>
>> Wollen wir ein niedrigeres Schutzniveau für vernetzte Implantate, 
>> Autos oder Solaranlagen? Ich hoffe nicht! Es läge auch nicht im 
>> Interesse der Herstellerin, wenn sich Schädlinge in den Produkten 
>> herumtreiben würden, denn dann würden die Kundinnen dem Laden wohl die 
>> Freundschaft kündigen?!
>>
>> Diese Regelkonformität der Datenverarbeitung lässt sich nach Ansicht 
>> des BfDI besonders gut mit "Open Source" erfüllen.
>>
>> Das bestätigt sogar ErwG 52 NIS-2:
>>
>> "Open-Source-Cybersicherheitswerkzeuge und -Anwendungen können zu 
>> einem höheren Maß an Offenheit beitragen und sich positiv auf die 
>> Effizienz industrieller Innovationen auswirken."
>>
>>
>>
>>>
>>> (2) Der Hersteller meldet der ENISA unverzüglich, jedenfalls aber 
>>> innerhalb von 24 Stunden, nachdem er davon Kenntnis erlangt hat, 
>>> jeden Vorfall, der sich auf die Sicherheit des Produkts mit digitalen 
>>> Elementen auswirkt. ...
>>
>>
>>
>> Mit dieser Pflicht werden insb. Unternehmen kollidieren, die nicht in 
>> den Quellcode ihrer Lieferkette gucken können.
>>
>> Die Frage ist: Wie sollte sich die Sicherheit von Daten, Prozessen und 
>> Produkten sichern lassen, wenn nicht durch eine umfassende 
>> Rechenschaftspflicht der Verantwortlichen für eigenes Handeln sowie 
>> das Handeln derer, die im Auftrag dieser Verantwortlichen an der 
>> Planung, Entwicklung, Einrichtung, Verwaltung oder Nutzung von SW zur 
>> Verarbeitung/Durchführung von Daten/Produkten und Prozessen beteiligt 
>> sind?
>>
>> Tatsächlich kritikwürdig empfinde ich es, dass die Gesetzgeberin 
>> einerseits für umfassende Rechenschaftspflichten eintritt -- und 
>> gleichzeitig andererseits Vorratsdaten sammeln, Chats kontrollieren 
>> und wer weiß Gott noch alles treiben will -- womit sie am Ende in 
>> Karlsruhe/Luxemburg aufm Bauch landen wird.
>>
>> Leider habe ich keine öffentliche Stimme zu dieser Kritik oder den 
>> Schlußfolgerungen gehört, die sich aus der Hyperkonnekvitität ergeben.
>>
>> Moment -- Stimmt nicht ganz:
>>
>> "Nachhaltige Digitalisierung geht nur sicher. Oder überhaupt nicht!" [2]
>>
>> Ich fänds gut, wenn die FSFE diesen Ball aufgreifen würde.
>>
>> Gruß Joachim
>>
>> [1] https://openjur.de/u/2395749.html
>> [2] 
>> https://www.nbs.de/die-nbs/aktuelles/news/details/news/nachhaltige-digitalisierung-geht-nur-sicher-oder-ueberhaupt-nicht
>>
>> _______________________________________________
>> FSFE-de mailing list
>> FSFE-de at lists.fsfe.org
>> https://lists.fsfe.org/mailman/listinfo/fsfe-de
>>
>> Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt.
>> Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu
>> behandeln: https://fsfe.org/about/codeofconduct
>>
> _______________________________________________
> FSFE-de mailing list
> FSFE-de at lists.fsfe.org
> https://lists.fsfe.org/mailman/listinfo/fsfe-de
> 
> Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt.
> Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu
> behandeln: https://fsfe.org/about/codeofconduct

-- 
Joachim Jakobs          2048R/D5D1F6DD 2012-03-03
   fon: +49-6233-1259.181  jj at privatsphaere.org
   mob: +49-176-97325.333  jj at pr-profi.com

PGP: D5D1F6DD