Sicherheit in der Embedded Software für die Medizintechnik

Standards, bewährte Vorgehensweisen und branchenübergreifende Erkenntnisse

Know-how
csm_AdobeStock_715737320__1__78967926ca.jpeg

Medizinprodukte entwickeln sich von Standalone-Systemen hin zu vernetzten Plattformen mit kontinuierlichen Updates und Ferndiagnose. Dies erhöht die Anforderungen an Sicherheit und Cybersecurity angesichts begrenzter Hardware-Ressourcen, langer Lebenszyklen und strenger Vorschriften. Auf der Grundlage branchenübergreifender Praktiken und der Arbeit von Vector im Bereich sicherheitskritischer Embedded Software konzentriert sich dieser Artikel darauf, was Ingenieure bereits heute umsetzen können.

Zentrale Herausforderungen

  • Lange Produktlebenszyklen mit regelmäßigen Updates: Gewährleisten Sie sichere Updates über einen Zeitraum von mehr als 10 Jahren und bewahren Sie dabei die Nachweise zur Einhaltung der Vorschriften auf.
  • Heterogene Plattformen und SOUP: Gemischte Toolchains und Code von Drittanbietern erschweren die Umsetzung einheitlicher Safety- und Security-Kontrollen.
  • Konnektivität und Interoperabilität: Vernetzte Systeme schaffen neue Angriffsflächen und erhöhen die Komplexität von Zertifizierungen, beispielsweise im Zusammenspiel mit Krankenhaus-IT und IEC 62443.
  • Kompetenzen und Tools: Kryptografie, sichere Update-Pipelines und redundante Architekturen bringen hohe technische Komplexität mit sich. Die eingesetzten Tools müssen es einfacher machen, standardmäßig die richtige Entscheidung zu treffen.

MedTech-Standards

  • IEC 62304: Software-Lebenszyklus, Klassifizierung, Verifizierung, Wartung und Problemlösung.
  • ISO 14971: Risikomanagement mit eindeutiger Gefahrenidentifizierung, Risikokontrollen und Restrisiko.
  • Unterstützende Frameworks: IEC 60601-1 (grundlegende Sicherheit/wesentliche Leistungsmerkmale), IEC/TR 60601-4-5, das auf IEC 62443 (Sicherheit für IACS) verweist, sowie Leitlinien zu SBOM und koordinierter Offenlegung.

Praxisnahe Muster für Safety und Security in MedTech Systemen

Lock-Stepping

Beim Lock-Stepping führen zwei identische CPU-Kerne dieselben Befehle synchron aus. Ein Hardware-Komparator prüft kontinuierlich die Register bzw. Ergebnisse beider Kerne. Sobald eine Abweichung festgestellt wird, wird ein Fehler gemeldet, und das System kann in einen sicheren Zustand übergehen. Dies trägt wie folgt zur funktionalen Sicherheit bei:

  • Fehlererkennung: 2oo2-Architektur (Two-out-of-Two) zur Erkennung von Abweichungen.
  • Kürzere Fehlerreaktionszeit: Der kontinuierliche Vergleich ermöglicht ein schnelles „Fail-Silent“- oder „Fallback“-Verhalten.
  • Unterstützung für den Sicherheitsnachweis: In Kombination mit ECC-geschütztem Speicher, einem Watchdog, Takt-/Leistungsüberwachung und durchgängigem Schutz wird eine geschlossene Fehlererkennungskette über Rechenkern, Speicher und Communication hinweg hergestellt.

Vertrauenswürdige Ausführungsumgebung

Ein Trusted Execution Environment nutzt hardwaregestützte Partitionierung, um das System in eine „Secure/Trusted World“ und eine „Normal World“ zu trennen. Die Secure World verfügt über isolierten Zugriff auf Speicher, Peripheriegeräte und kryptografisches Material; die Normal World ist streng davon getrennt.

  • Schutz sicherheitsrelevanter Artefakte: Sicherheitsanforderungen, Kalibrierungen, Konfigurationen, Zustandsmaschinen und Fehlerzähler können in der „Secure World“ abgelegt werden und sind vor unbeabsichtigten Änderungen oder Manipulationen geschützt.
  • Freiheit von Einwirkungen (Freedom from Interference): Die Hardware-Isolation (Secure vs. Normal) ergänzt die Partitionierung (MPU/MMU) und reduziert das Risiko, dass fehlerhafte oder unsichere Software sicherheitsrelevante Bereiche beeinträchtigt.
  • Schlüssel- und Kommunikationsschutz: Sichere Schlüsselverwaltung sowie Signaturen oder CMAC für Konfigurationen, Protokolle und sicherheitskritische Botschaften verbessern die Erkennung von Datenverfälschungen und unbefugten Änderungen.

Sichere Updates

Ein Secure Update ist ein Software-Update, das während seines gesamten Lebenszyklus vor Manipulationen geschützt ist, ausschließlich aus autorisierten Quellen stammt und ohne Beeinträchtigung der Sicherheit oder Funktionalität installiert werden kann. Die wesentlichen Komponenten sind:

  • Authentizität: Updates sind digital signiert (Code-Signierung); es werden nur Pakete aus vertrauenswürdigen Quellen akzeptiert.
  • Integrität: Hash-Prüfungen stellen sicher, dass der Inhalt unverändert bleibt.
  • Autorisierung und Zugriff: Die Rollen-/Rechteverwaltung stellt sicher, dass nur autorisierte Dienste/Benutzer Updates initiieren können.
  • Vertraulichkeit und sicherer Transport: Herunterladen über Secure Channels (z. B. TLS/mTLS), Schutz vor Man-in-the-Middle-Angriffen.

Secure Communication

Secure Communication schützt vor böswilligen oder versehentlichen Angriffen von außen oder innen: Vertraulichkeit, Integrität, Authentifizierung, Wiedergabeschutz.

Typische Maßnahmen sind:

  • Starke Crypto-Dienste mit Hardware-Unterstützung.
  • Übertragene Botschaften werden mit Authentifizierungsinformationen (z. B. MAC) und Aktualitätswerten ergänzt.
  • Verwendung von Verschlüsselungsprotokollen wie TLS.

Safe Communication

Safe Communication stellt eine sichere Kommunikation innerhalb einer Steuereinheit sowie zwischen Steuereinheiten sicher. Für die externe Kommunikation wird dies ermöglicht durch:

  • CRC-Prüfsumme über die Daten, Daten-ID und Sequenzzähler. Dadurch können Datenkorruption und Masquerading von Signalen erkannt werden.
  • Sequenzzähler zur Erkennung von Fehlern in der Reihenfolge der Botschaften sowie von wiederholten oder eingefügten Botschaften.
  • Timer auf der Seite des Empfängers, um auf verlorene und verspätete Botschaften zu reagieren.

„Shift-Left“-Testing

Shift-Left Testing bedeutet, Test- und Qualitätssicherungsaktivitäten so früh wie möglich im Software-Lebenszyklus zu verankern – näher an Anforderungen, Architektur und Implementierung, statt erst am Ende des Entwicklungsprozesses.

Ziel ist es, schnelles Feedback zu ermöglichen und Fehler frühzeitig zu erkennen. Typische Praktiken sind:

  • Frühzeitige Reviews der Anforderungen und der Architektur.
  • Statische Analysen und Coding Guidelines, die direkt in den Workflow der Entwickler integriert sind.
  • Continuous Integration (CI) mit automatisierten Builds, Tests und Quality Gates.
  • Frühzeitige Tests für API- und Integration.

Branchenübergreifende Erkenntnisse

Bei Vector entwickeln wir seit vielen Jahren sicherheitskritische Embedded Software und liefern sicherheitszertifizierte Lösungen an Kunden weltweit. Das schließt nicht nur die Produkte selbst ein, sondern auch robuste, gut dokumentierte Entwicklungs- und Qualifizierungsprozesse, die wir intern konsequent anwenden. Kurz gesagt: Wir wissen genau, wie komplex, aufwendig – und zugleich unverzichtbar – die Entwicklung von Sicherheitsanwendungen ist.

Warum Safety Work oft schwierig ist – und unverzichtbar:

  • Gefahren- und Risikoanalyse
  • Konzept zur funktionalen Sicherheit
  • Technisches Sicherheitskonzept
  • Definition von Schnittstellen zwischen Hardware und Software
  • Qualitative und quantitative Sicherheitsanalysen
  • Verifikation und Validierung
  • Auf den Zielmarkt zugeschnittene Entwicklungsprozesse und Arbeitsabläufe

All diese Aktivitäten sind notwendig – und sie sind häufig trocken, kleinteilig und anspruchsvoll. Niemand macht sie „nur zum Spaß“. Wer sie jedoch unterschätzt, riskiert später kostspielige Iterationen in Architektur, Implementierung und Zertifizierung.

Genau hier setzen unsere Tools und Produkte an: Sie reduzieren Komplexität, standardisieren Arbeitsschritte und machen die anspruchsvollen Teile beherrschbar.

Ein Beispiel aus der Praxis: Funktionale Sicherheit in Multi-Core-Embedded-Systemen ist heute Standard – und gerade hier besonders herausfordernd.

  • Die Rechenkerne müssen konsistent arbeiten: deterministisch, reproduzierbar und ohne unerwünschte Seiteneffekte.
  • Speicherzugriffe dürfen nicht auf falsche Ressourcen zielen: keine ungültigen Pointer, keine Cross-Partition-Interference.
  • Die Kommunikation zwischen den Kernen muss effizient, kontrolliert und safety-konform erfolgen. Ohne die passende Basissoftware erfordert dies enorme Disziplin in Architektur, Konfiguration, Testing und Nachweisführung.

Wie eine Basissoftware Ihre Safety-Entwicklung spürbar vereinfacht:

  • Freedom from Interference in gemischten Systemen: Safety-relevante und nicht Safety-relevante Softwarekomponenten können auf derselben Steuereinheit interferenzfrei ausgeführt werden.
    •  Dies reduziert systematische Risiken, vereinfacht den Nachweis von Freedom from Interference und spart Zeit in Architektur, Integration und beim Testen.

Safety-Anforderungen konsistent abbilden

  • Zusätzliche Safety-Anforderungen lassen sich gezielt auf geeignete Basissoftware-Module abbilden, etwa auf Safe Communication oder Secure Communication.
    • Das schafft technische Konsistenz, reduziert manuelle Fehlerquellen und unterstützt eine robuste Safety-Argumentation.

Unterstützung von Multi-Core-Mikrocontrollern

  • Die Basissoftware unterstützt die klare Trennung von Aufgaben, Ressourcen und Speicherbereichen über mehrere Mikrocontroller-Kerne hinweg. So werden komplexe Multi-Core-Architekturen strukturiert, kontrollierbar und safety-konform umsetzbar.

Speicherpartitionen und Kerne effizient verbinden

  • Eine kontrollierte Interaktion zwischen Speicherpartitionen und Mikrocontroller-Kernen hilft, ungültige Zugriffe frühzeitig zu verhindern.
  • Gleichzeitig bleibt die notwendige Performance erhalten, ohne Kompromisse bei der funktionalen Sicherheit einzugehen.

Standards, Zertifizierung und Nachweisführung integriert

  • Nach anerkannten Standards und Prozessen entwickelte und zertifizierte Basissoftware reduziert den Aufwand für Qualifikation, Audits und projektspezifische Nachweise. Sie stärkt die gesamte Nachweiskette – von der Architektur über die Implementierung bis zur Zertifizierung.

Der Effekt: Anstatt jeden Baustein selbst zu entwickeln, zu dokumentieren und zu warten, integrieren Sie eine Basis, die strukturell bereits Störfreiheit, Partitionierung, sichere Communication und Multi-Core-Koordination abdeckt. Ihr Zeitaufwand für die Sicherheitstechnik verlagert sich somit auf wirklich spezielle Risiken des Projekts und weg von der generischen Infrastruktur.

Was bedeutet das konkret am Beispiel von Multi-Core-Prozessoren?

  • Konsistente Ausführung: Die Basissoftware führt Aufgaben und Ressourcen pro Kern aus, sodass sich sicherheitsrelevante und nicht sicherheitsrelevante Teile nicht gegenseitig beeinflussen.
  • Speicher- und Ressourcenschutz: Klare Partitionen, definierte HSI (Hardware-Software-Schnittstellen) und verifizierte Zugriffspfade verhindern fehlerhafte Memory Access-Zugriffe.
  • Nachweisdokumente: Etablierte Module und Prozesse reduzieren den Aufwand für Verifikation, Validierung und die Begründung des Sicherheitsnachweises, da viele Anforderungen bereits durch die Basis abgedeckt sind und auf wiederverwendbare Weise nachgewiesen werden können.
  • Analysieren Sie Ihre aktuellen Sicherheitsmaßnahmen (von der Gefahrenanalyse bis zum Sicherheitsnachweis) auf Redundanzen und manuelle Schritte.
  • Definieren Sie Architektur- und Prozessrichtlinien, die von Anfang an die Störungsfreiheit und die Partitionierung gewährleisten.
  • Testen Sie einen Aufbau mit unserer Basis-Software auf einem Steuerelement, insbesondere im Hinblick auf die Trennung von Komponenten und sichere Kommunikation.
  • Messen Sie die Auswirkungen auf Entwicklungszeit, Testaufwand und Nachweiskraft – und skalieren Sie den Ansatz auf weitere Projekte.

Wer frühzeitig strukturiert, spart später doppelt: weniger Nacharbeit, klarere Nachweise, schnellere Freigaben. Beginnen Sie jetzt mit einem gezielten Pilotprojekt und heben Sie Ihre Sicherheitsentwicklung auf ein effizienteres Niveau.

Kontaktieren Sie unsere MedTech Experten
Kontaktieren Sie unsere MedTech Experten
Bitte nutzen Sie das Kontaktformular.