Author: Patrick Sauer

Die IEC 81001-5-1 definiert Anforderungen an den Lebenszyklus für die Entwicklung und Wartung von Gesundheitsanwendungen und die Informationstechnik innerhalb von Medizingeräten. Um dies zu erreichen stellt die Norm Anforderungen an verschiedene Prozesse im Lebenszyklus eines Medizingeräts und gliedert sich primär in folgende Anforderungskategorien.

• Quality management
• Software Development Process
• Software Maintenance Process
• Security Risk Management Process
• Software Configuration Management Process
• Software problem resolution Process

Innerhalb vom Software Development Process gibt es die Anforderung an das Software System Testing, dass sich in Security Requirement Testing, Threat Mitigation Testing, Vulnerability Testing und Penetration Testing unterteilt.

Der Hersteller muss dabei einen Penetrationstest beauftragen, um Sicherheitsschwachstellen in der Software (Gesundheitsanwendung bzw Medizingerät) zu identifizieren. Die IEC 81001-5-1 fordert, dass im Penetrationstest versucht wird die Vertraulichkeit, Integrität und die Verfügbarkeit zu beeinträchtigen. Hierzu können auch mehrere Verteidigungslinien im Design umgangen werden müssen, indem der Einsatz von Tools sowie insbesondere manuelle Fähigkeiten des Penetrationstesters zum Einsatz kommt.

Hervorgehoben wird in der Norm dazu noch, dass die Penetrationstester unabhängig von der Entwicklung sein müssen. Da die wenigsten Medizingeräte-Hersteller über eine eigene Abteilung für Penetrationstests verfügt, muss in der Regel ein darauf spezialisiertes Unternehmen beauftragt werden.

Die MDR verlangt 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

Die Teilnahme am Compliance-Programm für Microsoft 365-Zertifizierungs von Apps für Teams-Anwendungen, SharePoint-Apps/Add-Ins, Office-Add-Ins und WebApps erfordert die Durchführung eines Penetrationstests. Bei der Erstdokumenteneinreichung muss ein Unternehmen Unterlagen und Nachweise einreichen. Neben anderen Doikumenten ist ein Bericht von einem Penetrationstest erforderlich, der innerhalb der letzten 12 Monate abgeschlossen wurde. Der Pentest muss der Live-Umgebung prüfen, die die Bereitstellung der App unterstützt, sowie alle zusätzlichen Umgebungen, die den Betrieb der App ermöglichen. Wenn Segmentierungskontrollen vorhanden sind, müssen diese ebenfalls getestet werden.

Die Pentest-Anforderungen von Microsoft sind:

• Alle 12 Monate muss jährlich ein Applikations- und Infrastruktur-Pentest stattfinden.
• Diese Tests müssen von einem renommierten unabhängigen Unternehmen durchgeführt werden.
• Die Behebung identifizierter kritischer und hochriskanter Schwachstellen muss innerhalb eines Monats erfolgen nachdem Pentest-Bericht abgeschlossen ist.
• Die gesamte externe Angriffsfläche (IP-Adressen, URLs, API-Endpunkte usw.) muss in den Umfang des Penetrationstests einbezogen und im Penetrationstestbericht dokumentiert werden.
• Penetrationstests für Webanwendungen müssen alle typischen Schwachstellenklassen umfassen; zum Beispiel die aktuellsten OWASP Top 10 oder SANS Top 25 CWE.
• Ein erneutes Testen identifizierter Schwachstellen durch das Penetrationstestunternehmen ist nicht erforderlich – Behebung und Selbstüberprüfung sind ausreichend, jedoch müssen während der Bewertung angemessene Nachweise für eine ausreichende Behebung erbracht werden. Das erneute Testen identifizierter Schwachstellen ist dennoch Best Practice in der Informationssicherheit.
• Penetrationstestberichte werden am Ende überprüft, um sicherzustellen, dass es keine Schwachstellen gibt, die aus einer der folgenden Kategorien stammen:
  • Nicht unterstütztes Betriebssystem.
  • Standardmäßige, aufzählbare oder erratbare Administratorkonten.
  • SQL-Injection-Risiken
  • XSS
  • Sicherheitslücken bei Directory Traversal (Dateipfad).
  • Typische HTTP-Schwachstellen, z. B. Header-Response-Splitting, Request-Smuggling und Desync-Angriffe.
  • Offenlegung des Quellcodes (einschließlich LFI).
  • Jede kritische oder hoher Score nach CVSS-Richtlinien für das Patch-Management
  • Jede bedeutende technische Schwachstelle, die leicht ausgenutzt werden kann, um eine große Menge an EUII oder OUI zu kompromittieren.