Das BSI warnt nach § 7 BSI Gesetz vor (potenziellen) Sicherheitslücken in Kaspersky-Produkten. Dafür gibt es gute Gründe, denn gerade eine Antivirensoftware greift tief in die Systeme ein (sonst funktioniert sie nicht) und könnte tatsächlich für Cyberangriffe (etwa in Reaktion auf Sanktionen) durch staatliche Einflussnahme Russlands missbraucht werden – mit ungeahnten Folgen, denn knapp 20 Prozent der Unternehmen in Deutschland setzen auf die ein oder andere Weise bisher Kaspersky ein. Das Schweizer Gegenstück zum BSI, das Nationale Center Cybersicherheit (NSCS), sieht keinen Anlass für die Warnung und verweist auf die Transparenzoffensive des Unternehmens,. So erlaubt das Unternehmen Prüfungen seines Softwarequellcodes und ist damit ziemlich einzigartig in der Branche.
Wie man zum Fall Kaspersky auch steht – die Gefahr der Unterwanderung von Software ist real. Bereits 5 Jahre vor dem Ukraine-Krieg wurde das dänische Logistikunternehmen Maersk auf Tage lahmgelegt durch eine Attacke auf eine Software zur Steuerverwaltung der Niederlassung in der Ukraine. Dieses eher simple Problem lieferte den Grundstein für einen unternehmensweiten IT-Fall und mindestens 300 Millionen US-Dollar. Schaden beim Unternehmen selbst - und in Folge ungezählte Verspätungen bei Lieferungen und damit Milliardenkosten bei den Kunden von Maersk. Die mutmaßlichen Täter: Russische Hacker:innen, die den Update-Mechanismus der Software gekapert und darüber Schadcode eingeschleust hatten. Kein Einzelfall. Ähnliche Supply-Chain-Attacken wurden seither immer wieder bekannt und kulminierten in Folge Ende 2020 im Solarwinds-Hack, bei dem in einem einzigen Vorfall gleich mehrere hundert Unternehmen betroffen waren. Verdächtig auch hier: russische Gruppen.
Programmbibliotheken in der Lieferkette
Doch die Übernahme von Update-Mechanismen durch kriminelle Hacker:innen ist nicht das einzige Problem, das wir mit Software-Lieferketten haben, denn die Art und Weise, wie wir heute Software entwickeln, bringt ganz eigene Probleme mit sich.
Heutige Software besteht durchweg aus vorhandenen Programmbibliotheken, die mehr oder weniger sinnvoll zusammengeklickt werden. Dies sorgt nicht nur für vielfach unnötig umfangreiche Programme, sondern bringt es auch mit sich, dass ein und dieselbe Sicherheitslücke sich in unterschiedlichsten Programmen und Anwendungen wiederfinden kann. Wie weitreichend die Folgen sind, konnte man ebenfalls 2020 an der vom Entdecker – der israelischen Sicherheitsfirma JSOF – als „Ripple20“ bezeichneten Lücke sehen.
Betroffen waren unterschiedlichste vernetzte Geräte, darunter Drucker fürs Homeoffice, unterbrechungsfreie Stromversorgungen, Steuerungen von Kraftwerken und Industrieanlagen, aber auch so exotische Gerätschaften wie Laborspülmaschinen. Die Liste der betroffenen Hersteller las sich dann auch wie ein Who’s who der Tech-Branche. Allen gemeinsam war ein kleines Stück Software, die von der selbst in Fachkreisen kaum bekannten Firma Treck bereitgestellt und vieltausendfach weiterverwendet worden war.
Open Source fair bezahlen und Software-TÜV
Ende 2021 machte dann die Log4J-Sicherheitslücke Schlagzeilen. Das Problem hier: ein Stück Open-Source-Software, das wie Ripple20 an unterschiedlichsten Stellen – auch und gerade in vielen kommerziellen Softwareprodukten – eingesetzt wurde und wird. In beiden Fällen ging die Geschichte – nach allem was wir wissen - gut aus und die Probleme sind „gefixt“, aber was, wenn die sogenannten Maintainer der Software keine Lust mehr auf unbezahlte Arbeit haben, oder – wie Anfang 2021 mit „color,js“ passiert – ein jahrelang gepflegtes Softwaremodul plötzlich selbst sabotieren. Der Softwareentwickler hatte Im November 2020 angekündigt, nicht mehr „Gratis-Arbeit für Fortune500-Unternehmen“ leisten zu wollen.
Sogenannte „Protestware“ liefert nun eine neue Facette für diese Betrachtung, haben doch wiederholt Entwickler:innen von Updates von Open-Source-Komponenten diese dazu genutzt, Pro-Ukraine-Botschaften in der Software zu verstecken. Die russische Sberbank warnte Mitte März davor, Updates einzuspielen, da man das Einschleusen von Schadcode befürchtet.
So sehr man mit dieser Art von kreativem Protest auch sympathisieren mag, eine nüchterne Betrachtung führt zu der Schlussfolgerung, dass unser über Jahrzehnte entwickeltes Modell der Software-Entwicklung nicht nachhaltig ist, wenn wir keine Lösung finden, Qualität kontrollierbar zu machen – etwa über einen „Software-TÜV“ und adäquate Haftungsregelungen für kommerzielle Softwareprodukte. Darüber hinaus braucht es faire Vergütungsmodelle für die Open-Source-Community, insbesondere wenn deren Beiträge in kommerzieller Software Verwendung finden. Einfache Lösungen sind für die genannten Herausforderungen jedoch nicht in Sicht. Die vorliegende Warnung des BSI weist weit über den Fall Kaspersky hinaus. Wir sollten sie unbedingt Ernst nehmen.
Thomas R. Köhler ist Forschungsprofessor am Internationalen Innovationszentrum der Haikou University in Wuhan, China, und Lehrbeauftragter im Masterstudiengang Kriminalistik an der Hochschule der Polizei Brandenburg.