Soft Scheck Die zehn häufigsten Sicherheitslücken in medizinischen Mobile Apps

Um regulatorischen Anforderungen zu entsprechen, müssen Fitness- und vor allem Gesundheits-Apps auf Herz und Nieren geprüft werden. Dabei können verschiedene Sicherheitslücken identifiziert werden – der IT-Berater Soft Scheck hat eine Top-10 der häufigsten zusammengestellt.

Die europäische Medical Device Regulation (EU) 2017/745 (MDR) und die In-vitro-Diagnostic Regulation (EU) 2017/746 (IvDR) regeln die Sicherheitsprüfung von Software, Firmware, Microcode und mobilen Apps zur Steuerung medizinischer Geräte (hier generell als Software bezeichnet) wie z.B. Herzschrittmacher, Röntgengeräte, Tomografen, Ultraschallgeräte und auch Patientenverwaltungssoftware sowie Netze etc. Diese Regularien entsprechen Regelungen im internationalen Bereich (USA, Kanada, China, Japan etc.), so dass die sicherheitsrelevanten IT-Anforderungen und die Anforderungen an technische Datenschutzmaßnahmen weltweit vergleichbar sind.

IT-Sicherheitsmaßnahmen zum Schutz von Patientendaten notwendig

Medizinische Geräte und Systeme in Praxen und Krankenhäusern werden weit überwiegend vernetzt und sind – mehr oder weniger direkt – ans Internet angeschlossen, so dass IT-Sicherheitsmaßnahmen zum Schutz vor unberechtigter Einsichtnahme und Änderung von (Patienten-)Daten zwingend erforderlich sind. Gleichermaßen muss sichergestellt werden, dass die Software nicht verändert wird - beginnend bereits beim Bootprozess. Häufig werden die Geräte mit Hilfe von mobilen Apps gesteuert. Von der Menge her sind die sogenannten Fitness- und Gesundheits-Apps entscheidender, die mit Hilfe von Sensoren der Handys Gesundheitsdaten, wie messen und speichern von Blutdruck, Herzfrequenz, Blutzucker etc., erzeugen. Diese Daten können bei vielen Apps manipuliert, verfälscht oder auch an Unberechtigte versandt werden. Selbst die zugesicherten Funktionen arbeiten in vielen Fällen unregelmäßig.

Derzeit gibt es nur sehr wenige medizinische Apps für mobile Endgeräte, die den Anforderungen der europäische Medical Device Regulation (EU) 2017/745 (MDR) und die In-vitro-Diagnostic Regulation (EU) 2017/746 (IvDR) entsprechen, obwohl der technische Aufwand und die entsprechenden Kosten sehr überschaubar sind.

Erreicht werden sollen insbesondere die (für Informatiker bekannten) Sachziele Vertraulichkeit, Integrität und Verfügbarkeit der Daten und Systeme. Stand der Technik (ISO 27034) ist ein Security Testing Process, der die Software entwicklungsbegleitend auf sicherheitsrelevante Fehler – Sicherheitslücken – überprüft. Ein solcher Prozess enthält die folgenden Methoden:

• Security Requirements-Analysis – Risk Analysis

• Threat Modeling zur Analyse der Sicherheitsarchitektur

• Static Source Code Analyse – Code Reading

• Penetration Testing des ausführbaren Codes

• Dynamic Analysis – Fuzzing des Codes

• Conformity Testing zur Identifizierung von Backdoors und Covert Channels

Jede Methode ist notwendig, weil sie die Identifizierung andersartiger Sicherheitslücken unterstützt.

Zehn häufigste Sicherheitslücken

Auf der Grundlage der Erfahrungen mit Security Tests seit 2016 lassen sich im Folgenden die 10 häufigsten und schwerwiegendsten Sicherheitslücken und Herausforderungen in medizinischen Mobile Apps nennen:

• 1. Speicherung der Credentials im Klartext: Da viele Entwickler davon ausgehen, dass niemand Zugriff auf das App Verzeichnis hat, speichern Apps Login Informationen oder andere sensible Daten oft unverschlüsselt ab. Durch Sicherheitslücken im System oder gerootete Smartphones besteht dennoch Zugriff auf eben diese Verzeichnisse.

• 2. Unlimitierte Nutzung der API: Durch weglassen von Rate-Limits können Millionen von Anfragen in kürzester Zeit erstellt werden. Dies kann die unterschiedlichsten Auswirkungen haben. Beispielsweise können massenhaft Nutzer erstellt und anhand der Fehlermeldung auf bereits existierende Nutzer geschlossen werden. Es können extrem lange Passwörter gesetzt werden, welche dann unter hohem Zeitaufwand vom Server gehasht werden (Denial of Service) oder es kann versucht werden auf diesem Weg Passwörter per Brute-Force zu erraten.

• 3. Fehlerhafte Verwendung von Kryptographie: Fehler beim Einsatz von Kryptographie Protokollen erlauben es dem Angreifer die Verschlüsselung zu brechen oder öffentliche Schlüssel unbemerkt durch eigene auszutauschen und so den Verkehr mitzulesen.

• 4. Datenschutz: Übermäßig viele Persönliche Daten werden übers Internet versendet, häufig werden Tracker eingebunden, die Daten ohne Einwilligung des Nutzers außerhalb der EU speichern. Oftmals verlangen die Apps mehr Rechte als unbedingt benötigt. Die Gewährten Rechte werden an die eingebunden Tracker vererbt. Es sollte das Prinzip der Datensparsamkeit sowie Least Privilege gewahrt werden.

• 5. Fehler in der Business Logik: Durch Fehler in der Logik ist es einem Angreifer, häufig durch API-Calls möglich Dinge zu tun, die er eigentlich nicht dürfte. Dies kann Beispielsweise sein auf das Konto eines anderen Nutzers zuzugreifen.

• 6. Veraltete Softwareversionen: Das gesamte System muss betrachtet werden. Neben selbst entwickelten Anwendungen muss auch an das Betriebssystem selbst, sowie verwendete Libraries und Software von Drittanbietern die jüngsten Updates ausgerollt werden.

• 7. Best Practices: Zur Verschlüsselung, Passwortspeicherung etc. sollte auf Best Practice Methoden zurückgegriffen werden anstatt eigene Lösungen zu entwickeln.

• 8. Zu enger Fokus: Die von Drittanbietern bezogenen Funktionen müssen ebenfalls Sicherheits-überprüft werden.

• 9. Secure Coding Standards: Beispielsweise sind bei der Programmierung in C/C++ entsprechende Best Practices umzusetzen. So sollten u.a. „Banned Functions“ nicht verwendet werden, da diese anfällig für Angriffe wie Buffer Overflows sind. Auch in Java gibt es Funktionen die für bestimmte Dinge wie das generieren von Zufallszahlen nicht verwendet werden sollten.

• 10. Never Trust User Input: Nutzerdaten müssen vor der Verarbeitung vom Server validiert werden, da ein Angreifer Client-seitige Validierung immer umgehen kann.

In allen Fällen hat der jeweilige Hersteller – ausweislich einer Wiederholungsprüfung – die identifizierten Sicherheitslücken behoben, so dass die Software, Firmware, App oder der Microcode etc. nach dem Stand der Technik als sicher bezeichnet werden kann und damit die Anforderungen der Medical Device Regulation bzw. die In-vitro-Diagnostic Regulation erfüllt.

Dieser Beitrag stammt von unserem Partnerportal Devicemed.

* Die Autoren sind Wilfried Kirsch, Senior Consultant, und Prof. Dr. Hartmut Pohl, Geschäftsführer der Soft Scheck GmbH.

(ID:46561265)