Autor: Dr. Ralf Huuck, Synopsys<\/p>\n
Aktuelle Untersuchungen haben gezeigt, dass in weit \u00fcber 90% aller neuen Softwareprojekte Open-Source verwendet wird [6]. Dies ist nur nat\u00fcrlich, wenn man bedenkt, wie weitverbreitet Open-Source Standardpakete und Werkzeuge sind. Die Frage, die sich dabei stellt, ist: Wie kann man sicherstellen, dass diese Open-Source Komponenten den eigenen Qualit\u00e4ts-, Lizenz- und Sicherheitsanspr\u00fcchen gerecht werden? Dieser Artikel beleuchtet einige der Risiken beim Einbetten von Drittanbieter-Komponenten und stellt die Ergebnisses einer weltweiten Untersuchung zu Sicherheitsl\u00fccken in Open-Source Komponenten vor. Daraus abgeleitet wird erl\u00e4utert, wie automatische Software-Scanning-L\u00f6sungen verwendet werden k\u00f6nnen, um diese Sicherheitsl\u00fccken und Risiken im Entwicklungsprozess automatisch zu erkennen und eine Auslieferung im Produkt zu verhindern.<\/strong><\/p>\n Open-Source Software ist ein wichtiger Bestandteil vieler Produkte. Dabei ist die Sicherheit von Open-Source Software generell vergleichbar mit selber entwickelter Software. Das Prinzip der „many eyeballs“ hilft, entsprechende Anforderungsstandards zu erreichen. Umgekehrt bedeutet dieses aber, dass Angreifer ebenfalls die verwendeten Open-Source Pakete untersuchen k\u00f6nnen, um eventuelle Schwachstellen auszunutzen. Kritisch ist, dass Sicherheitsl\u00fccken oftmals erst nach l\u00e4ngerer Zeit bekannt werden, wenn die Pakete schon im Produkt verbaut sind.<\/p>\n Softwaresicherheit bedeutet eine zunehmend gr\u00f6\u00dfere Herausforderung bei der Entwicklung von eingebetteten Systemen. Dieses ist umso mehr der Fall, je gr\u00f6\u00dfer Softwareentwicklungsprojekte sind und je schneller sie sich fortentwickeln. Aktuelle Beispiele finden sich in Fahrerassistenzsystemen und Industrie 4.0 Applikationen, wo die Software Millionen Zeilen von Code umfassen kann und gleichzeitig sicherheitskritische Aufgaben erf\u00fcllen muss.<\/p>\n Ein Beispiel f\u00fcr die Auswirkungen von Sicherheitsl\u00fccken durch Drittanbieter ist das MIRAI Botnet [1]. Dieses Botnet umfasst in seinen verschiedenen Inkarnationen \u00fcber 130.000 eingebettete Systeme, zumeist internetf\u00e4hige \u00dcberwachungskameras, die durch eine gemeinsame Sicherheitsl\u00fccke in einem zugelieferten Bauteil von Hackern \u00fcbernommen wurden. Obwohl die \u00dcberwachungskameras von verschiedenen Herstellern vertrieben werden, basierten sie auf Lieferketten mit demselben Board und derselben Treibersoftware mit derselben Sicherheitsl\u00fccke.<\/p>\n Im Folgenden pr\u00e4sentieren wir einige Ergebnisses zur Untersuchung von Risiken von eingebetteten Softwarekomponenten. Wir gehen den Fragen nach: Wie h\u00e4ufig haben Softwarekomponenten Sicherheitsl\u00fccken und wie kritisch sind diese L\u00fccken? Dar\u00fcber hinaus stellen wir einige L\u00f6sungen vor, um diese Sicherheitsl\u00fccken automatisch im Entwicklungsprozess zu erkennen und zu vermeiden.<\/p>\n Die Nutzung von Open-Source ist heutzutage der Normalfall, und generell ist Qualit\u00e4t vergleichbar mit intern entwickelter Software. Allerdings werden oft keine speziellen Qualit\u00e4tskontrollen und Reviews von Open-Source Paketen durchgef\u00fchrt, die von extern eingebunden sind. Oft wird dem „many eyeballs“ Prinzip vertraut. Dies ist insbesondere deshalb erstaunlich, weil bis zu 96% aller neuer Softwareprojekte Open-Source verwendet wird [6].<\/p>\n Schwachstellen in Open-Source Software sind oftmals gut dokumentiert, sobald diese bekannt werden. Patches stehen h\u00e4ufig bereit, werden aber oft verz\u00f6gert eingepflegt. Die US-Beh\u00f6rde NIST pflegt die prim\u00e4re Datenbank an Sicherheitsl\u00fccken von Open-Source Software. Diese National Vulnerability Database (NVD) [3] umfasst etwa 90.000 Eintr\u00e4ge, die bekannte Sicherheitsl\u00fccken (CVEs) dokumentieren und ihnen eine sicherheitskritische Metrik gem\u00e4\u00df des Common Vulnerability Scoring System (CVSS) zuweist [4].<\/p>\n Abbildung 1 (siehe\u00a0PDF<\/a>) zeigt die neu hinzugekommenen Sicherheitsl\u00fccken per Jahr. Dieses bedeutet nicht, das Open-Source Software schlechter geworden ist, sondern vor allem, dass ihre Anzahl gestiegen ist und dass sie zunehmend nach Schwachstellen untersucht wird.<\/p>\n Synopsys publiziert regelm\u00e4\u00dfig Untersuchungen zu Sicherheitsl\u00fccken in Open-Source Komponenten. Dabei werden zusammenfassende Ergebnisse von Software, die auf der Protecode-Plattform hochgeladen wurde, ver\u00f6ffentlicht [2]. Protecode ist eine Analysesoftware, die Bin\u00e4rdateien auf bestehen Open-Source Komponenten untersucht, die Versionsnummern der Open-Source Komponenten ermittelt, und diese Komponenten mit bestehenden NVD-Eintr\u00e4gen abgleicht.<\/p>\n Die Studie von 2016\/2017 umfasst in etwa 130,000 Uploads zur Protecode-Plattform. Dabei konnten \u00fcber 16.000 verschiedene Komponenten und Versionen identifiziert werden.\u00a0 Abbildung 2 (siehe\u00a0PDF<\/a>) zeigt eine Untergliederung der h\u00e4ufigsten identifizierten Komponenten nach Aufgaben- und Nutzungsbereich. Dabei sind etwa zwei Drittel aller Komponenten Utilities f\u00fcr Windows- und Linux-Tools, Netzwerkprotokolle wie SLL und http sowie Medienbibliotheken f\u00fcr jpg, png oder XML.<\/p>\n Diese Komponenten werden typischerweise als Open-Source verwendet, da sie Standardfunktionen vereinfachen und in der Regel nicht neu implementiert werden m\u00fcssen. F\u00e4lschlicherweise wird davon ausgegangen, dass diese Komponenten sicher sind oder keinen sicherheitskritischen Einfluss haben.<\/p>\n Es zeigt sich aber, dass aus den \u00fcber 16.000 verschiedene Komponenten etwa 9.000 Sicherheitsl\u00fccken (CVEs) identifizieren lassen. Das bedeutet, dass eine Gro\u00dfzahl der Komponenten nicht sicher ist. Dar\u00fcber hinaus sind die gefundenen Sicherheitsl\u00fccken nicht neu, wie Abbildung 3 (siehe\u00a0PDF<\/a>) zeigt.<\/p>\n Dieses bedeutet, dass etwa 50% aller Sicherheitsl\u00fccken vier Jahre alt oder \u00e4lter sind. In den meisten F\u00e4llen gibt es eine neuere und sicherere Version, die zur Verf\u00fcgung steht, aber nicht benutzt wurde. Diese zeitliche Diskrepanz h\u00e4ngt auch damit zusammen, dass es oft einige Zeit dauert, bis Sicherheitsl\u00fccken entdeckt werden. Das hei\u00dft, dass Software die heute als sicher gilt, morgen neuere Erkenntnisse haben kann. Dieses ist f\u00fcr Hersteller schwer zu kontrollieren und zu korrigieren.<\/p>\n Es ist unrealistisch, auf Komponenten von Open-Source Quellen zu verzichten. Dieses ist ein n\u00fctzlicher Bestandteil, um Produkte kosteng\u00fcnstig und relativ schnell herzustellen. Dar\u00fcber hinaus ist es keineswegs erwiesen, dass Open-Source Komponenten schlechter als eigenentwickelte Software ist. In der Tat ist oft das Gegenteil der Fall.<\/p>\n Dennoch ist es nicht empfehlenswert, Komponenten von Drittanbietern ohne vorherige Pr\u00fcfungen einzubauen. Gl\u00fccklicherweise gibt es auf dem Markt heutzutage Softwarel\u00f6sungen wie Protecode, Sonatype oder Black Duck, die diese \u00dcberpr\u00fcfungen automatisch vornehmen k\u00f6nnen [5].<\/p>\n Idealerweise werden regelm\u00e4\u00dfige Scans durchgef\u00fchrt, die diese \u00dcberpr\u00fcfungen vornehmen. Dabei ist es hilfreich, ein Risikomodell zu erstellen, und den Software-Release daran zu koppeln. Beispielhaft ist dieses in Abbildung 4 (siehe\u00a0PDF<\/a>) dargestellt.<\/p>\n Das Sicherheitsrisiko bildet die gefundenen Schwachstellen in der \u00fcberpr\u00fcften Software ab, das Lizenzrisiko die Verwendung von unangebrachten Lizenzen und das operationelle Risiko besteht aus einer Kombination aus Sicherheit, H\u00e4ufigkeit der verwendeten Komponenten und der Projektaktivit\u00e4t.<\/p>\n Um diese Informationen immer zeitnah bereitzuhalten, lassen sich diese Softwarel\u00f6sungen auch direkt in den Entwicklungsprozess automatisiert eingebunden werden. Das hei\u00dft, es l\u00e4sst sich zum Beispiel ein DevOps Jenkins-Prozess starten, der bei jeder Produkterstellung eine automatisierte Analyse f\u00e4hrt, die Open-Source Komponenten entdecken und mit ihren bekannten Sicherheitsl\u00fccken abgleicht. Diese Ergebnisse k\u00f6nnen dann zeitnah den Softwareentwicklungsteams und den Qualit\u00e4tsteams zur Verf\u00fcgung gestellt werden.<\/p>\n Die hier vorgestellten Erkenntnisse zeigen, dass Open-Source weitverbreitet ist, dass sich aber auch routinem\u00e4\u00dfig Sicherheitsl\u00fccken in diesen Komponenten finden lassen. Dennoch sind Open-Source Pakete f\u00fcr die moderne Softwareentwicklung unerl\u00e4sslich.\u00a0 Wichtig ist, dass die Komponenten nicht mit blindem Vertrauen hingekommen werden, sondern dass man sie auf ihre Sicherheitsaspekte kontinuierlich \u00fcberpr\u00fcft. Softwarel\u00f6sungen im Bereich der Open-Source Scanning Analysis erm\u00f6glichen dieses heutzutage effizient und kosteng\u00fcnstig.<\/p>\n Kurzfristig sind einmalige Scans hilfreich, um sich ein Bild von den eigenen Projekten und Codebasen zu erstellen. Mittelfristig sollte aber dieser Scanprozess in den Entwicklungszyklus miteingebaut werden, um eine zeitnahe Risikoabsch\u00e4tzung durchf\u00fchren zu k\u00f6nnen. Dieses erm\u00f6glicht dann, automatische Akzeptanzschwellen zu definieren, die zum Beispiel den CI\/CD-Prozess abbrechen oder automatische Emails generieren. Zum anderen lassen sich h\u00e4ufig Verkn\u00fcpfungen zwischen vorhandenen Produkten mit ihren Open-Source Komponenten und neuen Forschungsergebnissen erstellen. Dieses Bedeutet, dass automatisch ein Alarm generiert wird, falls eine neue Schwachstelle in einer verbauten Komponente bekannt wird.<\/p>\n Dar\u00fcber hinaus ist es sinnvoll, eine Update-Strategie zu entwickeln. Welches Risiko gehe ich ein, bevor ich eine Komponente update oder patche? Wie pflege ich diesen Prozess in meinem Software-Lifecycle? Wer ist der Verantwortliche und welche Sicherheitskultur lebe ich? Dieses sind oft Fragen, die jenseits der Entwicklungsteams bestehen und gruppen\u00fcbergreifend angegangen werden m\u00fcssen.<\/p>\n [1] Constantinos Kolias, Georgios Kambourakis, Angelos Stavrou and Jeffrey Voas. DDoS in the IoT: Mirai and Other Botnets. IEEE Computer, Volume 50\/7, 2017.<\/p>\n [2] Synopsys Software Integrity Group. The State of Software Composition 2017. [3] Harold Booth, Doug Rike, Gregory A. Witte. The National Vulnerability Database (NVD): Overview. ITL Bulletin, Dec. 2013.<\/p>\n [4] Peter Mell, Karen Scarfone, and Sasha Romanosky. 2006. Common Vulnerability Scoring System. IEEE Security and Privacy 4, 6 (November 2006), 85-89.<\/p>\n [5] Millar S. Vulnerability Detection in Open-Source Software: The Cure and the Cause. Queen’s University Belfast, 2017.<\/p>\n [6] Synopsys Center for Open-Source Research and Innovation. Report: 2018 Open-Source and Security Risk Analysis.<\/p>\n Dr. Ralf Huuck ist ein Technischer Direktor bei Synopsys, Australien. Dr. Huuck arbeitet im Werkzeugbereich der Synopsys Software Integrity Group und unterst\u00fctzt die Werkzeugentwicklung, um standardkonforme Produkte sicher und schnell auf den Markt zu bringen. Zuvor war Dr. Huuck Gesch\u00e4ftsf\u00fchrer von Red Lizard Software, Sydney, und langj\u00e4hriger Forschungs- und Entwicklungsleiter am Forschungsinstitut NICTA. Zeitglich ist Dr. Huuck Adjunct Associate Professor an der UNSW, Australien, und im Bereich Softwaresicherheit t\u00e4tig.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Open-Source \/ Embedded Software Engineering.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Open-Source \/ Embedded Software Engineering steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinleitung<\/h2>\n
Wachsende Zahl Open-Source Nutzung und bekannten Schwachstellen<\/h2>\n
Ergebnisse zu Sicherheitsl\u00fccken in Open-Source Komponenten<\/h2>\n
Resultate f\u00fcr eingebettete Open-Source Komponenten<\/h3>\n
Automische Einbindung von Open-Source Scanning in den SDLC<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n
References<\/h2>\n
\nhttps:\/\/www.synopsys.com\/software-integrity\/resources\/analyst-reports\/state-of-software-composition-2017.html<\/p>\nAutor<\/h2>\n
\nOpen-Source – unsere Trainings & Coachings<\/h2>\n
\nOpen-Source – Fachwissen<\/h2>\n