Cyber Resilience Act und andere EU-Gesetzgebungsverfahren

Ilu ilu at fsfe.org
Do Okt 12 19:03:06 UTC 2023


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

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. 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. Das vermindert die Sicherheit anstatt sie zu erhöhen, so 
die einhellige Meinung aller Menschen, die sich mit IT-Sicherheit 
befassen. Gründe dafür kannst Du zB hier 
https://www.centerforcybersecuritypolicy.org/insights-and-research/joint-letter-of-experts-on-cra-and-vulnerability-disclosure 
nachlesen.
"Responsible disclosure" trägt nicht umsonst "verantwortungsbewußt" im 
Namen.

Ilu

PS: CRA wird nicht für solche Projekte gelten, die rein ehrenamtlich von 
Leuten betrieben werden, die auch in ihrem Hauptberuf nicht mit IT Geld 
verdienen - das merke ich nur der Vollständigkeit halber an, denn in der 
Realität kommt das so gut wie nicht vor.

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
> 


Mehr Informationen über die Mailingliste FSFE-de