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. (Bild: Synopsys)

Im Zuge der Digitalisierung unserer Gesellschaft, einem starken Zuwachs an elektronischen Systemen und einer Vielzahl an neuen Geschäftsmodellen, muss sich auch die Medizinelektronik einer ganz neuen Art und Dimension von Angriffen stellen. Nur auf den ersten Blick sind dabei die sogenannten Hacker die Schuldigen, die primär monetäre Ziele verfolgen. Die Kosten, um Schwachstellen auszunutzen sind marginal, die Auswirkungen oft immens. Wenn es um die eigentliche Haftungsfrage geht, wird ganz schnell das Verursacherprinzip zu Rate gezogen: Sind alle erdenklichen und wirtschaftlich machbaren Vorsorgemöglichkeiten schon während der Entwicklung getroffen worden, um mögliche Angriffsszenarien zu erschweren?

Fast täglich berichten die Medien von neuen Cyber-Angriffen. Begriffe wie Heartbleed, Ransomware und Stuxnet sind auch vielen Laien geläufig geworden. Die betroffenen Anbieter sind oftmals gezwungen, ihre Software nachzubessern, um per Update Schwachstellen zu beheben. Dieses entspricht jedoch oft einer Operation am offenen Herzen, die deshalb erfolgte, weil keine gründliche Vorsorgeuntersuchung stattfand.  Viele Cyber-Angriffe sind nur deshalb möglich, weil es prinzipielle sicherheitsrelevante Nachlässigkeiten im Entwicklungsprozess gibt, die erst bei der zunehmenden Vernetzung offensichtlich werden.

Eckdaten

In diesem Beitrag stellen die Autoren einige der wesentlichen Präventionsmaßnahmen für sicherheitsrelevante Software in der Medizintechnik vor. Sie gehen dabei insbesondere auf Methoden und Aktivitäten ein, die sich sowohl für die eigenen Entwicklungsprozesse als auch für die Bewertung der eingesetzten Software und -Komponenten zu Rate ziehen lassen.

Eine hundertprozentige Sicherheit kann und wird es nicht geben. Doch wer proaktiv sein möchte, sollte sich schon während der Produktdefinitionsphase über seine individuellen möglichen Angriffsflächen und -vektoren erkundigen, während der Entwicklung seinen eigenen Quelltext in punkto Schwachstellen analysieren, bei Einsatz von Open-Source-Software nach Lizenzobligationen und bekannten Schwachstellen suchen sowie abschließend ein zielgerichtetes Fuzzing durchführen.  Wer jedoch schutzlos und blind seine Produkte auf den Markt bringt, darf sich nicht wundern, wenn er vor dem Gesetz und dem Kunden als grob fahrlässiger Verursacher gebrandmarkt wird.

Im Gesundheitssektor stehen Software-Hersteller besonderen Anforderungen gegenüber. Da sind zum einen zahlreiche personenbezogene, sensitive Daten. Hier ist ein hoher Schutzbedarf sowohl beim Transport wie auch bei der Speicherung von elektronischen Patienteninformationen erforderlich. Die europäischen Datenschutzverordnungen oder auch die HIPPA für den US-Markt fordern daher Privacy- beziehungsweise Security-by-Design-Prinzipien bei der Softwareentwicklung. Ferner stehen gerade Hersteller von modernen, bildgebenden Diagnosesystemen – wie NMR- oder Computertomographen – im Wettbewerb, eine reibungslose Anbindung an die Krankenhaus-IT auf einem weltweiten Markt zu gewährleisten. Hier kommen oft spezialisierte, umfangreiche Übertragungsprotokolle wie DICOM zum Einsatz. Durch die Vernetzung ergeben sich neue Anforderungen an Interoperabilität und Datensicherheit. Nicht zuletzt werden Medizingeräte im Operationsbereich, zur Medikation oder Implantate zunehmend vernetzt und fernsteuerbar.

Auch klassische Medizingeräte- und -Softwareanbieter setzen vermehrt Open-Source-Komponenten ein. Dieses gilt insbesondere für den Konsumsektor sowie bei mobilen Gesundheits- und Fitness-Apps.

Die Staatssekretärin Dr. Suder hat im Februar 2016 im Bundestag zur Sicherung der inneren Sicherheit eine allgemeine „Cyber-Hygiene“ gefordert. Dabei erwähnt sie auch die Verantwortung um die erhöhte „Cyber-Awareness“ und „Cyber-Resilienz“ bei der Wirtschaft, betont aber nicht, dieser Verantwortung schon im Entwicklungsprozess gerecht zu werden. Cyber-Hygiene lässt sich unter anderem der „Software Security Touchpoints“ genannten Methodik betreiben. Dieses sind wesentliche sicherheitsrelevante Aktivitäten, sogenannte Berührungspunkte, die sich in einen bestehenden Software-Entwicklungsprozess eingliedern lassen.

Prävention von Karies und Verkalkungen in der Software

Analog kann man den Vergleich zur menschlichen Hygiene heranziehen. Auch dort gibt es nicht nur eine Hygienemaßnahme. Gesundheitsvorsorge und Hygiene müssen die Menschen im Kontext der aktuellen Lebenssituation betrachten. Tägliches Händewaschen und Zähneputzen reichen nicht aus, wenn die nächste Reise in ein Malariagebiet geht; die Malariatablette reicht nicht aus, wenn in der Familie genetische Indikatoren anderer Art vorliegen.

Im weiteren Verlauf fokussiert sich dieser Beitrag auf automatisierte Diagnose- und Prüfverfahren, die sich während der Entwicklung anwenden lassen und die effiziente Präventionen zu relativ niedrigen Kosten ermöglichen. Dazu gehören die automatische Analyse von Source-Code mit einem Quelltext-Prüfwerkzeug inklusive der Source-Code Composition Analysis (Prüfwerkzeug für Fremd-Software-Komponenten) sowie einer automatisierten Penetrations-Testing-Methodik, dem Fuzz-Testing.

Bild 1: Software Security Touchpoints

Bild 1: Software Security Touchpoints. Synopsys

Sicherheitslücken: Die Karies in der Software

Defekte in einer Applikation sind oft unausweichlich, ihre Ursachen jedoch vielfältig. Ein falsches Systemdesign, die mangelhafte Beachtung von Sicherheitsanforderungen oder eben eine fehlerhafte Programmierung können der Grund für Schwachstellen sein.

Schwachstellen in der Software sind wie Karies: Sie sind Sicherheitslücken in dem Quellcode, die ein Angreifer ausnutzen kann.  Diese Sicherheitslücken lassen sich systematisch ihrer Ursache nach klassifizieren; eine vollständige Liste ist in der „Common Weakness Enumeration“ (CWE) zu finden. Des Weiteren gibt es unter cwe.mitre.org/top25/ eine spezifische Auflistung der 25 häufigsten Software-Schwachstellen, unter www.owasp.org/index.php/Mobile_Top_10_2016-Top_10 eine Zusammenfassung der häufigsten Sicherheitsrisiken für mobile Applikationen sowie unter www.owasp.org/index.php/Top_10-2017_Top_10 eine Liste der Sicherheitsrisiken in Webapplikationen.

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.

Der Allergietest: Penetrationstesten von Software

Neben der Diagnose von allgemeingültigen Schwachstellen, wie sie bereits angesprochen wurde, ist es hilfreich, die auszuliefernde Software auf Herz und Nieren zu prüfen.  Dazu gehört unter anderem das klassische dynamische Testen.  Diese Penetrationstests entdeckten zum Beispiel den bekannten Heartbleed-Fehler (www.heartbleed.com), der auf einer unzureichenden Abfrage aller gültigen Eingabeparameter beim „Heartbeat“ des Open-SSL-Protokolls zurückzuführen ist.

Zwar lassen sich diese Penetrationstests auch mit entsprechendem (Protokoll-)Expertenwissen manuell durchführen, aber weil der Testraum hierfür sehr groß werden kann, bietet sich ein automatisierter Test an, das sogenannte Fuzz-Testing (oder auch Fuzzing). Fuzzing ist eine Methodik um die Fehleranfälligkeit eines Zielobjektes zu prüfen (Robustheit), gleichzeitig aber auch um sicherheitsrelevante Defekte zu provozieren (Cyber-Sicherheit). Das zu testende System wird dabei mit großen Mengen von Daten förmlich beschossen, um zu beobachten, wie es sich unter der Eingabe ungewöhnlicher Daten verhält.

Insbesondere beim Testen von Kommunikationsprotokollen gibt es Expertensysteme, die gezielt versuchen, Randbedingungen auszunutzen. Heutige Fuzzer der dritten Generation haben ein tiefgehendes Protokollverständnis, das es erlaubt, Kommunikationsschnittstellen mit nichtkonformen Anfragen intelligent, unnachgiebig und reproduzierbar zu testen. So lassen sich beispielsweise durch intelligente Permutationen von ungültigen Eingabewerten auf der Kommunikationsebene eines Protokolls solche Programmierfehler finden, die Zugriff zum System oder zu Daten- beziehungsweise Speicherfragmenten ermöglichen, wie es beim Heartbleed-Fehler der Fall war.

Fuzzing kann dann zum Einsatz kommen, wenn die Software bereits ausführbar und testbar ist. Fuzzing eignet sich insbesondere dazu, manuelles Testen zu komplementieren und Expertenwissen automatisiert anzuwenden.

Cyber-Hygiene leben

Die zuvor beschriebenen automatisierten Test-Aktivitäten sind essenziell für einen sicheren Software-Entwicklungsprozesses. Wie bei der menschlichen Hygiene und Absicherung bedarf es zuallererst des notwendigen Bewusstseins über mögliche Gefahren und Bedrohungslagen. Eine ausführliche Bildung aller beteiligten Mitarbeiter durch Security-Training sowie tiefgehende Analysen des Produkteinsatzes und seiner Architekturen durch eine Bedrohungs- und Risiko-Analyse gehören ebenso dazu wie ein von der Unternehmens- und Entwicklungsleitung eingeforderter und bewertbarer Prozess. Ohne die notwendigen Strukturen im Unternehmen wird ein sporadischer Einsatz von sicherheitsrelevanten Werkzeugen im Sande verlaufen.

Startpunkt innerhalb eines Unternehmens oder eines Software-Entwicklungsprozesses sollte die Analyse des Ist-Zustandes sein; dies geschieht durch Betrachtung der Aufgabe- und Ablauforganisation, der Prozesse und der eingesetzten Tools sowie der abschließenden Prüfverfahren. Hier bietet sich das etablierte Reifegrad Modell BSIMM (Build-Security-In-Maturity-Model, www.bsimm.com) an, das es auch erlaubt, sich anonymisiert mit den Prozessen anderer Firmen in der gleichen Domäne zu vergleichen.  Darauf aufbauend lassen sich dann entsprechende entwicklungsbegleitende Maßnahmen einpflegen, um Sicherheit als elementaren Aspekt im Entwicklungszyklus zu leben.

Alexios Fakos

arbeitet bei Synopsys

Dr. Elof Frank

arbeitet bei Synopsys

Matthias Krämer

arbeitet bei Synopsys

(av)

Sie möchten gerne weiterlesen?

Unternehmen

Synopsys GmbH Europa-Forum-II Building

Karl-Hammerschmidt-Str. 34
85609 Aschheim/Dornach
Germany