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.

Seite 1 von 3123