Open-Source-Code ist öffentlich, aber sehen ihn auch die richtigen Leute an?

Es gibt unterschiedliche Auffassungen über die Sicherheit von Open-Source-Code und Open-Source-Software - aber diese Auffassungen sind wichtig.

Auf der einen Seite wird Open-Source-Code von einigen als weniger sicher angesehen. Schließlich gibt es weniger kommerzielle Anreize, Open-Source-Code zu sichern, als Code, der von einem gewinnorientierten Anbieter geschrieben wurde, der seinen Ruf aufs Spiel setzt.

Andererseits gibt es die Ansicht, dass quelloffener Code einfach deshalb sicherer ist, weil er offen ist und überprüft werden kann. Das Argument lautet, dass diese Offenheit alle kommerziellen Anreize überwiegt. Je mehr Menschen sich mit Open-Source-Code befassen, desto einfacher sollte es sein, die Schwachstellen in Open-Source-Code zu erkennen.

In diesem Artikel werfen wir einen genaueren Blick auf die "Offenheit" von Open-Source-Code und die Sicherheitsvorteile, die dies mit sich bringen sollte - die aber oft nicht erreicht werden. Wir werden auch die Ansicht untersuchen, dass in Wirklichkeit zu viele der falschen Leute den Open-Source-Code nach Möglichkeiten untersuchen und zu wenige der richtigen Leute daran arbeiten, Sicherheitslücken zu finden und zu beheben.

Inhalt:

1. OPEN-SOURCE-CODE BIETET EINIGE SICHERHEITSVORTEILE
2. UNTERNEHMEN SIND VON OPEN-SOURCE-CODE ABHÄNGIG, HALTEN SICHERHEIT ABER FÜR SELBSTVERSTÄNDLICH ...
3. SCHLIMMER NOCH, DIE FALSCHEN LEUTE SEHEN SICH OPEN-SOURCE-CODE AN
4. ES GIBT EINE "GUTE" PRÜFUNG, ABER...
5. Anreize und Bewusstsein

Open-Source-Code bietet einige Sicherheitsvorteile

Erstens gibt es stichhaltige Gründe, warum Open-Source-Code im Vergleich zu Closed-Source-Code als sicherer angesehen wird. Es gibt vernünftige Argumente, die unterstreichen, warum Open-Source-Code unter bestimmten Umständen Sicherheitsvorteile bieten kann.

Der Hauptgedanke dabei ist, dass der Code von Open-Source-Code öffentlich ist und einer genaueren Prüfung unterzogen wird, so dass mehr Augen auf ihn gerichtet sind. Wo der Code weit verbreitet ist, sollte er auch genauer auf Sicherheitslücken untersucht werden. Daher sollte der Code sicherer sein, da Schwachstellen schneller gefunden und behoben werden können. Bei Code, der in kleineren Projekten, in Code-Bibliotheken oder hochspezialisiertem Code verwendet wird, ist dies jedoch nicht unbedingt der Fall.

Der zweite Sicherheitsvorteil von Open-Source-Code besteht darin, dass Unternehmen, die Open-Source-Code verwenden, Fehler schneller beheben können, bevor diese gefährlich werden. Auf jeden Fall schneller, als wenn sie sich auf einen kommerziellen Anbieter verlassen, der seinen proprietären Code unter Umständen erst ausgiebig testen muss.

Die isolierte Betrachtung dieser beiden Argumente kann den Eindruck erwecken, dass der quelloffene Code aufgrund der Sicherheitsvorteile die bessere Wahl ist, doch diese Sichtweise lässt einige wichtige Punkte außer Acht.

Unternehmen verlassen sich auf Open Source, halten aber Sicherheit für selbstverständlich...

Fast jedes Unternehmen setzt Open-Source-Code in großem Umfang ein. Sie können dies explizit tun, indem sie ein Produkt wie Red Hat Enterprise Linux verwenden, oder implizit, da selbst kommerziell lizenzierte Closed-Source-Software Open-Source enthält.

Eine Analyse von Synopsis aus dem Jahr 2020 ergab, dass 99 % der für den Bericht geprüften Codebasen Open-Source-Code enthielten. Ein Großteil dieses Codes ist zudem veraltet: 91 % des für den Bericht geprüften Codes enthielt Open-Source-Code, der seit vier oder mehr Jahren nicht mehr aktualisiert wurde.

Im Grunde genommen spielt es keine Rolle, ob Ihr Unternehmen explizit Open-Source-Lösungen einsetzt oder nicht, Open-Source-Code ist so allgegenwärtig, dass Sie die Bedrohung ernst nehmen müssen.

Leider nehmen Unternehmen die Sicherheit von Open Source oft als selbstverständlich hin. Entweder, weil ihnen nicht bewusst ist, wie viel Open-Source-Code ihre Arbeitslasten unterstützt, oder aufgrund der vermeintlichen Sicherheitsvorteile von Open-Source-Code.

Dies ist ein riskanter Ansatz, und es gibt zahllose Beispiele dafür, wie große Unternehmen, die wichtige Dienstleistungen erbringen, durch einen Fehler im Open-Source-Code überrumpelt werden. Eines der bekanntesten Beispiele ist die Sicherheitslücke bei Equifax im Jahr 2017, bei der sehr persönliche Finanzdaten von über 147 Millionen Menschen offengelegt wurden.

Im Fall des Equifax-Sicherheitsverstoßes nutzten Hacker anfälligen Code in Apache Struts 2 aus, einem vom Equifax-Website-Portal verwendeten Framework. Es dauerte sechs Wochen, bis das Unternehmen die Sicherheitsverletzung bemerkte, was dazu führte, dass eine sehr große Menge an Daten gestohlen wurde. Für Equifax waren die Kosten immens, sowohl in Bezug auf die finanzielle Ent schädigung als auch auf die öffentlichen Auswirkungen.

Das Equifax-Beispiel ist keineswegs einzigartig. Ein Teil des Problems liegt in der Tatsache, dass Entwickler einfach und schnell eine Reihe von Open-Source-Funktionen in ihre Anwendungen einbauen können. Von großen Funktionsblöcken bis hin zu einzelnen Bibliotheken.

Sie würden dies ohne wirkliche Prüfung tun - und oft ohne die Komponenten zu katalogisieren. Das Ergebnis ist, dass die Unternehmen kaum eine Vorstellung davon haben, von welchem Open-Source-Code ihre technischen Lösungen abhängen. Dabei ist es fast sicher, dass sich Open-Source-Code so ziemlich überall verstecken wird.

Schlimmer noch, die falschen Leute sehen sich Open-Source-Code an

Jeder kann Open-Source-Code untersuchen, auch die Bösewichte. Die weite Verbreitung von Open-Source-Code motiviert böswillige Akteure dazu, nach Schwachstellen zu suchen, die sich ausnutzen lassen.

In einigen Fällen geht es bei dieser Jagd einfach um finanziellen Gewinn - Kriminelle wollen Wege finden, sich in Systeme einzuhacken, um wertvolle Informationen zu stehlen oder um ein Unternehmen als Lösegeld zu erpressen. Andere Gruppen, von APT-Teams (Advanced Persistent Threats) bis hin zu staatlichen Akteuren, verfolgen bestimmte Ziele, die durch die Ausnutzung von Sicherheitslücken erreicht werden können.

Das Aufspüren von Schwachstellen in weit verbreiteten Open-Source-Codes gibt diesen Akteuren die Werkzeuge an die Hand, die sie benötigen, um in ansonsten sichere Systeme einzudringen. Manchmal finden böswillige Akteure Schwachstellen in Open-Source-Code, lange bevor die Nutzer von Open-Source-Code oder die Open-Source-Gemeinschaft diese Schwachstellen erkennen.

Mit anderen Worten: Diese Sicherheitslücken befinden sich in den Händen von Hackern, aber Patches und Korrekturen sind noch nicht verfügbar. Dies gibt Kriminellen und Nationalstaaten die Möglichkeit, Schwachstellen im Open-Source-Code auszunutzen, bevor die notwendigen Patches und Korrekturen veröffentlicht werden.

Es gibt eine "gute" Prüfung, aber...

Es ist nicht so, dass die Open-Source-Gemeinschaft Fehler ignoriert oder nachlässig Code schreibt, nur um zu vergessen, wie der Code aussieht und wo er verwendet wird. Aber die schiere Menge des verwendeten Open-Source-Codes - einigen Berichten zufolge 31 Milliarden Codezeilen - bedeutet, dass es fast unmöglich ist, den Code gründlich auf Fehler zu überprüfen.

In der Praxis sehen wir oft, dass alte Schwachstellen in Open-Source-Code erst Jahrzehnte nach dem Hinzufügen des Open-Source-Codes zu einer Code-Basis auftreten.

Nehmen wir den kürzlich entdeckten libcurl-Bug, der im April 2021 bekannt wurde. Der zugrunde liegende Code wurde im August 2000 in die Codebasis aufgenommen, so dass es mehr als zwanzig Jahre gedauert hat, bis die Schwachstelle bekannt wurde. Es gibt keine Möglichkeit festzustellen, welche böswilligen Akteure in den letzten Jahrzehnten Kenntnis von dieser Schwachstelle hatten und was sie mit diesem Wissen gemacht haben.

Ebenso wurde der Fehler, der hinter der weithin bekannten Heartbleed-Sicherheitslücke steckt, 15 Jahre, nachdem der Code ursprünglich in die OpenSSL-Bibliotheken aufgenommen wurde, gefunden. Auch hier gibt es keine Möglichkeit, herauszufinden, wer sonst noch von dieser Sicherheitslücke wusste, bevor sie das Licht der Welt erblickte.

Es liegt einfach daran, dass die Guten nicht genug Zeit aufwenden, um Open-Source-Code zu prüfen. Ja, es gibt Bemühungen, Open-Source-Code zu sichern. Aber diese Bemühungen sind kein gleichwertiger Ersatz für böswillige Akteure, die den Code systematisch untersuchen, um ausnutzbare Schwachstellen zu finden.

Anreize und Sensibilisierung

Das Problem der Anreize für das Auffinden von Schwachstellen in Open-Source-Code ist der Open-Source-Gemeinschaft, den Sicherheitsexperten und den Anbietern, die in hohem Maße auf Open-Source-Code angewiesen sind, bekannt. Daher gibt es Programme, die Anreize für Open-Source-Entwickler schaffen sollen, Fehler im Code zu finden.

Das Bug-Bounty-Programm der EU beispielsweise bietet bis zu 25.000 Euro für Entwickler, die Sicherheitslücken in bestimmten Open-Source-Projekten finden. Auch die Linux Foundation hat in ihrer Umfrage über freie und Open-Source-Entwickler im Jahr 2020 eine Reihe von Empfehlungen ausgesprochen, unter anderem, weil die Umfrage ergab, dass Open-Source-Entwickler die Behebung von Sicherheitsproblemen als seelisch belastende Aufgabe empfinden.

Aber Anreize werden niemals die Motivationslücke zwischen Kriminellen, Bedrohungsakteuren und der Open-Source-Gemeinschaft schließen. Deshalb ist das Bewusstsein so wichtig.

Für Unternehmensanwender besteht der erste Schritt darin, anzuerkennen, dass Open-Source-Code überall vorhanden ist. Der Kauf von Software von kommerziellen Anbietern, die proprietären Code verwenden, ist keine Versicherungspolice, da dieser Code höchstwahrscheinlich auf Open-Source-Code wie Open-Source-Bibliotheken beruht. Ja, kommerzielle Anbieter haben einen größeren Anreiz, den Code zu sichern, aber in Wirklichkeit bleiben sowohl proprietärer Code als auch Open-Source-Code angreifbar.

Ein weiterer wichtiger Schritt besteht darin, reaktionsfähig zu bleiben. Wenn eine Schwachstelle im Open-Source-Code entdeckt wird, folgt in der Regel schnell ein Patch oder eine andere Methode zur Abhilfe. Unternehmen müssen schnell und gründlich patchen, und wo dies schwierig ist, sollten sie den Einsatz automatisierter Live-Patching-Tools in Betracht ziehen, die die schwere Arbeit erledigen - ohne Unterbrechungen.

Schließlich wird es bei der Unternehmenssicherheit immer um die Sicherheitslage gehen. Sie kann den Unterschied ausmachen zwischen der schnellen Abwehr eines laufenden Angriffs und einer öffentlichen Entschuldigung sechs Monate später. Pauschale Annahmen über die öffentliche Kontrolle von Open-Source-Code sind für einen sicheren Betrieb nicht von Vorteil.

Zusammenfassend lässt sich sagen, dass es schwer ist, definitiv zu sagen, dass Open-Source-Code sicherer oder unsicherer ist als kommerzieller, proprietärer Closed-Source-Code. Das Argument ist einfach komplizierter als das. Es gibt zahllose Schwachstellen, die auch in proprietärem Closed-Source-Code gemeldet werden. Gehen Sie einfach nicht davon aus, dass ein Code sicherer ist, nur weil er offen ist. Das allein ist noch keine Garantie. Es bedarf erheblicher Anstrengungen, der richtigen Anreize und des technischen Know-hows, um Code zu sichern, und nicht nur des Zugangs zum Quellcode.

Unternehmen sollten sich darüber im Klaren sein, dass Open-Source-Code aufgrund seines offenen Charakters oft schnell gepatcht wird und sehr sicher ist. Auf der anderen Seite kann Open-Source-Code aber auch Schwachstellen verbergen - und das jahrzehntelang.

Lesen Sie weiter: OPEN SOURCE: UNTERNEHMENSGERECHTE SICHERHEIT MIT OFFENEM CODE?