Sollten Softwareanbieter für Unsicherheit haftbar gemacht werden?

Ein Zero-Day-Fehler in Ihrer bevorzugten Unternehmenssoftwareanwendung ermöglichte es Angreifern, in Ihr Netzwerk einzudringen und vertrauliche Daten zu kompromittieren. Es wird viel kosten, die Lösung zu reparieren, bevor es überhaupt zu Bußgeldern und Kundenklagen kommt – und die Anwendung gehört nicht einmal Ihnen. Wer soll bezahlen?

Es wird wahrscheinlich nicht das Unternehmen sein, das Ihnen die Software verkauft hat. Ihre Endbenutzer-Lizenzvereinbarungen (EULAs) begrenzen in der Regel ihre Haftung. Die meisten von uns lesen diese nicht, weil sie es sind zu lang und zu komplex.

In den letzten Monaten wurden Forderungen, diese Situation zu ändern, immer lauter und erreichten auch die obersten Regierungsebenen. Im Februar sagte Jen Easterly, Direktorin der Cybersecurity and Infrastructure Security Agency, ausdrücklich aufgerufen wegen Lieferantenhaftung während einer Rede an der Carnegie Mellon University.

Die Welt sei dazu übergegangen, unsichere Technologie als die Regel zu akzeptieren, obwohl sie die Ausnahme sein sollte, sagte sie. „Technologiehersteller müssen Verantwortung für die Sicherheitsergebnisse ihrer Kunden übernehmen.“

Easterly forderte die Regierung auf, Gesetze zu veröffentlichen, die Technologieunternehmen daran hindern würden, vertragliche Haftung auszuschließen. Die Biden-Regierung Nationale Cybersicherheitsstrategie, das im März dieses Jahres ins Leben gerufen wurde, wiederholte die Forderung nach diesem Gesetz.

Eine langjährige Debatte

Regierungen haben über dieses Problem schon früher nachgedacht. Das britische Oberhaus empfohlen im Jahr 2007 Softwareanbieter zur Rechenschaft zu ziehen, selbst nachdem Softwareentwickler aus verschiedenen Gründen Argumente gegen die Anbieterhaftung angehört hatten.

Zu diesen Protesten gehörte auch die schiere Komplexität moderner Softwareumgebungen. Viele Arten von Software existieren nebeneinander, betonte der Entwickler und fügte hinzu, dass sie möglicherweise auf seltsame Weise miteinander interagieren. Können wir vernünftigerweise erwarten, dass ein Softwareanbieter jeden Grenzfall der Interoperabilität vorhersagt?

Eine weitere Sorge war die Möglichkeit eines Benutzerfehlers. Was passiert, wenn ein Benutzer die Software falsch konfiguriert und sie oder eine Komponente, mit der sie interagiert, aufgrund einer schlechten Benutzeroberfläche unsicher macht? Was passiert, wenn der Benutzer einen Patch aus einem legitimen Grund, beispielsweise aufgrund einer behördlichen Einschränkung, nicht angewendet hat? Gibt es eine teilweise Haftung für Fehlkonfigurationen und wie kann darüber entschieden werden?

Es gibt weitere Herausforderungen für Unternehmen, die versuchen, Fragen der Lieferantenhaftung zu erfüllen. Viele Software entsteht nicht im luftleeren Raum; Es greift auf Bibliotheken von Drittanbietern zurück, die häufig unter Open-Source-Lizenzen veröffentlicht werden und möglicherweise eigene Sicherheitsprobleme aufweisen. Log4Shell, der Fehler in der Log4J-Java-Protokollierungsbibliothek, der seit 2013 unbemerkt die Cybersicherheit von Tausenden von Unternehmen beeinträchtigte, ist ein Paradebeispiel. Wer zahlt, wenn die von Ihnen erstellte Software zufällig eine unsichere Komponente eines Drittanbieters verwendet?

Easterly empfiehlt, dass Ihre Sicht auf Software über Ihre eigenen Grenzen hinausgehen sollte. Sie wiederholte die Forderung des Weißen Hauses nach einer Software Bill of Materials (SBOM), um die Herkunft der zusammengebauten Software zu definieren.

Wie sieht sichere Software aus?

Wenn man die Anbieter eines komplexen Produkts zur Rechenschaft zieht, ergeben sich andere Fragen, etwa die Frage, wie wir Softwaresicherheit überhaupt definieren. Definitionen liegen entlang eines Kontinuums und reichen von unzureichend – zum Nachweis einiger grundlegender statischer Softwaretests – bis hin zu unpraktisch – formale Verifizierung. Letzteres prüft den Softwarebetrieb anhand eines abstrakten mathematischen Modells. Solche Systeme gibt es zwar, aber sie sind für spezielle Anwendungen gedacht und erfordern einen hohen Codierungsaufwand.

Die realistischste Definition liegt irgendwo in der Mitte, mit dokumentierten Best Practices, die Sicherheit bereits in der Entwurfsphase direkt in die Softwareproduktion integrieren. NISTs Secure Software Development Framework, das das NCS empfiehlt, bringt viele davon zum Ausdruck.

Eine weitere Empfehlung von Easterly war die Verwendung speichersicherer Sprachen. Viele Sicherheitslücken moderner Software haben ihren Ursprung im Speichermissbrauch. Als schnelle Low-Level-Sprachen, bei denen Programmierer den Speicher selbst verwalten müssen, sind C und C++ hier besonders schwach. Go, Python und Java sind übergeordnete, interpretierte Sprachen, die den Speicher im Auftrag des Programmierers verwalten. Eine neuere Sprache, Mozillas Rust, ist ebenfalls speichersicher – und neben C und Assembler die erste Sprache, die im Linux-Kernel unterstützt wird.

Easterly forderte außerdem transparente Richtlinien zur Offenlegung von Schwachstellen bei Softwareanbietern. Allzu oft tun sie ihr Bestes, um Sicherheitslücken geheim zu halten, indem sie Meldungen über Sicherheitslücken ignorieren oder manchmal davon abhalten. Sie sagte, eine offenere und kooperativere Beziehung mit Cybersicherheitsforschern würde dazu beitragen, Softwarelücken zu schließen.

Zwischenschritte

Während es auf den Kongress wartet, verlässt sich das Weiße Haus auf den Ausführungsverordnung zur Verbesserung der Cybersicherheit der Nation, jetzt über zwei Jahre alt, um Anbietern den richtigen Weg einzuschlagen. Das Oval Office kann Unternehmen nicht direkt dafür bestrafen, dass sie schlechten Code erstellen, aber die EO verbietet Bundesbehörden, ihnen diesen Code abzukaufen.

Wir können auch auf die Standardisierung zurückgreifen, um Antworten zu finden. Die aktualisierte Norm ISO 27001:2022 umfasst: Anhang A Kontrolle 8.28, das sichere Design- und Entwicklungsprinzipien sowohl für intern entwickelte Software als auch für die Wiederverwendung von externem Code definiert. Da sich viele Unternehmen auf diese Akkreditierung als wesentliches Unterscheidungsmerkmal verlassen, erzeugt die Hinzufügung dieser Kontrolle zusätzlichen Druck, die Softwaresicherheit zu verbessern und zu dokumentieren.

Wechselnde politische Gezeiten

Während die Lieferantenhaftung ein heikles Thema ist, hat der Kongress in der Vergangenheit nicht davor zurückgeschreckt, Gesetze zur Bewältigung komplexer Technologieprobleme zu nutzen. Das Interesse der Unternehmen spielt eine wichtige Rolle bei der Zurückhaltung, dieses spezielle Problem anzugehen, das von einer Softwareindustrie mit großer Lobbymacht angetrieben wird.

Dennoch haben es immer mehr Menschen auf der Mission, eine hart umkämpfte Branche zur Rechenschaft zu ziehen. Facebook hat zwar offiziell seinen alten internen Slogan „Beweg dich schnell und mach Dinge kaputt“ aufgegeben, aber das ist immer noch ein De-facto-Betriebsmodell für Technologiefirmen, die um Innovationen kämpfen. Da Software einen immer größeren Teil unseres Alltagslebens beeinflusst, ist ein Gleichgewicht zwischen rücksichtsloser Funktionsentwicklung und maßvoller Verantwortung für einen sicheren Betrieb notwendiger denn je.