// HEISE ONLINE — SALUTE
„Viele unterschätzen den Aufwand“: Cybersecurity bei Medizinprodukten
Software-Lieferketten, Altgeräte und Co. erhöhen die IT-Risiken in der Medizintechnik. Was bei der Entwicklung wichtig ist, erklärt ein Experte im Interview.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Vernetzte Medizinprodukte bestehen heute nur noch zu einem Bruchteil aus selbst geschriebenem Code. Frameworks, Bibliotheken und Komponenten Dritter bilden das Fundament und mit ihnen wächst eine Angriffsfläche, die viele Hersteller unterschätzen. Kommt eine Schwachstelle in einer weit verbreiteten Bibliothek ans Licht, stellt sich die Frage: Steckt sie auch in unserem Produkt? Und wer entscheidet dann, wie schnell reagiert werden muss?
Sebastian Wittor ist Senior Project Manager Medical Engineering bei BAYOOMED, einem auf Medizinsoftware und digitale Gesundheitsanwendungen spezialisierten Unternehmen. Seine Schwerpunkte liegen in den Bereichen Cybersecurity, sichere Softwareentwicklung und Datenschutz. Im Interview erklärt er unter anderem, weshalb externe Penetrationstester einen entscheidenden Perspektivwechsel bringen, wie Usability und Sicherheit zusammenhängen und warum Transparenz das Vertrauen nach einem Vorfall sogar stärken kann.
Sie hatten in Ihrem Vortrag auf der vergangenen MedConf gesagt, dass die Lieferkette bei Medizinprodukten ein zentraler Punkt ist. Wie wird das überwacht?
Zunächst muss ich wissen, was überhaupt in meinem Produkt steckt. Dafür gibt es sogenannte Software Bills of Materials, kurz SBOMs. Vereinfacht gesagt ist das eine Komponentenliste: Welche Bibliotheken, Frameworks und Softwarebausteine nutze ich und welche Komponenten stecken wiederum darin?
Das ist wichtig, weil moderne Software fast nie vollständig selbst entwickelt wird. Sie besteht aus vielen Abhängigkeiten. Wenn irgendwo in dieser Kette eine Sicherheitslücke auftaucht, muss ich wissen, ob mein Produkt betroffen sein könnte.
Nein. Eine SBOM ist erst einmal nur eine Landkarte. Danach brauche ich Werkzeuge und Prozesse, die diese Komponenten mit bekannten Schwachstellen abgleichen. Das kann ein kontinuierliches Monitoring leisten.
Aber auch dann beginnt die eigentliche Arbeit erst: Eine bekannte Schwachstelle in einer Bibliothek bedeutet nicht automatisch, dass mein Produkt verwundbar ist. Vielleicht nutze ich genau die betroffene Funktion gar nicht. Man muss die Ergebnisse also fachlich bewerten und priorisieren.
Das größte Problem ist oft nicht das fehlende Tool. Viele Unternehmen haben inzwischen Übersichten und Scans. Schwieriger ist die Frage: Was passiert mit den Ergebnissen? Wer entscheidet, ob Handlungsbedarf besteht? Wie schnell wird reagiert? Und wie dokumentiert man das nachvollziehbar?