Regeln und Kooperation erhöhen Open Source Security

Dies ist ein Gastbeitrag von Julian Totzek-Hallhuber, Solution Architect bei Veracode.

Kaum ein Unternehmen kann auf Open-Source-Komponenten verzichten. Sie stecken in unternehmenskritischen Anwendungen, die ohne die „freie Software“ aufwendiger zu entwickeln wären. Der Rückgriff auf Open Source-Bibliotheken (OSB) verkürzt die „Time to Market“ und ist häufig günstiger als Eigenentwicklungen. Gleichwohl haben OSB einen hohen Preis, wenn Cyber-Kriminelle nicht entdeckte Sicherheitslücken ausnutzen. Dies zu verhindern geht nur mit Policy-Vorgaben und Zusammenarbeit der Entwickler mit den IT-Sicherheitsleuten.

Open Source Code wird häufig nicht so genau geprüft wie selbst entwickelte Software. Und wenn eine Schwachstelle erkannt wird, ist es oft zu spät, in jedem Falle aber schwierig und kostspielig, alle Anwendungen zu identifizieren, die eine riskante Komponente verwenden. Aktuell sind rund fünf Millionen Open-Source-Bibliotheken im Einsatz und der Bestand wächst fast exponentiell. Millionen Entwickler arbeiten an neuem Code und werden wohl innerhalb des nächsten Jahrzehnts bis zu einer halben Milliarde Bibliotheken veröffentlichen. Dies erhöht die Bedrohungslage für Unternehmen, die Open Source in ihren Anwendungen einsetzen.

44 Prozent aller Anwendungen mit OSB haben Sicherheitslücken

Auch wenn OSB die Effizienz der Anwendungsentwicklung erhöhen: Die Entwickler übernehmen unwissend Schwachstellen in den von ihnen verwendeten Komponenten. Das wissen auch Cyber-Kriminelle. Ein Großteil der aktuellen Anwendungssicherheitslandschaft basiert auf öffentlichen Common Vulnerabilities and Exposures (CVEs). Aber diese Liste wurde vor DevOps und vor der Explosion in Open Source erstellt. Es ist daher heute unmöglich auf die Behebung einer Schwachstelle zu warten, die zu einer öffentlichen Liste hinzugefügt wird. Das Risiko für Unternehmen ist nicht zu unterschätzen. Schnell verstoßen sie unerwartet gegen Compliance-Vorgaben und fallen bei Audits durch. Der „State of Software-Security 2017“-Report von Veracode konnte beispielsweise nachweisen, dass 44 Prozent aller Anwendungen erhebliche Schwachstellen aufwiesen, die auf Open-Source-Komponenten zurückzuführen waren. So legten Cyber-Kriminelle beispielsweise im November 2016 das öffentliche Nahverkehrssystem in San Francisco mit Hilfe einer Schwachstelle in den Apache Commons Collections lahm. Mehr als 2.100 Rechner waren betroffen.

Open-Source-Software wirkt auf die gesamte Software-Lieferkette

Trotzdem werden Unternehmen Open-Source weiter nutzen. Die Vorteile überwiegen, wenn die IT-Abteilungen sich professionelle Sicherheitsregeln geben. Denn nach Einschätzung von Veracode wird der weltweite Umsatz mit OS-Lösungen im Jahr 2020 rund 57 Milliarden Dollar betragen und hier sollte am Ende nicht an der Sicherheit gespart werden. Unternehmen sollten also Maßnahmen ergreifen, um die Schwachstellen zu minimieren. Denn die gute Nachricht ist: Die Verwendung einer Bibliothek mit Schwachstellen macht Unternehmen nicht automatisch verwundbar. Entscheidend ist nicht nur, wann eine Komponente einen Fehler enthält, sondern auch, ob diese Komponente so verwendet wird, dass der Fehler leicht ausnutzbar ist. In vielen Fällen, wenn Entwickler eine OSB einbinden, verwenden sie nur ein kleines Stück davon. Eine Methode oder Funktion bedeutet, dass selbst wenn die Bibliothek als verwundbar markiert ist, die Daten möglicherweise nicht durch diesen Teil geleitet werden. Es kommt also darauf an, die komplette Software-Lieferkette über ihren gesamten Lebenszyklus effektiv zu verwalten. Dann generieren Anwender sogar Wettbewerbsvorteile gegenüber den Unternehmen, die dies nicht tun. Eine gut gemanagte Software-Lieferkette, die durch häufige Sicherheitsüberprüfungen aktuell gehalten wird, kann ein Unternehmen vor Überraschungen schützen.

Trend: Cyber-Kriminelle infizieren beliebte OS-Komponenten

Die Veracode-Forschung hat gezeigt, dass die Fehlerbehebung in Open-Source-Software vergleichsweise lange dauert. Im Durchschnitt brauchen Unternehmen 93 Tage, bis sie mindestens 25 Prozent ihrer Open-Source-Fehler entdecken und eliminieren. Gleichzeitig gibt es bei den Angreifern ein Umdenken. Anstatt eine Anwendung zu attackieren und einen einzigen Angriff zu organisieren, greifen sie Komponenten an, um einen größeren Schaden anzurichten. Einige Angreifer schleusen bösartigen Open-Source-Code in bekannte OSB ein, die Entwickler dann unwissentlich in ihre Codebasis integrieren. Ransomware ist dabei die häufigste Bedrohung. Auch die zunehmende Cloud-Nutzung verändert das Sicherheitsdenken. Mit immer mehr Cloud-basierten Anwendungen steigt auch der Bedarf an Scans nach Schwachstellen. Und angesichts immer schnellerer Innovationszyklen bei unternehmenskritischen Softwarelösungen steigt dieser Bedarf noch verstärkt. Auch deshalb geht der Trend zu Automatisierung und kontinuierlicher Bereitstellung von Sicherheits-Scans bereits in der Entwicklung. Obwohl Branchenbenchmarks wie Open Web Application Security Projetcs (OWASP) heute Richtlinien und Kontrollen für die Verwendung von Komponenten empfehlen, haben viele Unternehmen Schwierigkeiten bei der Umsetzung dieser Richtlinien.

Auch kommerzielle Software besteht Sicherheits-Scans nicht immer

Aber auch die Annahme, Sicherheitslücken in OSB ließen sich durch permanente Analyse von Entwicklern und Anwendern entdecken, geht vielfach fehl. Das zeigte die „Heartbleed“-Sicherheitslücke in der OpenSSL-Bibliothek, die mehr als zwei Jahre unentdeckt blieb. Zudem konnte eine Studie von Veracode nachweisen, dass über 77 Prozent der kommerziellen Software-Pakete bei Sicherheits-Scans durchfielen, die den Vorgaben des OWASP entsprachen. Bei selbst entwickelter Software lag dieser Wert nur bei 65 Prozent. Zudem können die Entwickler bei Open-Source-Lösungen schnell einen Patch schreiben, während sie sonst lange auf Updates warten müssen.

Die Lösung: Policies und Zusammenarbeit mit IT-Security

Vor diesem Hintergrund bleibt für Unternehmen nur der Weg, ihre Regeln für Sicherheitsüberprüfungen während der gesamten Lebenszeit einer Software zu verschärfen. Entwickler brauchen exakt definierte Leitplanken, welche OS-Komponenten sie verwenden dürfen und welche nicht. Eine unternehmensweite Policy sollte daher festlegen, welche Tools aus dem Open Source-Repertoire eingesetzt werden dürfen. Darüber hinaus sollten Entwickler verpflichtet werden, regelmäßige Patches einzuspielen. Denn hier zählt Geschwindigkeit, Schwachstellen zu schließen, ehe Cyber-Kriminelle sie ausnutzen können. Ein zentrales Patch-Management hilft bei der Umsetzung. Dafür muss allerdings auch die komplette Software-Lieferkette unter ständiger Kontrolle stehen. Regelmäßige Sicherheitstests sind obligatorisch vorzuschreiben beispielsweise mit Tools für statische Code-Analysen und Werkzeuge für Software Composition Analysis (SCA). Nicht nur die IT-Sicherheitsteams sondern auch Entwickler erhalten so einen detaillierten Überblick über bestehende Risiken. Unternehmen sollten sich daher auch niemals mit dem Status Quo zufriedengeben und regelmäßig Risikobewertungen von Open-Source-Software und anderen Programmen durchführen.

Fazit: Policies und abteilungsübergreifender Informationsfluss

Entwickler und IT-Sicherheitsexperten brauchen also einen gemeinsamen Plan, damit sie Schwachstellen schneller entdecken und beseitigen können. Beide Abteilungen müssen sich regelmäßig austauschen. Gemeinsam müssen sie gewährleisten, dass sie bei Sicherheitslücken auf dem gleichen Stand sind und ein gemeinsames Vorgehen für die Bekämpfung definiert haben. Denn am Ende sind Open Source Bibliotheken und Komponenten nicht schlechter und anfälliger als proprietäre Software. Unternehmen sollten allerdings durch ihre Policies Grundlagen schaffen und Sicherheitsrisiken frühzeitig beheben können, die durch sie auftreten. Verbindliche Regeln, regelmäßige Sicherheitsüberprüfungen sowie institutionalisierte Zusammenarbeit und ein abteilungsübergreifender Informationsfluss sind das mindeste, damit Unternehmen die Vorteile von Open-Source-Komponenten nutzen und gleichzeitig ihre Sicherheit nicht gefährden.

Weitere Informationen unter:
http://de.veracode.net/

CC BY-SA 4.0 DE

Sie dürfen:

Teilen — das Material in jedwedem Format oder Medium vervielfältigen und weiterverbreiten
Bearbeiten — das Material remixen, verändern und darauf aufbauen und zwar für beliebige Zwecke, sogar kommerziell.
Der Lizenzgeber kann diese Freiheiten nicht widerrufen solange Sie sich an die Lizenzbedingungen halten.
Bitte berücksichtigen Sie, dass die im Beitrag enthaltenen Bild- und Mediendateien zusätzliche Urheberrechte enthalten.

Unter den folgenden Bedingungen:

Namensnennung — Sie müssen angemessene Urheber- und Rechteangaben machen, einen Link zur Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Diese Angaben dürfen in jeder angemessenen Art und Weise gemacht werden, allerdings nicht so, dass der Eindruck entsteht, der Lizenzgeber unterstütze gerade Sie oder Ihre Nutzung besonders.
Weitergabe unter gleichen Bedingungen — Wenn Sie das Material remixen, verändern oder anderweitig direkt darauf aufbauen, dürfen Sie Ihre Beiträge nur unter derselben Lizenz wie das Original verbreiten.

Julian Totzek-Hallhuber, Solution Architect, Veracode

Über den Autor

Julian Totzek-Hallhuber ist Solution Architect beim Spezialisten für Anwendungssicherheit Veracode und bringt mehr als 15 Jahre Erfahrung im IT-Sicherheitsumfeld mit. In seinen verschiedenen Funktionen war er für die Anwendungsentwicklung, für Penetrationstests sowie für die Sicherheit von Webanwendungen zuständig. Zudem ist er Autor zahlreicher Artikel, ist regelmäßig als Sprecher auf Messen anzutreffen und hat bei Projekten von www.webappsec.org (wie zum Beispiel WAFEC) mitgewirkt.