Ein erweiterter Risikohorizont
Die Risikoszenarien klassischer IT-Sicherheit sind bekannt: Datendiebstahl, Manipulation von Informationen, Ransomware, Erpressung oder unautorisierter Zugriff auf Netzwerke. Ziel dieser Angriffe ist in der Regel die Kompromittierung von Daten, finanziellen Werten oder der digitalen Infrastruktur selbst. Doch diese Perspektive greift bei Embedded-Systemen zu kurz – sowohl in ihrer Tiefe als auch in ihrer Reichweite .
In eingebetteten Systemen sind die Angriffsziele nicht nur digitale Assets, sondern konkret umgesetzte, physisch verankerte Funktionen im Sinne von Sensorik und Aktuatorik. Angreifer manipulieren nicht nur Bits und Bytes, sondern beeinflussen reale Abläufe, Maschinenzustände und technische Steuerungssysteme . Die Folgen solcher Angriffe können unmittelbar spürbar, sicherheitskritisch oder sogar lebensbedrohlich sein:
- Zerstörung oder Fehlverhalten des Geräts: Firmware-Manipulation kann gezielt dazu genutzt werden, Geräte in sicherheitskritischen Anwendungen (z.B. Medizintechnik, Industrieautomatisierung, Mobilität) außer Betrieb zu setzen. Unkontrollierte Motorbewegungen, deaktivierte Schutzmechanismen oder fehlerhafte Sensordatenverarbeitung führen dabei nicht nur zu Betriebsstörungen, sondern im Extremfall zu Sach- oder Personenschäden.
- Fernsteuerung durch Dritte: Kompromittierte Kommunikationsschnittstellen, mangelhaft abgesicherte Fernwartung oder bewusst platzierte Backdoors eröffnen Angreifern die Möglichkeit, Systeme fernzusteuern . Dies kann zur absichtlichen Manipulation von Parametern, zum Umschalten von Betriebsmodi oder zur Eskalation auf höhere Systemebenen führen – häufig ohne unmittelbare Sichtbarkeit für Betreiber oder Nutzer.
- Vorzeitiger Verschleiß: Embedded-Systeme können gezielt durch Überlastung in einen Zustand versetzt werden, der ihre Komponenten stark beansprucht. Häufige Aktorzyklen, thermische Belastung, oder das Umgehen von Schonzeiten führen zu verkürzter Lebensdauer, höherem Wartungsaufwand und ungeplanten Ausfällen – insbesondere dann, wenn Predictive-Maintenance-Systeme mit kompromittierten Eingangsdaten arbeiten.
- Erhöhter Verbrauch von Energie und Ressourcen: Geräte, die durch manipulierte Firmware ineffizient arbeiten, können dauerhaft erhöhte Stromaufnahme, Wärmeentwicklung oder Materialverbrauch verursachen. In ressourcenlimitierten Umgebungen (bspw. batteriebetrieben, medizinisch steril, autark im Feld) kann dies kritische Betriebsunterbrechungen zur Folge haben. Auch wirtschaftlich entsteht durch verdeckte Ineffizienzen ein signifikanter Schaden .
- Sicherheits-Bypass: Sicherheitsfunktionen – etwa Zugriffskontrollen, Authentifizierungsmechanismen, oder sensorbasierte Plausibilitätsprüfungen – können durch modifizierte Firmware deaktiviert oder umgangen werden. Dadurch wird der Zugang für weitere Angriffe erleichtert, eine sichere Systemgrenze untergraben und die Kontrollhoheit über kritische Komponenten verloren.
- Indirekte Wirkung auf verbundene Systeme: Eingebettete Systeme agieren häufig als Schnittstelle zwischen physischen Prozessen und vernetzten IT-Strukturen. Ein kompromittiertes Embedded-System kann als Einfallstor dienen und lateral in andere Netzbereiche eindringen – etwa von einem IoT-Gerät in ein produktionsnahes OT-Netzwerk . So können selbst scheinbar unkritische Geräte Hebelpunkte für großflächige Angriffe werden.
- Embedded-Systeme als Angriffswaffe: Ihre weite Verbreitung und Netzwerkfähigkeit machen Embedded-Systeme selbst zu einer ernstzunehmenden Bedrohung für andere. Einzeln kaum auffällig, können sie im Verbund Teil massiver Botnetze werden – wie im Fall des \emph{Mirai}-Botnetzes, das aus Millionen schlecht gesicherter IoT-Geräte bestand und große Internetplattformen lahmlegte . Noch gravierender zeigt sich das Potenzial bei gezielter physischer Sabotage: Der Fall Stuxnet belegt, wie ein spezialisierter Schadcode über kompromittierte Embedded-Steuerungen zur realen Zerstörung industrieller Anlagen eingesetzt werden kann – unauffällig, präzise und mit politischer Reichweite.
Diese erweiterten Risikoszenarien führen deutlich vor Augen, dass sich das Verständnis von Sicherheit bei Embedded-Systemen grundlegend von klassischer IT unterscheiden muss. Es reicht nicht, die Vertraulichkeit von Daten zu schützen oder unautorisierte Zugriffe zu verhindern. Vielmehr geht es darum, die physische Integrität, Funktionssicherheit und Verfügbarkeit komplexer Geräte über ihren gesamten Lebenszyklus hinweg abzusichern – unter Berücksichtigung realweltlicher Wechselwirkungen, technischer Vielfalt und systemischer Abhängigkeiten.
Vulnerabilities und ihre systemabhängige Wirkung
Die CVE-Datenbank bietet einen zentralen Katalog öffentlich bekannter Schwachstellen – strukturiert, durchsuchbar und klassifiziert nach Schweregrad. Doch bei aller Nützlichkeit hat dieses System einen grundsätzlichen methodischen Limit: Es abstrahiert von konkreten Systemkontexten. Die Schwachstellen werden auf Komponenten- oder Softwarepaketebene beschrieben, nicht aber im Hinblick auf ihre tatsächliche Wirkung in einem spezifischen technischen Gesamtsystem .
Gerade in Embedded-Systemen ist jedoch genau dieser Kontext entscheidend. Eine Schwachstelle ist nicht per se kritisch oder unkritisch – ihre Bedeutung ergibt sich erst aus dem Zusammenspiel von Funktion, Architektur, Exponiertheit und Schutzmechanismen im jeweiligen Gerät .
Beispiel: Eine CVE mit dem Attribut „Privilegieneskalation“ kann in einem lokal isolierten Gerät, das keinen direkten Zugang von außen bietet, nahezu irrelevant sein. In einem fernadministrierbaren Medizingerät mit aktivem Remote-Zugang, Benutzerverwaltung und Netzwerkprotokollen kann dieselbe Schwachstelle jedoch potenziell lebensbedrohlich sein. Ein weiterer Fall: Ein ungepatchter Netzwerk-Stack in einem Embedded-Router stellt ein hohes Sicherheitsrisiko dar – während dieselbe Softwarekomponente in einem Edge-Device ohne externe Schnittstellen keine reale Angriffsfläche bietet.
Die Auswirkungen von Schwachstellen sind also nicht global bewertbar, sondern hängen in hohem Maß von folgenden Faktoren ab:
- der Systemarchitektur – also der technischen Struktur des Geräts: Welche CPU, welches Betriebssystem, welche Trennung von Sicherheitsdomänen ist implementiert?
- dem Zugriffsmodell – welche Kommunikationskanäle sind aktiv, wie erfolgt der Zugriff auf die Systemkomponenten, gibt es direkte oder indirekte Benutzerinteraktion?
- den Aktivierungsmechanismen – welche Softwarekomponenten oder Funktionen sind im Normalbetrieb tatsächlich aktiv, welche werden nur optional verwendet oder sind im Auslieferungszustand deaktiviert?
- sowie dem konkreten Einsatzszenario – handelt es sich um ein autarkes Steuergerät in einer geschlossenen Maschine, oder um ein Cloud-verbundenes, öffentlich zugängliches IoT-Gerät?
Ein und dieselbe Schwachstelle kann somit in verschiedenen Geräten völlig unterschiedliche Bedeutung haben: harmlos in einem Gerät mit restriktiver Konfiguration, hochkritisch in einem anderen, das dem Internet ausgesetzt ist. Hinzu kommt: Embedded-Systeme sind häufig individuell konfiguriert – selbst bei gleichem Grundprodukt unterscheiden sich Varianten je nach Endkunde, Region oder Einsatzzweck.
Ein weiteres Problem ist die fehlende oder mangelhafte Rückverfolgbarkeit: Viele Embedded-Systeme verfügen nicht über eine vollständig gepflegte Software Bill of Materials (SBOM), sodass die Zuordnung einer CVE zur tatsächlich verwendeten Bibliotheksversion oder Konfiguration nicht trivial ist. Selbst bei bekannten Abhängigkeiten kann durch Patches, Forks oder Build-Optionen ein divergentes Verhalten entstehen .
Für das Risikomanagement bedeutet das: CVE-Einträge dürfen nicht isoliert betrachtet werden. Sie liefern wertvolle Hinweise, aber keine ausreichende Entscheidungsgrundlage. Ihre Bewertung muss eingebettet sein in ein systematisches Threat Modeling, das die Umgebung, die Schutzbedarfe und die mögliche Wirkung realistisch abbildet .
Zukunftsweisende Methoden wie das VEX-Format (Vulnerability Exploitability eXchange) gehen daher einen Schritt weiter: Sie ergänzen CVE-Informationen um Aussagen zur kontextuellen Ausnutzbarkeit – z.B. ob eine Schwachstelle im konkreten Produkt überhaupt aktiviert ist, ob sie durch andere Sicherheitsmaßnahmen mitigiert wird oder ob sie unter realistischen Bedingungen überhaupt ausnutzbar wäre . Solche Zusatzinformationen ermöglichen eine differenzierte Risikobewertung, die den tatsächlichen Bedrohungen besser gerecht wird als eine rein scorebasierte Filterung.
Fazit: In Embedded-Umgebungen ist es nicht die Existenz einer Schwachstelle allein, die zählt – sondern ihre systemische Wirkung. Erst wenn technische, funktionale und operationale Rahmenbedingungen mit einbezogen werden, entsteht ein zutreffendes Bild des Risikos. CVEs sind ein Startpunkt – aber kein Zielpunkt im Risikomanagement.
Neue Methoden jenseits des CVE-Filters
In der klassischen IT genügt es häufig, Schwachstellen nach ihrem CVSS-Schweregrad zu filtern (z.B. Score ≥ 8) und anschließend systemweit durch Patches oder Konfigurationsänderungen zu beheben. Dieser Ansatz ist skalierbar, durch Automatisierung gut beherrschbar und in vielen Unternehmensumgebungen bewährt. Doch Embedded-Systeme folgen anderen Gesetzmäßigkeiten – und setzen diesem Modell klare Grenzen .
Die Ursachen liegen in der technischen Vielfalt, der geringen Standardisierung, fehlender Patchfähigkeit und dem hohen Kontextbezug . Eingebettete Systeme sind hochgradig spezialisiert, oft nur eingeschränkt updatefähig und stark von ihrer konkreten Einsatzumgebung geprägt. Eine Schwachstelle, die in einer Serverlandschaft sofortige Reaktion erfordert, kann in einem Embedded-System entweder irrelevant sein – oder besonders kritisch, weil kein einfacher Fix möglich ist.
Deshalb braucht es neue, kontextsensitive Methoden, die über rein scorebasierte CVE-Bewertung hinausgehen und das tatsächliche Risiko individuell analysieren:
- Threat Modeling auf Systemebene:
Statt pauschaler Listenverarbeitung erfordert Embedded-Security eine gezielte Betrachtung der Funktionalität und Architektur eines Systems. Welche Schnittstellen sind aktiv? Welche Kommunikationspfade existieren? Welche Komponenten sind sicherheitskritisch, manipulationsanfällig oder für Angreifer besonders attraktiv?
Modelle wie STRIDE oder DFD-basierte Ansätze ermöglichen strukturierte Bedrohungsanalysen , bei denen Sicherheitsanforderungen direkt aus potenziellen Missbrauchsszenarien abgeleitet werden. Ziel ist es, nicht nur bestehende Schwachstellen zu katalogisieren, sondern das Denken wie ein Angreifer systematisch in den Entwicklungsprozess einzubringen. - Sicherheitsanalysen entlang der Toolchain:
Viele Risiken entstehen nicht durch Laufzeitkomponenten, sondern bereits während der Entwicklung, beim Build oder bei der Auslieferung. In der Embedded-Welt ist die Toolchain – also Compiler, Debug-Werkzeuge, Flash-Tools und automatisierte Tests – häufig komplex, historisch gewachsen und nur schlecht dokumentiert .
Sicherheitsanalysen entlang dieser Kette zielen darauf ab, potenzielle Angriffsflächen wie offene Debug-Interfaces, manipulierte Build-Umgebungen oder unsignierte Firmwarepakete zu identifizieren. Ohne abgesicherte Toolchain bleibt jede Schwachstellenbewertung auf Anwendungsebene lückenhaft. - Differenzierte SBOM-Analyse:
Eine Software Bill of Materials (SBOM) ist nur dann aussagekräftig, wenn sie nicht nur die enthaltenen Komponenten benennt, sondern auch deren Versionen, Herkunft und Konfigurationen exakt dokumentiert .
Viele CVEs betreffen nur bestimmte Versionen oder Konstellationen. Eine flache SBOM, die nur Dateinamen oder Modulbezeichnungen aufführt, verfehlt daher ihren Zweck. Es braucht eine differenzierte Analyse, die in der Lage ist, Unterschiede zwischen „verwundbarer Code vorhanden“ und „verwundbarer Code aktiv nutzbar“ zu erkennen.
Tools wie Dependency-Track oder CycloneDX unterstützen die Zuordnung und Priorisierung von Schwachstellen im Kontext real eingesetzter Komponenten. - VEX-Dokumentation (Vulnerability Exploitability Exchange):
CVEs sagen aus, dass eine Schwachstelle existiert – aber nicht, ob sie im betrachteten Produkt tatsächlich relevant ist. Genau hier setzt das VEX-Format an : Es erlaubt die zusätzliche Beschreibung, ob eine Schwachstelle im konkreten Systemzustand \emph{ausnutzbar}, \emph{nicht betroffen}, \emph{durch Konfiguration mitigiert} oder \emph{bereits behoben} ist.
Solche Kontextinformationen sind essenziell, um Ressourcen gezielt einzusetzen und Risiken realistisch zu bewerten. Ohne VEX laufen viele Sicherheitsverantwortliche Gefahr, sich mit Scheinrisiken zu beschäftigen, während reale Bedrohungen unter dem Radar bleiben.
Fazit: Das klassische Patch-Paradigma greift in Embedded-Umgebungen zu kurz – nicht aus Bequemlichkeit, sondern aus Notwendigkeit. Zu vielfältig sind die Systeme, zu unterschiedlich ihre Sicherheitsanforderungen, zu begrenzt die Möglichkeiten für standardisierte Reaktionen. Embedded-Risikomanagement muss sich daher stärker am Einsatzkontext, der Systemfunktion und der realen Gefährdung orientieren.
Nur durch Kombination aus präziser Bestandsaufnahme, kontextbasierter Bewertung und ganzheitlicher Systemanalyse lassen sich Sicherheitsmaßnahmen entwickeln, die wirkungsvoll und wirtschaftlich zugleich sind. Das verlangt mehr als Technologiewissen – es erfordert ein neues Mindset in der Risikosteuerung.
Wer trägt das Risiko – und wer ist verantwortlich?
Eine der zentralen Herausforderungen im Embedded-Risikomanagement liegt nicht in der Technik – sondern in der Organisation der Verantwortung. Wer ist zuständig für die Bewertung von Schwachstellen? Wer kommuniziert Risiken? Und wer muss bei Bedarf Maßnahmen ergreifen – technisch, wirtschaftlich, regulatorisch?
Gerade bei Embedded-Systemen ist diese Frage besonders komplex, weil sie typischerweise nicht aus einer Hand stammen. Die Endprodukte sind das Ergebnis hochgradig arbeitsteiliger Lieferketten, in denen Systemintegration, Komponentenentwicklung, Firmwarepflege, Infrastrukturservices und teilweise auch Open-Source-Beiträge über mehrere Organisationen hinweg verteilt sind. Entsprechend verzweigt ist auch die Risikoverantwortung:
- OEMs (Original Equipment Manufacturer):
Als Systemintegratoren und Produktanbieter tragen OEMs die \emph{gesamtverantwortliche Rolle}. Sie sind Ansprechpartner gegenüber Kunden, Behörden und Zertifizierern – und somit verpflichtet, Schwachstellen in der gesamten Gerätelogik zu managen. Dazu gehört nicht nur die technische Absicherung, sondern auch die vertragliche Steuerung der Lieferkette, die Definition von Security-Anforderungen sowie die Einhaltung branchenspezifischer Standards (z.B. UNECE R155, ISO/SAE 21434 ). - Zulieferer (Tier 1, Tier 2):
Zulieferer sind verantwortlich für die \emph{Sicherheit und Aktualität ihrer Komponenten} – insbesondere, wenn sie eigene Firmware, Treiber oder Middleware liefern. Sie müssen nicht nur sicherstellen, dass bekannte Schwachstellen gemeldet und gepflegt werden, sondern auch proaktiv Transparenz schaffen – etwa durch SBOMs, Patchnotizen oder CVE-Registrierungen. Gleichzeitig müssen sie ihre Produkte so gestalten, dass sie sich nahtlos in das Risikokonzept des OEM integrieren lassen. - Dienstleister und Open-Source-Communities:
Auch externe Codequellen wie Frameworks, Bibliotheken oder generierter Code (z.B. aus Modellierungstools oder Low-Code-Plattformen) tragen Verantwortung – mindestens für die \emph{offene Kommunikation von Schwachstellen und Abhängigkeiten}. Besonders im Open-Source-Bereich besteht jedoch häufig eine \emph{Verantwortungslücke}: Maintainer agieren freiwillig, ohne vertragliche Bindung – sodass Unternehmen die technische Qualität und Sicherheitslage selbst prüfen oder durch ergänzende Analysewerkzeuge absichern müssen. - Betreiberorganisationen:
Organisationen, die Embedded-Systeme in Betrieb nehmen – etwa Kliniken, Infrastrukturbetreiber oder industrielle Fertigungsunternehmen – sind verantwortlich für die \emph{Integration in bestehende Sicherheits- und Compliance-Prozesse}. Sie müssen sicherstellen, dass ihre Geräte sicher konfiguriert, überwacht und regelmäßig auf Schwachstellen geprüft werden. Ebenso sollten Anforderungen an Security-Updates, Remote-Zugänge und Incident-Handling bereits bei der Beschaffung vertraglich geregelt sein.
Doch: Die Verantwortung endet nicht mit der Lieferung. Embedded-Sicherheit ist eine kontinuierliche Aufgabe, bei der technische, rechtliche und organisatorische Risiken laufend neu bewertet und verteilt werden müssen. Klare Rollen, vertragliche Regelungen und verbindliche Kommunikationsprozesse sind dafür essenziell.
Insbesondere gilt:
- Risiken dürfen nicht entlang der Lieferkette nach unten durchgereicht werden – etwa vom OEM zum Tier-1-Zulieferer – ohne dass dabei technische Sorgfaltspflichten klar benannt und nachgewiesen werden .
- Es braucht definierte Meldemechanismen für Schwachstellen: Wer informiert wen, in welcher Frist, über welche Kanäle – und mit welchem Detailgrad?
- Die Frage der Haftung bei Sicherheitsvorfällen muss vorab geregelt sein – idealerweise abgestimmt mit branchenspezifischen Haftungsregimen (z.B. Produkthaftungsgesetz, MDR, RED, Cyber Resilience Act).
- Schließlich muss auch die Risikokommunikation professionell organisiert sein: gegenüber Kunden, Behörden, Prüfern – und nicht zuletzt intern im eigenen Unternehmen.
Fazit: Sicherheit ist nicht allein eine technische Aufgabe – sondern eine Frage der strukturellen Verantwortung. Nur wenn alle Beteiligten in der Entwicklung, Integration und Nutzung eingebetteter Systeme ihre Rollen kennen, annehmen und leben, kann ein tragfähiges Sicherheitsniveau erreicht werden. Ein Risikotransfer allein – etwa durch vertragliche AGB-Klauseln – ersetzt kein Risikomanagement.