zurück zur Übersicht

Open Source Vulnerability Management

Ein alter und beliebter Spruch bei Softwareentwicklern sagt: „Entwickle nicht das neu, was schon jemand vor dir gemacht hat.“ Dieser Spruch bezieht sich auf Funktionen, APIs, Frameworks und andere Komponenten wie einzelne Code-Snippets, die meist auf Open Source Code basieren. So können die Entwickler produktiver arbeiten. Sogenannte Code Mashups können schnell gebaut werden und bestehen aus verschiedenen Quellen und Diensten wie z.B. Google Maps oder YouTube.

Fertige Open Source Tools können in vielen Bereichen durchaus mit kommerziell angebotener Software mithalten, sind aber in der Regel weitaus günstiger oder sogar kostenlos zu haben.

Sehen, was drin steckt: Open Source Software erlaubt Einblick in den QuellcodeAndere Vorteile liegen darin, dass die Funktionalität einer Open-Source-Komponente immer transparent ist, weil der gesamte Quellcode zur Verfügung steht. Das unterjubeln von Malware, ein verstecktes „Nach-Hause-Telefonieren“ oder unerwünschtes, heimliches Tracken der Useraktivitäten ist also kaum möglich. Schließlich kann, zumindest theoretisch, jeder sehen, was das Programm tut. Das führt zu dem Eindruck: Open-Source-Komponenten sind sicherer, da sie von vielen anderen schon getestet und genutzt werden.

Ist das aber wirklich immer der Fall, vor allem wenn externe Programmbibliotheken benutzt werden, die tausende Code-Zeilen besitzen?

Weckruf

Einige große Schwachstellen in Open-Source-Komponenten wie Heartbleed oder DROWN in den letzten Jahren waren ein Weckruf für die Anwendungsverantwortlichen, denn diese mussten die brennende Frage beantworten: „Inwieweit bin ich betroffen?“

Anders formuliert:

  1. Welche neuen Anwendungen, die noch nicht produktiv laufen, nutzen die verwundbare Komponente?
  2. Welche laufenden Anwendungen haben diese Schwachstelle und wie können sie geschützt werden bis das Problem beseitigt ist?

Betrachtet man den SDLC (Software Development Lifecycle) wird deutlich, dass die erste Frage ein Teil der Prävention ist. Die verwundbare Komponente in der Anwendung kann noch rechtzeitig ersetzt werden. Jedoch werden nicht alle Anwendungen intern entwickelt und deswegen soll ein Umgang mit Schwachstellen in den bereits eingesetzten Anwendungen definiert werden.

Durchblick im Lizenzdschungel ist gefragt

Als ob das nicht genug wäre, kommt auch die Frage der legalen Lizenzierung auf den Tisch. Darf ich aus lizenzrechtlicher Sicht alle gewünschten Komponenten in meiner Anwendung nutzen? Welche davon haben eine GNU GPL, GNU LGPL, BSD oder Apache Lizenz? Verstößt meine Anwendung gegen diese Regeln? In den USA hat ein solcher Fall für großen Wirbel gesorgt.

Die Umfrage “Future of Open Source Survey 2016” hat gezeigt, dass jede zweite Organisation keine offizielle Richtlinie für den Einsatz von Open-Source-Software hat. Viele wissen auch nicht, wo genau Open-Source-Komponenten in Software genutzt werden.

Der Prozess, der alle obengenannten Herausforderungen abdeckt, heißt Open Source Vulnerability Management (OSVM). Ein wichtiger Teilbereich ist Software Composition Analysis. Dabei wird der Quellcode oder eine kompilierte Anwendung analysiert und als Ergebnis alle Komponenten, egal ob selbst entwickelt oder nicht, dargestellt. Basierend auf den Ergebnissen werden die bekannten Schwachstellen aus einer Datenbank, wie OSVDB (Open Source Vulnerability Database)  den Komponenten zugeordnet. Zusätzlich wird für jede externe Komponente auch die entsprechende Lizenz angezeigt.

Bei den bereits laufenden Anwendungen besteht auch die Frage, ob die Schwachstellen ausgenutzt werden können oder nicht. Dies kann mit Audits, Schwachstellenscans, Dynamischen Scans oder Penetrationstestes überprüft werden.

Am Ende des Prozesses hat der Applikationsverantwortliche beim richtigen Einsatz drei Fragen beantwortet:

  • Wie groß ist mein Sicherheitsrisiko bei den bekannten Open-Source Komponenten?
  • Besteht Compliance bezüglich der Lizenzierung?
  • Nutze ich Softwarekomponenten die nicht mehr gewartet werden?

Integration von OSVM in SDLC

Doch wie lässt sich OSVM in den restlichen Application-Security-Prozess integrieren? OSVM ist eine natürliche Ergänzung zur statischen (SAST) und dynamischer Analyse (DAST). Gerade in diesen Phasen wird Software frühzeitig auf Sicherheit getestet. Wird OSVM vorgeschaltet, kann das einen wertvollen Input für weitere Tests bringen. Werden alte und verwundbare Bibliotheken erkannt, müssen diese nicht statisch und dynamisch getestet werden, sondern werden am besten gleich ersetzt. Das spart Zeit.

Am besten funktioniert die Integration dann, wenn eine grafische Oberfläche die Ergebnisse von OSVM, SAST, DAST und anderen sicherheitsrelevanten Prozessen zusammenstellen kann. Solche Tests sollten in der heutigen  DevOps Welt automatisiert ausgeführt werden. Eine weitere wichtige Anforderung besteht in der Möglichkeit, eigene Policies definieren zu können, um gezielt die Verstöße erkennen zu können.

Der Markt für OSVM ist in den letzten zwei Jahren deutlich reifer geworden.  Einige Application-Security-Plattformen, wie Veracode, bieten ihre eigene Software Composition Analysis, die in den Prozess bestens integriert ist. Der Vorteil ist, dass keine zusätzliche Software und Hardware erforderlich ist.

OSVM
Abbildung 1: Integration HPE Fortify SSC und Black Duck

 

Ein neuer Trend ist die Integration mit führenden spezialisierten OSVM Anbietern wie BlackDuck und Sonatype. Diese werden von Herstellern wie Veracode und HPE Fortify bereits sehr gut unterstützt. So können die Ergebnisse von statischer und dynamischer Code-Analyse und OSVM miteinander korreliert werden und das Ergebnis für das gesamte Software-Projekt übersichtlich dargestellt werden.

Transparenz nutzen

All das gilt ebenso für fertige Software, die im Unternehmen eingesetzt werden soll. Bereits fertig programmierte Open Source Tools bieten eben diese reizvolle Möglichkeit, die kommerzieller Software fehlt. Da der Quellcode mitgeliefert wird, kann dieser mit einem der genannten Tools einer eingehenden Prüfung unterzogen werden. Bekannte Schwachstellen werden so problemlos identifiziert und können explizit geschützt werden – falls man die Software nutzen will.

Wer wirklich sichergehen möchte, dass eine Open Source Software die Unternehmens IT nicht kompromittieren kann, sollte dafür einen Prozess etablieren. Damit kann der Aufwand klar beziffert und niedrig gehalten werden. Die Scans selbst können ohnehin weitgehend automatisiert werden.

Fazit

Mit wachsendem Anteil von Open Source Software steigt auch die Nachfrage nach Sicherheit und einem schnellen Überblick über sich daraus ergebende Risiken. Egal ob Open Source Komponenten in eigenen Softwareprojekten verwendet werden sollen, oder ob vorhandene Open Source Tools auf Sicherheit und Schwachstellen geprüft werden: Es stehen Tools zur Verfügung.

Gefragt ist ein Open Source Vulnerability Management Process, der eng mit Security Testing und Design verknüpft ist.

 


 

Bild: ©iT-CUBE SYSTEMS AG 2017

Schreibe einen Kommentar