Eine der sicherlich herausragendsten Sicherheitslücken in diesem Jahrzehnt ist schon jetzt die Log4Shell-Sicherheitslücke, die zunehmend massiv ausgenutzt wird – ich hatte, wie üblich, auf LinkedIn frühzeitig dazu berichtet. Nun langsam, nachdem die Lücke bekannt ist und auch nicht nur in Teilen sondern massiv ausgenutzt werden kann und wird, stellt sich natürlich die Frage, was an rechtlichen Konsequenzen damit verbunden ist. Wie immer gilt: Es kommt drauf an.
Tatsächlich zeigt sich, dass die Lücke einige – vorhersehbare – Konsequenzen hat; viel interessanter ist, dass sich Datenschutzbehörden bereits postieren und auch anlasslose Kontrollen angekündigt haben. Dies nicht nur für Log4J speziell, sondern für Ransomware allgemein.
Was ist Log4Shell
Nur kurz, der Vollständigkeit halber: Bei ‚Log4j‚ handelt es sich um eine sehr weitverbreitete Protokollierungsbibliothek für Java. Sie ist Bestandteil einer ganz erheblichen Anzahl von Softwareprojekten, gleich, ob kommerziell oder Open-Source-Software. Die hier im Raum stehende Schwachstelle „Log4Shell“ (BSI: CVE-2021-44228) ermöglicht Angreifern durchaus „kinderleicht“ eigene Programmcodes ausführen. Nach allgemeiner Einschätzung droht die Kompromittierung vieler Dienste, da Log4J eben in zahlreicher auch Basis-Software Anwendung findet. Dabei mag man stilvoll diskutieren, ob es sich um eine Sicherheitslücke im eigentlichen Sinne handelt, denn tatsächlich tut Log4J das, was es tun soll – schlechte Implementation und deren Ausnutzen ist eher die Lücke (möglicherweise also ein Fall von „it’s not a bug, it’s a feature …?)
Allgemeine Log4J-Konsequenzen mit der DSGVO
Es ist Art. 33 DS-GVO ins Auge zu fassen:
Im Falle einer Verletzung des Schutzes personenbezogener Daten meldet der Verantwortliche unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde, diese der (…) zuständigen Aufsichtsbehörde, es sei denn, dass die Verletzung des Schutzes personenbezogener Daten voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. (…) Wenn dem Auftragsverarbeiter eine Verletzung des Schutzes personenbezogener Daten bekannt wird, meldet er diese dem Verantwortlichen unverzüglich (…)
Der Verantwortliche dokumentiert Verletzungen des Schutzes personenbezogener Daten einschließlich aller im Zusammenhang mit der Verletzung des Schutzes personenbezogener Daten stehenden Fakten, ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen.
Damit gilt zumindest schon einmal, dass im Fall eines festgestellten Datenabflusses („Data Breach“) bei der zuständigen Datenschutz-Aufsichtsbehörde eine Meldung gemacht werden muss. Zusätzlich kann eine Benachrichtigungspflicht an betroffene Personen im Raum stehen und es sind sämtliche Maßnahmen hinreichend zu dokumentieren, die ergriffen wurden.
Gerade Letzteres gerät schnell aus dem Blick, wobei bei Log4J die Problematik bestand, dass der Erste, per Update einzuspielende Fix, gar nicht ausreichend war. Dabei markieren gerade solche Geschehnisse einen juristisch wichtigen Punkt: Zum einen, ab einem Zeitpunkt fortlaufender Berichterstattung, ist man in jedem Fall im Bereich grober Fahrlässigkeit, wenn man gar nicht reagiert als Verantwortlicher; wenn dann ein Update eingespielt wurde dokumentiert man damit die eigene Kenntnis der Lücke – ist aber in der Pflicht, die weitere Entwicklung fortlaufend zu beobachten. Dabei gilt: Je kritischer die Lücke umso zeitnäher muss man regieren, wenn das BSI wie hier von einer derart kritischen Lücke spricht, wird man in Echtzeit zu beobachten und Updates einzuspielen haben.
Haftung der Verantwortlichen?
Haftet man als verantwortlicher Diensteanbieter, nur weil man Opensource-Software einsetzt? Sicherlich nicht! Auch die Tatsache, dass Opensource-Software häufig ehrenamtlich gepflegt wird und zugleich zunehmend eingesetzt wird, ist kein erhöhtes Sicherheitsrisiko, der frei zugängliche und jederzeit prüfbare Quellcode dürfte ein solches „Minus“ immer auffangen. Allerdings treffen Verantwortliche, je nach eigener Rolle, sehr eigene Pflichten, wer etwa Software entwickelt und dabei auf Opensource-Software einsetzt, sollte auf Standard-Tools wie OSS-Fuzz setzen, was gerade auch für Log4J ausgerichtet wurde. Insoweit ist daran zu erinnern, dass seit dem 1.1.22 die Sicherheit im Allgemeinen zum Kriterium für Mangelfreiheit (im Kaufrecht) wurde, was die Pflichten nochmals erhöht.
Insgesamt gilt: Grundsätzlich kommt eine Haftung in Betracht, auch wenn man die Sicherheitslücke nicht verantwortet hat, sondern die Software „nur“ einsetzt. Je nach eigener Rolle steigern sich die eigenen Pflichten, mindestens eine Beobachtungs- und Updatepflicht wird man in jedem Fall haben. Die Updatepflicht im geschäftlichen Verkehr ergibt sich dabei, nach altem wie neuen Recht, erst einmal als vertragliche Nebenpflicht bei einer derart gravierenden Lücke – gegenüber Verbrauchern ist sie seit dem 1.1.22 sogar im Gesetz kodifizierte Hauptpflicht (der allgemeine Beitrag zur Updatepflicht erscheint in den nächsten Tagen und wird hier verlinkt!)
Konkrete Meldepflicht weil das System „offen“ war?
Was bedeutet all dies nun konkret im Fall von Log4J: Zuvordert gilt der Grundsatz, dass eine Sicherheitslücke für sich noch keine datenschutzrechtliche Meldeverpflichtung auslöst!
Andererseits liegt alleine in der Existenz der Sicherheitslücke „Log4Shell“ in der Log4j-Bibliothek im Fall der Verwendung eine Verletzung der Vorgaben zur Sicherheit der Verarbeitung gemäß Art. 32 DS-GVO. Wenn dann Anzeichen hinzutreten, dass die Schwachstelle ausgenutzt wurde und personenbezogene Daten betroffen sind, wird eine meldepflichtige Datenschutzverletzung nach Art. 33 DSGVO vorliegen, da derart kompromittierte IT-Systeme selten „nicht zu einem Risiko“ für die Rechte und Freiheiten der davon betroffenen Personen führen dürften (so nun auch die klare Einschätzung des BayLDA).
Hiermit einher geht eine umfassende Dokumentationspflicht hinsichtlich der Feststellungen, ob ein Risiko für die betroffenen Personen besteht oder nicht (Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO).
Datenschutzbehörden kontrollieren Vorgaben!
Man sollte sich als Betrieb vorsehen: Die datenschutzrechtlichen Aufsichtsbehörden führen regelmäßig anlassbezogene und anlasslose Datenschutzprüfungen durch. Dies auch hinsichtlich Ransomware – das BayLDA etwa erfragt ergriffene technische und organisatorische Maßnahmen nach Art. 32 DS-GVO die mit dem Ziel existieren, einen Basisschutz gegen Ransonware-Angriffe zu gewährleisten:
Mit der Prüfung „Ransomware“ gibt die neu gegründete Stabstelle Prüfverfahren des BayLDA den Startschuss für eine Reihe anlassloser fokussierter Kontrollen. In kurzen Abständen werden künftig standardisierte schriftliche und auch automatisiert über das Internet ausgeführte Prüfungen mit klarer Schwerpunktsetzung durchgeführt.
Ziel der regelmäßigen fokussierten Prüfungen ist einerseits, die datenschutzrechtlichen Kontrollen der nicht-öffentlichen Stellen in Bayern auszuweiten. Andererseits soll durch die begleitende Bereitstellung von Informationen das Augenmerk auch der betrieblichen Datenschutzbeauftragten auf die jeweils geprüften oder zur Prüfung anstehenden Thematiken gelenkt werden.
- Sichere Softwareentwicklung: Ein Leitfaden zur Risikovermeidung und Qualitätssteigerung - November 10, 2024
- Open Source AI Definition 1.0 - Oktober 31, 2024
- Überblick über das Softwarerecht in Deutschland: Wichtige rechtliche Probleme bei der Softwareentwicklung und -vermarktung - September 21, 2024
