Cyber Resilience Act und andere EU-Gesetzgebungsverfahren

[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
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : OpenPGP_signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 659 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20231012/5da93332/attachment.sig>