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.

Reicht es, diese Liste zu führen?

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?

Welche Überraschungen erleben Hersteller bei der Entwicklung vernetzter Medizinprodukte besonders häufig?

Viele unterschätzen den Aufwand. Gerade bei Softwareprojekten können schnell sehr viele externe Bibliotheken zusammenkommen. Dann besteht eine SBOM nicht aus zehn oder zwanzig Komponenten, sondern aus mehreren hundert oder sogar tausend Einträgen.

Jede zusätzliche Abhängigkeit kann später Pflegeaufwand bedeuten. Sie muss beobachtet, bewertet und gegebenenfalls aktualisiert werden. Cybersecurity sollte deshalb nicht erst am Ende eines Projekts dazukommen. Sie gehört in Architekturentscheidungen – also in die Frage, wie ein Produkt von Anfang an technisch aufgebaut wird.

Was passiert, wenn man das erst kurz vor der Markteinführung bemerkt?

Dann wird es teuer und hektisch. In der Entwicklung kann man Sicherheitsprobleme meist deutlich einfacher beheben als nach einem Release. Sobald ein Produkt auf dem Markt ist, wächst die Zahl der potenziellen Angreifer enorm: Kunden, externe Dienstleister, Forschende, aber eben auch Menschen mit krimineller Absicht können auf das System stoßen.

Deshalb ist der Zeitpunkt vor der Veröffentlichung so kritisch. Sicherheit muss dann nicht nur dokumentiert sein, sondern sich auch praktisch bewährt haben.

Welche Rolle spielen Penetrationstests dabei?

Eine sehr große. Ein Penetrationstest simuliert im kontrollierten Rahmen, wie ein Angreifer vorgehen könnte. Dabei wird nicht nur nach einzelnen technischen Schwachstellen gesucht, sondern auch danach, wie sich diese kombinieren lassen.

Ich bin besonders bei komplexen Medizinprodukten ein Freund davon, externe Penetrationstester einzubeziehen. Sie bringen einen frischen Blick mit und denken anders als das Entwicklungsteam, das ein System seit Monaten oder Jahren kennt.

Bei einem Whitebox-Test erhalten die Tester möglichst viele Informationen über das System. Das klingt erst einmal kontraintuitiv, ist aber sinnvoll: Je mehr Schwachstellen ich vor einem potenziellen Angreifer finde, desto besser. Dann kann ich sie schließen, bevor ein Produkt breit eingesetzt wird.

Trägt auch der normale Nutzer ein Sicherheitsrisiko?

Ja, ohne dass ihm daraus ein Vorwurf gemacht werden sollte. Menschen machen Fehler, gerade wenn Software unverständlich reagiert. Wenn eine Anwendung einfriert oder keine Rückmeldung gibt, klicken viele Nutzer mehrfach auf denselben Button. Bei einer harmlosen Anwendung ist das vielleicht nur lästig. Bei einem Medizinprodukt kann es gravierende Folgen haben.

Deshalb gehört Usability unbedingt zur Cybersecurity. Gute Sicherheitskonzepte helfen Menschen, korrekt zu handeln, statt sie mit Fehlermeldungen und komplizierten Abläufen allein zu lassen.

Können Sie ein Beispiel nennen?

Die biometrische Anmeldung ist ein gutes Beispiel. Natürlich kann man über die Sicherheit einzelner Verfahren diskutieren. Aber wenn die Anmeldung per Fingerabdruck für Nutzer einfacher ist als ein kompliziertes Passwort, sinkt die Versuchung, unsichere oder mehrfach verwendete Passwörter zu wählen.

Ein gutes Beispiel sind auch PINs. Viele denken: Je mehr Stellen, desto sicherer. Das stimmt mathematisch auch, wenn die Zahlen zufällig gewählt werden.

In der Praxis wählen Menschen aber oft Muster, die sie sich leicht merken können. Bei sechs Stellen liegt ein Datum nahe: Geburtstag, Hochzeitstag oder das Geburtsdatum eines Kindes. Dann wird aus einer theoretisch stärkeren PIN schnell eine vorhersehbare. Deshalb muss man bei Sicherheitskonzepten immer auch berücksichtigen, wie Menschen Systeme tatsächlich nutzen.

Auch Fehlermeldungen sind ein Sicherheitsfaktor. Statt nur „Keine Internetverbindung“ anzuzeigen, sollte ein System erklären, was das bedeutet: Sind Daten verloren gegangen? Muss der Nutzer etwas tun? Oder werden die Daten automatisch synchronisiert, sobald die Verbindung wieder da ist?

Eine verständliche Meldung nimmt Stress aus der Situation. Gerade bei medizinischen Anwendungen ist das entscheidend.

Langzeitrisiken bei Bestandsgeräten

In Krankenhäusern stehen Geräte oft sehr lange im Einsatz. Ist das ein besonderes Risiko?

Absolut. Medizinprodukte haben teilweise Lebenszyklen von 20 oder 30 Jahren und das ist medizinisch erst einmal völlig sinnvoll. Wenn ein Gerät seinen Zweck zuverlässig erfüllt, muss es nicht allein wegen seines Alters ersetzt werden.

Die Herausforderung ist: Die digitale Welt hat sich verändert. Viele Geräte wurden entwickelt, als vernetzte Systeme, moderne Verschlüsselung oder Cybersecurity-Anforderungen noch eine ganz andere Rolle spielten. Manche nutzen Protokolle oder Komponenten, die heute als veraltet gelten.

Bei neueren Produkten ist Cybersecurity inzwischen wesentlich stärker in den regulatorischen Anforderungen verankert. Bei älteren Bestandsgeräten bleibt aber oft die Frage: Wie lange lassen sie sich sicher betreiben, wann muss man sie nachrüsten oder durch Nachfolgeprodukte ersetzen?

Müssen deshalb Produkte vom Markt genommen werden?

Das kann passieren, insbesondere wenn Übergangsfristen auslaufen und eine Nachzertifizierung wirtschaftlich oder technisch nicht mehr sinnvoll ist. Für manche ältere Systeme lohnt es sich eher, einen Nachfolger zu entwickeln, als die gesamte technische Dokumentation und Sicherheitsarchitektur nachträglich auf den heutigen Stand zu bringen. Für bestimmte Bestandsprodukte bestehen Übergangsregelungen, aber nur unter konkreten Bedingungen. Alte Produkte dürfen nicht pauschal und unbegrenzt weiterbetrieben oder weiter in Verkehr gebracht werden.

Wer trägt bei Sicherheitsvorfällen eigentlich die Verantwortung?

Das lässt sich nicht pauschal beantworten. Es hängt stark davon ab, um welche Komponente es geht und wie sie eingesetzt wird.

Der Hersteller eines Medizinprodukts trägt Verantwortung dafür, sein Produkt angemessen abzusichern. Das Krankenhaus wiederum muss seine Infrastruktur, Netzwerksegmentierung und Konfiguration im Blick haben. Ein Router oder Switch lässt sich nicht losgelöst vom Gesamtsystem bewerten – entscheidend ist, wie alles zusammenspielt.

Anders sieht es bei klar abgegrenzten, extern betriebenen Diensten aus. Wenn etwa eine Abrechnungssoftware als eigenständiger, über das Internet erreichbarer Dienst betrieben wird, liegt die Verantwortung beim Anbieter deutlich stärker in dessen eigenem Bereich.

Am Ende braucht es immer eine risikobasierte Betrachtung: Was ist die Komponente? Wo ist sie angebunden? Welche Folgen hätte ein Ausfall oder ein Angriff? Und wer kann realistisch welche Schutzmaßnahmen umsetzen?

Transparenz und Bedrohungslage

Viele Unternehmen kommunizieren nach Sicherheitsvorfällen sehr zurückhaltend. Wie wichtig ist Transparenz?

Es gibt keine komplexe Software, die fehlerfrei ist. Wer behauptet, sein Produkt habe keine Fehler, ist entweder schlecht informiert oder nicht ehrlich. Entscheidend ist deshalb nicht, ob ein Vorfall passiert, sondern wie ein Unternehmen damit umgeht.

Wenn ein Hersteller transparent, lösungsorientiert und nachvollziehbar kommuniziert, kann das das Vertrauen sogar stärken. Nutzer und Betreiber müssen wissen: Was ist passiert? Bin ich betroffen? Was muss ich jetzt tun? Welche Maßnahmen laufen bereits?

Das ist auch eine Frage des Respekts. Hinter den Systemen stehen Menschen – in Kliniken, bei Herstellern und auf Seiten der Patienten. Kommunikation darf deshalb nicht nur juristisch abgesichert, sondern muss auch praktisch hilfreich sein.

Wie realistisch ist das Szenario, dass Menschen durch Cyberangriffe auf Medizinprodukte zu Schaden kommen?

Leider sehr realistisch. Bei Cyberangriffen auf Krankenhäuser gab es bereits Fälle, bei denen zumindest ein Zusammenhang mit gravierenden Folgen für die Versorgung diskutiert wurde. Bei einzelnen Medizinprodukten sind solche Fälle schwerer nachzuweisen, auch weil medizinische Ursachen und technische Störungen im Einzelfall komplex zusammenkommen können.

Aber die grundsätzliche Entwicklung ist klar: Viele Angriffe werden schneller, skalierbarer und professioneller. KI kann Angreifern dabei helfen, Schwachstellen automatisiert zu suchen, Phishing-Angriffe glaubwürdiger zu machen oder Angriffswege schneller auszuprobieren.

Die Frage ist deshalb nicht, ob sich die Bedrohung verändert, sondern wie schnell Hersteller und Betreiber darauf reagieren.

Ich sehe aber auch, dass das Thema bei Herstellern deutlich präsenter geworden ist. Die Anforderungen steigen, die Prüfungen werden genauer und viele Unternehmen investieren heute ernsthafter in Sicherheit als noch vor einigen Jahren. Meine Hoffnung ist, dass wir nicht erst auf einen großen, öffentlich sichtbaren Schaden warten müssen, bevor alle Beteiligten handeln.

Gerade für kleinere Unternehmen und Start-ups dürften die Anforderungen schwer umzusetzen sein.

Ja. Viele Start-ups konzentrieren sich verständlicherweise zunächst auf ihre Produktidee und die Entwicklung. Aber bei Medizinprodukten ist Programmierung nur ein Teil der Arbeit. Testen, technische Dokumentation, Risikomanagement, Zulassung und Cybersecurity sind mindestens genauso wichtig.

Oft merken junge Unternehmen erst spät, dass ihr Produkt technisch vielleicht weit entwickelt ist, aber die Nachweise und Prozesse drumherum noch fehlen. Dann müssen Dokumentation und Sicherheitskonzept nachträglich aufgebaut werden. Das verursacht häufig deutlich mehr Aufwand.

Ist das auch ein Grund, warum manche digitale Gesundheitsanwendungen wieder vom Markt verschwinden?

Die Anforderungen an digitale Gesundheitsanwendungen sind in den vergangenen Jahren deutlich gestiegen. Das ist grundsätzlich sinnvoll, kann aber Geschäftsmodelle unter Druck setzen.

Was wünschen Sie sich für die Debatte über Cybersicherheit in der Medizintechnik?

Mehr Austausch aus der Praxis. Natürlich sind Normen und regulatorische Anforderungen wichtig. Aber viele Menschen hören auf Konferenzen zum fünften Mal dieselbe Folie über eine Vorschrift. Wirklich hilfreich wird es, wenn offen darüber gesprochen wird, was in Projekten funktioniert hat – und was nicht.

Cybersecurity ist kein Thema, das ein Unternehmen allein lösen kann. Hersteller, Kliniken, Sicherheitsforscher, benannte Stellen und Behörden müssen voneinander lernen. Die besten Lösungen entstehen oft nicht durch eine weitere Checkliste, sondern durch ehrliche Gespräche über reale Probleme.

(mack)