In unseren Projekten mit Herstellern von Medizinprodukten rückt das Thema IT-Sicherheit in den letzten Jahren immer stärker in den Fokus. Viele Hersteller stehen vor der Herausforderung, dass Benannte Stellen im Rahmen der Konformitätsbewertung konkrete Nachweise zur Informationssicherheit einfordern.
Der Grund dafür liegt in der fortschreitenden Digitalisierung der Medizintechnik. Kaum ein modernes Medizinprodukt kommt noch ohne Cloud-Backends, mobile Steuerungs-Apps für iOS/Android oder Bluetooth-Low-Energy-Schnittstellen (BLE) aus. Auch reine Software as a Medical Device (SaMD) nimmt einen immer größeren Stellenwert ein. Mit jedem dieser Bausteine wächst jedoch die Angriffsfläche, was eine systematische Überprüfung der IT-Sicherheit erforderlich macht.
Rechtliche Grundlage
Die MDR verlangt dabei im Anhang I bei „Produkte, zu deren Bestandteilen programmierbare Elektroniksysteme gehören, und Produkte in Form einer Software“ unter Punkt 17.2 die Verifzierung und Validierung, dass das Produkt bzw die Software nach dem Stand der Technik entwickelt wurde – aus der Perspektive der IT-Sicherheit:
17.2 Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.
MDR, Anhang I – Verordnung (EU) 2017/745 des Europäischen Parlaments und des Rates vom 5. April 2017 über Medizinprodukte, zur Änderung der Richtlinie 2001/83/EG, der Verordnung (EG) Nr. 178/2002 und der Verordnung (EG) Nr. 1223/2009 und zur Aufhebung der Richtlinien 90/385/EWG und 93/42/EWG des Rates (Text von Bedeutung für den EWR. )
Im Medical Device Coordination Group Document „MDCG 2019-16 Guidance on Cybersecurity for medical devices“ findet sich nun als Konkretisierung der vorherigen Verifzierung- und Validierungsbestimmung Penetration Testing als eine Möglichkeit:
MDR Annex I Section 17.2 and IVDR Annex I Section 16.2 require for devices that incorporate software or for software that are devices in themselves, that the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of the development life cycle, risk management, including information security, verification and validation. The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing. Additional security testing can be one by using tools for secure code analysis and tools that scan for open source code and libraries used in the product, to identify components with known issues.
Medical Device Coordination Group Document, MDCG 2019-16
Scope-Definition und Abgleich mit der Risikoanalyse
Bei der Scoping-Phase beobachten wir in der Praxis häufig zwei unterschiedliche Probleme:
- Zu stark verkürzter Scope: Potenziell relevante Schnittstellen (wie Cloud-APIs oder physische Wartungsschnittstellen) werden ausgeklammert, um Zeit und Aufwand zu sparen. Das kann funktionieren, führt aber bei den Benannten Stellen eher zu kritischen Rückfragen und Probleme im Zulassungsprozess.
- Übermäßig breiter Scope: Es wird versucht, jeden theoretisch denkbaren Vektor zu prüfen. Unabhängig davon, wie realistisch das Bedrohungsszenario für das konkrete Produkt überhaupt ist.
Aus unserer Erfahrung ist es entscheidend, den Scope eines MDR-Pentests eng an der herstellereigenen Risikoanalyse auszurichten und dabei pragmatisch vorzugehen.
Beispiel aus der Praxis: Bei einem Medizinprodukt, das ausschließlich für den häuslichen Bereich (Home-Only) vorgesehen ist, ist die Bedrohungslage eine andere als bei einem Gerät im Krankenhausnetzwerk. Es ist in der Regel nicht verhältnismäßig, tagelang zu prüfen, ob ein Angreifer physisch vor Ort eine lokale BLE-Verbindung manipulieren könnte, wenn derselbe Angreifer über unzureichend geschützte Backend-APIs oder App-Schnittstellen potenziell auf weitaus mehr Daten zugreifen oder größere Schäden anrichten könnte.
Der Prüffokus sollte daher auf den Angriffsvektoren liegen, die ein realistisches Risiko für die Patientensicherheit oder den Datenschutz darstellen.
Fazit
Ein Penetrationstest im Kontext der MDR erfüllt dann seinen Zweck, wenn der Scope auf Basis einer realistischen Risikoanalyse definiert wird. Auf diese Weise erhalten Hersteller einen fundierten Nachweis für die Konformitätsbewertung und stellen sicher, dass die tatsächlichen Risiken des Produkts angemessen adressiert werden.
Die Kernfragen für einen Penetrationstest eines Medizinprodukts oder einer SaMD sind dabei meistens:
- Kann die Gesundheit des Patienten durch Manipulation des Geräts, der Software oder ihrer Konfiguration negativ beeinträchtigt werden?
- Können Messdaten, medizinische Daten, Berechnungen, Diagnosen oder Therapieempfehlungen manipuliert werden, sodass aufgrund einer falschen oder ausbleibenden Therapie ein Schaden für den Patienten entsteht?
- Kann die Verfügbarkeit des Geräts oder der Software so beeinträchtigt werden, dass eine notwendige Diagnose, Überwachung oder Behandlung verzögert oder verhindert wird?
- Sind die Gesundheitsdaten des Patienten bei der Speicherung, Verarbeitung und Übertragung angemessen nach dem Stand der Technik geschützt?
