How-to Medical Device-Security
Die 10 häufigsten Sicherheitslücken in Medical Devices
Nicht erst seit Corona steht die Herstellung von Sicherheit bei zunehmend vernetzten medizinischen Geräten auf der Agenda. Wir nennen die in der Security-Testing-Praxis am häufigsten entdeckten Sicherheitslücken und, wie diese von Herstellern und Entwicklern systematisch eliminiert werden können.
Die europäische Medical Device Regulation (EU) 2017/745 (MDR) und die In-vitro-Diagnostic Regulation (EU) 2017/746 (IvDR) regeln die Sicherheitsüberprü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. Die Verordnungen sollen derzeit bis Mai 2020 (Medizinprodukte) und bis Mai 2022 (In-vitro Diagnostika) schrittweise in Kraft treten.
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 z.B. MDCG 2019-16 und dem „Leitfaden zur Nutzung des MDS2 aus 2019: Sicherheit von Medizinprodukten“ der Allianz für Cyber-Sicherheit weltweit vergleichbar sind.
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 Manipulation der Geräte sowie Einsichtnahme und Änderung von (Patienten-)daten zwingend erforderlich sind. Gleichermaßen muss sichergestellt werden, dass die die Geräte steuernde Software nicht verändert wird - beginnend bereits beim Bootprozess.
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 Medizinprodukten nennen:
- Datenschutz. Unzureichend geschützte Patientendaten: Die sensiblen Daten müssen mit geeigneten technischen Maßnahmen vor unberechtigtem Zugriff und Manipulation geschützt werden. Mittels Verschlüsselung sind die Daten auch bei Datenübertragung und vor physischem Zugriff zu schützen.
- Authentifizierung. Unzureichende Authentifizierung vor dem Gerätezugriff: Um sicherzustellen das nur berechtigte Personen auf das medizinische Gerät (und die Daten) zugreifen, hat vor jeder Interaktion mit der Software oder dem Gerät eine Authentifizierung zu erfolgen.
- Generische/schwache Standardkonfigurationen: Die Wahl von Standardpasswörtern für Geräte oder Applikationen muss auf starke, gerätespezifische Kennwörter setzen. Gleiche Passwörter für Geräte, die vielfach verkauft werden, senken massiv das Sicherheitsniveau.
- Veraltete Softwareversionen. Das Gesamtsystem muss betrachtet werden. Neben selbst entwickelten Anwendungen müssen die jüngsten Updates auch an das Betriebssystem sowie verwendete Libraries und Software von Drittanbietern ausgerollt werden.
- Updateprozess. Fehlende oder unzureichende Signaturprüfung: Um Authentizität und Integrität einer Softwareaktualisierung zu gewährleisten und unberechtigte Änderungen zu verhindern, muss eine Signaturprüfung vor Ausführung des Updates erfolgen.
- Best Practices. Zur Verschlüsselung, Passwortspeicherung etc. sollte auf Best Practice Methoden zurückgegriffen werden, anstatt eigene Lösungen zu entwickeln.
- Zu enger Fokus. Die von Drittanbietern bezogenen Funktionen müssen ebenfalls Sicherheits-überprüft werden. Beispielsweise gilt dies auch für HL7/DICOM Protokoll-Implementierungen, die typischerweise in Form von Third Party Libraries eingebunden werden.
- 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.
- Never Trust User Input. Unabhängig davon, ob Daten über das Netzwerk via HL7/DICOM oder lokal zur Verfügung gestellt werden, müssen Nutzerdaten vor der Verarbeitung validiert werden.
- Least Privilege. Anwendungen dürfen nur die Berechtigungen erhalten, die für den Betrieb des Systems unverzichtbar sind. Im Fall eines erfolgreichen Angriffs kann so das Schadensausmaß begrenzt werden.
Diese Sicherheitsmängel werden regelmäßig mit einem (von softScheck angewandten) Security Testing Process entdeckt, der die Software entwicklungsbegleitend auf sicherheitsrelevante Fehler – Sicherheitslücken – überprüft. Er entspricht dem Stand der Technik (ISO 27034) und erreicht insbesondere die (für Informatiker bekannten) Sachziele Vertraulichkeit, Integrität und Verfügbarkeit der Daten und Systeme.
Ein solcher Prozess enthält die folgenden 6 Methoden:
– Security Requirements-Analysis - Riskanalysis
– Threat Modeling zur Analyse der Sicherheitsarchitektur
– Static Source Code Analyse – Code Reading des Quellcodes
– Penetration Testing des ausführbaren Codes
– Dynamic Analysis – Fuzzing des ausführbaren Codes
– Conformity Testing zur Identifizierung von Backdoors und Covert Channels
Jede Methode ist notwendig, weil sie die Identifizierung andersartiger Sicherheitslücken unterstützt. Die oben beschriebenen, vom Security Testing Prozess identifizierten Sicherheitslücken wurden in allen Fällen durch den jeweiligen Hersteller – ausweislich einer Wiederholungsprüfung – 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. der In-vitro-Diagnostic Regulation erfüllt.
Lesen Sie mehr zum Thema
