Security Patches – aus der regulatorischen Brille betrachtet

Freitag 12. Januar 2018

Unter einem Security Patch versteht man eine Nachbesserung an einer Software, um eine Sicherheitslücke zu stopfen. Für einen Security Patch gelten teilweise andere regulatorische Anforderungen als an andere Software Updates. Auf was Sie achten müssen, erfahren Sie in diesem Beitrag.

Security Patch

Definition

Eine etwas längliche aber hilfreiche Definition des Begriffs stammt von der FDA:

Definition: Begriff

„Cybersecurity “routine updates and patches” are updates or patches to a device to increase device security and/or remediate vulnerabilities associated with controlled risk and not to reduce a risk to health or correct a violation of the FD&C Act. They include any regularly scheduled security updates or patches to a device, including upgrades to the software, firmware, programmable logic, hardware, or security of a device to increase device security as well as updates or patches to address vulnerabilities associated with controlled risk performed earlier than their regularly scheduled deployment cycle even if they are distributed to multiple units.“

Quelle: FDA Guidance „Postmarket Management of Cybersecurity in Medical Devices“

Abgrenzung von Security Patches und Software Updates

Ein Security Patch unterscheidet sich von einem „normalen“ Software Update, dadurch, dass er

  • ausschließlich dem Schließen von Sicherheitslücken dient,
  • keine Funktionalität ändert oder gar hinzufügt,
  • keinesfalls die Zweckbestimmung modifiziert,
  • nicht der Beseitigung einer Nicht-Konformität dient und
  • auch keine Maßnahme zur Risikominimierung wie ein Bug-Fix darstellt, außer es geht um Risiken durch mangelnde IT-Sicherheit.

Security Patch

Beispiele für Security Patches

Viele Security Patches stammen von den OTS- bzw. SOUP-Herstellern wie Microsoft (z.B. für Windows oder .NET), Oracle (z.B. für die Datenbanken oder für Java) oder Apple (z.B. für iOS). Allerdings enthalten diese Software-Patches regelmäßig auch neue oder geänderte Funktionen, so dass die Abgrenzung nicht immer gelingt.

Regulatorische Anforderungen

IEC 62304

Die IEC 62304 verlangt von den Herstellern die SOUP-Komponenten kontinuierlich zu überwachen, beispielsweise Release-Notes und Bug-Reports zu studieren. Stellt der Hersteller fest, dass damit ein Sicherheitsproblem (oder sonstiges Problem) behoben wird, das zu inakzeptablen Risiken führen könnte, ist eine Maßnahme erforderlich.

MDR

Die MDR stellt Anforderungen an die IT-Sicherheit, macht aber keine Aussagen zum Ausliefern von Patches. Auch unterscheidet sie Patches und Updates nicht.

UL 2900-1

Sehr konkret ist der UL 2900-1 zur Software Cyber-Security. Er fordert von den Herstellern, dass sie in der Lage sein müssen, Patches innerhalb von 14 Tagen auszuliefern.

FDA Post-Market Guidance

Die FDA stellt in Ihrem Post-Market-Guidance zur Cybersecurity klar, dass proaktive Maßnahmen zur Verbesserung der Cybersecurity gemäß 21 CFR part 806.10 der FDA nicht gemeldet werden müssen.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema FDA Anforderungen an die Cybersecurity.

Falls Ihr Software-Upgrade mehr ist als nur ein proaktive Maßnahme zur Verbesserung der Cybersecurity, liegt ein Software-Change vor, den Sie bewerten müssen.

Weiterführende Informationen

Finden Sie weiterführende Informationen in einem Artikel zu Software-Changes bei der FDA.

 

ISO 13485

Die ISO 13485 nennt keine spezifischen Anforderungen für Software. Sie fordert, dass die Produkte immer die grundlegenden Anforderungen einhalten. Darüber, ob eine Änderung an der Software / einem Produkt eine neue Konformitätsbewertung erfordert, macht sie keine Aussagen. Das Johner Institut empfiehlt, gemäß dem Artikel zu den Software-Changes vorzugehen.

Security Patches bei Betreibern (z.B. Krankenhäusern)

Vielleicht geht es Ihnen manchmal wie mir in der Vorlesung: Auf einmal werden alle Rechner heruntergefahren. Dann ist sofort klar: es gibt einen neuen Windows Security Patch – und zwar einen, den Microsoft als kritisch einstuft. Dabei definiert Microsoft eine kritische Schwachstelle als eine, „die für die Verbreitung eines Internet-Wurms ausgenützt werden kann, ohne dass hierfür spezielle Aktionen des Benutzers erforderlich sind“.

Einen Patch auf den Rechnern einer Hochschule automatisiert einspielen zu lassen, mag sinnvoll sein. Das gleiche auf Systemen zu tun, die als Medizinprodukt klassifiziert sind, kann schlicht unzulässig und sogar lebensbedrohlich sein. Es zu unterlassen u.U. ebenfalls. Eine logische Zwickmühle, eine echte „catch-22“ Situation.

Bitte Patch nicht sofort aufspielen!?

Ein Medizinprodukt ist ein durch Qualitätssicherungsprozesse „zertifiziertes“ System. Die Hersteller gewährleisten nur dann, dass Ihre Systeme die „grundlegenden Anforderungen“ einhalten, wenn die Anwender an diesen Systemen keine Änderungen vornehmen. Das Aufspielen eines Windows-Patches, der vom Hersteller nicht auf seine Auswirkung auf das System geprüft wurde, stellt eine solche Änderung dar.

Bitte Patch sofort aufspielen!?

Andererseits zeigt die Erfahrung nicht nur deutscher Kliniken, dass die medizinischen Informationssysteme durch Würmer bereits stillgelegt wurden: Die Schadsoftware hatte soviel Netzwerklast verursacht, dass die Röntgengeräte nicht mehr mit dem RIS und das KIS nicht mehr mit dem LIS kommunizieren konnten. Welche Folgen ein Monitoring-System hat, das aufgrund von Netzwerküberlastung keine Alarme mehr übertragen bekommt, kann sich jeder selbst ausmalen.

Was tun?

Wir empfehlen zumindest das Folgende:

  1. schützen Sie Ihre Infrastruktur durch geeignete Maßnahmen wie Firewalls, Antivirus-Software (muss bei Medizinprodukten mit dem Hersteller abgesprochen sein) und Verfahrensanweisungen für Anwender, IT und Medizintechnik. Auch eine Aufteilung der Netze in verschiedene Risikoklassen – so wie in einer der früheren Entwürfe zur IEC 80001 gefordert – kann eine geeignete Maßnahme sein.
  2. prüfen Sie die Dokumentation Ihrer Medizinprodukte auf Hinweise, wie im Fall eines (Notfall-) Patches verfahren werden soll. Kommunizieren und schulen Sie diese Maßnahmen. Sie finden keine Hinweise dazu? Dann
  3. verpflichten Sie Ihren Hersteller auf ein definiertes Vorgehen und legen Sie Verantwortlichkeiten vertraglich fest: In welcher Zeit muss wer welche Maßnahme ergriffen haben? Wer ist autorisiert, Patches aufzuspielen und wie viele Zeit wird dafür gewährt? Dieser Vertrag muss auch das Thema Haftung adressieren.
  4. dokumentieren Sie Ihre komplette Netzwerk- und Medizingeräte-Infrastruktur. Identifizieren Sie mögliche Risiken. Bestimmen Sie eine Person – den Risikomanager – der diese Analyse und mögliche Maßnahmen kontinuierlich aktualisiert.
  5. definieren Sie einen Eskalationsplan. Auch ein sehr gut abgesichertes Netzwerk ist gegen Schadsoftware nicht immun. Selbst andere Gründe können dazu führen, dass Teile Ihrer Infrastruktur nicht mehr verfügbar sind. Also regeln Sie:
    • Wie soll verfahren werden?
    • Wer übernimmt welche Aufgaben?
    • Was sind die Verantwortlichkeiten von Medizintechnik und IT?
    • In welcher Reihenfolge sind welche Systeme wieder herzustellen?
    • Wann und wie wird der Hersteller eingebunden?
    • Muss das BfArM informiert werden?

All diese Schritte zu planen und auch zu üben(!), ist aufwendig. Das stimmt. Im Krisenfall in unkoordinierte Panik zu verfallen, ist aber unprofessionell und stellt keine Alternative dar. Die Koordination sollte einem IT-Sicherheitsbeauftragten übertragen werden, also einem Experten in Sachen IT-Sicherheit. Leider haben nur die wenigsten Kliniken einen solchen Spezialisten und müssen sich notfalls externe Hilfe herbeiholen.

Weiterführende Informationen

Eine gute Handlungsleitung speziell für Betreiber liefert die ISO 80001-1.


Kategorien: FDA Zulassung - die U.S. Food and Drug Administration, Regulatory Affairs, Software & IEC 62304
Tags: ,

Kommentar schreiben