| RA Prof. Dr. Felix Buchmann, André Fritsche und RA Sebastian Nardone |
Kurz und Knapp
Open-Source-Software (OSS) gehört die Zukunft. Ihr Einsatz birgt aber aus sicherheitstechnischer Sicht erhebliche Risiken für Unternehmen. Der Beitrag gibt einen Überblick über die technischen Risiken, die datenschutz- sowie IT-rechtlichen Implikationen und die Frage der Haftung von Gesellschaftsorganen im Falle von IT-Sicherheitsvorfällen.
I. Einleitung
Insbesondere Software-Versorgungsketten von Unternehmen und Institutionen sind in den letzten Jahren zu beliebten Zielen von Cyber-Kriminellen geworden. Die Angreifer nutzen eine Vielzahl von Methoden (z. B. Dependancy Confusion, Brandjacking, etc.), um Entwickler und Nutzer in die Falle gehen zu lassen. Hierbei geraten insbesondere Open-Source-Bibliotheken zunehmend in den Fokus der Cyber-Kriminellen. Laut einer aktuellen Studie des auf Software-Supply-Chain-Management spezialisierten Unternehmens Sonatype1 beträgt der durchschnittliche Anstieg von böswilligen Software-Angriffen auf die Software Supply Chain besorgniserregende 700 % pro Jahr, wobei ein Großteil hiervon aus vorgelagerten Open-Source-Ökosystemen stammt.
Neben dem hieraus resultierenden kommerziellen aber auch dem nicht zu vernachlässigenden Image-Schaden muss sich für das Management eines betroffenen Unternehmens zusätzlich die Frage stellen, inwiefern der Einsatz von Open-Source-Produkten auch persönliche Haftungsrisiken mit sich bringt.
Nach einer Darstellung der technischen Besonderheiten in diesem Bereich versucht der vorliegende Beitrag, eine Antwort auf diese Frage aus gesellschaftsrechtlicher, datenschutzrechtlicher und IT-sicherheitsrechtlicher Sicht zu geben.
II. Technische Betrachtung
1. Die Software-Versorgungskette
Unter einer Software-Versorgungskette versteht man den Prozess bzw. die Methodik, durch die Softwareanwendungen von ihrer ursprünglichen Konzeption bis zur endgültigen Implementierung und Nutzung entwickelt, verteilt und gewartet werden. Diese Kette umfasst nicht nur die interne Entwicklung und das Management der Software, sondern im Besonderen auch die Integration externer Komponenten, wie Open-Source-Bibliotheken und Drittanbieter-Tools. Im Zuge dieses Prozesses spielen verschiedene Akteure eine Rolle, darunter Entwickler, Qualitätsprüfer und Sicherheitsexperten, die alle darauf abzielen, die Funktionalität, Sicherheit und Compliance der Software sicherzustellen. In der heutigen, stark vernetzten Geschäftswelt ist diese Versorgungskette zunehmend komplex, wobei Code und Komponenten aus einer Vielzahl von Quellen und geografischen Standorten stammen können.
Eine typische Software-Versorgungskette besteht aus mehreren Schlüsselkomponenten, die zusammenarbeiten, um die Entwicklung, den Test, die Bereitstellung und die Wartung von Softwareanwendungen zu ermöglichen. Hierzu zählen insbesondere:
- Software Code Management: Tools wie Git oder früher SVN und CVS dienen zur Verwaltung des Quellcodes. Sie ermöglichen eine umfangreiche Versionskontrolle und Zusammenarbeit zwischen Entwicklern.
- Abhängigkeitsmanager: Hiermit werden externe Bibliotheken und Frameworks verwaltet, auf die der Quellcode angewiesen ist. Sie helfen, die benötigten Abhängigkeiten in den richtigen Versionen automatisch herunterzuladen und zu installieren.
- Entwicklungswerkzeuge: Moderne Softwareentwicklung wird heute durch spezielle integrierte Entwicklungsumgebungen inklusive Code-Editoren unterstützt. Die Systeme erkennen die Konfiguration des Abhängigkeitsmanagers und kümmern sich automatisch um die Installation. Gleichzeitig unterstützen diese Systeme Entwickler auch bei der Programmierung, da bereits installierte externe Open-Source-Software analysiert und als Vorschlag beim Tippen angegeben wird.
- Testwerkzeuge: Unit-Tests, Integrationstests und Systemtests sind unerlässlich, um ein System auf Funktionalität, Zuverlässigkeit und Leistung zu prüfen.
- Build-Systeme: Tools wie Jenkins und Ant helfen dabei, automatisiert den Quellcode in eine Umgebung zu packen, die für erste Tests ausgeführt werden kann.
2. Mögliche Angriffe auf die Software-Versorgungskette
Je komplexer ein IT-System ist, desto anfälliger wird dieses für Schwachstellen, und damit auch für einen erfolgreichen Angriff. Häufig werden hierbei Angriffsmethoden wie insbesondere Dependency Confusion und Brandjacking verwendet:
Dependency Confusion, auch als Abhängigkeits-Repository-Hijacking oder Substitutionsangriff bekannt, ist eine Art von Software Supply Chain Angriff, der auf einer Eigenart bestimmter Paketmanager basiert, um unerwünschten und potenziell bösartigen Code einzufügen. Dieser Angriff tritt auf, wenn ein Paketmanager aus öffentlichen Code-Registern nach einem Paket sucht, bevor er private Register überprüft. In einem solchen Fall kann ein Angreifer dann ein Paket mit demselben Namen im öffentlichen Register registrieren und so bewirken, dass die bösartige Version aus dem öffentlichen Register heruntergeladen wird, wenn eine neue Installation erfolgt. Dies kann dann dazu führen, dass Schadcode eingeführt wird, der dem Angreifer beispielsweise einen Zugang mit administrativen Rechten zum jeweiligen System liefert. Trifft diese Angriffsform ferner auf Abhängigkeitsmanager bzw. Einwicklungswerkzeuge, kann dies dazu führen, dass Schadcode automatisch ohne irgendein Zutun des Verwenders eingeschleust wird.
Beim Brandjacking nutzen Cyberkriminelle den Markennamen eines Unternehmens oder eines bekannten Herstellers einer Bibliothek, um gefälschte oder bösartige Softwarekomponenten zu erstellen und zu verbreiten. Dies kann dazu führen, dass Kunden getäuscht werden und unerwünschte oder schädliche Software in ihre Systeme integrieren.
3. Beispiele aus der Praxis: Log4j & Python
Ein prominentes Beispiel aus der näheren Vergangenheit war die Sicherheitslücke innerhalb der Bibliothek Log4j. Angreifer suchen in diesen Fällen immer nach einer einfachen Möglichkeit, möglichst viele Systeme mit wenig Aufwand zu infizieren. Trotz Sicherheitslücken ist jedoch nicht jedes System automatisch verwundbar, denn erfolgreich durchgeführte Exploits benötigen häufig eine Kombination aus unterschiedlichen Parametern.
Beispielsweise fußt nicht jede Software auf Logging-Mechanismen durch Log4j. Je nach Architektur, in welcher sich potenzielle OSS-Schwachstellen verstecken, ist ihre Wahrscheinlichkeit für einen erfolgreichen oder überhaupt möglichen Exploit stark abhängig von Umständen wie:
- konkret installierte und betroffene Version inkl. möglicher sog. Builds;
- architektonische Elemente wie die Einbettung in Unternehmensnetzwerke inkl. sicherheitsrelevanter Assets wie Web-Application-Schutzsysteme und Firewalls;
- Fehlkonfigurationen innerhalb der eingesetzten Softwaremodule und infrastrukturellen Elemente.
Aber nicht nur fertige Softwareprodukte wie Log4j sind möglicherweise betroffen. Vor allem innerhalb der Python-Welt mehren sich neue Angriffsarten und Techniken, wie Schadcode in Open-Source-Abhängigkeiten für die eigene Software eingebaut werden kann. Eine recht neue Art Schadcode einzuschleusen, besteht darin, die Art und Weise wie Python mit Unicode umgeht, auszunutzen. Dabei wird die Kodierung von Zeichen so ausgenutzt, dass dem Python-Interpreter Daten untergeschoben werden, die auf den ersten Blick jedes Analyseprogramm passieren. In der Ausführung wird dort Code interpretiert und ausgeführt, meistens ohne gute Absicht.
III. Haftungsrisiken für Vorstand und Geschäftsführung
1. Haftung des Vorstands gemäß §§ 91 Abs. 2, 93 Abs. 2 AktG
a) Pflichtverletzung in Form eines Verstoßes gegen § 91 Abs. 2 AktG
Außerhalb des Anwendungsbereichs spezieller Haftungsregelungen2 sind bei Fragen zur Haftung der Unternehmensleitung gegenüber der Gesellschaft regelmäßig § 91 Abs. 2 AktG bzw. § 43 Abs. 1 GmbHG als Anspruchsgrundlagen in Betracht zu ziehen. Nach dieser Vorschrift hat der Vorstand einer Aktiengesellschaft auf einer ersten Stufe die Früherkennung bestandsgefährdender Entwicklungen durch geeignete Maßnahmen zu gewährleisten und auf einer zweiten Stufe die eingeleiteten Maßnahmen zu überwachen.3 Eine Anwendbarkeit dieser Grundsätze insbesondere auf die GmbH ist zwar weiterhin in der Literatur nicht unumstritten,4 im Ergebnis kann jedoch davon ausgegangen werden, dass über die allgemeine Sorgfaltspflicht gemäß § 43 Abs. 1 GmbHG auch bei der Geschäftsführung einer GmbH zumindest vergleichbare Pflichten vorliegen.
Bei der Entscheidung, ob die zu ergreifenden Maßnahmen im Sinne des § 91 Abs. 2 AktG „geeignet“ sind, steht dem Vorstand gemäß § 93 Abs. 1 AktG ein unternehmerisches Ermessen zu. Dieses Ermessen hat der Vorstand jedenfalls dann pflichtgemäß ausgeübt, wenn die Voraussetzungen der sog. Business Judgement Rule gemäß § 93 Abs. 1 S. 2 AktG erfüllt sind. Eine Pflichtverletzung liegt demnach nicht vor, wenn die Geschäftsleitung bei einer unternehmerischen Entscheidung vernünftigerweise annehmen durfte, auf der Basis angemessener Information zum Wohle der Gesellschaft zu handeln. Wendet man diese Regel auf die Pflicht zur Implementierung von Maßnahmen zur Früherkennung gemäß § 91 Abs. 2 AktG an, so folgt daraus, dass die Unternehmensleitung zumindest bei der Frage, ob sie ein solches System einführt, nicht frei ist, da diese Verpflichtung sich unmittelbar aus dem Gesetz ergibt. Bei der Frage der Ausgestaltung der zu ergreifenden Maßnahmen („wie“), entfaltet die Business Judgement Rule ihren Schutz und führt zu einer eingeschränkten Justiziabilität.
In Ermangelung spezialgesetzlicher Vorgaben beschränkt sich eine Überprüfung dieses unternehmerischen Ermessens darauf, ob die Unternehmensleitung überhaupt Maßnahmen zur Eindämmung existenzgefährdender Risiken unternommen hat. Darüber, wann von einer solchen Existenzgefährdung auszugehen ist und welche Verpflichtungen sich hieraus für den Vorstand ergeben, gibt es in Literatur und Rechtsprechung jedoch nur vereinzelte Anhaltspunkte.5 So wurde beispielsweise ein Verstoß gegen § 91 Abs. 2 AktG in der Implementierung eines lediglich informellen Früherkennungssystems für bestandsgefährdende Risiken gesehen, welches nicht dokumentiert war.6
b) Übertragung dieser Grundsätze auf den Bereich der IT-Sicherheit
Gemäß der Business Judgement Rule müssen unternehmerische Entscheidungen regelmäßig aufgrund einer angemessenen Informationsgrundlage getroffen werden. Bei Entscheidungen im IT-Bereich muss der Vorstand umso mehr Informationen über die einzusetzende IT einholen, je bedeutsamer diese für das Unternehmen ist.7 Insbesondere beim Einsatz von Open-Source-Software ist hierbei ein besonderer Sorgfaltsmaßstab einzuhalten.8 Hinzukommt, dass IT-Sicherheit unstreitig als C-Level Thema anzusehen ist und damit zusammenhängende Risiken existenzbedrohend sein können.9 Vor diesem Hintergrund ist ein Vorstand im besonderen Maße gehalten, bei der Auswahl von Open-Source-Produkten, alle ihm zur Verfügung stehenden Erkenntnisquellen unter Einhaltung der gebotenen Sorgfalt auszuschöpfen und dies umso mehr, sofern sich durch die Verwendung der Open-Source-Software IT-sicherheitsrechtliche Risiken ergeben können. Mangels konkreter gesetzlicher Vorgaben im nicht regulierten Bereich hat sich der Vorstand im Rahmen seiner Entscheidung an dem für seinen Tätigkeitsbereich geltenden Stand der Technik10 zu orientieren, welcher regelmäßig durch die gängigen Zertifizierungsstandards11 wiedergegeben wird. Zwar kann aus der Befolgung von bestimmten Vorgaben beispielsweise der ISO/IEC 27001 nicht automatisch die Einhaltung der nach § 93 Abs. 1 AktG bzw. § 43 GmbHG geforderten Sorgfalt abgeleitet werden,12 da für die Frage der Haftung stets der Einzelfall beleuchtet werden muss. Sollte aber eine Unternehmensleitung vorab sowohl für den eigenen Betrieb als auch mit Hinblick auf die eingesetzte Open-Source-Software die Einhaltung der einschlägigen Zertifizierungsstandards13 fordern und überwachen, wäre hierdurch das Haftungsrisiko zumindest auf ein vertretbares Maß reduziert.
2. Datenschutz
a) Sicherheit der Verarbeitung
Art. 32 DSGVO konkretisiert den allgemeinen Grundsatz der Integrität und der Vertraulichkeit (Art. 5 Abs. 1 lit. f DSGVO). Eine Verpflichtung von Vorstand und Geschäftsführung ergibt sich im Rahmen der seitens des Vorstands erforderlichen Compliance-Organisation14 aus § 91 Abs. 2 AktG i. V. m. Art. 32 Abs. 1 DSGVO.15 In der DSGVO wird hinsichtlich verschiedener Pflichten und Haftungsfragen auf den Begriff des „Verantwortlichen“ abgestellt. Das OLG Dresden16 entschied, dass der Geschäftsführer einer GmbH neben der Gesellschaft selbst „Verantwortlicher“ im Sinne der DSGVO sei und daher als Gesamtschuldner neben der Gesellschaft hafte.17 Verstöße gegen die DSGVO stellen ebenfalls eine „den Fortbestand der Gesellschaft gefährdende Entwicklung“ i. S. v. § 91 Abs. 2 AktG dar.18 Der Vorstand ist daher verpflichtet, geeignete Maßnahmen zu treffen, insbesondere ein Überwachungssystem einzurichten.
b) Technische und organisatorische Maßnahmen
Die Verantwortlichen sind verpflichtet, Maßnahmen zu treffen, die den Schutz gegen jede Form der (datenschutz-)rechtswidrigen Verarbeitung personenbezogener Daten gewährleisten. Dabei beziehen sich die organisatorischen Maßnahmen insbesondere auf das Verfahren, die Umstände und die ausführenden Personen, während die technischen Maßnahmen Hardware-, Software- und Netzwerkkomponenten betreffen, mit denen die Datenverarbeitung konkret durchgeführt wird.19
In Art. 32 Abs. 1 Hs. 1 DSGVO wird zunächst der Stand der Technik berücksichtigt. Dadurch werden die Maßnahmen zum einen auf das technisch Mögliche begrenzt und den Verantwortlichen eine dauerhafte Aktualisierungspflicht auferlegt. Das IT-Sicherheitsrecht dient zur Konkretisierung des unbestimmten Rechtsbegriffes.20
Es muss daher in regelmäßigen Abständen anhand der derzeitigen Datensicherheitsmaßnahmen ermittelt werden, ob diese geeignet sind, ein angemessenes Schutzniveau zu gewährleisten. Dabei ist zu prüfen, ob aufgrund veränderter Umstände der Verarbeitung oder aufgrund neu bekannt gewordener Sicherheitslücken weitere Risiken bekannt geworden sind, die eine Aktualisierung der Maßnahmen erforderlich machen. Abschließend wird eine Evaluierung zur Wirksamkeit der Maßnahmen durchgeführt, indem z. B. Angriffe simuliert werden.21 Empfehlenswert sind zudem anlassbezogene Kontrollen, wenn im Rahmen der Open-Source-Software eine Instabilität im Quellcode bekannt wird. Sollten die Ergebnisse des Sicherheitsverfahrens Lücken aufzeigen, sind diese entsprechend durch geeignete Maßnahmen zu beheben.
c) Angemessenes Schutzniveau
Inwiefern das festgelegte Schutzniveau angemessen ist, ist anhand einer datenschutzrechtlichen Risikoeinschätzung zu bewerten. Als riskante Beeinträchtigungen (Art. 32 Abs. 2 DSGVO) gelten die Vernichtung, der Verlust und die Veränderung der personenbezogenen Daten sowie die unbefugte Offenlegung und der unbefugte Zugang zu diesen Daten im Rahmen einer Verarbeitung. Je sensibler die Daten, desto größer ist die mögliche Schadensschwere und umso umfassendere Maßnahmen der Datensicherheit werden von den Verpflichteten gefordert.22
Mögliche Maßnahmen zur Verbesserung des Datenschutzes sind Sicherheitstests sowie Werkzeuge zur statischen Codeanalyse und Softwarezusammensetzungsanalyse (SCA).
d) Schadensersatz
Wenn keine Vorkehrungen getroffen werden und es zu einer unbefugten Verarbeitung von Daten kommt, drohen Schadensersatzforderungen und empfindliche Geldbußen.
Nach Art. 82 DSGVO hat eine geschädigte Person, der durch einen Verstoß des Verantwortlichen gegen die DSGVO ein Schaden entstanden ist, Anspruch auf Schadenersatz, es sei denn, der Verantwortliche kann nachweisen, dass er für den schadensbegründenden Umstand in keiner Weise verantwortlich ist. Um einen Anspruch zu begründen, muss allerdings auch ein Schaden dargelegt werden; ein Verstoß gegen die DSGVO als solcher allein begründet nach der jüngsten Entscheidung des EuGH keinen Schadensersatzanspruch.23
Der Schaden darf nicht nur befürchtet, sondern muss tatsächlich eingetreten sein, und es muss ein eindeutiger Kausalzusammenhang zwischen dem Verstoß und dem materiellen oder immateriellen Schaden bestehen.24 Allerdings hat der EuGH im Urteil vom 4. 5. 202325 entschieden, dass keine Erheblichkeitsschwelle überschritten werden muss.26 Grund dafür ist die Besorgnis, dass die angerufenen Gerichte verschiedene Schwellenwerte individuell festlegen und dadurch widersprüchliche Entscheidungen treffen könnten, was zu erheblicher Rechtsunsicherheit führen würde.27
Auch bei den materiellen Schäden stellt sich die Frage, ob allein das Abgreifen von Daten durch Dritte im Rahmen der Datenübermittlung über die Supply Chains einen Schaden darstellt oder ob bei Cyberangriffen auf die eingesetzte Open-Source-Software den Unternehmen weitere Folgeschäden entstehen müssen.28
Während ein materieller Schaden unproblematisch bei missbräuchlicher Verwendung der unbefugt überlassenen Daten (z. B. Missbrauch von Kreditkarten- oder Bankdaten) und dadurch kausal verursachten Vermögenseinbußen entsteht, muss im Einzelfall beurteilt werden, ob auch ein Datenverlust ohne nachfolgenden Missbrauch einen materiellen Schadensersatzanspruch auslösen kann.29 Die Auseinandersetzung mit den Grundsatzfragen der „Datenökonomie“,30 sowie dem wirtschaftlichen Wert von Daten31 ist in solchen Fallkonstellationen unerlässlich. Jedenfalls wird man bei einer unberechtigten Nutzung von Daten – in Anlehnung an die Lizenzanalogie bei Urheberrechtsverletzungen – auf den Wert dieser Daten im Rahmen einer kommerziellen Nutzung abstellen können.32 Auch die Kosten der Rechtsverfolgung, insbesondere Anwalts- und Ermittlungskosten zählen unbeschadet zu den ersatzfähigen materiellen Schäden.33
Zu erwähnen ist im Rahmen dieser Vorschrift auch die Exkulpationsmöglichkeit von Unternehmen gem. Art. 82 Abs. 3 DSGVO. Die konkreten Anforderungen für den Nachweis, dass die erforderliche Sorgfalt beachtet wurde, hängen von den Umständen des Einzelfalls ab.34 Aber auch hier zeigt die, dem EuGH35 vorgelegte Frage – ob das grundsätzlich vermutete Verschulden36 und damit die Haftung dadurch ausgeschlossen wird, dass die Rechtsverletzung auf menschliches Versagen eines Mitarbeiters zurückzuführen ist –, dass noch viele Fragen in der höchstrichterlichen Rechtsprechung ungeklärt sind. In jedem Fall wäre eine umfassende Dokumentation der datenschutzrelevanten Maßnahmen zur Sicherstellung des Datenschutzes und Zertifizierungen empfehlenswert, aber nicht unbedingt ausreichend.37 Über die Grundsätze des § 278 BGB zur Entlastung der beteiligten Mitarbeiter hinaus wird auch über die ergänzende Heranziehung der Exkulpationsregelungen des § 831 Abs. 1 S. 2 BGB gestritten. Ob der Unternehmer für das eigene Auswahl- und Überwachungsverschulden seiner Mitarbeiter zum Schadensersatz herangezogen werden kann, ist in der Rechtsprechung noch nicht geklärt.38 Jedenfalls sind dem Unternehmer auch Fehler von grundsätzlich unabhängigen betrieblichen Datenschutzbeauftragten i. S. v. Art. 38 Abs. 3 DSGVO zurechenbar.39 Beachtenswert ist auch, dass bei Übermittlungen an Drittländer oder internationale Organisationen der in dem Mitgliedstaat niedergelassene Unternehmer grundsätzlich die Haftung für Verstöße des nicht in der Union niedergelassenen Partners in den nach Art. 47 Abs. 2 lit. f erforderlichen internen Datenschutzvorschriften übernehmen muss.40
e) Bußgelder
Als weitere Sanktion sieht der Art. 83 DSGVO Geldbußen vor. Umstritten ist, ob ein Verschulden des Verantwortlichen i. S. d. Art. 83 DSGVO erforderlich ist. In Abs. 2 lit. b. wird die Berücksichtigung von Vorsatz und Fahrlässigkeit bei Berechnung der Höhe der Geldbuße normiert. Einerseits wird hieraus gefolgert, dass mindestens Fahrlässigkeit für eine Sanktionierung erforderlich ist.41 Andererseits wird angebracht, dass es sich nur um ein Zumessungskriterium handelt und ein Verschulden gerade nicht im Rahmen der Voraussetzungen für eine Geldbuße in der DSGVO genannt wird.42 Im Gegensatz zu den Entwürfen der Kommission und des Rates wurde im endgültigen Gesetzestext der Zusatz „vorsätzlich und fahrlässig“ aus dem Tatbestand gestrichen.43
In der Praxis wird jedoch grundsätzlich eine Fahrlässigkeit angenommen, weshalb dem Streit überwiegend akademische Natur zukommt.44 Die DSGVO legt den Verantwortlichen umfassende Pflichten auf und verpflichtet sie auch zur regelmäßigen Überprüfung der Datenschutzmaßnahmen. Bei Missachtung gerade dieser Pflichten wird den Verantwortlichen zumeist Fahrlässigkeit zur Last gelegt.
Es sind somit die übernommenen Quellcodes innerhalb der Open Source-Software umfassend zu prüfen, um sich nicht dem Risiko eines Bußgelds auszusetzen. Um Angriffe – ausgelöst durch Instabilitäten in den Quellcodes – zu vermeiden, ist dieser regelmäßig auf Schwachstellen zu untersuchen.
f) Maßnahmen aus datenschutzrechtlicher Sicht
Im Umgang mit Open-Source-Software in der Supply Chain müssen Unternehmen aus datenschutzrechtlicher Sicht verschiedene Aspekte berücksichtigen.
Es empfiehlt sich zunächst, regelmäßig Risikobewertungen durchzuführen, um potenzielle Datenschutzrisiken im Zusammenhang mit der OSS zu identifizieren. Außerdem sollten stets mögliche Aktualisierungen der Software implementiert werden. Die OSS-Community arbeitet fortlaufend an der Verbesserung von Open-Source-Software-Projekten, diese Veränderungen müssen stetig verfolgt und entsprechende Sicherheitsaktualisierungen und Patches eingespielt werden.
Zudem sollten Sicherheitsrichtlinien und -verfahren für die Nutzung von OSS innerhalb des Unternehmens und entlang der Supply Chain umgesetzt werden. Mögliche Maßnahmen zur Gewährleistung der Einhaltung der DSGVO können spezifische Schulungen für Mitarbeiter im Bereich Datenschutz sowie Datenschutz-Folgeabschätzungen umfassen, um mögliche Risiken frühzeitig zu identifizieren und geeignete Maßnahmen zur Risikominimierung umzusetzen.
Eine ausführliche Dokumentation über die eingesetzten OSS-Komponenten sowie die ergriffenen Sicherheitsmaßnahmen sollte Standard sein. Den Verantwortlichen trifft eine gesetzliche Rechenschaftspflicht gem. Art. 5 Abs. 2 DSGVO und Art. 24 DSGVO, die Verarbeitung personenbezogener Daten ordnungsgemäß durchzuführen und dies zu dokumentieren. Es müssen daher alle datenschutzrechtlich relevanten Vorgänge lückenlos festgehalten werden.
g) Risikoeinstufung aus datenschutzrechtlicher Sicht
Angesichts der zunehmenden Bedrohung durch Cyberangriffe auf Unternehmen, insbesondere im Kontext der Nutzung von Open-Source-Software in der Supply Chain, ist es von entscheidender Bedeutung, die Grundsätze des Datenschutzrechts strikt zu beachten.
Vor allem durch das in Art. 5 Abs. 2 und Art. 24 DSGVO verankerte Rechenschaftsprinzips ist es in der Praxis unerlässlich, eine lückenlose Dokumentation aller datenschutzrelevanten Vorgänge zu führen, um diese zur Minimierung von Haftungsrisiken in späteren gerichtlichen oder aufsichtsbehördlichen Verfahren als Beweismittel verwenden zu können.
Darüber hinaus können Haftungsrisiken auch aus einer unzureichenden Datenschutz-Compliance entstehen. Zwar bieten Zertifizierungen und Verhaltensregeln keine vollständige Haftungsfreistellung, sie können jedoch dazu beitragen, Schwachstellen aufzudecken und das Haftungsrisiko zu mindern.
Angesichts der zunehmenden Cyberangriffe und den wirtschaftlichen Auswirkungen wird die Etablierung eines Cybersicherheitssystems zur zentralen Aufgabe der Geschäftsleitung. Dies sollte Teil einer umfassenden Cyber-Compliance-Strategie sein, um Datenschutzanforderungen zu erfüllen.
Insgesamt sollte Cyber-Security aus datenschutzrechtlicher Sicht höchste Priorität bei den Verantwortlichen genießen, da die Gefahren und wirtschaftlichen Folgen von Cyberangriffen massiv sein können. Nur eine sorgfältige Auseinandersetzung mit den rechtlichen Anforderungen und die Umsetzung angemessener Risikominimierungsmaßnahmen können Organmitglieder aktiv Schutz vor Haftungsansprüchen bieten und die Sicherheit ihres Unternehmens gewährleisten.
3. IT-Sicherheitsrecht
a) Einleitung zum IT-Sicherheitsrecht
Grundsätzlich sollte jedes Unternehmen sein eigenes Cyber-Sicherheitskonzept wählen und je nach Geschäftsmodell und Betätigungsfeld eine individuelle Cyber Security Governance entwickeln und implementieren. Im Anwendungsbereich des IT-Sicherheitsrecht ergeben sich jedoch konkrete rechtliche Anforderungen an die Cyber-Security-Organisation des betroffenen Unternehmens.
Da IT-Sicherheit nicht an nationalen Grenzen haltmacht, ist dieses Rechtsgebiet bestimmungsgemäß durch europäische Rechtsakte beeinflusst und ständig im Wandel. Erst kürzlich, am 16. 1. 2023, trat die überarbeitete Version eines zentralen europäischen Rechtsakts, der sog. NIS-Richtlinie45 in Kraft.
Solche Neuerungen auf EU-Ebene sind in einem weiteren Schritt in die maßgeblichen nationalen Kodifizierungen, insbesondere in das BSIG,46 zu überführen, wie zuletzt anlässlich des IT-Sicherheitsgesetzes 2.0 am 28. 5. 202147 und demnächst im Zuge der Umsetzung der oben erwähnten NIS-2-Richtlinie. Ein entsprechender Referentenentwurf des Bundesinnenministerium liegt bereits vor.48
b) Anwendungsbereich
Nicht alle Unternehmen unterfallen den Vorgaben des IT-Sicherheitsrechts. Die Anwendung dieses Rechtsgebiets ist sachlich auf einen bestimmten, in sich abgestuften Adressatenkreis beschränkt. Auf europäischer Ebene spricht man dabei von den sogenannten wesentlichen und wichtigen Einrichtungen, auf nationaler Ebene von den Betreibern kritischer Infrastrukturen (KRITIS)49 bzw. Unternehmen im besonderen öffentlichen Interesse (UBI).50 Diese erst vor Kurzem durch das IT-Sicherheitsgesetzes 2.0 eingeführte Adressatenstruktur wird allerdings schon bald wieder durch das künftig zu erlassende NIS2UmsuCG jedenfalls als eigenständige Adressatengruppe abgeschafft. Zu den Betreibern kritischer Infrastrukturen (künftig gem. § 28 Abs. 1 BSIG-E: Betreiber kritischer Anlagen) gesellen sich dann die besonders wichtigen Einrichtungen (§ 28 Abs. 6 BSIG-E) und die wichtigen Einrichtungen (§ 28 Abs. 7 BSIG-E). Die gerade erst eingeführten Unternehmen im besonderen öffentlichen Interesse gehen dabei größtenteils in der Kategorie der wichtigen Einrichtungen auf.
Grundsätzlich fallen jedenfalls nach Wertung des Gesetz- bzw. Richtliniengebers solche Einrichtungen in den Anwendungsbereich, die wesentliche Dienste in Schlüsselsektoren erbringen, deren Ausfall oder Beeinträchtigung die Sicherheit bzw. das reibungslose Funktionieren von Wirtschaft und Gesellschaft gefährden könnte.
Laut § 30 Abs. 1 BSIG-E hat daher ein Unternehmen im regulierten Bereich geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen zu ergreifen, um Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit der informationstechnischen Systeme, Komponenten und Prozesse, die sie für die Erbringung ihrer Dienste nutzen, zu vermeiden. Weiter konkretisiert wird diese Verpflichtung neuerdings durch die aus der NIS-2-Richtlinie unverändert entnommenen Liste der Mindestvorgaben für technische und organisatorische Maßnahmen in § 30 Abs. 4 BSIG-E. Überdies soll gem. § 30 Abs. 2 BSIG-E bei Einsatz dieser Maßnahmen der Stand der Technik, welcher regelmäßig in branchenspezifischen Standards definiert wird,51 eingehalten werden.
c) Einsatz von Open-Source-Software im Anwendungsbereich des IT-Sicherheitsrechts
Das Management eines Unternehmens im regulierten Bereich trifft eine Reihe von Pflichten, die je nach Adressatenkategorie einen besonderen Qualitätsgrad erreichen können. Vor diesem Hintergrund erscheint es ratsam, den Einsatz bestimmter Technologien vorab gründlich zu prüfen, insbesondere mit Hinblick auf die Tatsache, dass der Schutz anfälliger Lieferketten nunmehr gesetzlich verpflichtend verankert wurde.
Gemäß § 30 Abs. 4 Nr. 4 BSIG-E besteht nunmehr das Erfordernis, dass solche nach § 30 Abs. 1 BSIG-E zu ergreifende Maßnahmen die Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern umfassen müssen. Konkretisiert wird diese Vorgabe ferner durch § 30 Abs. 8 BSIG-E, wonach die Verantwortlichen betroffener Unternehmen beim Einsatz der geeigneten Maßnahmen (1) die spezifischen Schwachstellen der einzelnen Anbieter, (2) die Gesamtqualität der Produkte und (3) die vom jeweiligen Anbieter gelebte Cybersicherheitspraxis einschließlich der Sicherheit der Entwicklungsprozesse berücksichtigen müssen. Sollte überdies mit Hinblick auf ein bestimmtes IKT-Produkt eine koordinierte Risikobewertung der Lieferketten gemäß Art. 22 Abs. 1 NIS-2-Richtlinie vorliegen,52 so müssen auch diese Erkenntnisse bei der Implementierung geeigneter Maßnahmen ausdrücklich berücksichtigt werden.
Das Problem anfälliger Lieferketten erfährt somit sowohl in der NIS-2-Richtlinie als auch um NIS2UmsucG einen besonderen Stellenwert einschließlich einer beachtlichen Regelungstiefe. Dies mag auf den ersten Blick ein großer Schritt in die richtige Richtung sein, in der Praxis wird der Anwender jedoch auch künftig nicht auf bewährte technische Standards im Einklang mit dem jeweiligen Stand der Technik verzichten können.
d) Software-Supply-Chain als besonderes Angriffsziel
Bei „Stand der Technik“ handelt es sich um einen dynamischen, unbestimmten Rechtsbegriff, dessen Ausgestaltung durch entsprechende Expertenkreise fortentwickelt wird53 und der auch immer nur für einen bestimmten Sachbereich definiert werden kann.54 Interessant ist in diesem Zusammenhang, dass § 30 Abs. 2 BSIG-E im Gegensatz zur parallelen Regelung in Art. 21 Abs. 1, Unterabs. 2 NIS-2-Richtlinie eine Einhaltung des Stands der Technik und nicht lediglich eine Berücksichtigung55 fordert. Damit räumt der deutsche Gesetzentwurf dem Stand der Technik einen besonderen Stellenwert ein und geht damit über die Forderung der NIS-2-Richtlinie hinaus. Tatsächlich kann nur mithilfe dieser Öffnungsregelung die sich dynamisch weiterentwickelnden Methoden im Bereich der IT-Sicherheit angemessen berücksichtigt werden.
Insbesondere im Bereich der Beschaffung von (Open-Source)-Software finden Entscheidungsträger bereits konkrete Antworten auf ihre Fragen. In diesem Umfeld hat sich bereits eine Reihe dezidierter Maßnahmen bewährt, welche gerade die Aufspürbarkeit von Sicherheitslücken in der Software-Supply-Chain sicherstellen sollen. Hervorzuheben wäre in diesem Zusammenhang die Installation eines Riskmanagements und die Entwicklung von Sicherheitsstrategien zur Identifizierung, Bewertung und Mitigation von Schwachstellen in der Versorgungskette. Dies beinhaltet die Implementierung von Best Practices und den Einsatz spezifischer Tools und Techniken:
- Abgleich mit Schwachstellendatenbanken: Diese Datenbanken beinhalten Informationen darüber, welche Schwachstellen in welchen Versionen vorhanden und wie diese zu kategorisieren sind. Je nach Qualität dieser Datenbanken kann auch vor bereits bekannten Exploits gewarnt werden. Letzteres dürfte der Priorisierung in der Entwicklung sehr helfen.
- Prinzip der geringsten Privilegien: Moderne Software ist heute modular aufgebaut. Um also zu verhindern, dass eine schädliche Open-Source-Drittanbieterkomponente möglicherweise auf andere Module überspringt, oder gar auf das Betriebssystem, sollten die einzelnen Module nur mit den nötigsten Privilegien ausgestattet sein.
- Statische und Dynamische Codeanalyse (SAST und DAST): Mit diesen Techniken bzw. den richtigen Werkzeugen hierzu lässt sich Software noch während der Entwicklung auf ihre Robustheit prüfen. Beim Einsatz von Open-Source-Abhängigkeiten Dritter könnte genau hier eine Codeanalyse zur erfolgreichen Abwehr führen. Schadhafter Code, der nicht in das System gehört, könnte durch solche Analysen auffallen, bevor weiterer Schaden im Betrieb entsteht.
- Regelmäßige Penetrationstest (Sicherheitsanalysen) durch Experten: Neben den Methoden zur Überprüfung der Software, sollten eventuelle Schwachstellen im System mithilfe einer echten Angriffssimulation aufgedeckt werden. Dazu eignet sich vor allem ein sog. Penetrationstest, bei dem ein typischer Angriff im kontrollierten Umfeld auf ein oder mehrere Zielsysteme durchgeführt wird.
- Aufbau eines Incident-Response-Plans: Das Risiko, Schadcode über eine schädliche Open-Source-Drittanbietersoftware in die eigene Software zu implementieren, lässt sich nie vollständig ausschließen. Aus diesem Grund sollte sich jedes Unternehmen mit Hilfe eines Incident-Response-Plans für den Ernstfall vorbereiten.
- Weitere Maßnahmen wie beispielsweise die Einrichtung eines Source-Code-Control-Systems (SCCS) und insbesondere die Erstellung einer sog. Software Bill of Materials (SBoM).56
Man kann somit festhalten: Für Adressaten des IT-Sicherheitsrechts ergibt sich nicht zuletzt durch die Neuerungen im NIS2UmsuCG eine hinreichend klare Verpflichtung zur Implementierung konkreter Maßnahmen bei der Verwendung von Open-Source-Produkten. Diese Verpflichtung bekommt eine umso Bedeutung, wenn man bedenkt, dass Verstöße dagegen mit immer empfindlicheren Sanktionen belegt werden.
e) Sanktionen im Falle eines Verstoßes
aa) Gegenwärtige rechtliche Situation nach BSIG
Mit welchen Folgen ein KRITIS-Unternehmen oder UBI im Falle eines Verstoßes zu rechnen hat, ergibt sich aus dem recht komplexen Bußgeldkatalog in § 14 BSIG. Demgemäß droht z. B. einem KRITIS-Unternehmen, das entgegen § 8a Abs. 1 BSIG keine angemessenen technischen und organisatorischen Maßnahmen implementiert bzw. dies dem BSI nicht ordnungsgemäß nachgewiesen hat, ein Bußgeld gemäß 14 Abs. 1 BSIG.
Was die Höhe dieses Bußgeldes angeht, so wurde diesbezüglich erst kürzlich die gesetzliche Obergrenze durch das IT-Sicherheitsgesetz 2.0 von bisher maximal 100 000 € auf bis zu 20 Mio. € heraufgesetzt (vgl. § 14 V 3 BSIG, § 30 Abs. 2 S. 3 OWiG),57 wobei sich dieser Bußgeldrahmen im Anwendungsbereich der Unternehmen im besonderen öffentlichen Interesse auf 500 000 € herabsenkt. Für das KRITIS-Unternehmen aus dem obigen Beispiel bedeutet dies, dass es als juristische Person im schlimmsten Fall mit einer Verzehnfachung des in § 14 Abs. 5 S. 1 angedrohten Höchstmaß der Geldbuße von 1 Mio. € rechnen müsste, in unserem Fall also 10 Mio. €.
bb) Künftige rechtliche Situation – das Sanktionsregime im BSIG-E
Dieser Bußgeldrahmen war wohl aus Sicht des Europäischen Gesetzgebers immer noch nicht abschreckend genug.
Im Gegensatz zur Vorgängerrichtlinie wurde daher der Bußgeldrahmen durch Art. 34 Abs. 4 und 5 NIS-2-Richtlinie konkret festgesetzt. Bei einem Verstoß gegen die Pflicht zur Implementierung technischer und organisatorischer Maßnahmen gem. Art. 21 NIS-2-Richtlinie sollten sowohl die Betreiber von wesentlichen als auch von wichtigen Einrichtungen fortan mit empfindlichen Geldbußen von bis zu 2 %, respektive bis zu 1,4 % des weltweiten Konzernumsatzes zu rechnen haben. Diese Vorgaben finden sich nun auch unverändert in § 60 Abs. 2 Nr. 2, Abs. 6 u. Abs. 7 BSIG-E wieder.
Gleiches gilt für die Vorgabe der Richtlinie, dass auch Angehörige des Managements wesentlicher und wichtiger Einrichtungen bei Nicht-Einhaltung von Risikomanagementmaßnahmen gemäß Art. 21 NIS-2-Richtlinie persönlich in die Haftung genommen werden sollen. § 38 Abs. 1 BSIG-E bestimmt, dass Geschäftsleiter besonders wichtiger Einrichtungen58 und wichtiger Einrichtungen verpflichtet sind, Risikomanagementmaßnahmen im Bereich der Cybersicherheit zu billigen und ihre Umsetzung zu überwachen. Bei Verletzung dieser Verpflichtung haften Geschäftsleiter der Einrichtung künftig gemäß § 38 Abs. 2 BSIG-E59 persönlich für den hierdurch entstandenen Schaden. Laut Begründung zum NIS2UmsuCG-E sollen vom Schadensbegriff dieser Haftungsnorm sowohl Regressforderungen als auch gegen das Unternehmen verhängte Bußgelder erfasst sein.60 Dies ist bemerkenswert, bedenkt man, dass die Regressfähigkeit von Unternehmensbußen gegenüber Organmitgliedern höchst umstritten ist,61 bzw. seitens der Rechtsprechung unter Hinweis auf den Sanktionscharakter der Geldbuße abgelehnt wird.62 Verschärfend kommt im vorliegenden Falle hinzu, dass gemäß § 38 Abs. 3 BSIG-E ein Verzicht des Unternehmens auf Ersatzansprüche gegen die Unternehmensleitung oder ein Vergleich über diese Ansprüche unwirksam ist.63
Nicht zuletzt aus diesen Gründen bestimmt der Gesetzgeber gemäß § 38 Abs. 4 BSIG-E, dass Geschäftsleiter regelmäßig an Schulungen teilnehmen, um ausreichende Kenntnisse und Fähigkeiten zur Erkennung und Bewertung von Risiken sowie Risikomanagementpraktiken im Bereich der Cybersicherheit und deren Auswirkungen auf die von der Einrichtung erbrachten Dienste zu erwerben.
Darüber hinaus wird das BSI64 als zuständige Behörde künftig ermächtigt sein, die verantwortlichen Vorstände bzw. Geschäftsführer besonders wichtiger Einrichtungen gemäß § 64 Abs. 6 Nr. 2 BSIG-E vorübergehend von ihren Leitungsaufgaben zu entbinden, sofern diese Anordnungen des BSI nach dem BSIG nicht befolgen sollten.
Unternehmen, die in den Anwendungsbereich des BSIG fallen, sind somit in Zukunft gut beraten, bei der Auswahl der von ihnen verwendeten Software-Produkte eine besondere Sorgfalt walten zu lassen. Dieses Sorgfaltsgebot schließt die Beachtung und Implementierung aller nach gegenwärtigem Stand der Technik möglichen und zumutbaren Maßnahmen mit ein. Insbesondere, wenn man bedenkt, dass gerade die Risikoanfälligkeit von Lieferketten in § 30 Abs. 4 Nr. 4 BSIG-E eine besondere Berücksichtigung erfahren hat. Sollte beispielsweise der Vorstand eines als besonders wichtige Einrichtung einzustufenden Unternehmens keine oder nur unzulängliche Maßnahmen zur Gewährleitung der Lieferkettensicherheit getroffen haben, müssten sowohl das Unternehmen als auch der Vorstand persönlich gemäß § 60 Abs. 2 Nr. 2 und Abs. 7 BSIG-E i. V. m. §§ 30 Abs. 1 und Abs. 4 Nr. 4, 38 Abs. 2 BSIG-E schlimmstenfalls mit Geldbußen von bis zu 2 % des globalen Jahresumsatzes des Unternehmens rechnen.
cc) Vorteile von Open-Source-Software
Trotz der oben festgestellten Widrigkeiten nutzen mittlerweile 69 % der Unternehmen Open Source Anwendungen65. Von Anwendern wird Open-Source-Software als ebenso sicher oder sogar sicherer als proprietäre Anwendungen angesehen.
Die meistgenannten Vorteile von Open Source in Bezug auf die Sicherheit von Open Source sind: eine gute Code-Qualität, gute Verfügbarkeit und Dokumentation von Sicherheitspatches, die Möglichkeit einer Vorab-Prüfung des Codes und schließlich die Tatsache, dass eine Großzahl von Entwicklern den Code immer wieder testen und ggf. ausbessern. Dies hat auch der Europäische Gesetzgeber erkannt66 und regt offen zu einer Förderung von Open-Source-Projekten durch die Mitgliedstaaten an.
f) Mehr Rechtssicherheit durch Zertifizierung?
Angesichts dieser Erkenntnisse befinden sich Vorstände und IT-Verantwortliche von Unternehmen im regulierten Bereich zunehmend in der Zwickmühle, ob sie nun besser auf Nummer sicher gehen und auf einen Einsatz von Open-Source gänzlich verzichten oder doch die dargelegten Risiken eines Einsatzes von Open-Source-Produkten in Kauf nehmen sollen. Aus den dargestellten Gründen können solche Entscheidungen den Verantwortlichen eines traditionell geführten Unternehmens kaum mehr zugemutet werden, weshalb bereits von mehreren Seiten die Einführung eines eigenen Vorstandressort für IT-Sicherheitsfragen empfohlen wird.67
Für mehr Rechtssicherheit in diesem Zusammenhang sorgen ferner Zertifizierungsstandards für solche, in wesentlichen und wichtigen Einrichtungen eingesetzten Informations- und Kommunikationstechnologien („IKT-Produkte“). Eine Zertifizierung stellt hierbei sicher, dass die Architektur, das Anforderungsmanagement, das Konfigurationsmanagement und das Risikomanagement der Software für einen sicheren Entwicklungs- und vor allem Fehlerbehebungsprozess geeignet sind. Art. 24 NIS-2-Richtlinie regt insofern an, eine gesetzliche Verpflichtung zur Verwendung solcher gemäß Art. 49 EU-Cybersecurity Act68 zertifizierte IKT-Produkte in wesentlichen und wichtigen Einrichtungen auf nationaler Eben zu etablieren.69 Daneben ist aber auch die Kommission gemäß Art. 38 NIS-2-Richtlinie dazu ermächtigt, delegierte Rechtsakte erlassen, die festlegen, welche Kategorien wesentlicher und wichtiger Einrichtungen verpflichtet sind, bestimmte zertifizierte IKT-Produkte zu nutzen bzw. welche Produkte eine entsprechende Zertifizierung erlangen müssen.
Die International Organization for Standardization (ISO) war insofern mit der kürzlich erfolgen Veröffentlichung der ISO/IEC 5230:2020 schon einen Schritt weiter. Dieser Standard enthält nunmehr die wichtigsten Anforderungen an ein hochwertiges Open-Source-Lizenz-Compliance-Programm und konzentriert sich unter anderem auf die Festlegung von Maßnahmen zur Absicherung von Software-Lieferketten. Interessanterweise sieht diese Maßnahmenliste neben vielen anderen Erfordernissen auch die Erstellung einer SBoM vor, was wie oben bereits dargelegt, nach Stand der Technik als eines der wichtigsten Instrumente zur Aufdeckung von Sicherheitslücken angesehen wird.
IV. Fazit und Ausblick
Der Einsatz von Open-Source-Produkten innerhalb der IT-Architektur eines Unternehmens birgt sowohl Vor- als auch Nachteile. Auch wenn nach Auffassung der Europäischen Normgebers und den Fachkreisen Open Source die Zukunft gehören dürfte, sehen sich Anwender und Verantwortliche in Unternehmen gegenwärtig noch der Herausforderung ausgesetzt, im konkreten Einzelfall für ihr Unternehmen die richtige Entscheidung zu treffen.
Hierbei sind Vorstände von Unternehmen sowohl im regulierten als auch im nicht-regulierten Bereich generell gehalten, den Einsatz von Open-Source-Produkten unter besonderer Berücksichtigung der IT-Sicherheitslage zu prüfen und dabei die ihnen zur Verfügung stehenden Erkenntnisquellen im Einklang mit dem Stand der Technik sorgfältig auszunutzen.
Im regulierten Bereich erhält diese Verpflichtung indes angesichts detaillierterer Vorgaben und unmissverständlich formulierter Haftungsregelungen einen weitaus höheren Stellenwert. Man könnte sogar sagen, dass der deutsche Gesetzgeber nicht zuletzt mit seiner Begründung zu § 38 Abs. 2 BSIG-E bzgl. der Regressfähigkeit von Unternehmensgeldbußen das Tor zu einer völlig neuen Haftungsdimension aufgestoßen hat.
Im Falle der Verwendung von Open-Source-Produkten ist daher gerade im regulierten Bereich verstärkt darauf zu achten, dass die branchenüblichen technischen und organisatorischen Maßnahmen implementiert werden,70 bzw. bei den zu beschaffenden Open-Source-Produkten eine Zertifizierung nach ISO/IEC 5230:2020 vorliegt.
1 Siehe hierzu Sonatype Pressemeldung vom 20. 9. 2022, https://www.sonatype.com/press-releases/sonatype-finds-700-average-increase-in-open-source-supply-chain-attacks.
2 Siehe hierzu Ziffern 2. und 3.
3 LG Berlin, 3.7.2002 – 2 O 358/01, BKR 2002, 970; Koch, in: Koch, Aktiengesetz, 16. Aufl. 2022, § 91 Rn. 4; vgl. auch OLG Zweibrücken, 27. 10. 2022 – 4 U 198/21, jedoch ohne weitere Ausführung zur Frage ob fehlende Präventivmaßnahmen bereits eine Organhaftung auslösen können, hierzu auch Versteyl/El-Taki, NJW 2023, 1548.
4 Siehe Streitstand bei Fleischer, in Beck Online-Großkommentar, 1. 7. 2022, AktG § 91 Rn. 41; siehe auch bei Frank/Petersen/Bernzen, CR 2022, 758; v. Holleben/Menz, CR 2010, 63 – Mehrheitlich dürfte dies mit Hinweis auf die Kommentierung in den Gesetzesmaterialien zu § 91 Abs. 2 AktG, wo von einer Ausstrahlungswirkung auf den Pflichtenrahmen der Geschäftsführer anderer Gesellschaftsformen die Rede ist, befürwortet werden.
5 Frank/Petersen/Bernzen, CR 2022, 759.
6 LG München, 5. 4. 2007 – 5 HKO 15964/06, CR 2007, 423.
7 Spindler, CR 2017, 717.
8 v. Holleben/Menz. CR 2010, 68.
9 Spindler, CR 2017, 722; v. Holleben/Menz, CR 2010, 65.
10 Im regulierten Bereich ergibt sich die Verpflichtung zur Berücksichtigung bzw. Einhaltung des Stands der Technik direkt aus dem Gesetz (vgl. Art. 32 Abs. 1 DSGVO bzw. § 30 Abs. 2 BSIG-E).
11 Insbesondere BSI-Grundschutz und ISO/IEC 27001.
12 Spindler, CR 2017, 722.
13 Neben einer Zertifizierung nach ISO/EIC 27001 käme bei der Verwendung von Open-Source-Software noch die Zertifizierung nach ISO/IEC 5230:2020 in Betracht, näheres hierzu unter Ziffer III. 3 c)
14 LG München I, 10. 12. 2013 – 5 HKO 1387/10, NZG 2014, 345 f.
15 Löschhorn/Fuhrmann, NZG 2019, 163.
16 OLG Dresden, 30. 11. 2021 – 4 U 1158/21, NZG 2022, 335.
17 Zur Frage der Haftung der Gesellschaft selbst vgl. EuGH, 5.12.2023 – C-807/21 – Deutsche Wohnen SE.
18 Spindler, in: MüKo Aktiengesetz, 6. A., 2023,, § 91 Rn. 21.
19 Jandt, in: Kühling/Buchner, DSGVO BDSG, 2. Aufl. 2018, Art. 32 Rn. 5.
20 Siehe dazu unten unter Ziffer 3), IT-Sicherheitsrecht.
21 Jandt, in: Kühling/Buchner, DSGVO BDSG (Fn. 18), Art. 32 Rn. 30.
22 Martini, in: Paal/Pauly, DSGVO BDSG, 3. A., 2021, , Art. 31 Rn. 51.
23 EuGH, 4. 5. 2023 – C-300/21, K&R 2023, 416 ff.
24 OLG Dresden, 14.12.2021 – 4 U 1278/21, ZD 2022, 235; OLG Brandenburg, 11.8.2021 – 1 U 69/20, ZD 2021, 693, Rn. 3; OLG Bremen, 16.07.2021 - 1 W 18/21, ZD 2021, 652; LAG Baden-Württemberg, 25.2.2021 – 17 Sa 37/20, ZD 2021, 436, Rn. 82.
25 EuGH, 4.5.2023 – C-300/21, K&R 2023, 416 – Österreichische Post; Vorlage des OGH Österreich, 4.5.2023 – C-300/21, ZD 2021, 631.
26 Zuvor wurde die Frage, ob der Datenverlust an sich, ein Kontrollverlust oder ein unangenehmes Gefühl einen ausreichenden Schaden darstellen und sog. Bagatellschäden auszuschließen sind, von zahlreichen Gerichten unterschiedlich beurteilt bzw. offengelassen (vgl. hierzu BVerfG, 14.1.2021 – 1 BvR 2853/19, NJW 2021, 1005).
27 EuGH, 4.5.2023 – C-300/21, K&R 2023, 416, Rn. 49 – Österreichische Post.
28 Vgl. hierzu Paal, MMR 2020, 14, 16.
29 Vgl. Paal, MMR 2020, 14, 16.
30 S. etwa Peitz/Schweitzer, NJW 2018, 275.
31 S. Wandtke, MMR 2017, 6.
32 Dickmann, r+s 2018, 345, 350 „Kommerzialisierungsvermutung“; Kohn, ZD 2019, 498, 501.
33 Bergt, in: Kühling/Buchner, DSGVO/BDSG (Fn. 18), Art. 82 DSGVO Rn. 19; Paal, MMR 2020, 14, 16.
34 Quaas, in: BeckOK-DSGVO, 46. Ed., 2023, Art. 82 Rn. 18: „Hackerangriffe oder Datenlecks entlasten nur, wenn der Verantwortliche die übliche Sorgfalt zum Schutz der Daten angewendet. Zu berücksichtigen ist in diesem Fall, dass die DSGVO nicht erfordert, alle theoretisch möglichen Schutzvorkehrungen vorzusehen.“
35 LG Saarbrücken, 22.11.2021 – 5 O 151/19: EuGH-Vorlage zum Anspruch auf Ersatz immaterieller Schäden aus Art. 82 DSGVO, ZD 2022, 162.
36 Zur teilweise in der Literatur vertretenen Ansicht, es handele sich um eine Gefährdungshaftung mit einem rechtsvernichtenden Einwand nach Abs. 3, vgl. Quaas, in: BeckOK-DSGVO (Fn. 34), Art. 82 Rn. 17.1.
37 Quaas, in: BeckOK-DSGVO (Fn. 33), Art. 82 Rn. 19; Vgl. auch Wybitul/Haß/Albrecht, NJW 2018, 113, 117 f.
38 Vgl. Quaas, in: BeckOK-DSGVO (Fn. 34), Art. 82 Rn. 20: „Für eine Anwendung spricht die Einordnung des Art. 82 als deliktischer Anspruch, der durch die allgemeinen Regelungen des Deliktsrechte ergänzt wird, dagegen sprechen die datenschutzrechtlichen Sonderreglungen mit Organisationspflichten, die hierdurch ausgehebelt werden sowie der von Art. 82 beabsichtigte wirkungsvolle und umfassende Schadensersatz.
39 Vgl. Quaas, in: BeckOK-DSGVO (Fn. 34), Art. 82 Rn. 21: Ihm kommt „gerade im Interesse des Verantwortlichen die Aufgabe der Sicherstellung der datenschutzrechtlichen Regelungen zu. Eine Exculpation durch den Nachweis ordnungsgemäßer Auswahl des Datenschutzbeauftragten stünde zudem im Widerspruch mit dem Grundsatz des effektiven Schadensersatzes, den Art. 82 gewährleisten soll (vgl. Erwägungsgrund 146)“.
40 Quaas, in: BeckOK-DSGVO (Fn. 34), Art. 82 Rn. 43: Er kann sich von dieser Haftung nur befreien, wenn er nachweist, dass der Umstand, durch den der Schaden eingetreten ist, ihm nicht zur Last gelegt werden kann.
41 Frenzel, in: Paal/Pauly, DSGVO BDSG (Fn. 21), Art. 83 Rn. 14; Rodowski/Nowak; in. BeckOK DatenschutzR BDSG 46. Ed., 2023, § 41 Rn. 17.
42 Boms, ZD 2019, 536, 537.
43 Boehm, in: Simitis / Hornung / Spiecker gen. Döhmann, Datenschutzrecht, 2. A., 2024, , Art. 83 Rn. 26.
44 Frenzel, in: Paal/Pauly, DSGVO BDSG (Fn. 21), Art. 83 Rn. 14; Boms, ZD 2019, 536, 537.
45 RL (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. 12. 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union, zur Änderung der VO (EU) Nr. 910/2014 und der RL (EU) 2018/1972 sowie zur Aufhebung der RL (EU) 2016/1148) (NIS-2-Richtline).
46 Gesetz über das Bundesamt für Sicherheit in der Informationstechnik.
47 Siehe ausführliche Darstellung zum IT-Sicherheitsgesetz 2.0: Schallbruch, CR 2021, 450 u. 517.
48 Referentenentwurf des Bundesministeriums des Innern und für Heimat eines Gesetzes zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung („NIS2UmsuCG-E“), Fassung vom 2. 7. 2023.
49 Zu den sog. KRITIS gehören derzeit gem. § 2 Abs. 10 Nr. 1 BSIG die folgenden Sektoren: Energie, Wasser, Ernährung, Informationstechnik und Telekommunikation, Gesundheit, Finanz- und Versicherungswesen, Transport und Verkehr, Staat und Verwaltung, Siedlungsabfallentsorgung sowie Medien und Kultur.
50 Zu den Unternehmen im besonderen öffentlichen Interesse siehe: Nardone, ITRB 2022, 19.
51 Bundesverband IT-Sicherheit e. V. (TeleTrusT) – Handreichung zum Stand der Technik – Technische und organisatorische Maßnahmen.
52 Gemäß Art. 22 Abs. 1 NIS-2-Richtlinie kann eine Risikobewertung bestimmter kritischer IKT-Produkte durchgeführt werden.
53 Siehe zum z. B.: TeleTrusT – Handreichung zum Stand der Technik – Technische und organisatorische Maßnahmen, 2021.
54 Werner/Brinker/Raabe, CR 2022, 824: „Einen generellen Stand der Technik zur Gewährleistung der IT-Sicherheit“ kann es hingegen nicht geben…“.
55 Zum Begriff der Berücksichtigung des Stands der Technik vgl. Werner/Brinker/Raabe, CR 2022, 824.
56 Hierbei handelt es sich um ein, mithilfe eines Software Composition Analysis Tools erstelltes, Inventar der Codebasis einer Software, unter Angabe aller identifizierbaren Komponenten samt ihrer Lizenz- und Versionsinformationen sowie aller eventuell vorhandenen Sicherheitslücken. Weitere Informationen zur SBoM unter: https://www.datacenter-insider.de/was-ist-sbom–software-bill-of-materials-a-fec098925174be7bc1e799bbb18105d2/.
57 Hierzu Hornung, NJW 2021, 1991.
58 Über § 28 Abs. 3 Nr. 4 BSIG-E zählen auch Betreiber kritischer Anlagen zu den besonders wichtigen Einrichtungen.
59 Insofern dürfte § 38 Abs. 2 BSIG-E weniger als eigenständige Anspruchsgrundlage zu verstehen sein, sondern vielmehr als konkretisierende Compliance-Vorschrift, welche im Rahmen einer Haftung z. B. gemäß § 93 Abs. 2 AktG herangezogen wird.
60 Siehe Begründung zu § 38 Abs. 2 NIS2UmsuCG-E, Version vom 2. 7. 2023, 118.
61 Ablehnend jedenfalls im Falle von Kartellgeldbußen: Leclerc, NZKart 2021, 220; Suchy, NZG 2015, 592; differenzierter: Werner, CCZ, 2010, 143.
62 LAG Düsseldorf, 20.1.2015 –16 Sa 459/14, NZG 2015, 599.
63 Sollten durch die Cyber-Attacke personenbezogene Haftung betroffen gewesen sein, trifft das verarbeitende Unternehmen darüber hinaus auch noch die Beweisleist dafür, dass die von ihm getroffenen Schutzmaßnahmen tatsächlich geeignet waren – vgl. EuGH, 14. 12. 2023 – C 340/21, K&R 2024, ■ ff. (in diesem Heft).
64 Bundesamt für Sicherheit in der Informationstechnik.
65 Siehe hierzu Bitkom, Open Source Monitor – Studienbericht 2023, Seite 22, abgerufen über: https://www.pwc.de/de/digitale-transformation/bitkom-open-source-monitor-2023.pdf.
66 Siehe zum Einsatz von OSS als Sicherheitssoftware: ErwG 52 NIS-2-Richlinie. Diese Privilegierung von OSS Produkten zeigt sich auch anhand der aktuellen Diskussion darüber ob OSS Produkte unter den künftig zu erlassenden Cyber Resilience Act fallen sollen, hierzu Poncza, ZfPC 2023, 44 (46).
67 Bspw. Schreiber/Basar, Deutscher AnwaltSpiegel, Online-Ausgabe 11 v. 24. 5. 2023, 7.
68 VO (EU) 2019/881 des Europäischen Parlaments und des Rates vom 17. 4. 2019 über die ENISA (Agentur der Europäischen Union für Cybersicherheit) und über die Zertifizierung der Cybersicherheit von Informations- und Kommunikationstechnik und zur Aufhebung der VO (EU) Nr. 526/2013.
69 Siehe hierzu auch ErwG 80 NIS-2-Richtlinie.
70 Zu den bei einer Implementierung von Drittsoftware zu ergreifenden Maßnahmen siehe TeleTrusT – Handreichung zum Stand der Technik, S. 84.
