Firmware-Sicherheit & OTA für Medizingeräte
Medizingeräte-Einreichungen scheitern heute an der Cybersicherheit, bevor sie überhaupt an der klinischen Funktion scheitern: ein Refuse-to-Accept-Brief wegen fehlender SBOM oder eine CVE in einer nicht patchbaren Komponente, die in der Postmarket-Überwachung entdeckt wird. Wir bauen die Firmware-Sicherheit und die OTA-Pipeline so, dass das Gerät nur signierten Code bootet, nur signierte Updates akzeptiert und die SBOM-, Schwachstellenmanagement- und Audit-Trail-Nachweise liefert, die der FDA-Premarket-Leitfaden und der IEC-81001-5-1-Prüfer verlangen. Das ist die Wartbarkeitsschicht, die ein eingesetztes Gerät über Jahre patchbar hält, kein einmaliger Pentest.
Challenges specific to Medical Devices
Refuse-to-Accept wegen fehlender SBOM
Die FDA-Premarket-Cybersicherheitsprüfung weist die Einreichung zurück, weil keine maschinenlesbare Software-Stückliste existiert, die jede Drittanbieter- und Open-Source-Komponente mit Version und bekannten Schwachstellen auflistet.
Ein Feldgerät lässt sich nicht sicher patchen
Eine CVE der Log4Shell-Klasse trifft eine ausgelieferte Komponente, doch die Firmware hat keinen signierten Update-Pfad, sodass dem Hersteller ein Rückruf droht, statt ein bereinigtes Image an Feldgeräte zu verteilen.
Unsignierte Firmware ermöglicht Angreifer-Persistenz
Ohne Secure Boot führt der Bootloader jedes Image im Flash aus, sodass ein bösartiger oder veränderter Build den Reset überdauert und das Gerät nicht mehr bestätigen kann, dass es herstellergenehmigten Code ausführt.
OTA-Rollback öffnet eine gepatchte Lücke erneut
Ein Update-Mechanismus, der ein älteres signiertes Image akzeptiert, erlaubt einem Angreifer, eine gepatchte Einheit auf eine verwundbare Version herabzustufen und so das gesamte Schwachstellenmanagement im Postmarket auszuhebeln.
Kein koordiniertes CVE-Tracking und -Triage
Die Postmarket-Überwachung erfordert den Abgleich des Komponenteninventars mit neuen Meldungen, doch ohne SBOM-zu-CVE-Feed erfährt das Team von ausnutzbaren Schwachstellen zuerst von Kunden oder Behörden.
Sicherheitsereignisse hinterlassen keinen belastbaren Nachweis
Eine fehlgeschlagene Signaturprüfung, ein abgelehntes Update oder eine Konfigurationsänderung erzeugt kein manipulationssicheres Protokoll, sodass der Hersteller einen Vorfall nicht rekonstruieren oder bei einem IEC-81001-5-1-Audit Kontrolle nachweisen kann.
How GizanTech solves them
- Secure-Boot-v2-Vertrauenskette. Wir aktivieren Hardware-Secure-Boot v2 mit dem im eFuse verankerten Public-Key-Digest, signieren jede Stufe von Bootloader und Anwendung mit RSA-3072/ECDSA und deaktivieren JTAG sowie ROM-Download, sodass nur herstellersignierte Firmware ausgeführt wird.
- Signierte, rollback-geschützte OTA. Updates werden als mit einem Offline-Schlüssel signierte Images ausgeliefert, vor der Aktivierung verifiziert und durch einen monotonen Anti-Rollback-Versionszähler im eFuse abgesichert, sodass ein Downgrade auf einen verwundbaren Build am Bootloader abgewiesen wird.
- Automatisierte CycloneDX-SBOM-Generierung. Der CI-Build erzeugt eine CycloneDX-SBOM, die jede Komponente, Version und Lizenz auflistet, exportiert als maschinenlesbares Artefakt, das die FDA-Premarket-Einreichung und die IEC-81001-5-1-SOUP-Prüfung verlangen.
- SBOM-gesteuertes Schwachstellenmanagement. Wir verbinden die SBOM mit einem CVE-Feed (NVD/OSV), sodass jedes Release gegen bekannte Meldungen gescannt wird, Schwachstellen nach Ausnutzbarkeit triagiert werden und die Patch-oder-Begründung-Entscheidung für die Postmarket-Überwachung dokumentiert wird.
- Feld-patchbare A/B-Update-Partitionen. Zwei Anwendungs-Slots mit einem Confirm-and-Revert-Watchdog erlauben es, ein bereinigtes Image over the air zu verteilen und zu validieren, mit Rückfall auf den letzten funktionierenden Slot bei Boot-Fehler, sodass ein Patch nie ein Feldgerät unbrauchbar macht.
- Signierter, anfügbarer Sicherheits-Audit-Trail. Boot-Integritätsergebnisse, Update-Annahmen und -Ablehnungen sowie sicherheitsrelevante Konfigurationsänderungen werden in ein hash-verkettetes, HMAC-signiertes Ereignisprotokoll geschrieben, das als manipulationssicherer Nachweis für Vorfallrekonstruktion und Audit exportiert.
| Sicherheitseigenschaft | Mechanismus | Norm (FDA-Premarket-Cybersicherheit / IEC 81001-5-1) | Verhindertes Risiko |
|---|---|---|---|
| Secure Boot | Hardware-Secure-Boot v2, Public-Key-Digest im eFuse verankert, signierte Bootloader- und App-Stufen, JTAG und ROM-Download deaktiviert | FDA-Premarket-Cybersicherheit - Authentizität/Integrität; IEC 81001-5-1 5.4 sichere Implementierung | Unsignierte oder veränderte Firmware, die ausgeführt wird und den Reset überdauert |
| Signiertes Update | Mit Offline-Schlüssel signiertes Image vor Aktivierung verifiziert plus monotoner Anti-Rollback-Zähler im eFuse | FDA-Premarket-Cybersicherheit - Patchbarkeit/Integrität; IEC 81001-5-1 5.6 Verifizierung | Gefälschte oder herabgestufte Firmware, die eine bereits gepatchte Schwachstelle erneut öffnet |
| SBOM-Generierung | Automatisierte CycloneDX-SBOM aus CI, Inventar aus Komponente-Version-Lizenz pro Release exportiert | FDA-Premarket-Cybersicherheit - SBOM-Anforderung; IEC 81001-5-1 SOUP-Inventar | Refuse-to-Accept und blinde Flecken bei undokumentierten Drittanbieter-Komponenten |
| Schwachstellenmanagement | SBOM auf NVD/OSV-CVE-Feed abgebildet, Ausnutzbarkeits-Triage, Patch-oder-Begründung-Entscheidung dokumentiert | FDA-Postmarket-Cybersicherheit; IEC 81001-5-1 6.1 Schwachstellenbehandlung | Ausnutzbare CVE in einer ausgelieferten Komponente, die ungetrackt ins Postmarket gelangt |
| Feld-Patchbarkeit | Zwei A/B-Partitionen mit Confirm-and-Revert-Watchdog und signierter OTA-Auslieferung | FDA-Premarket-Cybersicherheit - Wartbarkeit; IEC 81001-5-1 6.2 Update-Management | Ein nicht patchbares Gerät, das einen Rückruf statt einer Fernbereinigung erzwingt |
| Audit-Trail | Hash-verkettetes, HMAC-signiertes anfügbares Ereignisprotokoll von Boot-, Update- und Konfigurationsereignissen | FDA-Premarket-Cybersicherheit - Ereignisprotokollierung/-erkennung; IEC 81001-5-1 5.7 Audit | Kein belastbarer Nachweis, um bei einem Vorfall Kontrolle zu rekonstruieren oder nachzuweisen |
Go deeper
Firmware Security & OTA for other industries
Frequently asked questions
Erfüllt das die FDA-Premarket-Cybersicherheits-SBOM-Anforderung?
Ja. Unser CI-Build erzeugt eine CycloneDX-SBOM, die jede Komponente, Version und Lizenz als maschinenlesbares Artefakt auflistet, also genau die Software-Stückliste, die die FDA-Premarket-Einreichung und die Schwachstellenbewertung des Prüfers erwarten.
Wie verhindern Sie, dass ein gepatchtes Gerät herabgestuft wird?
Jedes signierte OTA-Image trägt eine Security-Version, die einen im eFuse verankerten monotonen Anti-Rollback-Zähler erreichen oder übertreffen muss, sodass der Bootloader jedes ältere Image abweist und ein Angreifer eine bereinigte Einheit nicht auf einen verwundbaren Build herabstufen kann.
Was passiert, wenn ein OTA-Update im Feld nicht bootet?
Updates landen in einem inaktiven A/B-Slot und müssen nach dem ersten Boot einen Confirm-and-Revert-Watchdog bestehen; wenn das neue Image die Validierung nicht besteht, fällt das Gerät automatisch auf den letzten funktionierenden Slot zurück, sodass ein Fern-Patch nie ein Feldgerät unbrauchbar macht.
Wie gehen Sie mit einer neuen CVE um, nachdem das Gerät ausgeliefert wurde?
Die SBOM ist auf NVD/OSV-Feeds abgebildet, sodass jede Meldung gegen Ihr Komponenteninventar geprüft, nach Ausnutzbarkeit triagiert und mit einer dokumentierten Patch-oder-Begründung-Entscheidung gelöst wird, die in Ihre Postmarket-Überwachung und die signierte Update-Pipeline einfließt.
Wie ordnet sich das in IEC 81001-5-1 ein?
Secure Boot und signierte Images decken sichere Implementierung und Verifizierung ab, die SBOM deckt das SOUP-Inventar ab, die CVE-Pipeline deckt Schwachstellenbehandlung und Update-Management ab, und das signierte Audit-Log deckt die Protokollierungs- und Audit-Erwartungen der Norm ab.