Software überprüfen

Liegt der Quellcode vor, bedient man sich häufig der statischen Code-Analyse, um Schwachstellen während der Implementierungsphase frühzeitig zu identifizieren. Manuelle Code-Analysen lassen sich nur für kleinere Projekte durchführen, da die Komplexität der Fehlerfindung mit zunehmender Codegröße exponenziell zunimmt. Werkzeuge zur statischen Code-Analyse erlauben den regelmäßigen und automatisierten Scan. Sogenannte Checker durchsuchen dabei gezielt nach bekannten Mustern im Quelltext und geben in einer Analyse den Ausgangspunkt sowie die Ursache der Schwachstelle an. Mit ihrer Hilfe werden Entwickler und Produktverantwortliche zeitnah auf genau solche Schwachstellen verwiesen, die es zu überprüfen gilt.

Moderne Werkzeuge kombinieren dabei verschiedene Technologien zur Excecution-, Dataflow- und Boundary-Analyse, berücksichtigen auf der semantischen Sprachebene moderne Programmierparadigmen wie Objektorientierung, Polymorphismus, Templates oder Nebenläufigkeit und können so dem Software-Entwickler eine präzise Evidenz eines Fehlverhaltens im Quelltext aufweisen.

Bild 2: Die Struktur der Heartbleed-Sicherheitlücke (CVE-2014-0160) in der OpenSSL Bibliothek. Durch statische Codeanalyse ist es offensichtlich, dass von einem eingehenden Datenpaket über die Netzwerkschnittstelle (Zeile 417) ein bestimmtes Datenfeld ungeprüft verwendet wird, um einen beliebigen Speicherbereich auszulesen (Payload-Länge in Zeile 1487).

Bild 2: Die Struktur der Heartbleed-Sicherheitlücke (CVE-2014-0160) in der Open-SSL-Bibliothek. Durch statische Codeanalyse ist es offensichtlich, dass von einem eingehenden Datenpaket über die Netzwerkschnittstelle (Zeile 417) ein bestimmtes Datenfeld ungeprüft verwendet wird, um einen beliebigen Speicherbereich auszulesen (Payload-Länge in Zeile 1487). Synopsys

Statische Werkzeuge haben sich in den letzten Jahren weiterentwickelt, sodass wesentliche Klassen von schwerwiegenden Sicherheitslücken heute im Code erkannt werden können. Die Leistungsfähigkeit wird exemplarisch deutlich an dem Datenleck der Heartbeat-Implementierung der Open-SSL-Bibliothek, die über Jahre nicht behoben wurde (Bild 2). Mit heutigen Mitteln wird – ohne besondere weitere Annahmen – der Datenfluss von einer nicht vertrauenswürdigen Quelle („tainted source“), hier dem Lesen von Daten aus einer Socket-Schnittstelle vom Netzwerk, zu einer kritischen Leseoperation aus dem Hauptspeicher („critical sink“) aufgezeigt. Ein Angreifer war so in der Lage, die Länge der Nutzdaten (Payload) über einen geeignet modifizierten Heartbeat-Request zu beeinflussen. Der Fehler blieb nicht zuletzt wegen der Komplexität der verwendeten Datenstrukturen unentdeckt.

Statische Code-Analyse lässt sich unmittelbar in den Entwicklungsprozess einbinden. Dieses kann entweder durch Integration in die Entwicklungsumgebung, durch Integration in den sogenannten Software-Build-Prozess oder als Teil des Review-Prozesses erfolgen. Sollte man intern nicht die Kompetenzen oder Möglichkeiten haben, ist dieses auch als Dienstleistung durch einen Drittanbieter erfüllbar. Ohne eine statische Code-Analyse lässt sich kaum eine hinreichende Aussage über den Sicherheits-Reifegrad einer Software treffen.

Generell ist es sinnvoll, die statische Code-Analyse gezielt im jeweiligen Risikokontext durchzuführen. Dazu gehört eine vorhergehende Risikobewertung (Risk Analysis) sowie eine Bedrohungsanalyse (Threat Modeling). Diese erlauben es, eine Dringlichkeitsabschätzung zu bekommen, um Schwachstellen zu priorisieren und ein Risikoprofil an die Produktverantwortlichen abzugeben.

Veraltete Fremd-Komponenten: Die Verkalkungen in der Software

Auch in der Medizintechnik setzen viele Unternehmen Fremd-Komponenten (Open-Source-Projekte und Bibliotheken) ein. Ohne Open-Source könnte die momentane digitale Revolution überhaupt nicht stattfinden. Probleme entstehen jedoch, wenn komplexe Applikationen mithilfe von Open-Source-Paketen mehr zusammengestöpselt als gezielt entwickelt und getestet werden.

Bild 3: Open-Source schleicht sich auf vielfältigen Wegen in die Applikationen.

Bild 3: Open-Source schleicht sich auf vielfältigen Wegen in die Applikationen. Synopsys

Die eigentlichen Open-Source Projekte selbst dürfen ihre Software bei kommerziellen Anbietern statisch analysieren lassen und tun dies auch meist (scan.coverity.com). So stellt eine öffentliche Datenbank unter https://nvd.nist.gov die Schwachstellen (Known Vulnerabilities) für Open-Source-Komponenten bereit. Das heißt aber nicht, dass diese Probleme dann auch behoben werden – im Gegenteil. Einer Studie der Firma Blackduck Software zufolge enthalten in der Medizintechnik 46 Prozent aller untersuchten Applikationen Open-Source-Anteile, von denen wiederum 46 Prozent hochriskante Komponenten enthielten.

Wie Software trotz Open-Source gesund bleibt

Wer somit Open-Source einsetzt, muss sich daher mit folgenden Fragestellungen auseinandersetzen: Welche Open-Source-Software haben die eigenen Entwickler denn überhaupt eingebunden, welche bekannten Schwachstellen und Verwundbarkeiten sind darin enthalten, und gibt es eventuell neuere Versionen mit behobenen Sicherheitslücken? Darüber hinaus stellt sich oft die Frage, ob die Open-Source-Software überhaupt mit den Lizenzvereinbarungen des eigenen Produktes kompatibel ist.

Es bedarf daher kontinuierlich einer automatisierten Inventarisierung aller benutzten Open-Source-Komponenten mit der entsprechenden Bewertung und Absicherung der enthaltenen Schwachstellen und Verwundbarkeiten. Hier hat sich die „Software Composition Analysis“ (SCA) etabliert, die den vorhandenen Quelltext nicht nur nach ganzen Projekten sondern auch nach bekannten Open-Source-Fragmenten durchsucht. Gute Werkzeuge gleichen diese Informationen sowohl mit Datenbanken zu den bekannten Schwachstellen als auch mit den Lizenz-Obligationen ab, um einerseits die Sicherheit und andererseits auch die Lizenzkompatibilität zu gewährleisten. Selbst wer ganze Produkte von Drittanbietern in Binärform lizensiert, kann sich sogenannter Binary-Scanner bedienen, die vollständige Inventarlisten mit ähnlichen Abgleichungen extrahieren.

Diese Diagnosen auf bestehende Software-Komponenten und deren „Verkalkungen“ sind zwingend, um keine veraltete Software mit Sicherheitslücken einzusetzen, die später zu einem Produktrückruf führen können. Es ist insbesondere wichtig, diesen Prozess auch nach der Produktauslieferung weiter zu betreiben, da viele Sicherheitslücken erst im Laufe der Zeit entdeckt werden.  Daher ist es sinnvoll, einen automatischen Benachrichtigungsservice aufzusetzen, der anschlägt, wenn eine neue Sicherheitslücke in einer eingesetzten Open-Source-Komponente entdeckt wird. Diese Features unterstützen professionelle Anbieter von entsprechenden Werkzeugen.

Seite 2 von 3123