Kolumne : IT-Sicherheit bei Freier Software: Der Staat ist in der Pflicht

Freie Software, oder auch Open-Source-Software (OSS), ist ein elementarer Bestandteil unseres digitalen Lebens. Es handelt sich dabei um „Code, der der Öffentlichkeit zugänglich ist, das heißt, jeder kann ihn anzeigen sowie nach Belieben verändern und verteilen“. Von Schreib- und Grafikbearbeitungsprogrammen bis hin zu Programmiersprachen, Softwarebibliotheken und ganzen Betriebssystemen: Kaum eine Firma oder Behörde kommt an Freier Software vorbei. Dabei ist oft nicht ersichtlich, wo Freie Software enthalten ist – zum Beispiel, wenn sie in Form von Softwarebibliotheken in anderer Software integriert ist. Das gilt auch für Kritische Infrastrukturen. Illustriert wird dies durch eine populäre Comic-Zeichnung:

Webcomic von Randall Munroe (xkcd.com), CC BY-NC 2.5

Schwachstellen wie Heartbleed haben gezeigt, welche weitreichenden Auswirkungen unsichere Freie Software haben kann. Die Auswirkungen unterscheiden sich in dieser Hinsicht nicht von denen proprietärer Software, allerdings sind einige Freie-Software-Komponenten extrem weit verbreitet.

Offener Code ist nicht automatisch ein Sicherheitsrisiko

In der IT-Sicherheit wird Freie Software schon lange in sicherheitskritischen Bereichen verwendet. Die Kryptographie beispielsweise folgt dem Kerckhoffs’schen Prinzip: „Das System darf keine Geheimhaltung erfordern [um sicher zu sein]“. Die Argumentation, Freie Software ermögliche es potentiellen Angreifern, zum Beispiel Kriminellen und Nachrichtendiensten, mithilfe einer Source-Code-Analyse Schwachstellen zu finden, geht an der Praxis vorbei.

Zur Qualitätssicherung und Ermittlung von Schwachstellen wird heutzutage meist auf die zahlreichen Methoden des automatisierten Blackbox-/Dynamic Application Security Testing (DAST) zurückgegriffen, beispielsweise dem Fuzzing. Diese Methoden werden genauso im Bereich proprietärer Software eingesetzt.

Eine entscheidende Rolle spielt die Langlebigkeit von Software, die bei den meisten Freie-Software-Lizenzen durch garantierte Veränderbarkeit, Zugänglichkeit und Verteilbarkeit des Source Codes durch jede:n sichergestellt wird. Dank eines offenen Source Codes können auch Dritte, etwa Dienstleister, Patches für Anwender:innen zur Verfügung stellen, wenn die eigentlichen Entwickler:innen die Weiterentwicklung und Pflege einer Software bereits aufgegeben haben; sie können die Weiterentwicklung einer Software sogar komplett übernehmen. Diese Unabhängigkeit bietet Anwender:innen von Freier Software einen entscheidenden Sicherheitsvorteil für ihre IT-Ökosysteme.

Staatliche Fürsorgepflicht für Freie Software

Die Bundesregierung hat die zentrale Bedeutung von Freier Software in ihrem Koalitionsvertrag erkannt und unter anderem angekündigt, bei Ausschreibungen Entwicklungen „in der Regel als Open Source“ zu beauftragen. Gleichzeitig soll nach dem Willen der Bundesregierung Freie Software dafür sorgen, unsere „digitale Souveränität“ zu „sichern“. Dabei wirkt es allerdings so, als habe die Bundesregierung nicht verstanden, welche Verantwortung der Staat im Hinblick auf die IT-Sicherheit von Freier Software hat, beziehungsweise setzt diese Erkenntnis bisher nicht um.

Eine führende Rolle hat bei Freier Software natürlich „die Community“, also die Entwickler:innen und Anwender:innen. Diese sind damit auch primär verantwortlich für die Sicherheit von Freier Software. Weil der Staat selbst inzwischen über alle Ebenen, von den Kommunen über die Länder bis hin zum Bund, selbst Nutzer von Freier Software geworden ist, könnte die Sicherheit von Freier Software zu Recht als öffentliches Interesse gewertet werden. Aber ist der Staat auch für die IT-Sicherheit von Freier Software zuständig?

Bei Kritischen Infrastrukturen (KRITIS) und Unternehmen im besonderen öffentlichen Interesse (UBI), die ebenfalls Freie Software einsetzen, ist das bereits teilweise der Fall. In beiden Fällen lässt sich eine gewisse Art von staatlicher Fürsorgepflicht für die IT-Sicherheit von Freier Software, vor allem in Bezug auf Wartung und nachhaltige Weiterentwicklung, ableiten – alleine schon aus Selbstschutz. Dies gilt vor allem für die Software, die in der öffentlichen Verwaltung, bei Dienstleistern, KRITIS und UBI aktiv genutzt wird.

Inventur- und Wartungspflicht von Kommunen bis Bund

Daraus ergeben sich zunächst drei Konsequenzen für die Umsetzung: In einem ersten Schritt muss der Staat erfassen, für welche Freie Software er eine Fürsorgepflicht hat. Das bedeutet, es bedarf einer Inventur (Software Asset Management) bei Kommunen, Ländern, Bund und ihren Dienstleistern. In einem weiteren Schritt sollten KRITIS, UBI und politische Parteien angehalten werden, möglicherweise durch eine entsprechende Rechtssetzung, es ihnen gleich zu tun. Diese Inventur bildet eine wichtige Grundlage für weitere Maßnahmen zur Verbesserung der IT-Sicherheit von Freier Software.

Beispielsweise können diese Akteure bei neu gefundenen Schwachstellen sofort feststellen, ob sie oder ihre Dienstleister betroffene Software im Einsatz haben, ohne wertvolle Zeit zu vergeuden, wie zum Beispiel beim Log4J-Sicherheitsvorfall. Aber nur eine Inventur ist nicht ausreichend. Wenn Freie Software eingesetzt wird, muss Drittens sichergestellt werden, dass diese Behörden und Unternehmen Dienstleistungsverträge für Anpassungen, Wartung, Pflege und ggf. auch Weiterentwicklung der Software abschließen. Im Idealfall verfügen die Behörden auch selbst – zumindest teilweise – über entsprechende Kompetenzen.

IT-Sicherheitsdividende: Einen Teil an die Community zurückgeben

Wenn man erst mit der Software-Inventarisierung beginnt, wenn eine Schwachstelle bekannt geworden ist, ist es viel zu spät. Deshalb muss über die Einführung von rechtlich verpflichtenden Software-Materiallisten – Software Bill of Materials (SBOM) – diskutiert werden. SBOM – für proprietäre wie Freie Software gleichermaßen – könnte als Bedingung für die Vergabe von staatlichen Aufträgen im Rahmen des Onlinezugangsgesetzes (OZG) und der EVB-IT-Verträge verankert werden. Alternativ sollten Informationen über verfügbare Patches und Updates gemäß des Common Security Advisory Frameworks (CSAF) verarbeitet werden.

Auf Basis dieser Inventurlisten sollte grob überschlagen werden, wie viel Lizenzgebühren die öffentliche Verwaltung, KRITIS, UBI und deren Dienstleister durch den Einsatz Freier Software sparen. Einen bestimmten Prozentsatz dieses Betrags sollten die Institutionen als IT-Sicherheitsdividende („Kickback“) in einen Fonds einzahlen. Aus dem Fonds könnten Sicherheitsaudits durch Dritte, Bug Bounties, skalierende Unterstützung wie die Entwicklung von automatisierten Source Code-Prüf-Frameworks als Freie Software (vgl. proprietäre Angebote von Coverity und Github) und weitere Maßnahmen zur Verbesserung der IT-Sicherheit finanziert werden. Der Fonds sollte Communitymanager:innen anstellen, die aktiv auf die Entwickler:innen von Freier Software sowie deren Anbieter und Dienstleister zugehen.

Der Fonds müsste auch bei aufgegebenen Freie-Software-Projekten einspringen und zumindest Sicherheitsaudits durchführen, Common Vulnerabilities and Exposures (CVEs) nachverfolgen und Sicherheitsupdates gewährleisten. Dies könnte auch in Zusammenarbeit mit Dienstleistern geschehen. Auch eine Art öffentliche Anerkennung für die Arbeit der Entwickler:innen, analog zur Bundeswehr Hall of Fame im Rahmen der Vulnerability Disclosure Policy, könnte in Erwägung gezogen werden (Background berichtete).

Höhere Priorität und mehr Verständnis für IT-Sicherheit bei Freier Software

Verwaltet werden könnte dieser Fonds zum Beispiel durch das Bundesamt für Sicherheit für Informationstechnik (BSI), das Zentrum für Digitale Souveränität (ZenDIS) oder den Sovereign Tech Fund. Neben diesen operativen Maßnahmen muss die für den Fonds verantwortliche Institution darauf hinwirken, dass die strukturellen Probleme, die sich aus dem Einsatz von Freier Software ergeben und sich indirekt zum Risiko für die IT-Sicherheit entwickeln können, gelöst werden. Dazu gehört es, Policy-Entscheider:innen über die Natur von Freier Software zu informieren. So wird in der deutschen Cybersicherheitspolitik zusehends mehr auf Herstellererklärungen gesetzt, etwa beim IT-Sicherheitskennzeichen, bei Zertifizierungen und Zulassungen. Unabhängig davon, wie aussagekräftig Herstellererklärungen in Bezug auf die IT-Sicherheit wirklich sind, gibt es bei Freier Software keine Hersteller, sondern Entwickler:innen, Dienstleister und Anbieter, und somit niemanden, der die in einer Herstellererklärung geforderten Zusagen geben kann.

Der Staat profitiert von Freier Software, und er setzt sie insbesondere auch in der aktuellen Gefährdungslage im Cyberraum ein, um sich vor fremden Nachrichtendiensten und anderen Akteuren besser zu schützen. Freie Software hat viele Vorteile, doch ihr Einsatz birgt auch Risiken; der Staat ist daher in der Pflicht, den weiterhin bestehenden Schwächen in der IT-Sicherheit aktiv entgegenzuwirken. Das bedeutet, dass die Freie-Software-Strategie der Bundesregierung IT-Sicherheit explizit berücksichtigen, höher priorisieren und mit einem Budget versehen sollte. Außerdem sollte die Bundesregierung die zentralen Akteure mit der Entwicklung und Umsetzung der entsprechenden Maßnahmen beauftragen.

Sven Herpig ist Leiter für Internationale Cybersicherheitspolitik bei der Stiftung Neue Verantwortung.

In unserer Reihe „Perspektiven“ ordnen unsere Kolumnist:innen regelmäßig aktuelle Entwicklungen, Trends und Innovationen im Bereich Cybersicherheit ein. Zuletzt von Sven Herpig erschienen: Cybersicherheitspolitik – Deutsche Ideenlosigkeit?