Zurück auf die Schulbank! Open Source und Software­komponenten Dritter – Risiken der Finanzbranche

In der Softwarebranche haben sich die Zeiten geändert: Was vor 10 Jahren vor Cyber-Bedrohungen schützte, reicht heute längst nicht mehr aus. Vor allem im Hinblick auf Open Source Software und die Software Dritter ist das Risiko gewachsen – auch für den Finanzsektor. Denn die in der Software enthaltenen Schwachstellen dienen Hackern als idealer Ausgangspunkt für Angriffe.

von Jeff Luszcz, Vice President of Product Management bei Flexera Software

Tatsächlich nimmt das Sicherheits- und Compliance-Risiko durch Open Source und kommerzielle Komponenten erschreckende Ausmaße an – und gefährdet die Sicherheit der Software Supply Chain. Der Anteil an Open Source und kommerziellen Komponenten beträgt in vielen kommerziellen Softwarepaketen bis zu 50 Prozent. Die meisten Entwickler nutzen sie, um ihre Arbeit schneller voranzubringen – …

… die genaue Herkunft der verwendeten Komponenten wird allerdings nur selten zurückverfolgt.”

Die Verfügbarkeit unzähliger hochwertiger, kostenfreier Softwarekomponenten bringt es mit sich, dass 50% der Anwendungen von Programmierern geschrieben werden, die keine Mitarbeiter des Unternehmens sind. Dadurch fehlt in vielen Fällen das Wissen über Lizenzbestimmungen und mögliche Sicherheitslücken.

Heartbleed und Apache Struts2

Im Banken- und Finanzsektor ist jedoch ein Verständnis über Sicherheit und Compliance der genutzten Software wesentlich! In jüngster Zeit waren es vor allem zwei Schwachstellen, die den Banken und Versicherungen Sorge bereiteten: die OSS-Komponenten OpenSSL und Struts2.

– Unter dem Namen „Heartbleed“ machte das Open Source-Projekt OpenSSL 2014 Schlagzeilen und verunsicherte branchenübergreifend Unternehmen weltweit. Durch die Schwachstelle konnten vertrauliche Informationen per Remote-Zugriff aus dem Speicher abgerufen werden. Das ermöglichte den Diebstahl geheimer Informationen und Authentifizierungsdaten. Heartbleed ist eine der bekanntesten Sicherheitslücken überhaupt und war der Auslöser für zahlreiche Patches und Upgrades betroffener Anwendungen. Der Fokus lag vor allem auf Finanzinstituten, aber auch der gesamte Technologie-Sektor war betroffen.

Verschärft wurde Heartbleed durch die Handlungsunfähigkeit vieler Institute: Zwar war man sich sicher, dass  bestimmte Bereiche von der Sicherheitslücke betroffen waren. Der Großteil der Institute konnte jedoch nicht zeitnah identifizieren, wo genau die mit der Schwachstelle versehenen Komponenten zum Einsatz kamen und welche Produkte davon betroffen waren – das kostete wertvolle Zeit.

– Aktueller ist das Beispiel des Apache Struts2-Projekts, das von der Schwachstelle CVE-2017-5638 betroffen war. Diese erlaubte die externe Ausführung des Codes (Remote Code Execution oder RCE) der betroffenen Programme. So eine Sicherheitslücke, die externen Zugriff ermöglicht, ist besonders gefürchtet, denn durch sie kann der betroffene Code beliebig ausgeführt werden. Mögliche Folgen sind Diebstahl von Finanzmitteln oder Zugangsdaten sowie das Einschleusen von Trojanern oder einer vergleichbaren Malware.

In der Finanzbranche führte die Gefährlichkeit dieser Sicherheitslücke und den dadurch möglichen Angriffen, wie zuvor schon bei Heartbleed, zu zahl- und umfangreichen Patches. Zahlreiche Firewalls wurden außerdem neu konfiguriert und Log-Analysen durchgeführt.

Beide Beispiele zeigen, welchem Risiko der Finanzsektor ausgesetzt ist und wie Sicherheitslücken für Angriffe in der Vergangenheit bereits erfolgreich ausgenutzt wurden. Und sie verdeutlichen die Notwendigkeit, auch in Zukunft ein wachsames Auge auf Software und Software-Schwachstellen zu werfen.

Zurück auf die Schulbank!

Um schneller und effektiver auf Schwachstellen reagieren zu können, ist daher ein umfassendes Sicherheitskonzept nötig, das auch die Compliance abdeckt. Im Zentrum stehen dabei auch alle Mitarbeiter, die für die Entwicklung oder Verwaltung eines Softwareprodukts verantwortlich sind. Sie sollten zumindest Grundkenntnisse über Open-Source-Lizenzierung und Compliance-Vorgaben besitzen und die unternehmensinternen Prozesse und Bestimmungen kennen.

Neben der intensiven Schulung von Mitarbeitern empfiehlt sich zudem ein sogenanntes Open Source Review Board (OSRB). Es beschäftigt sich zum einen mit konkreten Problemanfragen und legt zudem auch die allgemein gültigen Richtlinien für die Verwendung von Drittsoftware fest. Für gewöhnlich besteht das OSRB aus Vertretern der Rechtsabteilung, Ingenieuren, Sicherheitsbeauftragten und anderen involvierten Parteien.

Um Sicherheitslücken vorzubeugen, müssen alle Softwarekomponenten auf die aktuellste Version gepatcht werden. Darüber hinaus muss die Verwaltung von allgemein bekannten Komponenten wie OpenSSL sowie das Identifizieren integrierter und weniger sichtbarer Komponenten sichergestellt werden. Nur wer sich so detailliert mit dem Thema Sicherheit auseinandersetzt, kann das Gesamtrisiko mit jeder neu veröffentlichten Komponente verringern.aj