2/5 Unsichtbare Schwachstellen: Warum klassische IT-Sicherheitsstrategien Embedded-Systeme gefährden

1 – 2 – 3 – 4 – 5

Embedded Systeme wie Firewalls, Steuerungen und IoT-Geräte sind das Rückgrat moderner Infrastrukturen – und gleichzeitig ein blinder Fleck in vielen Sicherheitskonzepten. Während Server, Workstations und Cloud-Anwendungen durch etablierte Prozesse und Tools gut abgesichert sind, fristen Embedded-Komponenten häufig ein Dasein im Schatten. Ihre Software ist meist tief ins Gerät integriert, hochspezialisiert und schwer aktualisierbar – was sie besonders anfällig für langfristig bestehende Schwachstellen macht. Hinzu kommt: Die klassischen Mechanismen des Vulnerability Managements greifen hier nur bedingt. Es fehlt an standardisierten Schnittstellen, etablierten Meldeprozessen und einer ausreichenden Abdeckung durch öffentliche Schwachstellendatenbanken. Wer Embedded-Systeme absichern will, muss deshalb umdenken – weg vom vertrauten IT-Schema, hin zu einer risikobasierten, kontextsensitiven Sicherheitsstrategie, die die Eigenheiten dieser Systeme ernst nimmt.

Embedded ≠ Klassische IT: Wo der Vergleich hinkt

In der Welt klassischer IT ist das Vulnerability Management längst Routine: Scanner durchforsten Netzwerke, Reports listen Schwachstellen auf, und CVE-Nummern sorgen für schnelle Orientierung. Sicherheitslücken werden öffentlich dokumentiert, bewertet und priorisiert – oft binnen Stunden. Doch was, wenn diese Werkzeuge auf Embedded Systeme treffen? Auf Geräte also, deren Software selten öffentlich dokumentiert, proprietär und tief in Hardware integriert ist?

Genau hier offenbart sich ein fundamentaler Unterschied: Embedded Software ist oft hochspezialisiert, schwer updatebar und nutzt individuelle Open-Source-Abwandlungen. Nicht selten ist der Code in Teilen noch „handgeschrieben“ – also speziell für das Zielsystem entwickelt, oft ohne Standardbibliotheken oder modularen Aufbau. Diese maßgeschneiderte Entwicklung erhöht nicht nur die Komplexität, sondern erschwert auch die Nachvollziehbarkeit der genutzten Komponenten.

Hinzu kommt: Viele Embedded-Hersteller sichern ihre Software gezielt gegen Reverse Engineering ab – etwa durch Obfuskation, Verschlüsselung oder gezielte Schutzmechanismen auf der Hardwareebene. Obfuskation bezeichnet dabei das absichtliche „Verschleiern“ von Quell- oder Maschinen-Code, sodass dieser für Menschen und Analysewerkzeuge schwerer zu verstehen ist. Variablennamen werden anonymisiert, Programmstrukturen fragmentiert und Kontrollflüsse so verändert, dass das Rückverfolgen der ursprünglichen Logik fast unmöglich wird. Ziel ist es, die Nachbildung oder Sicherheitsanalyse zu erschweren – was allerdings auch legitime Prüfprozesse behindert.

Ein weiterer Denkfehler, der sich hartnäckig hält: Security by Obscurity. Viele Hersteller verlassen sich noch immer darauf, dass ihre Systeme durch Intransparenz geschützt sind – nach dem Motto: „Was niemand kennt, kann auch niemand angreifen.“ Doch diese Haltung ist trügerisch. Sobald ein Gerät auf dem Markt ist, kann es analysiert, zerlegt und getestet werden. Die fehlende Dokumentation schützt nicht vor Angriffen – sie erschwert lediglich den Schutz.

Zudem steht die Offenlegung von Schwachstellen oft im Spannungsfeld unternehmerischer Interessen. Wer möchte schon öffentlich machen, dass etwa die Bluetooth-Verbindung einer elektrischen Zahnbürste von außen manipulierbar ist? Oder dass die Steuerung eines Industrie-Routers über eine ungepatchte Schwachstelle kompromittiert werden kann? Die Angst vor Reputationsverlust, Produkthaftung oder regulatorischen Konsequenzen sorgt dafür, dass viele Schwachstellen lieber intern behalten als öffentlich geteilt werden. Das führt zu einer systemischen Intransparenz, die das Sicherheitsniveau ganzer Branchen gefährdet.

Schwachstellendatenbanken: Für Embedded nur begrenzt brauchbar

Die etablierten Schwachstellendatenbanken wie CVE (Common Vulnerabilities and Exposures), NVD (National Vulnerability Database) oder die EUVD (European Union Vulnerability Database) bilden das Rückgrat klassischer IT-Sicherheitsprozesse. Sie strukturieren öffentlich gemeldete Schwachstellen, bewerten deren Schweregrad und bieten damit die Basis für automatisierte Security-Tools. Doch gerade diese Systematik wird Embedded-Systemen zum Problem.

Die Logik dieser Datenbanken setzt voraus, dass Schwachstellen einem identifizierbaren Softwareprodukt und einer klaren Versionsnummer zugeordnet werden können. Genau hier scheitert der Abgleich bei Embedded Software oft. Firmware-Builds sind individuell, Release-Zyklen intransparent, und die verwendeten Komponenten selten standardisiert. Statt eines klar benennbaren „Produkts“ liegen oft proprietäre Kombinationen aus Bootloader, Treibern, Middleware und angepasstem Linux-Kernel vor – auf einem einzigen Mikrocontroller verschmolzen.

Ein praktisches Beispiel: Eine Sicherheitslücke in OpenSSL ist in der NVD klar dokumentiert, mit CVE-ID, CVSS-Bewertung und Fix-Status. Doch wenn ein Hersteller diese Bibliothek in einer angepassten Form tief in ein Embedded-System integriert hat, wird die Verbindung zur ursprünglichen Schwachstelle oft nicht erkannt – weder vom Hersteller noch von externen Sicherheitstools.

Die Folge: Systeme bleiben verwundbar, obwohl ein Patch existiert. Und da viele Embedded-Produkte nie ein vollständiges SBOM (Software Bill of Materials) mitliefern, fehlt es Sicherheitsverantwortlichen an der nötigen Transparenz, um gezielt auf Schwachstellen reagieren zu können.

Selbst wenn die betroffenen Komponenten in öffentlichen Datenbanken gelistet sind, fehlt oft der Kontext: Welche Varianten sind betroffen? Wie relevant ist der Exploit in einem ressourcenlimitierten Gerät? Und wie lässt sich überhaupt ein Update einspielen, wenn der Kunde keinen Zugriff auf die Firmware hat?

Die strukturellen Lücken in der Abdeckung embedded-typischer Software durch klassische Schwachstellendatenbanken führen so zu einem systemischen Blindflug. Das Sicherheitsniveau hängt oft weniger vom tatsächlichen Risiko als von der Frage ab, ob ein Hersteller willens und in der Lage ist, Schwachstellen aktiv zu melden – und Nutzer darüber zu informieren.

Warum Embedded-Systeme durch das Raster fallen

Dass Embedded-Systeme immer wieder durch das Raster fallen, hat Gründe.

• Modifizierte Software: Embedded-Systeme verwenden häufig stark angepasste oder sogar vollständig selbst entwickelte Softwarekomponenten. Diese weichen nicht nur von Standardversionen ab, sondern kombinieren oft verschiedene Bibliotheken, Treiber und Middleware in einer proprietären Architektur. Dadurch lässt sich eine bekannte Schwachstelle – etwa in einer weitverbreiteten Komponente wie OpenSSL – nicht ohne Weiteres einer spezifischen Firmware-Version zuordnen. Automatisierte Tools stoßen hier an ihre Grenzen, da die betroffenen Codepfade oft individuell verändert oder rekombiniert wurden.
• Keine Disclosure-Prozesse: Anders als in der klassischen IT, wo Security-Teams, Bug-Bounty-Programme oder CERTs (Computer Emergency Response Teams) etabliert sind, fehlt in vielen Embedded-Organisationen ein standardisierter Prozess zur Schwachstellenmeldung und -bewertung. Hersteller von Embedded-Systemen sind oft stark produktorientiert, nicht sicherheitszentriert aufgestellt. Ohne klare interne Prozesse – etwa für CVE-Registrierungen oder Patch-Kommunikation – bleiben bekannte Schwachstellen intern oder werden nur mit Verzögerung öffentlich kommuniziert. Für Sicherheitsverantwortliche bedeutet das: Wichtige Informationen sind entweder nicht verfügbar oder nur über inoffizielle Wege zugänglich.
• Fehlende Standardisierung: Die meisten öffentlichen Schwachstellendatenbanken wie CVE oder NVD arbeiten mit klar definierten Produkten, Versionen und Plattformen. Embedded-Software sprengt dieses Raster regelmäßig: Hier gibt es keine marktweit standardisierten Release-Zyklen oder Produktnamen, sondern eine Vielzahl individueller Firmware-Varianten, oft angepasst pro OEM, pro Gerätetyp oder sogar pro Seriennummer. Diese Vielfalt lässt sich in der Struktur klassischer Datenbanken nicht abbilden. Zudem ist das Mapping zwischen einer gefundenen Schwachstelle und den tatsächlich betroffenen Produkten oft unvollständig oder gar nicht möglich – besonders wenn ein SBOM fehlt.

Ein weiteres Grundproblem liegt in der fehlenden Begriffs- und Systemklarheit: Was zählt überhaupt als Embedded-System? Während bei Steuergeräten in Fahrzeugen oder industriellen Steuerungen weitgehend Konsens herrscht, beginnt die Unsicherheit im Consumer-Bereich. Gehört eine elektrische Zahnbürste mit Bluetooth-Verbindung bereits dazu? Ist ein Staubsaugerroboter mit App-Anbindung ein Embedded-System? Oder nur ein „smarter“ Haushaltshelfer? Genau diese Unklarheit erschwert die Entwicklung einheitlicher Sicherheitsstandards – und bietet Schlupflöcher für Hersteller, sich ihrer Verantwortung zu entziehen. Die Abgrenzung ist nicht nur semantisch relevant, sondern bestimmt auch, ob Sicherheitsprüfungen verpflichtend, freiwillig oder gar nicht stattfinden.

Hinzu kommt eine enorme technische Diversität: Es gibt dutzende Mikrocontrollerfamilien – von ARM Cortex-M über AVR, ESP32 bis hin zu NXP, Renesas oder STM32 –, die je nach Anwendungsgebiet und Hersteller in Embedded-Systemen zum Einsatz kommen. Jede dieser Architekturen bringt eigene Besonderheiten bei der Speicherverwaltung, beim Bootprozess, bei der Updatefähigkeit und bei der Integration sicherheitsrelevanter Funktionen mit. Allein durch diese Hardwarevielfalt entstehen unzählige Kombinationen aus Systemarchitektur, Betriebssystem (wenn überhaupt vorhanden) und Firmwaredesign, die eine standardisierte Sicherheitsbewertung nahezu unmöglich machen.

Das Ergebnis: Vulnerabilities bleiben unsichtbar – oder werden zu spät erkannt. In der Praxis bedeutet das, dass viele sicherheitsrelevante Lücken in Embedded-Produkten erst dann Aufmerksamkeit bekommen, wenn sie aktiv ausgenutzt werden – ein Zustand, der in der klassischen IT längst als inakzeptabel gilt. Die Folge ist ein strukturelles Risiko, das mit jeder ungesicherten Komponente wächst – oft unbemerkt von Anwendern und Betreibern.

Welche Alternativen existieren?

Ein Hoffnungsschimmer liegt in SBOMs (Software Bill of Materials): Sie schaffen Transparenz über die enthaltenen Komponenten und ermöglichen eine komponentenbasierte Sicherheitsanalyse. Ähnlich wie ein Zutatenverzeichnis auf einem Lebensmittelprodukt listet ein SBOM alle Softwarebestandteile eines Systems auf – von Standardbibliotheken über Open-Source-Komponenten bis hin zu proprietären Modulen. Das ist insbesondere bei Embedded-Systemen entscheidend, da hier oft intransparente, tief verschachtelte Abhängigkeiten vorliegen.

Doch auch hier gilt: Nur wer weiß, was enthalten ist, kann gezielt nach Schwachstellen suchen. Eine SBOM entfaltet nur dann ihren vollen Nutzen, wenn sie vollständig, aktuell und präzise gepflegt ist. In der Praxis scheitert dies häufig an Zeitmangel, unzureichender Tool-Unterstützung oder fehlenden Prozessen zur automatisierten Generierung. Zudem sind viele Unternehmen zurückhaltend, SBOMs vollständig offen zu legen – aus Angst vor Reverse Engineering, Know-how-Verlust oder rechtlichen Konsequenzen bei falsch deklarierten Abhängigkeiten.

Einige große Hersteller wie Siemens, QNX oder Bosch pflegen interne Sicherheits-Advisories, die bekannten Schwachstellen und empfohlene Gegenmaßnahmen dokumentieren. Diese Informationen sind jedoch meist nur registrierten Kunden zugänglich, selten strukturiert auffindbar und oft nicht in den bekannten Schwachstellendatenbanken wie CVE oder NVD verlinkt. Externe Analysten, CERTs oder Sicherheitsdienstleister haben somit nur eingeschränkten Zugriff – was die Koordination und Analyse erschwert.

Ein weiterer Ansatz ist der Einsatz von Analyse- und Überwachungswerkzeugen wie Dependency-Track, VDR (Vulnerability Disclosure Report) oder VEX (Vulnerability Exploitability eXchange). Diese Tools erlauben es, bekannte Schwachstellen gezielt mit den Komponenten eines Systems abzugleichen und deren Relevanz im jeweiligen Kontext zu bewerten. Der VEX-Standard beispielsweise ermöglicht es, zusätzlich zur bloßen Existenz einer Schwachstelle auch deren tatsächliche Ausnutzbarkeit („exploitability“) zu kommunizieren – etwa mit Blick auf Zugriffsmöglichkeiten, Isolationsebenen oder aktive Schutzmechanismen.

Zukunftsweisend sind auch regulatorische Entwicklungen wie der EU Cyber Resilience Act, der unter anderem die verpflichtende Einführung und Pflege von SBOMs in sicherheitskritischen Produkten vorsieht. Solche Vorgaben könnten helfen, eine Mindesttransparenz zu schaffen und zumindest in kritischen Infrastrukturen oder zertifizierungspflichtigen Branchen einen Sicherheitsgrundstandard zu etablieren.

Dennoch bleibt die Realität: Solange keine interoperablen Standards und industrieweiten Verpflichtungen zur Veröffentlichung von Schwachstellen bestehen, bleiben viele Embedded-Systeme faktisch außerhalb des Radars. Die Herausforderung besteht darin, diese Strukturen aufzubrechen – technisch, organisatorisch und regulatorisch.

Was bedeutet das für Firewalls und andere Embedded-Komponenten?

Für das Vulnerability Management auf Firewall-Ebene ergeben sich daraus klare Konsequenzen – sowohl strategisch als auch operativ. Mit „Firewall-Ebene“ ist hier jener technische und organisatorische Schnittpunkt gemeint, an dem eingebettete Systeme sicherheitsrelevante Kommunikationsflüsse kontrollieren – etwa als Netzwerk-Perimeter in industriellen Anlagen, als eingebettete Firewall in Routern oder als Sicherheitsmodul innerhalb eines verteilten Embedded-Systems. Es geht also um jene kritischen Komponenten, die zwischen internen und externen Datenströmen vermitteln – und damit ein bevorzugtes Angriffsziel darstellen.

• IT-Standardtools reichen nicht aus. Herkömmliche Schwachstellenscanner sind auf Desktop-Betriebssysteme, Server-Software oder Web-Applikationen ausgelegt. Sie erkennen nur, was standardisiert beschrieben ist – und übersehen embedded-typische Risiken. Wer Embedded-Firewalls absichern will, muss zusätzliche Methoden beherrschen: statische und dynamische Codeanalyse, Reverse Engineering, Firmware-Dumping oder sogar Physical Device Testing. Auch das Verstehen von Mikrocontroller-Architekturen und Low-Level-Kommunikationsprotokollen (z. B. UART, SPI, I²C) ist in sicherheitskritischen Kontexten unerlässlich.
• Regelmäßige Herstellerkommunikation ist essenziell. Firewalls und andere Embedded-Komponenten enthalten häufig proprietäre Firmware, deren Sicherheitslage sich nicht über öffentliche Quellen klären lässt. Ein aktiver Austausch mit dem Hersteller – idealerweise über vertraglich definierte Support- oder Disclosure-Kanäle – ist entscheidend. Nur so erhält man Informationen über bekannte Schwachstellen, verfügbare Patches oder geplante Sicherheitsupdates. Ohne diesen Dialog bleibt man auf eigene forensische Analysen angewiesen – mit entsprechendem Aufwand und Risiko.
• Risiko- statt reiner Listenorientierung. Das bloße Abarbeiten von CVE-Listen greift bei Embedded-Systemen zu kurz. Stattdessen ist eine kontextbasierte Risikobewertung erforderlich: Welche Funktionen sind aktiv? Welche Komponenten sind exponiert? Welche Schwachstelle ist in der Praxis wirklich ausnutzbar – und mit welchem Aufwand? Ein systematisches Threat Modeling, ergänzt um eine realistische Einschätzung der Betriebssituation (z. B. remote erreichbar vs. lokal isoliert), ermöglicht fundierte Managemententscheidungen. Nur so lassen sich begrenzte Ressourcen gezielt einsetzen und relevante Risiken priorisieren.

In der Summe erfordert das Vulnerability Management für Embedded Firewalls eine tiefere technische Auseinandersetzung, spezifisches Know-how und eine enge Verzahnung mit Herstellern und internen Entwicklerteams. Klassische IT-Sicherheitsabteilungen stoßen hier oft an ihre Grenzen – es braucht spezialisierte Schnittstellen zwischen IT und Embedded Engineering, um ein ganzheitliches Sicherheitskonzept zu etablieren.

Die unsichtbare Angriffsfläche: Toolchains im Fokus

Ein oft unterschätzter, aber sicherheitskritischer Aspekt im Embedded Vulnerability Management ist die Toolchain – also jene Werkzeuge und Prozesse, mit denen Embedded-Software entwickelt, getestet, geflasht, deployed und später gewartet wird. Während das Augenmerk meist auf der Laufzeitumgebung liegt, eröffnet bereits die Entwicklungs- und Lieferkette ein erhebliches Angriffsrisiko.

Build-Systeme, Compiler, Debug-Interfaces, Flash-Tools und Testautomatisierungen sind selbst komplexe Softwaresysteme – häufig mit historisch gewachsenen Abhängigkeiten, schlechter Dokumentation und eingeschränktem Zugriffsschutz. Kompromittierte Toolchains können manipulierten Code einspielen, Debug-Zugänge offenlassen oder ungewollt Debug-Symbole in Produktions-Firmware übertragen. Besonders kritisch: Viele dieser Tools stammen von Drittanbietern oder Open-Source-Projekten, die nur sporadisch gepflegt werden und selten im Fokus gängiger Sicherheitsanalysen stehen.

Auch physische Schnittstellen – wie JTAG, SWD oder serielle Konsolen – bleiben oft aktiv und ungesichert. Wer über entsprechende Zugänge verfügt, kann nicht nur die Firmware auslesen, sondern auch Systemzustände manipulieren oder sicherheitsrelevante Funktionen umgehen. Und selbst im Servicefall, etwa beim Flashen über Wartungstools, besteht das Risiko, dass Schadcode in den Updateprozess eingeschleust wird – sei es über manipulierte Images, unsichere Kommunikationsprotokolle oder fehlende Integritätsprüfungen.

Beispiele aus der Praxis:

• Automotive: In einem bekannten Fall wurde über die offene Debug-Schnittstelle eines Steuergeräts Zugriff auf sicherheitsrelevante Fahrfunktionen ermöglicht – weil die Service-Software nicht prüfte, ob sie mit einem freigegebenen Firmware-Image arbeitete.
• Medizintechnik: In einem klinischen Umfeld wurden Geräte-Updates über USB-Sticks verteilt. Ein infiziertes Update-Tool führte dazu, dass manipulierte Firmware auf mehrere Geräte aufgespielt wurde – ohne Integritätsprüfung oder Authentifizierung.
• Smart Home: Bei einem smarten Türschloss wurde bekannt, dass Entwickler-Keys in der finalen Firmware verblieben – eingebettet über die Build-Toolchain. Ein Reverse Engineer konnte damit vollständige Kontrolle über das Gerät übernehmen.

Ein ganzheitliches Embedded-Sicherheitskonzept muss deshalb auch die Toolchain einbeziehen: von der gesicherten Entwicklungsumgebung über reproduzierbare Builds bis hin zu signierten Firmware-Images und kontrollierten Servicezugängen. Ohne diese Erweiterung bleibt Vulnerability Management unvollständig – und die Sicherheitslücke beginnt womöglich schon vor dem ersten Produktstart.

Ein Paradigmenwechsel ist nötig

Embedded Vulnerability Management ist keine technische Randdisziplin – es ist eine Sicherheitsstrategie eigener Art. Sie beginnt nicht beim Patch, sondern bei der Architektur, der Toolchain und dem Verständnis des gesamten Lebenszyklus eines Geräts. Denn anders als in der klassischen IT sind embedded-Systeme oft über Jahre – teils Jahrzehnte – im Feld und lassen sich nur mit großem Aufwand nachbessern. Die Folge: Sicherheitslücken müssen früher erkannt, genauer verstanden und gezielter bewertet werden.

Während klassische IT auf Automatisierung, Skalierbarkeit und zentralisierte Sicherheitsmechanismen setzt, braucht Embedded-Security Tiefe, Kontext und kreative Ansätze. Es geht weniger um das flächendeckende Scannen, sondern um gezielte Analysen – etwa von Firmware-Abhängigkeiten, Build-Prozessen, Hardware-Schnittstellen und Kommunikationspfaden. Jede Umgebung ist anders, jeder Mikrocontroller ein Unikat, jedes Produkt ein eigener Kosmos.

Dieser Paradigmenwechsel betrifft nicht nur Technik, sondern auch Kultur und Organisation: Sicherheitsverantwortung darf nicht an den Rand der Entwicklung gedrängt werden, sondern muss integraler Bestandteil des gesamten Embedded-Lifecycle werden – vom ersten Architekturentwurf über die Toolchain-Konfiguration bis zum Updateprozess im Feld. Ohne dieses Umdenken bleibt Sicherheitsmanagement reaktiv – und Embedded-Systeme dauerhaft angreifbar.

„Sicherheit für Embedded Systeme beginnt nicht mit dem nächsten Patch, sondern mit dem Verständnis der eigenen Software-Landschaft.“

Fazit: Sicherheit neu denken

Wer Embedded Systeme wie Firewalls wirklich absichern will, darf sich nicht auf klassische Konzepte verlassen. Die Besonderheiten dieser Systeme – von der individuellen Softwarearchitektur über proprietäre Toolchains bis hin zur fehlenden Abdeckung in öffentlichen Schwachstellendatenbanken – erfordern ein eigenes Set an Methoden, Denkweisen und Strategien. Vulnerability Management muss hier nicht nur technischer, sondern auch kontextueller gedacht werden: Was sind die realen Einsatzbedingungen? Welche Komponenten sind besonders kritisch? Welche Kommunikationspfade potenziell exponiert?

Statt Checklisten-Compliance und CVE-Abarbeitung braucht es ein risikobasiertes Sicherheitsverständnis, das Embedded-Systeme in ihrer Vielfalt ernst nimmt. Dazu gehören: vollständige SBOMs, abgesicherte Toolchains, gezielte Firmware-Analysen, langfristige Updatekonzepte – und nicht zuletzt eine enge, transparente Kommunikation mit Herstellern und Lieferanten.

Nur wer bereit ist, bestehende IT-Sicherheitsparadigmen zu hinterfragen und die Spezifika eingebetteter Systeme konsequent mitzudenken, kann das volle Potenzial eines effektiven Embedded Vulnerability Managements entfalten. Andernfalls bleibt die Sicherheitsarchitektur lückenhaft – und das Unsichtbare wird zur realen Bedrohung.

„Embedded Security ist keine Disziplin für nebenbei – sie ist Voraussetzung für Vertrauen in vernetzte Technik.“