Aktuelles
Zugelassen – und am nächsten Tag schon veraltet?
Die Zulassung prüft den Stand von heute. Ein Medizingerät arbeitet aber 10 bis 15 Jahre im Feld. Drei Fragen entscheiden, ob es in dieser Zeit sicher, wartbar und lieferbar bleibt.
Warum die Zulassung nur eine Momentaufnahme ist
Tag 1: Alles geprüft, dokumentiert, zugelassen. Tag 2: Eine neue Sicherheitslücke in einer Open-Source-Bibliothek wird bekannt. Am Gerät hat sich nichts geändert, und doch entspricht es nicht mehr dem Stand seiner Zulassung. Die Zulassung ist eine Momentaufnahme. Danach ist das Gerät 10 bis 15 Jahre im Feld. Bauteile werden abgekündigt, Preise und Verfügbarkeit schwanken, neue Funktionen werden gefordert, und die Anforderungen an die Cybersecurity steigen.
Die MDR ist hier eindeutig: Software muss nach dem Stand der Technik entwickelt werden, inklusive Risikomanagement und Informationssicherheit. Für die IVDR gilt dasselbe. Die Leitlinie MDCG 2019-16 erwartet zudem, dass Hersteller Schwachstellen über die gesamte Lebensdauer beobachten und darauf reagieren. Der Stand der Technik entwickelt sich weiter. Ein Gerät im Feld tut das nicht von selbst.
Welche drei Fragen entscheiden über 15 Jahre?
Über den Lebenszyklus eines vernetzten Geräts sind neue Sicherheitslücken sehr wahrscheinlich. Ob ein Hersteller damit umgehen kann, hängt an drei Fragen. Sie unterscheiden sich vor allem darin, wie viel Zeit für die Antwort bleibt:
- Stunden: Bin ich überhaupt betroffen?
- Wochen: Kann ich den Fix sicher ausrollen?
- Jahre: Halte ich das 15 Jahre durch?
Stunden: Bin ich betroffen?
Eine neue Schwachstelle wird veröffentlicht, meist als CVE-Eintrag (Common Vulnerabilities and Exposures) im öffentlichen Katalog bekannter Sicherheitslücken. Die erste Frage aus Qualitätsmanagement, Vertrieb oder Kundschaft lautet: Ist unser Gerät betroffen? Ohne gepflegte Software-Stückliste (SBOM, Software Bill of Materials) heißt das: Hunderte Open-Source-Komponenten von Hand durchsuchen. Das dauert Wochen, und das Ergebnis bleibt unsicher. Mit gepflegter SBOM und einem festgelegten Bewertungsprozess ist es ein Abgleich des Komponentenstands mit einem Schwachstellen-Feed. Eine belastbare Aussage liegt dann in Stunden vor. Dafür braucht es drei Bausteine:
- Automatisierte SBOM: Software-Komponenten und Lizenzinformationen werden bei jedem Build im Projekt erzeugt, nicht nachträglich zusammengetragen.
- Automatisches CVE-Monitoring: Security-Datenbanken werden laufend gegen die SBOM abgeglichen.
- Produktkontext: Version, Konfiguration, tatsächlich aktivierter Code, Exposition (etwa: Ist die betroffene Schnittstelle von außen erreichbar?), Produktvarianten und Feldbestand.
Erst der Kontext macht aus einem Treffer eine Bewertung. Am Ende steht eines von drei Ergebnissen: nicht betroffen, Patch ausbringen oder weiter analysieren. Ein zusätzlicher Hebel ist die Angriffsfläche. Jede Software-Komponente, die im Gerät läuft, muss beobachtet und bewertet werden. Wer nur das einsetzt, was in Serie gebraucht wird, hat weniger zu überwachen. Ein maßgeschneidertes Embedded Linux enthält typischerweise deutlich weniger Komponenten als ein allgemeines Betriebssystem wie Android.
Wochen: Kann ich den Fix sicher ausrollen?
Fixen wollen ist nicht dasselbe wie fixen können. Sobald feststeht, dass ein Patch nötig ist, zählen andere Fragen:
- Kann ich den betroffenen Build exakt reproduzieren?
- Ist die Toolchain noch verfügbar?
- Werden Betriebssystem, Kernel und Bibliotheken noch gewartet?
- Sind die Tests automatisiert, oder ist alles Handarbeit?
Ein Security-Patch, den man nicht zuverlässig bauen und testen kann, löst kein Problem. Deshalb gehört Software-Wartung von Anfang an in die Planung: regelmäßige Update-Zyklen im Produkt, Betriebssysteme und Bibliotheken mit Long Term Support (LTS) und eine automatisierte Testabdeckung. Hardware-in-the-Loop-Tests prüfen die Software auf der echten Zielhardware. Das erhöht die Testabdeckung und das Vertrauen in jedes Update. Updatefähigkeit ist eine Frage der Produktarchitektur. Die Kette hat fünf Glieder: Update-Paket sicher erzeugen, signieren, verteilen, installieren und verifizieren.
Entscheidend ist aber eine andere Frage: Was passiert, wenn das Update mittendrin scheitert? Ein Gerät, das nach einem Stromausfall während der Installation nicht mehr startet, ist im Feld ein ernstes Problem. Ein sauberer Rollback auf den letzten funktionierenden Stand gehört deshalb in die Architektur.
Jahre: Hält das Gerät 15 Jahre durch?
Hier läuft eine Uhr mit zwei Zeigern. Der erste ist der Software-Support: LTS-Versionen von Linux-Kernel und Bibliotheken werden typischerweise drei bis fünf Jahre gepflegt. Das ist deutlich kürzer als die Lebensdauer des Geräts. Der zweite Zeiger ist die Bauteilverfügbarkeit. Abkündigungen und Lieferengpässe gehören zum Alltag.
Beide Zeiger laufen ab, lange bevor das Gerät außer Betrieb geht. Bei einem zugelassenen Medizingerät bedeutet ein ungeplanter Wechsel oft Redesign und Neuvalidierung, also Zeit und Kosten, die niemand eingeplant hat.
Was hilft:
- Lifecycle-Konzept von Beginn an: Software inklusive Wartungsprozess und Bauteilalternativen werden in der Entwicklung mitgedacht. Zyklische Software-Updates sind als Prozess festgelegt.
- Langfristigen Aufwand planen: Analysen, präventives Obsoleszenz-Screening, Redesigns und Wartung sind planbarer Aufwand, intern oder mit Partnern.
- Enge Abstimmung: Entwicklung, Fertigung und Inverkehrbringer stimmen sich über den gesamten Lebenszyklus ab, nicht erst im Anlassfall.
Was muss der Zulieferer liefern?
Die Produktverantwortung trägt der Hersteller. Ein großer Teil der Informationen, die er dafür braucht, entsteht aber bei Zulieferern. Damit diese Informationen in die technische Dokumentation einfließen können, sollten sie vertraglich und prozessual geregelt sein:
- Automatisierte SBOM: Komponenten, Versionen, Lizenzen
- CVE-Bewertung (ganz oder teilweise): Scan und technische Bewertung
- Release Notes: Änderungen und Risiken
- Support und Grenzen: Wartungsprozess, klare Zuständigkeiten
- PCN/EOL: Änderungs- und Abkündigungsmitteilungen mit Auswirkungsanalyse und Änderungssteuerung
- Traceability: Zuordnung von Seriennummer und Software-/Hardware-Stand
So unterstützt Ginzinger electronic systems
Ginzinger electronic systems entwickelt, fertigt und betreut kundenspezifische Elektronik und Embedded Systems. Für die drei Fragen heißt das konkret:
- GELin, die Embedded-Linux-Distribution von Ginzinger, erzeugt die SBOM automatisch im Build und dokumentiert dabei auch Open-Source-Lizenzen.
- Security-Monitoring und Software-Wartung für GELin-basierte Geräte
- Langzeitunterstützung und Produktbetreuung: Obsoleszenzmanagement, Redesigns und Wartung, abgestimmt zwischen Entwicklung und Fertigung im eigenen Haus
Ein Medizingerät 15 Jahre aktiv zu betreuen, wird anspruchsvoller. Die gute Nachricht: Die Werkzeuge dafür gibt es. Eine automatisierte SBOM beantwortet die Stunden-Frage, eine updatefähige Architektur mit LTS-Basis die Wochen-Frage, ein geplanter Lifecycle-Prozess die Jahre-Frage. Entscheidend ist, dass alle drei vor der Zulassung angelegt werden, nicht danach.
Zum weiterlesen - Best Practices im Whitepaper
Für Produkte unter MDR oder IVDR gilt der Cyber Resilience Act (CRA) nicht. Viele Medizintechnik-Hersteller haben aber auch Geräte im Portfolio, die nicht unter die MDR fallen und für die der CRA relevant sein kann. Die Methoden sind ohnehin dieselben: SBOM, Schwachstellenmanagement, Threat Risk Analysis. Unser Whitepaper mit Limes Security erklärt sie praxisnah und Schritt für Schritt.