(TLDR – Text zu lang? Ganz unten als letzten Abschnitt gibt es eine Zusammenfassung.)
Der Bundesparteitag möge folgendes Positionspapier beschließen:
Dieses Konzept dreht sich um die Frage, inwiefern es Sinn macht, den Einsatz von Software und Informationssystemen (typischerweise Software + Hardware) einer Haftung der Beteiligten zu unterwerfen.
Motivation
Software an sich ist bisher im Rahmen des Produkt- und Mängelhaftung praktisch nicht von einer gesetzlichen Haftung betroffen. Warum kann es sinnvoll sein, dies zu ändern?
- Software wird immer wichtiger, die Verbreitung und die Zahl der Anwendungsfälle nimmt kontinuierlich zu
- die tatsächlichen und potenziellen Schäden durch Sicherheitslücken und deren Folgen werden immer erheblicher
- die Komplexität erschwert Anbietern, Nutzern, Käufern und Öffentlichkeit die Transparenz der Bewertung einer Software
- aktuell existiert keine grundsätzliche Folgehaftung für Softwarefehler bzw. diese wird praktisch fast immer vertraglich ausgeschlossen
- die Unterscheidung gegenüber physischen Produkten – für die eine Haftung existiert – wird zunehmend willkürlicher, da andere Produkte zunehmend Software enthalten
- die meisten kritischen Systeme (Militär, Energieversorgung, Luftfahrt, etc.) unterliegen einer Haftung, dort zeigt sich ein deutlich höheres Level an Qualitätsbewusstsein
Wirkungsbereich
Software kann am ehesten verglichen werden mit geistigen Werken wie Schriftstücken, Zeichnungen, Büchern usw. An dieser Stelle ist die Wirkung einer Haftung problematisch, da solche Werke interpretierbar sind und eine Haftung die Meinungsfreiheit einschränken könnte. Ein Quellcode kann beispielsweise in Kombination mit einem bestimmten Compiler oder Hardwareplattform sicher betrieben werden, aber sonst völlig unsicher sein. Im Vergleich zu Schriften ist die Wirkung von Software durch Automatisierung von Verbreitung und Ausführung allerdings deutlich unmittelbarer. Zum Vergleich: im Presserecht existiert auch keine allgemeine Haftung, sondern nur spezifische rechtliche Regelungen.
Daher empfiehlt sich folgende Eingrenzung:
- eine Haftung sollte beschränkt sein auf kommerziell eingesetzte Software, d. h. eine Software ist Teil eines Geschäfts mit Gewinnabsicht
- die Haftung gilt nur für sicherheitsrelevante Softwarefehler, da die Bedeutung der eigentlichen Funktionalität der Software sehr spezifisch sein kann und von den Beteiligten besser bewertet werden kann als vom Gesetzgeber
- um die Meinungsfreiheit und persönliche Freiheit zu schützen, soll die Haftung nur für den Einsatz an sich gelten, nicht für die blanke Software, z. B. in Form von Quellcode
- bestehende Haftungsregelungen für z. B. physische Produkte sollen nicht ersetzt, sondern ggf. ergänzt werden
- welcher Lizenz die Software unterliegt, spielt an dieser Stelle keine Rolle
Die Frage der Haftung wird also im Folgenden für sicherheitsrelevante Softwarefehler in kommerziell eingesetzter Software diskutiert.
Nutzungsmodell
Zunächst müssen wir allgemein definieren, von welchen Beteiligten, Zuständen und Ereignissen ausgegangen wird.
In dieser Modell gibt es Bereitsteller, Betreiber und Nutzer einer Software. Der Bereitsteller erstellt die Software und macht sie zugänglich. Betreiber ist, wer die laufende Software kontrolliert. Der Nutzer setzt die Software ein. Es muss sich dabei nicht um unterschiedliche Personen oder Organisationen handeln, z. B. im Falle von eigener, intern genutzter Software in einer Organisation.
Die Einschränkung auf kommerziell genutzte Software führt dazu, dass nicht-kommerzielle Teilnehmer aus der Betrachtung herausfallen. Nutzt eine Firma also z. B. Open-Source-Software, die von einer Community erstellt wurde, gehen die Pflichten aus der Haftung auf diese Firma über, als wäre sie der Bereitsteller. Delegiert jemand Aufgaben (gegen Geld) an eine andere Stelle, haften beide wiederum gemeinsam. So wird die Nutzung von IT-Dienstleistungen abgebildet, ohne den Auftraggeber aus der Verantwortung zu entlassen.
Hinsichtlich der Software gehen wir davon aus, dass diese bekannte oder unbekannte Sicherheitslücken enthalten kann, die in bestimmten Fällen (z. B. Remote Exploit, Local Exploit) ausgenutzt werden können oder eben nicht.
Haftungsfälle
Natürlich muss festgelegt werden, in welchen Fällen eine Haftung greifen soll. Eine pauschale Haftung für alle Sicherheitslücken erscheint aus folgenden Gründen überzogen:
- nicht jeder Hack und jede Folge einer Sicherheitslücke wird entdeckt
- Nachvollziehbarkeit und Beweisbarkeit der Folgen eines Hacks sind eingeschränkt
- es würde größere Anbieter und Betreiber bevorzugen, da diese die finanziellen Reserven für Schadenersatzzahlungen eher vorhalten können
- alle Käufer zahlen in der Folge evtl. höhere Preise für Software oder IT-Dienste aufgrund von Schadensersatzzahlungen an Einzelne; das ist zwar grundsätzlich bei jeder Haftung so, kann aber zu einem gewissen Grad auch zu einer Umverteilung zugunsten risikobehafteter Nutzer führen
- Software ist typischerweise sehr fragil, die Asymmetrie zwischen Ursache, Fehler und Wirkung kann sehr hoch sein, eine Haftung kann also auch „die Falschen“ treffen, während andere rein zufällig davonkommen
Stattdessen soll versucht werden, Szenarien zu finden, die für alle Seiten klar definierbar sind und deren Eintritt allgemein unerwünscht ist. Dazu sind eine Reihe von Kriterien denkbar:
Crypto: in dem meisten Fällen dürfte es einfach sein, die z. B. für eine Übertragung verwendete Kryptographie (Verschlüsselung, Prüfsummen) festzustellen. Typischerweise ist öffentlich bekannt bzw. kann sogar bewiesen werden, dass die verwendete Technik ggf. unsicher ist. Angesichts der Relevanz von Kryptographie sollte diese genutzt werden, um mathematisch gebrochene oder zu schwache Kryptographie ins Fadenkreuz zu nehmen (auch unabhängig vom Kriterium Blacklist).
Whitelist: eine Liste mit zulässigen Techniken ist abzulehnen, da diese sehr umfangreich und differenziert sein müsste und dennoch die Entwicklung und Innovation in diesem Bereich hemmen würde. Außerdem könnte eine veraltete Liste in einzelnen Bereichen die Verwendung von unzureichenden Maßnahmen oder Techniken vorschreiben, wenn sich der Stand der Technik schneller ändert als die Liste.
Blacklist: wiederum die Verwendung von veralteten und als unsicher bekannten Techniken als haftungsrelevant zu definieren, umgeht die Probleme einer Whitelist. Derartige „IT-Zombies“ (z. B. veraltete Softwareversionen, alte Crypto, unsichere Protokolle) halten sich oft lange, da ihre Beseitigung mit Aufwand und Kosten verbunden ist. Eine Haftung kann hier für Bewegung sorgen. Wenn eine offiziellen Stelle (z. B. BSI) für die Blacklist verantwortlich ist, stellt sich natürlich die Vertrauensfrage. Offizielle Stellen sollten daher an ihr eigenes Regelwerk vollständig gebunden sein. Die Regierung kann AES oder PGP schlecht verbieten, wenn sie es dann selbst nicht mehr einsetzen darf.
Stand der Technik: es erscheint naheliegend, den Stand der Technik wie in anderen technischen Bereichen per Gesetz vorzuschreiben. Dies bringt jedoch auch Probleme mit sich. Was ist der Stand der Technik und welche Maßnahmen sind für einen Haftungsfall angemessen? Zudem kann die Vorgabe zu Strukturkonservatismus führen, da modernere Techniken den Status Quo (z. B. aufgrund von Normen) evtl. nicht ersetzen können. Außerdem wird über dieses Kriterium nur ein Mindeststandard definiert. Somit sollte dieser Ansatz zurückhaltend verwendet werden, um ein gewisses Mindestniveau zu gewährleisten, ähnlich wie im Falle der Blacklist. Eventuell kann eine Umsetzung durch Adaption des Vorgehens bei klassischen Gütern erfolgen. Dort hat ein Produkt einen Fehler, wenn es nicht bietet, was „erwartet werden kann“.
Spezifische Vorgaben: wie im Abschnitt Motivation bereits erläutert, herrschen im Bereich kritischer Infrastrukturen zumindest häufig höhere Maßstäbe an die Sicherheit und Qualität von Software (etwa bei Programmiersprachen, Testing, Zertifizierung). Es bietet sich an, in einigen Bereichen etwas mehr staatliches Mikromanagement zu betreiben und höhere Standards festzuschreiben. Schließlich ist im Falle eines Hacks der Schaden ja auch höher.
Personenbezogene Daten: eine einfache Möglichkeit für eine Haftung besteht, wenn im datenschutzrechtlichen Sinne personenbezogene Daten leaken. Für sensible Daten (z. B. Gesundheitsdaten, Finanzdaten) ließe sich die Haftung zusätzlich verschärfen. Aus Sicht des Schutzes der Privatsphäre wäre dies ein Fortschritt, da so Anbieter den Betroffenen eine Entschädigung zahlen müssten und Software für die Verarbeitung von personenbezogen Daten vermutlich auch teurer würde.
Softwareupdates: ein neuralgisches Thema ist das Bereitstellen und Einspielen von Softwareupdates. Hier empfehlen sich Auflagen für die Bereitstellung von Updates für kommerziell eingesetzte Software als auch die Dokumentation für das Einspielen dieser Updates. Besonders kritisch ist auch die Frage, wie und wann der Bereitsteller der Software von einem Softwarefehler erfahren hat.
Support: da hier ja von kommerziell eingesetzter Software die Rede ist, stellt sich die Frage, inwiefern Support insbesondere für Softwareupdates relevant ist. Dabei geht es nicht um klassischen IT-Support, sondern unter anderem um die Frage, ob Sicherheitslücken in Individualsoftware ausreichend schnell und zuverlässig korrigiert werden können. In der klassischen Produkthaftung existiert eine gesetzliche Mindestgewährleistung. Darüber hinaus ließe sich festlegen, dass Bereitsteller von Standardsoftware bis zum Ende des Lebenszyklus bei Bedarf Sicherheitsupdates ausliefern müssen. Im Falle von Individualsoftware oder von Privatpersonen kommerziell (v. a. Selbstständige) erstellter Software sollte eine Regelung der Modalitäten im Vertrag verpflichtend sein.
Mängel im Softwarebetrieb: neben klassischen Sicherheitslücken besteht auch die Gefahr von z. B. Konfigurationsfehlern im Betrieb der Software, die zu Schwachstellen in Informationssystemen führen. Da die physische Kontrolle über diesen Bereich dem Betreiber der Software unterliegt stellt sich die Frage, wie ein Mangel oder nicht-Mangel überhaupt vor Gericht bewiesen werden soll.
Diskriminierung im Netzwerk: ein ganz anderes Kriterium stellt der Umgang mit unerwünschten Techniken (z. B. veraltete Verschlüsselung) in öffentlichen Netzwerken (etwa WLAN-Hotspots, Mobilfunknetze) dar. Man könnte den Teilnehmern erlauben die Kommunikation mittels unsicherer Standards zu verweigern und sie von zivilrechtlichen Konsequenzen (z. B. Vertragsstrafen) freistellen. Dies würde jedoch auch die Netzneutralität tangieren. Ein Beispiel: ein Endgerät aus Südamerika baut eine Verbindung zu einem Server im Inland auf und möchte eine als unsicher bekannte SSL-Verschlüsselung verwenden, sodass einem Angreifer auf der Kommunikationsstrecke Anmeldedaten für den Server im Inland in die Hände fallen. Ein deutlich weitergehender Schritt wäre, es allen Teilnehmern zu erlauben, faktisch unwirksame Maßnahmen wie zu schwache Prüfsummen on-the-fly zu entfernen. Dabei handelt es sich allerdings um eine relativ bösartige Vorgehensweise, mit der viele Kommunikationsprotokolle wortwörtlich nicht rechnen werden.
Vertragsrecht: eine vertragliche Pflicht zur Unterstützung unsicherer Technik sollte rechtswidrig sein, sodass alle Beteiligten (z. B. in Altverträgen festgelegte) unsichere Techniken im Zweifelsfall ignorieren können. Das Problem hat somit immer, wer von veralteter, unsicherer Technik abhängt. Mit Blick auf die Haftung von Dienstleistern (siehe Nutzungsmodell) ist dies auch nur konsequent. Hinweis: als Technik ist hierbei nicht z. B. ein einzelnes Protokoll gemeint. Z. B. ist SMTP nicht „sicher“, SMTP mit SSL/TLS hingegen schon. Im Unterschied zum vorherigen Abschnitt geht es hier um Kommunikationsendpunkte.
Bricking: ein großes und wachsendes Problem stellen unsichere, nicht mehr unterstützte oder technisch nicht aktualisierbare Geräte in öffentlichen Netzen dar. Als Gegenmaßnahme ließen sich angreifbare Geräte aus der Entfernung hacken, um diese unschädlich oder notfalls ganz untauglich zu machen. Das kommt bereits vor, allerdings ohne gesetzliche Grundlage. Dabei besteht die Gefahr, dass z. B. Medizingeräte oder PKWs betroffen sind und so Menschen oder Material zu schaden kommen. Außerdem wäre nicht nachvollziehbar, was ein solcher Hack vor dem Bricking eines Geräts noch so alles verursacht hat, etwa Versand von SPAM. Eine gesetzliche Regelung könnte eine Registrierung der legalen Angreifer, die Dokumentation des Vorgehens und Vorgaben zur Minimierung des Schadens auf dem angegriffenen Gerät beinhalten. Ist es notwendig, Geräte zu bricken, ließe sich eine öffentliche Liste mit unsicheren (insbesondere: nicht mehr unterstützten) Geräten vorschalten. Diese sorgt zum einen für Transparenz, ermöglicht den Herstellern aber auch eine Reaktion, wenn ihre Geräte auf der Liste landen. Das Bricking betrifft dann wohlgemerkt auch den nicht-kommerziellen Betrieb von Geräten in öffentlichen Netzen.
Komplexität: durch die Verbreitung komplexer dynamischer Heuristiken (Machine Learning) kann es zu Situationen kommen, in denen durch Software gefällte Entscheidungen nicht nachvollziehbar sind, da sich der Entscheidungsalgorithmus laufend selbst verändert. Was bedeutet es eigentlich, wenn eine solche Software etwa für die Vergabe von Krediten zuständig ist und diese Software sich selbst so modifiziert, dass sie in der Folge gegen Gesetze verstößt? Analog dazu würde eine Sicherheitshaftung bedeuten, dass beim Einsatz von – insbesondere komplexer – Software nachvollziehbar sein muss, wie und wieso diese gehandelt hat. So könnte man dem etwa dem Betreiber einer solchen Software Fahrlässigkeit nachweisen, wenn diese sicherheitskritische Konfigurationseinstellungen im System geändert hat.
Umsetzung und Wirkung
Mit Blick auf die Voraussetzungen erscheint eine Umsetzung über das Zivilrecht sinnvoll. Ein Verbot von bestimmten Techniken oder Algorithmen hingegen schränkt die Handlungsfreiheit der Betroffenen ein und macht keinen Sinn, wenn diese Techniken unter gewissen Voraussetzungen noch sinnvoll weiter genutzt werden können. Etwa wenn eine altersschwache Verschlüsselung durch das zusätzliche Verwenden einer modernen Variante „verstärkt“ und somit abgesichert wird.
Die zivilrechtliche Umsetzung sollte anhand der im vorherigen Kapitel genannten Kriterien über die Justierung der Beweislast vor Gericht erfolgen. Wer etwa durch das Versäumen des Einspielens von Sicherheitsupdates möglicherweise den Abfluss von privaten oder geschäftlichen Daten verursacht hat, muss dann vor Gericht beweisen, dass die Lücke in der fraglichen Software nicht für einen eingetretenen Schaden in Frage kommen kann. Es findet eine Beweislastumkehr statt, der Geschädigte (der Kläger) muss nur die Existenz des Schadens beweisen. Erfüllt der Beklagte die Kriterien, findet hingegen keine Beweislastumkehr statt.
Den Einsatz von Staatsanwaltschaften oder Behörden – abgesehen von Zivilgerichten – braucht es bei diesem Konzept wenn dann nur in speziellen Fällen.
Präventiver vorgegangen werden muss hingegen bei Systemen, welche in öffentlichen Netzwerken erreichbar sind, da sonst die vielen Millionen Systeme nicht-kommerzieller Endnutzer als Schwachpunkt verbleiben. Diese Prävention sollen geeignete nicht-staatliche Stellen vornehmen, ähnlich wie bei Elektroinstallationen und Autos („TÜV“). Zum einen kann der Betreiber über den Mangel benachrichtigt werden, sofern er identifizierbar ist. Diese Benachrichtigung soll für Privatpersonen kostenlos sein. Zum anderen ist es möglich, veraltete Software in öffentlichen Netzen – wie im vorherigen Kapitel beschrieben – zu hacken und vom Netz zu trennen. Der Eingriff soll dabei so minimal wie technisch möglich sein, sodass der Betreiber das betroffene Gerät ggf. wieder in Stand setzen kann. In der Umsetzung lassen sich beide Maßnahmen kombinieren oder eskalierend anwenden. Also erst warnen, dann hacken.
Speziell betrachtet werden müssen nicht-kommerzielle Organisationen, da manche über umfangreiche Ressourcen und IT-Systeme verfügen, viele aber auch nicht. Von der grundsätzlichen Definition „kommerzieller Einsatz“ wären sie mangels Gewinnabsicht zunächst nicht betroffen. Folgende Maßnahmen sind hierzu denkbar:
- nimmt eine Organisation Geld ein, greift die Haftung für daran beteiligte Software bzw. Informationssysteme
- verarbeitet eine Organisation im öffentlichen Auftrag Daten, greift die Haftung für die gesamte Organisation
- Justierung der Haftung abhängig von der Gemeinnützigkeit der Organisation
- die persönliche Haftung von Vorstandsmitgliedern für Schadensersatzansprüche aus der Haftung einschränken, sodass sich nicht jeder kleine Sportverein einen IT-Sicherheitsexperten für den Vorsitz suchen muss
Die erhoffte Wirkung einer solchen Haftung ist schließlich, dass sicherere Software und Systeme mehr Wertschätzung erfahren und Techniken zur Entwicklung besserer Software gefördert werden. Insbesondere Organisationen wird daran gelegen sein, die Nachvollziehbarkeit und Plausibilität der Vorgänge in ihrer ITK zu verbessern und die Risikobewertung zusätzlicher Komplexität zu verschärfen.
Nebenwirkungen und Regressionen
Skaleneffekte: die hier vorgeschlagene Haftung trifft kleine Firmen potenziell stärker als die Großen, da letztere steigende Anforderungen an ihre IT-Infrastruktur vergleichsweise einfach umsetzen können und mehr finanzielle Reserven für Schadenersatzzahlungen in der Hinterhand haben. Dieses Ungleichgewicht soll ausgeglichen werden. Allerdings nicht, indem Kriterien für kleinere Marktteilnehmer abgesenkt werden, was für diese indirekt wieder zum Nachteil wird, weil der Kunde das natürlich auch weiß. Stattdessen sollen für großen Unternehmen zusätzliche Aufgaben definiert werden, welche deren Potenzial und Rolle gerecht werden, ohne ihnen damit einen zusätzlichen Vorteil zu verschaffen. Das können höhere Anforderungen an Leistungsfähigkeit beim Patchen von Standardsoftware sein, eine Pflicht zur verstärkten internen und externen Suche nach eigenen Sicherheitslücken sowie die Verwendung eines kleinen Teils des eigenen Umsatzes für öffentliche IT-Sicherheit:
- Belohnungszahlungen und Bereitstellung von Ressourcen für das Aufdecken von Sicherheitslücken in verbreiteter Software (etwa Google Project Zero)
- Unterstützung von Initiativen zur Absicherung von verbreiteter Open-Source-Software (z. B. Core Infrastructure Initiative)
- finanzielle Förderung von öffentlicher Forschung und Entwicklung mit dem Ziel sicherer Software und Informationssysteme
Open Source: auf den ersten Blick erscheint eine Haftung zum Nachteil von Open-Source-Software, da diese häufig ohne kommerzielle Bereitstellung genutzt wird. Kommerziell agierende Unternehmen müssten das Haftungsrisiko alleine tragen, da sie sich aktuell auf Patches und Kontinuität aus der Community verlassen. Jedoch ist dieses Risiko berechtigt, da es zum Teil zu einer „fire-and-forget“-Mentalität führt, sodass etwa viele IoT-Geräte aktuell mit Open-Source-Komponenten ausgeliefert und dann nicht mehr gepflegt werden. Dies ist inakzeptabel und auf Dauer schlecht für das Image von freiheitlich lizenzierter Software. Des weiteren werden viele Betreiber sich Gedanken um mehr Support für Open-Source-Software von entsprechenden Dienstleistern machen, z. B. für Patches. Dadurch fließt Geld zurück in Richtung der Open-Source-Projekte. Gleichzeitig wird proprietäre Software vermutlich teurer, da die Anbieter das Risiko für Schadenersatzzahlungen einkalkulieren. Zudem könnte man Software als Beweismittel mit einer erhöhten Beweislast versehen, wenn ihr Quellcode nicht öffentlich einsehbar ist.
Zertifizierung: ein spezielles Problem tritt auf, wenn der Staat die Zertifizierung von Software in kritischen Systemen verlangt, da diese Software nicht ohne weiteres geändert werden darf, auch wenn Sicherheitsupdates vorliegen. Hier muss entweder eine gesetzliche Regelung für eine Nachzertifizierung von Sicherheitsupdates gefunden oder die Haftung beschränkt werden.
Inland und Ausland: angesichts weltweiter öffentlicher Netze und Datenströme muss die Wirkung lokaler Gültigkeit der vorgeschlagenen Haftung bewertet werden, z. B. nur in Deutschland oder in der EU (im Folgenden „Inland“). Zunächst sollte eine Haftung nur gelten, wenn die betroffenen Systeme den gleichen Regeln unterliegen, um Nachteile für inländische Anbieter zu vermeiden. Dem erhöhten Aufwand für die bessere Absicherung von Software und Systemen steht ein möglicher Imagegewinn entgegen. Insbesondere kleinere Anbieter werden für ausländische Kunden nicht zweigleisig fahren, was wie im Abschnitt Skaleneffekte beschrieben berücksichtigt werden muss. Evtl. ist es notwendig, die Kommunikation ins Ausland mittels als unsicher betrachteten Techniken (z. B. Protokollen, Verschlüsselung) gesondert zu regeln, um Abschottungseffekte zu vermeiden.
Zusammenfassung
Insgesamt ergibt sich eine spezifische Mangel- und Produkthaftung für die Sicherheit von kommerziell eingesetzter Software und Informationssystemen.
Folgende Forderungen lassen sich festhalten:
- Die Pflicht für Hersteller, Sicherheitslücken zu Registrieren, Updates bereitzustellen und einzuspielen sowie die Dokumentation des Vorgangs
- Eine ausschließliche Verschlüsselung mit schwacher oder unsicherer Kryptographie führt zur Haftung von kommerziellen Betreibern und Herstellern
- Die Definition von abstrakten technischen Mindestanforderungen insbesondere in kritischen Infrastrukturen ist langfristig erforderlich, aber nicht trivial
- Der Umgang mit persönlichen und privaten Daten und darauf ausgerichtete Software soll durch Haftung rechtlich riskanter und aufwändiger werden
- Insgesamt die zivilrechtliche Möglichkeit, andere auf Schadensersatz zu verklagen, wenn deren grob fahrlässige Handlungen zu Schäden durch Software führen
- Ressourcentechnisch leistungsfähige Organisationen werden in die Pflicht genommen, sich im besonderen Maße für die eigene und öffentliche IT-Sicherheit einzusetzen
- Autorisierung von Organisationen, in geregelten Verfahren gegen die Teilnahme von Geräten mit unsicherer Software an öffentlichen Netzen vorzugehen
