IT-Sicherheit Cybersecurity forever

Anbieter zum Thema

KUMAVISION AG

Forum MedTech Pharma eV

Metecon GmbH

embeX GmbH

Nicht nur bei der Entwicklung von vernetzten Medizinprodukten muss auf die Cybersicherheit geachtet werden. Auch Produkte im Feld müssen gegen Hacker geschützt werden. Dieses Thema wird von Medizintechnik-Herstellern allerdings noch eher stiefmütterlich behandelt. Sicherheitsteams, die so genannten Product Security Incident Response Teams, sorgen für die Überwachung der Cybersecurity, reagieren auf erkannte Schwachstellen und koordinieren die Betreuung der betroffenen Produkte im Feld.

Medizintechnikhersteller machen es Hackern leicht: Das FBI hat jüngst eine zunehmende Zahl von Sicherheitslücken festgestellt, die durch nicht gepatchte, mit veralteter Software betriebene medizinische Geräte oder durch Geräte mit unzureichenden Sicherheitsfunktionen entstehen. Im Januar 2022 wiesen demnach 53 Prozent der vernetzten medizinischen Geräte und anderer in Krankenhäusern genutzter IoT-Geräte bekannte kritische Schwachstellen auf, so das FBI. „Ungefähr ein Drittel der IoT-Geräte im Gesundheitswesen weisen ein identifiziertes kritisches Risiko auf, das den technischen Betrieb und die Funktionen medizinischer Geräte beeinträchtigen könnte“, heißt es in einer Mitteilung an die Privatwirtschaft.

Da die aus diesem Missstand abgeleiteten Forderungen des FBI inhaltlich bereits weitgehend in der FDA Guidance zur Premarket Cybersecurity aus dem April 2022 enthalten sind, wird es dadurch wohl zu keiner weitergehenden Regulierung kommen. Auch wenn sich diese Leitlinie formal noch im Entwurfsstadium befindet, repräsentiert sie dennoch für aktuelle Zulassungsverfahren die gegenwärtige Richtschnur der Behörde und ist daher bei der Entwicklung medizintechnischer Produkte zu berücksichtigen. In der EU gibt es zwar weniger konkrete Regulierungen zur Cybersecurity von Medizinprodukten, doch seit Dezember 2021 bestehen durch die IEC 81001 (Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle) auch auf europäischer Ebene klare regulatorische Forderungen, bekannte Sicherheitslücken zu schließen.

Hersteller bei Risikobehebung in der Verantwortung

Trotz dieser Erfahrungen aus der Praxis und der einschlägigen Anforderungen der Regulierungsbehörden haben bisher nur wenige Hersteller das Thema der (Cyber-) Security ihrer Produkte im Feld auf dem Schirm – i. d. R. verlässt man sich darauf, dass ein Produkt sorgfältig entwickelt wurde. Doch was passiert, wenn sich herausstellt, dass es doch Sicherheitslücken gibt?

Für den Anwender im Krankenhaus sind die Medizinprodukte Black Boxes, auf deren Sicherheit er vertrauen können muss, um seine IT-Domänen – und seine Patienten – nicht zu gefährden. In den USA ist es immerhin üblich, dass Medizintechnikhersteller ihre Kunden in einem Manufacturer Disclosure Statement for Medical Device Security (MDS2) hinsichtlich einer sicheren Integration ihrer Produkte informieren. In der EU werden derartige Abstimmungen sehr unterschiedlich gehandhabt oder unterbleiben ganz.

Für beide Märkte ist festzuhalten, dass die Anwender darauf angewiesen sind, dass Schwachstellen in vernetzten Medizinprodukten erkannt und zeitnah behoben werden, bevor Patienten und Betreiber Schaden erleiden. Hier sind eindeutig die Hersteller in der Verantwortung – dies gilt umso mehr, als die Anzahl von IoT-Geräten im medizinischen Bereich wie auch in anderen Branchen stetig weiter zunimmt.

Wodurch entstehen Sicherheitsrisiken?

Die meisten Security-Schwachstellen, die während des Betriebs auftreten, lassen sich auf die Entwicklung zurückführen – auch wenn diese sorgfältig erfolgt ist. Dazu muss man wissen, wie die Erstellung einer Gerätesoftware üblicherweise vonstattengeht: Der Programmcode entsteht meist nur in kleinem Umfang – dem applikationsspezifischen Teil – neu, ansonsten greifen Softwareentwickler auf Komponenten von Drittanbietern wie Betriebssysteme, Bibliotheken, Treiber, Verschlüsselungsalgorithmen etc. zurück. Nur so ist die Entwicklung von vernetzten Produkten überhaupt wirtschaftlich darstellbar, birgt aber die Gefahr eines Imports von Schwachstellen in das eigene Produkt.

Man spricht bei kommerzieller Software Dritter und Open Source Software im Sinne der IEC 62304 auch von Software of Unknown Provenance (SOUP). Solche Software-Module und -Betriebssysteme sind aufgrund ihrer weiten Verbreitung als Angriffsziel für Hacker besonders attraktiv. Historisch wurden sie meist nach rein funktionalen Kriterien und ohne Beachtung von Sicherheitsaspekten ausgewählt, denn Security war lange Zeit kein Entwicklungsziel. Wie die eingangs zitierte Feststellung des FBI zeigt, findet selbst heute noch Software mit längst bekannten Schwachstellen ihren Weg in neue Applikationen.

Aber auch wenn bei der Entwicklung auf Security-Aspekte geachtet wurde, ist das Thema damit nicht für alle Zeiten erledigt. Selbst nach erfolgreich absolvierten Penetrationstests werden viele Sicherheitslücken erst bekannt, wenn das Produkt längst im Feldeinsatz ist. Diese Schwachstellen können dann für Cyberattacken ausgenutzt werden.

Parallel entwickeln sich auch die Angriffsmethoden auf vernetzte IoT-Produkte mit hohem Tempo weiter. Um ihrer Verantwortung gegenüber den Kunden gerecht zu werden, müssen die Hersteller gemäß der IEC 81001-5-1 somit einen Monitoringprozess über die gesamte Produktlebensdauer etablieren. Bei der Entdeckung einer potenziellen Schwachstelle gilt es dann, betroffene Anwender in einem ersten Schritt unverzüglich zu informieren und Maßnahmen zur Minderung des Schadensrisikos zu empfehlen. Sobald ein Update verfügbar ist, das die Sicherheitslücke schließt, ist dieses den Anwendern zur Verfügung zu stellen.

PSIRT kümmert sich um Schwachstellen und sichert Produkte dauerhaft

Fachabteilungen, die sich um einen solchen Monitoringprozess kümmern, werden auch Product Security Incident Response Teams (PSIRT) genannt. Sie bilden das produktbezogene Pendant beim Hersteller zu den – schon länger etablierten – Computer Emergency Response Teams (CERT) auf Anwenderseite. Sie kümmern sich um die Security des Unternehmensnetzwerks und sind nur in Einzelfällen produktbezogen tätig. Selbst bei großen und namhaften Unternehmen sind PSIRT bisher jedoch nicht flächendeckend etabliert, obwohl es mit der internationalen Norm IEC 81001-5-1, die am 24.Mail 2024 in Kraft tritt, klare Vorgaben für die Aufrechterhaltung der Cybersecurity im Feld gibt. Ebenso gilt es, das im Mai 2021 in Kraft getretene IT-Sicherheitsgesetz 2.0 zum Schutz kritischer Infrastrukturen (KRITIS) einzuhalten.

Die meisten Hersteller sind jedoch mit diesen Aufgaben überfordert: Sie verfügen weder über einschlägiges Expertenwissen noch die notwendigen Personalressourcen, um einen internen PSIRT-Prozess zu etablieren. Hier setzt der unabhängige Entwicklungsdienstleister Embex an: Als externes Sicherheitsteam unterstützt Embex die Hersteller von vernetzten Produkten beim Aufbau von geeigneten PSIRT-Prozessen sowie mit einem maßgeschneiderten Dienstleistungspaket, das den gesamten Produktlebenszyklus umfasst.

Der PSIRT-Prozess in der Praxis

Wie bereitet man die Absicherung eines Produkts konkret vor? Um eine spezifische Schwachstellenanalyse durchführen zu können, muss in einem ersten Schritt bestimmt werden, aus welchen (Sub-)Komponenten der Quellcode der Gerätesoftware besteht. Man spricht hier auch von Software Bill of Materials (SBOM), vergleichbar der Teileliste bei einem Hardware-Produkt. Anschließend nimmt der Experte die einzelnen Komponenten unter die Lupe; als Handwerkszeug dienen ihm dabei spezielle Informationsquellen (z. B. CVE-DB, CWE-DB, BSI), in denen bekannte Schwachstellen erfasst werden. Das Aufspüren erfordert viel Fachwissen und Erfahrung – allein die CVE-Datenbank enthält aktuell über 185.000 Einträge. Im nächsten Schritt werden gefundene Schwachstellen auf ihre Relevanz hin bewertet, also ob und wenn ja welche Risiken im Fall der spezifischen Applikation auftreten können. Die Bewertung erfolgt nach dem Critical Vulnerability Scoring System (CVSS) auf einer Skala von 1 bis 10, wobei Stufe 10 für eine – in Bezug auf die gegebene Anwendung – höchst kritische Schwachstelle steht.

Über die Ergebnisse wird der Hersteller in Kenntnis gesetzt und erhält Empfehlungen für die weitere Vorgehensweise. Dies kann beispielsweise eine verstärkte Beobachtung des Produktes durch den Betreiber sein oder aber eine Einschränkung, das Produkt nur noch im Verbund mit zusätzlichen Sicherheitsmodulen zu betreiben. Die IEC 81001-5-1 definiert den Begriff Supported Product als ein Produkt, bei dem die Anwender über Sicherheitslücken informiert werden, das Risiko einschätzen und durch eigene Maßnahmen Schaden abwenden können. Normalerweise ist bei Bekanntwerden von Sicherheitslücken der Betrieb mit Einschränkungen oder zusätzlichen Aufwänden auf Seiten des Betreibers weiterhin möglich.

Der weitestgehende Schritt ist das Schließen der Sicherheitslücke durch Überarbeitung des Quellcodes. Die IEC 81001-5-1 verwendet hierfür den Begriff Maintained Product. Diese Überarbeitung kann Embex ebenfalls übernehmen. Diese Arbeiten zielen darauf ab, dass die Betreiber die Produkte ohne Sicherheitslücken, Gefährdungen und Einschränkungen nutzen können. Selbstverständlich folgt auf die Überarbeitung des Codes eine erneute Verifikation. Die Auswirkungsanalysen ergeben in der Praxis zumeist, dass Validierungen und Neuzulassungen nicht erforderlich sind.

Auch im Fall von Neuentwicklungen kann der spezialisierte Dienstleister hinzugezogen werden, um das Thema Security von vornherein im Entwicklungsprozess zu verankern – beginnend mit der Auswahl sicherheitsgeprüfter Komponenten und weiteren entwicklungsbegleitenden Prüfungen der SBOM auf Schwachstellen noch vor der Markteinführung. Dazu gehört auch die Überlegung, inwieweit künftige Sicherheitsupdates die Funktionalität des Produkts, z.B. durch höhere Anforderungen an die Rechenleistung und Speicherkapazität, beeinflussen können.

Fazit: Cybersecurity im Auge behalten

Wer sich nach Lektüre dieses Beitrags Sorgen hinsichtlich der Sicherheit seiner IoT-Produkte macht, befindet sich in guter Gesellschaft mit vielen großen und namhaften internationalen Unternehmen, die ebenfalls keinen oder nur einen lückenhaften Umgang mit dem Thema pflegen. Ist dies bei Herstellern von Consumerprodukten mit beschränktem Schädigungspotenzial vielleicht noch tolerabel, kann es hierfür in medizinischen Anwendungen kein Pardon geben. Da die Vernetzung der Produkte im IoT und damit auch einschlägige Risiken absehbar weiter zunehmen werden, sollte dem Thema der Cybersecurity daher die nötige Aufmerksamkeit geschenkt werden. Nicht zuletzt geht es darum, Folgeschäden bei den Kunden zu vermeiden. Denn diese können sich massiv auf das eigene Image und künftige Kaufentscheidungen auswirken.

Wer nicht über die (menschlichen und fachlichen) Ressourcen für ein internes PSIRT-Team verfügt, kann sich das entsprechende Wissen auch als externe Dienstleistung beschaffen. Um es mit einem Bild zu sagen: Nicht jedes Unternehmen benötigt eine eigene Werksfeuerwehr, sollte sich aber dennoch verpflichtet fühlen, alle notwendigen Maßnahmen zur Brandvorbeugung zu treffen und diese immer wieder an veränderte Realitäten anzupassen.

Weitere Artikel zur Führung von Medizintechnik-Unternehmen finden Sie in unserem Themenkanal Management.

* Dr. Kai Borgwarth ist Leiter Geschäftsbereich Medical Engineering bei der Embex GmbH sowie Trainer beim TÜV Süd zum Thema „IT-Sicherheit für Medizinprodukte“. Lukas Fey ist Leiter Fachbereich Cybersecurity bei der Embex GmbH.

(ID:48691929)